RE: [dhcwg] Assigning DHCPv6 option codes

Bernie - thanks for writing up the proposed change to 
draft-ietf-dnsext-dhcid-rr-04.txt; that new text is exactly what I had in mind.

Are there any specific advantages to avoiding overlap in the two address 
spaces?

I will add some text reserving a range of option codes for site-specific 
options.  32768-65535 seems extreme; perhaps 57344(0xe000)-65535?

- Ralph

At 01:22 AM 1/23/2002 -0600, Bernie Volz (EUD) wrote:

>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>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>https://www1.ietf.org/mailman/listinfo/dhcwg 
>

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