Subject: RE: [dhcwg] Assigning DHCPv6 option codes

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 23 Jan 2002 01:22:42 -0600

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:[email-masked]]
Sent: Tuesday, January 22, 2002 9:50 PM
To: [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Jan 2002 06:38:17 -0500

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:

>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
>From: Ralph Droms [<mailto:[email-masked]>mailto:[email-masked]]
><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg 
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jan 2002 13:37:54 +0100

I am unaware of a single example where site-specific options have ever been 
used.   This is why I think it's better not to put language about reserved 
portions of the option space in the base draft - I think we need to figure 
out what we want to do carefully.   Is it really site-specific that we want?
    What about vendor-specific?   What about user-defined?   If you want to 
reserve any space in the draft, I would just call the reserved space 
"experimental" rather than being specific about who can use it.   Reserving 
4096 codes is probably plenty, though, as you say - I don't think we need 
32k.

---

From: Richard Barr Hibbs <[email-masked]>
Date: Wed, 23 Jan 2002 14:59:18 -0800

> From: Ted Lemon
> Sent: Wednesday, January 23, 2002 04:38
>
> I am unaware of a single example where site-specific options have
> ever been used.
>
... many "thin clients" such as Wyse used those option numbers for their
configuration.  Of course, that is really "vendor-specific" and not
"site-specific" but it still is the same number range (128-254).

> This is why I think it's better not to put language about
> reserved portions of the option space in the base draft - I think
> we need to figure out what we want to do carefully.   Is it really
> site-specific that we want?
>     What about vendor-specific?   What about user-defined?  If you
> want to reserve any space in the draft, I would just call the
> reserved space "experimental" rather than being specific about who
> can use it.  Reserving 4096 codes is probably plenty, though, as you
> say - I don't think we need 32k.
>
...and I agree that "experimental" or "not defined by RFC" or some similar
title is appropriate, as well as a reasonably small space such as 4096
codes.

--Barr