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 PROTECTED]
--------------------------------------------------------------------

Reply via email to