Subject: [dhcwg] Review: 6rd DHCP option

From: Ole Troan <[email-masked]>
Date: Mon, 18 Jan 2010 11:19:59 +0100

DHCP experts,

we are just about to publish revision 04 of the 6rd draft in softwires. we expect that  revision 04 should be ready for last call. the DHCP option is included in the main 6rd draft and I think that means the draft must be last called in dhc wg too.

the softwires chairs has suggested we consider splitting the DHCP option into a separate draft (and 6rd has other provisioning options so it has some value also without DHCP), we as the authors feel that one spec with all an implementor needs to know published at one point in time is better.

what is the DHC WG's opinion? one factor which affects this choice is how contentious the option is. we have presented it in DHC WG before, but if you could have a second look and confirm that you are happy with this option that would be excellent.

the revision 03 version is available here:
http://tools.ietf.org/html/draft-ietf-softwire-ipv6-6rd-03

Best regards,
Ole

7.1.1.  6rd DHCPv4 Option

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  OPTION_6RD   | option-length | IPv4PrefixLen |  6rdPrefixLen |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     6rdBRIPv4Address (4 octets)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           6rdPrefix                           |
   |                   (variable, up to 16 octets)                 |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 2

   option-code         OPTION_6RD(TBD)

   option-length       the length of the DHCP option in octets (between
                       7 and 22 octets).

   IPv4PrefixLen       The number of high-order bits that are identical
                       across all CE IPv4 addresses within a given 6rd
                       domain.  This may be any value between 0 and 32.
                       Any value greater than 32 is invalid.

   6rdPrefixLen        The IPv6 Prefix length of the SP's 6rd IPv6
                       prefix in number of bits.  For the purpose of
                       bounds checking by DHCP option processing, the
                       sum of (32 - IPv4PrefixLen) + 6rdPrefixLen MUST
                       be less than or equal to 128.  The 6rd
                       implementation may further limit the sum of these
                       lengths to 64.

   option-length       the length of the DHCP option in octets (between
                       7 and 22 octets).

   IPv4PrefixLen       The number of high-order bits that are identical
                       across all CE IPv4 addresses within a given 6rd
                       domain.  This may be any value between 0 and 32.
                       Any value greater than 32 is invalid.

   6rdPrefixLen        The IPv6 Prefix length of the SP's 6rd IPv6
                       prefix in number of bits.  For the purpose of
                       bounds checking by DHCP option processing, the
                       sum of (32 - IPv4PrefixLen) + 6rdPrefixLen MUST
                       be less than or equal to 128.  The 6rd
                       implementation may further limit the sum of these
                       lengths to 64.

   6rdBRIPv4Address    The IPv4 address of the 6rd Border Relay for a
                       given 6rd domain (typically anycast).

   6rdPrefix           Variable length field containing the Service
                       Provider's 6rd IPv6 prefix.  The sender of this
                       option MUST pad with zero to at least to a full
                       octet, and MAY pad with zero to the full 16
                       octets.  Length of the 6rdPrefix field (in
                       octets) is determined solely from the "option-
                       length" field, by subtracting 6 from the "option-
                       length" value.

   When 6rd is enabled, a typical CE router will install a default route
   to the BR, a black hole route for the 6rd delegated prefix, and
   routes for any LAN side assigned and advertised prefixes.  For
   example, using a CE IPv4 address of 10.100.100.1, a BR IPv4 address
   of 10.0.0.1, an IPv4PrefixLen of 8, 2001:ABC0::/32 as the 6rdPrefix,
   and one /64 prefix assigned to a LAN side Interface, a typical CE
   Routing Information Base (RIB) will look like:

     ::/0 -> 6rd-virtual-int0 via 2001:ABC0:0:0100:: (default route)
     2001:ABC0::/32 -> 6rd-virtual-int0 (direct connect to 6rd)
     2001:ABC0:6464:0100::/56 -> Null0 (delegated prefix sink route)
     2001:ABC0:6464:0100::/64 -> Ethernet0 (LAN interface)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Jan 2010 12:06:05 -0700

Personally I think it's fine to keep it in a single draft.   My very superficial reaction to the option format is to point out that DHCP traditionally doesn't do bit-whacking in options.   So we would encourage you to use eight bits for each mask, rather than than cramming both into a single eight-bit field.   Otherwise your option would require special code in every implementation.

Aside from that, it looks fine.   Whether I'm wearing my working group participant hat or my co-chair hat, I don't see any reason to insist that you break out the DHCP portion of the draft separately.

---

From: Ole Troan <[email-masked]>
Date: Mon, 18 Jan 2010 20:17:38 +0100

Ted,

> Personally I think it's fine to keep it in a single draft.   My very superficial reaction to the option format is to point out that DHCP traditionally doesn't do bit-whacking in options.   So we wo…

both masks are supposed to be 8 bits. please point me to where we weren't clear on that so I can fix.

> Aside from that, it looks fine.   Whether I'm wearing my working group participant hat or my co-chair hat, I don't see any reason to insist that you break out the DHCP portion of the draft separate…

thanks! good to hear.

Best regards,
Ole

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 18 Jan 2010 12:50:13 -0800 (PST)

Hi Ted,
  Isn't it customary in IETF to have it separated in a draft that defines DHCP aspects of the solution?

As far as I know that is the case in many WGs.

Regards,

Behcet

----- Original Message ----
> From: Ted Lemon <[email-masked]>
> To: Ole Troan <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Mon, January 18, 2010 1:06:05 PM
> Subject: Re: [dhcwg] Review: 6rd DHCP option
> 
> Personally I think it's fine to keep it in a single draft.  My very superficial 
> reaction to the option format is to point out that DHCP traditionally doesn't do 
> bit-whacking in options.  So we would encourage you to use eight bits for each 
> mask, rather than than cramming both into a single eight-bit field.  Otherwise 
> your option would require special code in every implementation.
> 
> Aside from that, it looks fine.  Whether I'm wearing my working group 
> participant hat or my co-chair hat, I don't see any reason to insist that you 
> break out the DHCP portion of the draft separately.
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Jan 2010 12:04:20 -0700

> both masks are supposed to be 8 bits. please point me to where we weren't clear on that so I can fix.

Hm, for some reason the description led me to that conclusion, although in re-reading it I don't see any actual problem with the text.   However, some of the field descriptions (e.g., option-length) are duplicated, at least in the text you forwarded to us.