Re: [dhcwg] Assigning DHCPv6 option codes
Thomas Narten <narten@us.ibm.com> Sat, 26 January 2002 13:12 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06306 for <dhcwg-archive@odin.ietf.org>; Sat, 26 Jan 2002 08:12:19 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20674 for dhcwg-archive@odin.ietf.org; Sat, 26 Jan 2002 08:12:23 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20021; Sat, 26 Jan 2002 07:56:33 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20002 for <dhcwg@optimus.ietf.org>; Sat, 26 Jan 2002 07:56:31 -0500 (EST)
Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06173 for <dhcwg@ietf.org>; Sat, 26 Jan 2002 07:56:27 -0500 (EST)
Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g0QCswE07373; Sat, 26 Jan 2002 07:54:58 -0500
Message-Id: <200201261254.g0QCswE07373@cichlid.adsl.duke.edu>
To: Ralph Droms <rdroms@cisco.com>
cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Assigning DHCPv6 option codes
In-Reply-To: Message from Ralph Droms <rdroms@cisco.com> of "Tue, 22 Jan 2002 21:49:56 EST." <4.3.2.7.2.20020122213702.03702ea0@funnel.cisco.com>
Date: Sat, 26 Jan 2002 07:54:58 -0500
From: Thomas Narten <narten@us.ibm.com>
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
> 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 dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [Dhcwg] Re: Change to 'seconds' field in DHCP mes… Ralph Droms
- RE: [Dhcwg] Re: Change to 'seconds' field in DHCP… Bernie Volz (EUD)
- [dhcwg] RE: Change to 'seconds' field in DHCP mes… Ralph Droms
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ted Lemon
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ralph Droms
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ted Lemon
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ted Lemon
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ralph Droms
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ralph Droms
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ted Lemon
- [dhcwg] Changes to remove "client-link-local-addr… Ralph Droms
- Re: [dhcwg] Changes to remove "client-link-local-… Ted Lemon
- Re: [dhcwg] Changes to remove "client-link-local-… Ralph Droms
- Re: [dhcwg] Changes to remove "client-link-local-… Ted Lemon
- Re: Re[2]: [dhcwg] Lease database storage in DHCP… Thomas Narten
- Re: [dhcwg] Assigning DHCPv6 option codes Thomas Narten
- Re: [dhcwg] dhcpv6-24: randomization delay before… Thomas Narten
- Re: [dhcwg] dhcpv6-24: randomization delay before… Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Thomas Narten
- Re: [dhcwg] dhcpv6-24: use of anycast Thomas Narten
- Re: [dhcwg] dhcpv6-24: use of anycast Thomas Narten
- Re: [dhcwg] dhcpv6-24: vendor-specific issues Thomas Narten
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Thomas Narten
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Thomas Narten
- Re: [dhcwg] DHC WG charter Thomas Narten
- Re: [dhcwg] DHC WG charter Thomas Narten
- RE: [dhcwg] DHC WG charter Ralph Droms
- Re: [dhcwg] DHC WG charter Thomas Narten
- Re: [dhcwg] DHC WG charter Ralph Droms
- Re: [dhcwg] Agenda items for IETF-59, Seoul Naiming Shen
- Re: [dhcwg] *DRAFT* minutes from WG meeting in Se… Naiming Shen
- Re: [dhcwg] dhc wg last call on "DHCP Relay Agent… Thomas Narten