Re: [dhcwg] Assigning DHCPv6 option codes

[Thomas Narten <[e-mail]>]

> 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.

What the DHCID RR is doing here makes sense, but the way its doing it
seems overly complex and confusing. The DHCID RR includes a 16-bit
type value, which apparently has the same value as a DHCP option
code. I.e., the idea is that the DHCP option code identifies the kind
of data in the DHCID RR. I find this awkward/confusing for the
following reasons:

- it ties the DHCID RR format needlessly closely with DHCP. It might
  be nice, for instance  to define a DHCID RR that is based on
  "statically configured by Admin". I.e, having nothing to do with
  DHC. This would presumably require defining a DHC option  to reserve
  the value even though it would have nothing to do with DHC.

- In practice there are a very small number of DHC options that are
  relevent to the DHCID RR. 3? 4? Automatically assigning the other
  DHC options to the DHCID name space just wastes identifiers and adds
  confusion. Seem overkill to assign all 255 values from the DHCPv4
  option space. But to do the same for all 2^^16 from DHCPv6 makes no
  sense to me at all.

- It puts the numbering of DHCP v4 and v6 options in to the same name
  space, and one then has to worry about collision. This seems
  unnecessary. Why would we want to do this? DHCPv4 and DHCPv6 are
  different protocols.

- The DHCID RR type value fits very cleanly into the kind of name
  space IANA manages and assigns values to. If someone needs an ID for
  a DHCID RR, just ask IANA for one. That way, only those type values
  that actually make sense will be formally defined/used. It would
  seem a lot less confusing to me if there were only (say) 5 DHCID
  type fields assigned, and it was clear from the IANA pages what they
  were.

> 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?

This latter seems (i.e, register the values through IANA) the most
simple and straightforward. Why wouldn't we want to do this? Is there
some other benefit to the first approach that I have missed?

Thomas

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg