headers
a r pradeep | 24 May 20:40
Picon

Question on DHCPv6 / RFC3315

Hello All
 
Had a question on RFC 3315, Section 18.1.2 Creation and Transmission of Confirm messages
 
When a client changes its configuration from dhcpv6 enabled to static, is this considered as moving to new link and is the client required to send out a Confirm message ?
 
Thanks
pradeep 

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
Permalink | Reply | 1 comment |
headers
Gaurav Halwasia (ghalwasi | 24 May 17:03
Picon
Favicon

Comments on draft-troan-dhc-dhcpv6-stateful-issues-00

I have read this informational draft and I have couple of comments so far.

 

1.)Section 3.1

   Replace Section 17.1.3: (existing errata)

 

 

      The client MUST ignore any Advertise message that includes a Status

      Code option containing the value NoAddrsAvail, with the exception

      that the client MAY display the associated status message to the

      user.

 

   With:

 

 

      The client MUST ignore any IAs in an Advertise message that

      includes a Status Code option containing the value NoAddrsAvail,

      with the exception that the client MAY display the associated

      status message to the user. An Advertise message without any IA

      options MUST be ignored.

 

Is this only applicable to IA_NA.? I guess in case client sends SOLICIT with both IA_NA and IA_PD. Then in that case I guess we should mention “NoPrefixAvail” as well.

 

2.) Section 3.6

   Proposed solution: the client should keep a single session with the

   server.  The client should continue with the IA_ options received,

   while continuing to request the other IA options in subsequent

   messages to the server.  That means continue to include the empty

   unanswered IAs in subsequent Renew and Rebind messages.

 

I believe, it is possible that a particular server is willing to offer only a subset of IA_’s which has been requested. In that case, what’s the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted.

 

 

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
Permalink | Reply | 5 comments |
headers
internet-drafts | 23 May 03:01
Picon
Favicon

I-D Action: draft-ietf-dhc-host-gen-id-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Dynamic Host Configuration Working Group of the IETF.

	Title           : Prefix Assignment in DHCPv6
	Author(s)       : Sheng Jiang
                          Frank Xia
                          Behcet Sarikaya
	Filename        : draft-ietf-dhc-host-gen-id-02.txt
	Pages           : 10
	Date            : 2012-05-22

   This document introduce a procedure for configuring hosts' IPv6
   address which the prefix is assigned from a DHCPv6 server through
   DHCPv6 protocol while the interface identifiers are independently
   generated by the hosts.  The method is applicable to
   Cryptographically Generated Addresses (CGA), and other IPv6 addresses
   with host-generated interface identifiers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-host-gen-id-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-host-gen-id-02.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-host-gen-id/
Permalink | Reply | 0 comments |
headers
Fernando Gont | 19 May 01:33
Picon
Favicon

New IETF I-D: draft-gont-opsec-dhcpv6-shield-00.txt

Folks,

We have published a new IETF I-D entitled: "DHCPv6-Shield: Protecting
Against Rogue DHCPv6 Servers". It is analogous to the RA-Guard (RFC
6105) mechanism currently employed for mitigating RA-based attacks.

The I-D is available at:
<http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt>

I'm not sure in which wg I'd be pursuing this effort (v6ops, opsec, or
dhcwg). If there's interest in this wg, it could be done here. However,
in any case discussion of this document within dhcwg would be welcome.

Thanks!

Best regards,
Fernando

-------- Original Message --------
Subject: New Version Notification for draft-gont-opsec-dhcpv6-shield-00.txt
Date: Thu, 17 May 2012 22:26:10 -0700
From: internet-drafts <at> ietf.org
To: fgont <at> si6networks.com

A new version of I-D, draft-gont-opsec-dhcpv6-shield-00.txt has been
successfully submitted by Fernando Gont and posted to the IETF repository.

Filename:	 draft-gont-opsec-dhcpv6-shield
Revision:	 00
Title:		 DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers
Creation date:	 2012-05-18
WG ID:		 Individual Submission
Number of pages: 12

Abstract:
   This document specifies a mechanism for protecting hosts connected to
   a broadcast network against rogue DHCPv6 servers.  The aforementioned
   mechanism is based on DHCPv6 packet-filtering at the layer-2 device
   on which the packets are received.  The aforementioned mechanism has
   been widely deployed in IPv4 networks ("DHCP snooping"), and hence it
   is desirable that similar functionality be provided for IPv6
   networks.

The IETF Secretariat
Permalink | Reply | 0 comments |
headers
rfc-editor | 16 May 00:17
Favicon

RFC 6603 on Prefix Exclude Option for DHCPv6-based Prefix Delegation


A new Request for Comments is now available in online RFC libraries.

        
        RFC 6603

        Title:      Prefix Exclude Option for DHCPv6-based 
                    Prefix Delegation 
        Author:     J. Korhonen, Ed.,
                    T. Savolainen, S. Krishnan,
                    O. Troan
        Status:     Standards Track
        Stream:     IETF
        Date:       May 2012
        Mailbox:    jouni.nospam <at> gmail.com, 
                    teemu.savolainen <at> nokia.com, 
                    suresh.krishnan <at> ericsson.com,
                    ot <at> cisco.com
        Pages:      10
        Characters: 19485
        Updates:    RFC3633

        I-D Tag:    draft-ietf-dhc-pd-exclude-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6603.txt

This specification defines an optional mechanism to allow exclusion
of one specific prefix from a delegated prefix set when using DHCPv6-based
prefix delegation.  The new mechanism updates RFC 3633.  [STANDARDS-TRACK]

This document is a product of the Dynamic Host Configuration Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor <at> rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC
Permalink | Reply | 0 comments |
headers
The IESG | 11 May 21:30
Picon
Favicon

Document Action: 'Description of Cisco Systems' Subnet Allocation Option for DHCPv4' to Informational RFC (draft-ietf-dhc-subnet-alloc-13.txt)

The IESG has approved the following document:
- 'Description of Cisco Systems' Subnet Allocation Option for DHCPv4'
  (draft-ietf-dhc-subnet-alloc-13.txt) as Informational RFC

This document is the product of the Dynamic Host Configuration Working
Group.

The IESG contact persons are Ralph Droms and Brian Haberman.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-dhc-subnet-alloc/

Technical Summary

  This document defines a new DHCP option which is passed between the
  DHCP Client and the DHCP Server to request dynamic allocation of a
  subnet, give specifications of subnet(s) allocated, and report usage
  statistics.  This memo documents the current usage of the option in
  agreement with [RFC3942], which declares that any pre-existing usages
  of option numbers in the range 128 - 223 should be documented and the
  working group will try to officially assign those numbers to those
  options.

Working Group Summary

   There was nothing controversial about this document.  There was
   consensus in the working group to include the following text in the
   document:

   At the time when RFC 3942 came out, Cisco Systems had already
   deployed products which made use of option number 220.  In RFC 3942,
   section 4, procedure 2, it is clearly stated, "Vendors that currently
   use one or more of the reclassified options have 6 months following
   this RFC's publication date to notify the DHC WG and IANA that they
   are using particular options numbers and agree to document that usage
   in an RFC."  This procedure was immediately followed.  It further
   states, "Vendors have 18 months from this RFC's publication date to
   start the documentation process by submitting an Internet-Draft."
   This procedure was also followed.  For the purposes of clarity, it
   was thought important for the submitted draft to go through Working
   Group review.  This process took quite a long time, with the document
   moving to "Last Call" multiple times.  Since Cisco Systems already
   had deployed products, and thus wanted to avoid anything except for
   minor changes to the existing option definition, it was deemed best
   for the document to be Informational instead of Standard Track.  This
   decision was made in cooperation with the Working Group and Work
   Group Chair at the time.

Document Quality

   There is at least one existing implementation of this specification.  It is not
   known if additional DHCP server implementations have or will implement this
   draft.  Existing implementations are believed to be available today.

   Beyond what was performed with key members of the dhc WG no special
   reviews were performed or required.

Personnel

   The document shepherd is John Brzozowski
   <John_Brzozowski <at> Cable.Comcast.com>.  The responsible
  Area Director is Ralph Droms <rdroms.ietf <at> gmail.com>.
Permalink | Reply | 0 comments |
headers
Di Ma | 8 May 05:48
Picon

Fw: WGLC: draft-ietf-dhc-secure-dhcpv6

Considering DHCPv6 is somehow of big importance in the era of IPv6, CGA, as a well-fashioned IPv6 address, is going to protect DHCPv6 away from various attacks. Some efforts on the standardization of related techniques should be made. 
I am in favor of advancing this document.
 
Di Ma

CNNIC Advanced Research Department
___________________________________________________

China Internet Network Information Center
Tel: (8610)-58813216
Https://www.cnnic.cn

Add: 4, South 4th Street, Zhongguancun
Haidian District, Beijing
P.R.China 100190

POB: Beijing 349, Branch 6
____________________________________________________

 
From: Ted Lemon
Date: 2012-05-07 12:37
To: DHC WG
Subject: [dhcwg] WGLC: draft-ietf-dhc-secure-dhcpv6
In the Paris meeting a show of hands indicated that the group favored bringing this document to last call.   So this is the last call for this document.   If you are in favor of advancing it, and have read it, please say so.   If you think it needs work, please send text or suggestions.   If you don't think it should advance, please say so.
 
We will determine consensus on May 21.
 
_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
Permalink | Reply | 1 comment |
headers
Ted Lemon | 7 May 06:37
Favicon

WGLC: draft-ietf-dhc-secure-dhcpv6

In the Paris meeting a show of hands indicated that the group favored bringing this document to last call.   So
this is the last call for this document.   If you are in favor of advancing it, and have read it, please say so.  
If you think it needs work, please send text or suggestions.   If you don't think it should advance, please
say so.

We will determine consensus on May 21.
Permalink | Reply | 2 comments |
headers
internet-drafts | 7 May 05:28
Picon
Favicon

I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Dynamic Host Configuration Working Group of the IETF.

	Title           : Issues with multiple stateful DHCPv6 options
	Author(s)       : Ole Troan
                          Bernie Volz
	Filename        : draft-ietf-dhc-dhcpv6-stateful-issues-00.txt
	Pages           : 8
	Date            : 2012-05-06

   Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written
   with the expectation that additional stateful DHCPv6 options would be
   developed.  IPv6 Prefix Options for Dynamic Host Configuration
   Protocol (DHCP) version 6 shoe-horned the new options for Prefix
   Delegation into DHCPv6.  Implementation experience of the CPE model
   described in has shown multiple issues with the DHCPv6 protocol in
   supporting multiple stateful options.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateful-issues-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateful-issues-00.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/
Permalink | Reply | 1 comment |
headers
Shankari Vaidyalingam | 27 Apr 14:59
Picon

Re: dhcwg Digest, Vol 96, Issue 38

Hi,

Can you let me know where can I get this draft - draft-ietf-dhc-client-id-02.

Regards,
Shankari.V

On Fri, Apr 27, 2012 at 12:30 AM, <dhcwg-request <at> ietf.org> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/dhcwg

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send dhcwg mailing list submissions to
       dhcwg <at> ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
       https://www.ietf.org/mailman/listinfo/dhcwg
or, via email, send a message with subject or body 'help' to
       dhcwg-request <at> ietf.org

You can reach the person managing the list at
       dhcwg-owner <at> ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcwg digest..."


Today's Topics:

  1. Re: WGLC: draft-ietf-dhc-client-id-02 (Richard Johnson)
  2. Re: Call for adoption:    draft-yeh-dhc-dhcpv6-authorization-opt
     (Sheng Jiang)
  3. Re: Call  for     adoption:       draft-yeh-dhc-dhcpv6-authorization-opt
     (Leaf yeh)
  4. Re: Call for      adoption:       draft-yeh-dhc-dhcpv6-authorization-opt
     (Tina TSOU)


----------------------------------------------------------------------

Message: 1
Date: Wed, 25 Apr 2012 12:59:39 -0700
From: Richard Johnson <raj <at> cisco.com>
To: Ted Lemon <Ted.Lemon <at> nominum.com>
Cc: DHC WG <dhcwg <at> ietf.org>
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02
Message-ID: <0579F6EF-7CBE-456C-AFE4-756023B0D406 <at> cisco.com>
Content-Type: text/plain; charset=windows-1252

I definitely support this draft, although I think the current description of the problem to be solved could use quite a lot of work to make it more clear.  Your own description is quite clear, but the document is not really.

/raj


On Apr 14, 2012, at 5:54 AM, Ted Lemon wrote:

> This document corrects a bug in RFC2131 that forbids the DHCP server from returning a DHCP client identifier.   The lack of a DHCP client identifier creates a problem in two cases: where the underlying transport has no link-layer address, and where two clients are running on the same host, supplying different client identifiers so as to present different network identities.   In both of these cases, insufficient information is returned from the DHCP server to clearly identify the client that is the intended recipient of the message.   The only way to fix this is to _require_ the DHCP server to return the client identifier if it receives it.   This is what the proposed document does.
>
> We checked for consensus in the meeting, and four people were in favor of advancing the draft; nobody was against.
>
> I think this is actually pretty important work?it's a lingering bug in the spec which I think will come back to bite us more and more as we start getting deeper into the dual-stack transition.   So if you haven't read the document, please do.
>
> If you support advancing it, please signify by replying to this message and saying that you support it. If you think it's a bad idea, please signify by replying to this message and explaining why.   If you have comments or changes to propose, please send them along, and also signify whether you are in favor of advancement with the change, without the change, or oppose advancement.
>
> We will determine consensus on April 27, based solely on responses on the mailing list, so please do respond.
>
> Thanks!
>
> _______________________________________________
> dhcwg mailing list
> dhcwg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg



------------------------------

Message: 2
Date: Wed, 25 Apr 2012 23:42:38 +0000
From: Sheng Jiang <jiangsheng <at> huawei.com>
To: Ted Lemon <Ted.Lemon <at> nominum.com>, DHC WG <dhcwg <at> ietf.org>
Subject: Re: [dhcwg] Call for adoption:
       draft-yeh-dhc-dhcpv6-authorization-opt
Message-ID:
       <5D36713D8A4E7348A7E10DF7437A4B921E48EDCC <at> SZXEML506-MBS.china.huawei.com>

Content-Type: text/plain; charset="us-ascii"

Support adopt this draft.

Sheng

> -----Original Message-----
> From: dhcwg-bounces <at> ietf.org [mailto:dhcwg-bounces <at> ietf.org] On Behalf
> Of Ted Lemon
> Sent: Wednesday, April 25, 2012 7:38 PM
> To: DHC WG
> Subject: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-
> opt
>
> One of the authors of this draft has requested a formal call for
> adoption.   There was substantial support for the work in the DHC
> working group meeting in Paris, and no objections.   The idea is to
> have a RADIUS option for DHCPv6, similar to the functionality present
> in DHCPv4.
>
> If you favor or oppose taking this on as working group work, please
> signify by replying to this message.   If you have comments or concerns,
> please raise them now.
>
> We will make a determination of consensus on May 9.
>
> _______________________________________________
> dhcwg mailing list
> dhcwg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg


------------------------------

Message: 3
Date: Thu, 26 Apr 2012 01:36:56 +0000
From: Leaf yeh <leaf.y.yeh <at> huawei.com>
To: Ted Lemon <Ted.Lemon <at> nominum.com>, Tomek Mrugalski
       <tomasz.mrugalski <at> gmail.com>
Cc: "<dhcwg <at> ietf.org>" <dhcwg <at> ietf.org>
Subject: Re: [dhcwg] Call       for     adoption:
       draft-yeh-dhc-dhcpv6-authorization-opt
Message-ID:
       <E1CE3E6E6D4E1C438B0ADC9FFFA345EA262CB99C <at> SZXEML510-MBS.china.huawei.com>

Content-Type: text/plain; charset="utf-8"

Tomek - Once adopted, it seems reasonable to call this draft
draft-ietf-dhc-dhcpv6-radius-option, rather than -authorization-.
Ted - Yes, I agree completely.   Leaf, is that okay with you?

FYI again, the context including the title of draft & the name of the new option  has been updated to the 'RADIUS option' in the draft-yeh-01.

Yes, I am OK with this suggestion.


Best Regards,
Leaf


----------------------------------------------------------------------------------------------------------------
From: dhcwg-bounces <at> ietf.org [mailto:dhcwg-bounces <at> ietf.org] On Behalf Of Ted Lemon
Sent: Wednesday, April 25, 2012 9:53 PM
To: Tomek Mrugalski
Cc: <dhcwg <at> ietf.org>
Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt

On Apr 25, 2012, at 9:37 AM, Tomek Mrugalski <tomasz.mrugalski <at> gmail.com>
?wrote:
Once adopted, it seems reasonable to call this draft
draft-ietf-dhc-dhcpv6-radius-option, rather than -authorization-.

Yes, I agree completely. ? Leaf, is that okay with you?

Tomek, are you for or against adoption? ? (Or don't have an opinion?)


------------------------------

Message: 4
Date: Thu, 26 Apr 2012 02:59:50 +0000
From: Tina TSOU <Tina.Tsou.Zouting <at> huawei.com>
To: Sheng Jiang <jiangsheng <at> huawei.com>
Cc: DHC WG <dhcwg <at> ietf.org>, Ted Lemon <Ted.Lemon <at> nominum.com>
Subject: Re: [dhcwg] Call for   adoption:
       draft-yeh-dhc-dhcpv6-authorization-opt
Message-ID: <3CF7C125-3B76-464A-8C58-D7BDCE72B996 <at> huawei.com>
Content-Type: text/plain; charset="us-ascii"

I support adoption of this draft.

Sent from my iPad

On Apr 25, 2012, at 5:00 PM, "Sheng Jiang" <jiangsheng <at> huawei.com> wrote:

> Support adopt this draft.
>
> Sheng
>
>> -----Original Message-----
>> From: dhcwg-bounces <at> ietf.org [mailto:dhcwg-bounces <at> ietf.org] On Behalf
>> Of Ted Lemon
>> Sent: Wednesday, April 25, 2012 7:38 PM
>> To: DHC WG
>> Subject: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-
>> opt
>>
>> One of the authors of this draft has requested a formal call for
>> adoption.   There was substantial support for the work in the DHC
>> working group meeting in Paris, and no objections.   The idea is to
>> have a RADIUS option for DHCPv6, similar to the functionality present
>> in DHCPv4.
>>
>> If you favor or oppose taking this on as working group work, please
>> signify by replying to this message.   If you have comments or concerns,
>> please raise them now.
>>
>> We will make a determination of consensus on May 9.
>>
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> dhcwg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg


------------------------------

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


End of dhcwg Digest, Vol 96, Issue 38
*************************************

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
Permalink | Reply | 1 comment |
headers
RFC Errata System | 27 Apr 12:33
Favicon

[Technical Errata Reported] RFC3942 (3204)


The following errata report has been submitted for RFC3942,
"Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3942&eid=3204

--------------------------------------
Type: Technical
Reported by: Alfred Hoenes <ah <at> TR-Sys.de>

Section: 6. IANA Cons

Original Text
-------------
   4. change the listing of any options listed as "Tentatively-Assigned"
|     to "Unavailable" 18 months from this RFC's publication date and
      periodically thereafter as long as there is an option listed as
      "Tentatively-Assigned", if no un-expired Internet-Draft exists
      documenting the usage.

Corrected Text
--------------
   4. change the listing of any options listed as "Tentatively-Assigned"
|     to "Unassigned" 18 months from this RFC's publication date and
      periodically thereafter as long as there is an option listed as
      "Tentatively-Assigned", if no un-expired Internet-Draft exists
      documenting the usage.

Notes
-----
The body of the RFC clearly states in Section 4, bullet 4.
that the IANA action desired by the RFC is to make these code
points available for assignment after the 18-month grace period.

This Errata Note is tagged as "Technical" because the inconsistency
between the IANA Considerations and the body of the RFC apparently
has caused IANA to not follow the body and spirit of the RFC -- at
the time this Errata Note is being filed, there are several entries
left in the BOOTP+DHCP parameters option codes registry that should
have been cleaned up and made available for assignment since the
publication of RFC 3942 in November 2004.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC3942 (draft-ietf-dhc-reclassify-options-01)
--------------------------------------
Title               : Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options
Publication Date    : November 2004
Author(s)           : B. Volz
Category            : PROPOSED STANDARD
Source              : Dynamic Host Configuration
Area                : Internet
Stream              : IETF
Verifying Party     : IESG
Permalink | Reply | 0 comments |

Gmane