Subject: DHCPv6 + prefix delegation comments.

From: Pekka Savola <[email-masked]>
Date: Sun, 17 Mar 2002 15:21:49 +0200 (EET)

Hi,

A few comments to the DHCPv6 + prefix delegation draft.

--8<--

5.1 IA Prefix option
[...]
   The lease-duration is expressed in seconds.  The prefix-length gives
   the number of bits in the prefix carried in this option.  To reduce
   the number of octets used for this option, the IPv6 prefix is
   represented in ceiling(prefix-length/8) octets.

==> I think the ceiling function should
be spelled out a bit differently for clarity.

5.2 IA Prefix Request option
[...]
   prefix-length: Prefix length for the requested global-scope prefixes.
      A value of zero (0) indicates that the requesting router will
      accept any prefix length provided by the delegating router.

==> Don't site-locals have a prefix length at all?

   num-global:    The number of global-scope prefixes requested.  A
      value of 0 indicates that the requesting router is not requesting
      any prefixes.  A value of -1 indicates that the requesting router
      does not indicate a preference.

   num-site:      The number of site-scope prefixes requested.  A value
      of 0 indicates that the requesting router is not requesting any
      prefixes.  A value of -1 indicates that the requesting router does
      not indicate a preference.

==> What does -1 actually signify: how are the fields coded?  I'm assuming
they're unsigned numbers and -1 is just a shorthand notation for 255;
if so, 255 should be used instead.

==> Would it be better to say, "A value of 255 means any number of
prefixes will be accepted"?

7.2 Delegating router behavior
[xxx]
   an ISP; dyanmic assignment from a pool of available prefixes;
   selection based on an external authority such as a RADIUS server.

==> s/dyanmic/dynamic/

8. Requesting-router-initiated prefix delegation

==> Requesting router-initiated..

8.1 Requesting router behavior
[...]
   If the requesting router subnets a delegated prefix, it must assign
   additional bits to the prefix to generate unique, longer prefixes.
   For example, if the requesting router were delegated
   DEAD:BEEF:CAFE:0::/48, it might generate DEAD:BEEF:CAFE:0001::/64 and
   DEAD:BEEF:CAFE:0002::/64 for assignment to the two links in the
   subscriber network.

==> It would probably be better use prefixes from under 3FFE:FFFF.

8.2 Delegating Router Behavior
[...]
   Upon the receipt of a valid Decline message, the delegating router
   examines the IA options and the IA Prefix options for validity.  If
   the IAs in the message are in a binding for the requesting router and
   the prefixes in the IAs have been assigned by the delegating router
   to those IA, the delegating router deletes the prefix(es) from the
   IAs.  The delegating router MAY choose to make a notification that
   prefixes were declined.

==> what kind of notification?

9. Delegating Router-initiated prefix delegation reconfiguration

==> s/Delegating //

9.1 Delegating Router behavior

[...]

9.2 Requesting Router behvaior

[...]

==> should operations which are recommended when renumbering like this
be discussed (e.g. immediate sending of new router advertisements in the
subnet)?

11. Security Considerations

[...]

   An intruder requesting router may be able to mount a denial of
   service attack by repeated requests for delegated prefixes that
   exhaust the delegating router's available prefixes.

   To guard against attacks through prefix delegation, requesting
   routers and delegating routers SHOULD use DHCP authentication as
   described in section "Authentication of DHCP messages" in the DHCP
   specification.

==> this gives only partial protection to the intruder problem above: or
is it ok that theoretically authentic clients can exhaust the prefix pool
or such too?

==> perhaps accidental delegation of site-prefixes outside of the
site could be a problem here too

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Alberto Escudero-Pascual <[email-masked]>
Date: Sun, 17 Mar 2002 15:23:07 +0100 (CET)

(MUST, SHOULD) the (stateful) addresses provided by a DHCPv6 have the "u"
bit to 0 as manual configuration? If i buy a 1000 Ethernet cards and keep
them in a box under the table and set the u bit to 1 and provide those
EUI-64 to my users?

/aep

---

From: Robert Elz <[email-masked]>
Date: Sun, 17 Mar 2002 22:24:49 +0700

Date:        Sun, 17 Mar 2002 15:23:07 +0100 (CET)
    From:        Alberto Escudero-Pascual <[email-masked]>
    Message-ID:  <[email-masked]>

  | (MUST, SHOULD) the (stateful) addresses provided by a DHCPv6 have the "u"
  | bit to 0 as manual configuration?

They MAY  (SHOULD is perhaps reasonable as a default setting).

  | If i buy a 1000 Ethernet cards and keep
  | them in a box under the table and set the u bit to 1 and provide those
  | EUI-64 to my users?

It would be cheaper to buy an OUI from IEEE - you get lots more EUI's
for a much lower price...   I see no reason why you couldn't do that.

But IPv6 addreses are delegated by a registry, or by someone delegated
a bigger block than you need, making sub-delegations.  They give you a
/n.   What you do with the 128-n bits inside that delegation is entirely
your business, and you don't have to take the slightest bit of notice of
anything anyone else claims that you should do.

Of course, you should be aware of the consequences of your decisions,
but whether you are or not, it is your address space for as long as the
assignment of the prefix to you remains valiue, you decide how it gets
apportioned.

kre

---

From: Alberto Escudero-Pascual <[email-masked]>
Date: Sun, 17 Mar 2002 17:04:10 +0100 (CET)

Robert,

Is this your opinion or is stated somewhere?

-- 
--------------------------------------------------------------------------
That you are not paranoid, it doesn't mean that they are not watching you!
http://www.it.kth.se/~aep

---

From: Robert Elz <[email-masked]>
Date: Mon, 18 Mar 2002 00:01:47 +0700

Date:        Sun, 17 Mar 2002 17:04:10 +0100 (CET)
    From:        Alberto Escudero-Pascual <[email-masked]>
    Message-ID:  <[email-masked]>

  | Is this your opinion or is stated somewhere?

It is my opinion, and it should be stated somewhere...  It is also
a fact of life, there's nothing anyone can possibly do to control the
way you use the addresses in a prefix delegated to you.  It doesn't
matter what the standards say, you still get to do what you like.

kre

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 17 Mar 2002 09:07:07 -0800

Robert Elz wrote:
>     Message-ID:
> <[email-masked]>
>

Yes this is a fact of life for the end user of the space, but the
documents are targeted at various vendors supplying that end user. While
the end user can choose to set the bits any way they like, their vendors
are expected to follow a consistent set of rules so the end user knows
what they are getting.

Tony

---

From: Robert Elz <[email-masked]>
Date: Mon, 18 Mar 2002 00:38:29 +0700

Date:        Sun, 17 Mar 2002 09:07:07 -0800
    From:        "Tony Hain" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Yes this is a fact of life for the end user of the space, but the
  | documents are targeted at various vendors supplying that end user. While
  | the end user can choose to set the bits any way they like, their vendors
  | are expected to follow a consistent set of rules so the end user knows
  | what they are getting.

Wonderful.   That's the right approach - can we all agree on that?

First, that would answer Alberto's question the same way I did - he
can config his DHCP server to return the u (& g) bits in any state he
likes.

Second, it will mean that the gibberish in 2373bis about u==1 implying
a globally unique IID can go in the trash where it belongs, and we
can keep the u bit the same as it was in 2373.   That is, we tell the
implementors what they're supposed to do, but not go on to ascribe some
unrealisable meaning to the value of the bit if seen in an address.

kre

---

From: Steve Deering <[email-masked]>
Date: Mon, 18 Mar 2002 13:02:49 -0800

At 3:23 PM +0100 3/17/02, Alberto Escudero-Pascual wrote:
>bit to 0 as manual configuration?

If the address provided by the DHCP server contains the modified EUI-64
value generated from an IEEE 802 or EUI-64 address belonging to the
requesting node, it should have the "u" bit set to one; otherwise,
it should be set to zero.

Steve

---

From: Ralph Droms <[email-masked]>
Date: Mon, 18 Mar 2002 17:21:06 -0500

Text specifying the appropriate behavior (as Steve describes) on the part 
of DHCP servers will be added to the next rev of the DHCPv6 spec...

- Ralph