Skip to main content

Prefix Exclude Option for DHCPv6-based Prefix Delegation
RFC 6603

Revision differences

Document history

Date Rev. By Action
2020-01-21
04 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-12-31
04 Jean Mahoney Closed request for Last Call review by GENART with state 'No Response'
2015-10-14
04 (System) Notify list changed from dhc-chairs@ietf.org, draft-ietf-dhc-pd-exclude@ietf.org to (None)
2012-05-16
04 (System) RFC published
2012-02-29
04 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2012-02-29
04 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2012-02-28
04 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-02-22
04 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2012-02-22
04 (System) IANA Action state changed to In Progress
2012-02-21
04 Amy Vezza IESG state changed to Approved-announcement sent
2012-02-21
04 Amy Vezza IESG has approved the document
2012-02-21
04 Amy Vezza Closed "Approve" ballot
2012-02-21
04 Amy Vezza Approval announcement text regenerated
2012-02-21
04 Amy Vezza Ballot writeup text changed
2012-02-16
04 Cindy Morgan Removed from agenda for telechat
2012-02-16
04 Cindy Morgan State changed to Approved-announcement to be sent from IESG Evaluation.
2012-02-16
04 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2012-02-16
04 Jari Arkko [Ballot comment]
Thanks for writing this draft, it is very important addition to DHCPv6.
2012-02-16
04 Jari Arkko
[Ballot comment]
Thanks for writing this draft, it is very important addition to DHCPv6.

Isn't this code wrong:

    uint16_t d = (c/8)+1;  // …
[Ballot comment]
Thanks for writing this draft, it is very important addition to DHCPv6.

Isn't this code wrong:

    uint16_t d = (c/8)+1;  // the IPv6_subnet_ID_length in octets

as you'd get d = 2 for c = 8, for instance. You'd want something like:

    uint8_t d = i/8 + (i%8>0);

Or am I missing something obvious?
2012-02-16
04 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded
2012-02-15
04 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Magnus Nystrom.
2012-02-15
04 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2012-02-15
04 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2012-02-14
04 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2012-02-14
04 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2012-02-14
04 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2012-02-14
04 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2012-02-14
04 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2012-02-13
04 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2012-02-13
04 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2012-02-13
04 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded
2012-02-09
04 Ralph Droms State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2012-02-09
04 Ralph Droms Placed on agenda for telechat - 2012-02-16
2012-02-09
04 Ralph Droms [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms
2012-02-09
04 Ralph Droms Ballot has been issued
2012-02-09
04 Ralph Droms Created "Approve" ballot
2012-02-07
04 Amanda Baber
IANA understands that, upon approval of this document, there is a single IANA action which needs to be completed.

In the DHCP Option Codes in …
IANA understands that, upon approval of this document, there is a single IANA action which needs to be completed.

In the DHCP Option Codes in the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry located at:

www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml

a new option code is to be registered as follows:

Value: [ tbd ]
Description: OPTION_PD_EXCLUDE
Reference: [ RFC-to-be ]
2012-02-07
04 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2012-01-27
04 Samuel Weiler Request for Last Call review by SECDIR is assigned to Magnus Nystrom
2012-01-27
04 Samuel Weiler Request for Last Call review by SECDIR is assigned to Magnus Nystrom
2012-01-26
04 Jean Mahoney Request for Last Call review by GENART is assigned to Pete McCann
2012-01-26
04 Jean Mahoney Request for Last Call review by GENART is assigned to Pete McCann
2012-01-24
04 Amy Vezza Last call sent
2012-01-24
04 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <dhcwg@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-dhc-pd-exclude-04.txt> (Prefix Exclude Option for DHCPv6-based Prefix Delegation) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Prefix Exclude Option for DHCPv6-based Prefix Delegation'
  <draft-ietf-dhc-pd-exclude-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-pd-exclude/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-pd-exclude/

If approved, this document will update RFC 3633.

No IPR declarations have been submitted directly on this I-D.


2012-01-24
04 Ralph Droms Last Call was requested
2012-01-24
04 Ralph Droms State changed to Last Call Requested from Last Call Requested.
2012-01-24
04 Ralph Droms Last Call text changed
2012-01-24
04 Ralph Droms Last Call was requested
2012-01-24
04 Ralph Droms State changed to Last Call Requested from AD Evaluation.
2012-01-24
04 Ralph Droms Last Call text changed
2012-01-24
04 (System) Ballot writeup text was added
2012-01-24
04 (System) Last call text was added
2012-01-24
04 (System) Ballot approval text was added
2012-01-24
04 Ralph Droms Ballot writeup text changed
2012-01-24
04 Ralph Droms Ballot writeup text changed
2012-01-23
04 Ralph Droms State changed to AD Evaluation from Publication Requested.
2011-12-20
04 Cindy Morgan
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
  …
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?
       
I (Ted Lemon) am the document shepherd. I have reviewed the document,
and believe it is ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that

       
The document has had thorough review from several members of the working
group, and is quite mature. The described solution has been also
adopted, and referenced, by 3GPP in Release-10 version of 23.401”
Technical Specification Group Services and System Aspects; General
Packet Radio Service (GPRS) enhancements for Evolved Universal
Terrestrial Radio Access Network (E-UTRAN) access (Release 10)”, latest
(10.5.0) being here: http://www.3gpp.org/ftp/Specs/archive/23_series/
23.401/23401-a50.zip

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?
       
I am quite happy with the degree of review that this document has had,
although of course more review is always welcomed.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.
I think this document is definitely needed, and is important work.  I
was initially uncomfortable with the way the algorithm for computing the
IPv6 subnet ID field was done.  However, I walked through the algorithm
with pencil and paper, and after doing so had a clear understanding of
how it works, so I think actually it's a pretty good way to specify it. 
There was debate in the working group as to whether to make the
representation compact, as is done in the current document, or to
simplify the algorithm at the expense of using extra space.  The
consensus of the working group was to be space-efficient, and I think
this will produce an acceptable outcome. I don't think it's possible to
implement this without a clear understanding of the algorithm: a half-
assed attempt at implementation would immediately and obviously fail to
interoperate.  No IPR disclosures have been made, and I am not aware of
any that are pending.  Teemu also says there are no IPR claims.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 
       
There is substantial consensus in the working group to publish the
document.  There was some debate early on as to whether it was
necessary, but ultimately no substantive objections were raised, and the
consensus to advance the document was broad after the working group
review was complete.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)
       
Nothing of this sort has been expressed in any venue that I'm aware of.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?
       
The document passes idnits.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].
       
References have been split.  There are no downward references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?
The IANA considersations section seems clear to me, although I would
have liked it if the language were a bit more imperative.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?
       
No such language exists in the text. As stated earlier, I walked through
the C pseudocode on paper to make sure it works, and it does.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:
    Technical Summary
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.
    Working Group Summary
This document received a thorough review by the WG. Many comments were
made, and several revisions done.  The process was amicable and seems to
have satisfied all participants.
    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?
       
The protocol is required by the latest 3GPP GPRS specification, but the
authors are not aware of any specific implementations yet.  We would
expect to see these implementations appearing in cellular data devices
that do IPv6 tethering, which is a relatively new sort of application.
2011-12-20
04 Cindy Morgan Draft added in state Publication Requested
2011-12-20
04 Cindy Morgan [Note]: 'Ted Lemon (ted.lemon@nominum.com) is the document shepherd.' added
2011-12-19
04 (System) New version available: draft-ietf-dhc-pd-exclude-04.txt
2011-08-05
03 (System) New version available: draft-ietf-dhc-pd-exclude-03.txt
2011-06-20
02 (System) New version available: draft-ietf-dhc-pd-exclude-02.txt
2011-01-11
01 (System) New version available: draft-ietf-dhc-pd-exclude-01.txt
2010-10-08
00 (System) New version available: draft-ietf-dhc-pd-exclude-00.txt