[dhcwg] Assigning DHCPv6 option codes

Ralph Droms <rdroms@cisco.com> Wed, 23 January 2002 03:01 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 WAA19130 for <dhcwg-archive@odin.ietf.org>; Tue, 22 Jan 2002 22:01:56 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA25824 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 22:01:59 -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 VAA25081; Tue, 22 Jan 2002 21:50:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25056 for <dhcwg@ns.ietf.org>; Tue, 22 Jan 2002 21:50:02 -0500 (EST)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18821 for <dhcwg@ietf.org>; Tue, 22 Jan 2002 21:49:58 -0500 (EST)
Received: from rdroms-w2k.cisco.com (rtp-vpn2-594.cisco.com [10.82.242.82]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA07144 for <dhcwg@ietf.org>; Tue, 22 Jan 2002 21:49:30 -0500 (EST)
Message-Id: <4.3.2.7.2.20020122213702.03702ea0@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 22 Jan 2002 21:49:56 -0500
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: [dhcwg] Assigning DHCPv6 option codes
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.  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