RE: [dhcwg] Assigning DHCPv6 option codes

Richard Barr Hibbs <> Wed, 23 January 2002 23:03 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id SAA28792 for <>; Wed, 23 Jan 2002 18:03:12 -0500 (EST)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id SAA22412 for; Wed, 23 Jan 2002 18:03:14 -0500 (EST)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id RAA21806; Wed, 23 Jan 2002 17:51:47 -0500 (EST)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id RAA21782 for <>; Wed, 23 Jan 2002 17:51:45 -0500 (EST)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id RAA28540 for <>; Wed, 23 Jan 2002 17:51:42 -0500 (EST)
Received: from BarrH63p601 ([]) by (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <> for; Wed, 23 Jan 2002 14:51:44 -0800 (PST)
Date: Wed, 23 Jan 2002 14:50:49 -0800
From: Richard Barr Hibbs <>
Subject: RE: [dhcwg] Assigning DHCPv6 option codes
In-reply-to: <>
To: Dhcwg <>
Message-id: <>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: Ralph Droms
> Sent: Wednesday, January 23, 2002 09:43
> There's a little more to it than just the scarcity of option codes in
> DHCPv4.  Just before we instituted the new policy of assigning an option
> code after acceptance to PS, there were several (10-15 or so) that were
> proposed, had option codes assigned, and then were never followed up
> on.  Those option codes are now in limbo.
> Even though we have plenty of options code in DHCPv6, I don't
> think it's a good idea to have option codes in an uncertain state -
> assigned to options that never went to PS.  Perhaps we need some sort
> of sunsetting to establish a process for marking option codes as
> "unused - do not reassign"...
> may recall that I proposed exactly that -- the sunsetting of option
codes -- at least twice in working group meetings, but Thomas Narten argued
convincingly that the IETF has never been very good at enforcing adherence
to updated RFCs, and may never be able to do anything but move an RFC to
Historic status, which doesn't provide any practical, timely relief for the
option exhaustion problem.

I'd love for most options to be subject either to a sunset clause, but I
don't know how effective it would be -- certainly one side effect would be
to keep the DHC working group in existence for a long, long time.


dhcwg mailing list