RE: [dhcwg] Assigning DHCPv6 option codes

Personally, I've always thought it best to have the two option spaces avoid overlap.

But, the other proposal is OK by me as well. I assume you are referring to redefining the <type> could field from draft-ietf-dnsext-dhcid-rr-04.txt:

From section 3.4:

   The type code and the
   identifier are related as specified in Section 3.3: the type code
   describes the source of the identifier.

       type code           identifier

       0x0000              htype,hlen,chaddr from the client's DHCPREQUEST

       0x0001-             'data' portion of a DHCP option from the
       0xfffe              client's DHCPREQUEST

       0xffff              RESERVED

Would be changed to something like:

   The type code and the
   identifier are related as specified in Section 3.3: the type code
   describes the source of the identifier.

       type code           identifier

       0x0000              htype,hlen,chaddr from the client's DHCPREQUEST (DHCPv4)

       0x0001		   client identifier (DHCPv4)

       0x0002              DUID (DHCPv6)

       0x0003-             Available for future type codes, type code space is
       0xfffe               to be managed by IANA

       0xffff              RESERVED

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, January 22, 2002 9:50 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Assigning DHCPv6 option codes

There is a potential collision problem between DHCPv4 and DHCPv6 option 
codes.  The DHCID RR uses the option code to identify the source of the 
information stored in the RR.  If DHCPv4 and DHCPv6 use overlapping option 
codes that identify different options, the source of the information in the 
RR will be ambiguous.  One proposed solution is to start numbering DHCPv6 
options at 256, to avoid collisions with DHCPv4 option codes.  Another 
solution is to assign new codes for the identification field in the DHCID 
RR, which then identify DHCPv4 or DHCPv6 options - or, perhaps other 
sources of information not encoded in a DHCP option.  For example, DHCID RR 
code 1 might identify the contents of the RR as a DHCPv4 client identifier, 
while DHCID RR code 2 might indicate a DHCPv6 DUID.  Comments on the two 
solutions?

- Ralph

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg