Skip to main content

Rebind Capability in DHCPv6 Reconfigure Messages
RFC 6644

Revision differences

Document history

Date Rev. By Action
2015-10-14
10 (System) Notify list changed from dhc-chairs@ietf.org, draft-ietf-dhc-dhcpv6-reconfigure-rebind@ietf.org to (None)
2012-07-11
10 (System) RFC published
2012-04-24
10 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2012-04-23
10 (System) IANA Action state changed to No IC
2012-04-23
10 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2012-04-23
10 Amy Vezza IESG has approved the document
2012-04-23
10 Amy Vezza Closed "Approve" ballot
2012-04-23
10 Amy Vezza State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2012-04-23
10 Brian Haberman Ballot writeup was changed
2012-04-23
10 Brian Haberman Ballot approval text was changed
2012-04-20
10 Brian Haberman Ballot approval text was changed
2012-04-20
10 Brian Haberman Ballot writeup was changed
2012-04-19
10 Stephen Farrell
[Ballot comment]
- 1st sentence of abstract seems odd, v. hard to read anyway and that's
not so good usually. How does the "Reconfigure Message" …
[Ballot comment]
- 1st sentence of abstract seems odd, v. hard to read anyway and that's
not so good usually. How does the "Reconfigure Message" extend "the
Reconfigure Message"? (That's how I read it anyway)
2012-04-19
10 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2012-04-18
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-04-18
10 Sheng Jiang New version available: draft-ietf-dhc-dhcpv6-reconfigure-rebind-10.txt
2012-04-16
09 Stephen Farrell
[Ballot discuss]
Since I know squat about DHCPv6 these may be cleared up
really quickly:

- I don't see why the dhc-secure-dhcpv6 is non-normative since …
[Ballot discuss]
Since I know squat about DHCPv6 these may be cleared up
really quickly:

- I don't see why the dhc-secure-dhcpv6 is non-normative since its
one of two possible ways to do a thing.

- Should one of AUTH from 3315 or dhc-secure-dhcpv6 be mandatory
to implement? If not, why not?
2012-04-16
09 Stephen Farrell
[Ballot comment]

- 1st sentence of abstract seems odd, v. hard to read anyway and that's
not so good usually. How does the "Reconfigure Message" …
[Ballot comment]

- 1st sentence of abstract seems odd, v. hard to read anyway and that's
not so good usually. How does the "Reconfigure Message" extend "the
Reconfigure Message"? (That's how I read it anyway)
2012-04-16
09 Stephen Farrell Ballot comment and discuss text updated for Stephen Farrell
2012-04-12
09 Brian Haberman Ballot writeup was changed
2012-04-12
09 Brian Haberman State changed to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead
2012-04-12
09 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2012-04-11
09 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Tobias Gondrom.
2012-04-11
09 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2012-04-11
09 Russ Housley
[Ballot comment]

  Please consider the editorial suggestions in the Gen-ART Review by
  Francis Dupont on 7-Apr-2012.  The review can be found here:
  …
[Ballot comment]

  Please consider the editorial suggestions in the Gen-ART Review by
  Francis Dupont on 7-Apr-2012.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07344.html
2012-04-11
09 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2012-04-11
09 Francis Dupont Request for Last Call review by GENART Completed. Reviewer: Francis Dupont.
2012-04-11
09 Robert Sparks
[Ballot comment]
The introduction motivates some of these changes with a use case of a network administrator who is preparing to shut down a dhcpv6 …
[Ballot comment]
The introduction motivates some of these changes with a use case of a network administrator who is preparing to shut down a dhcpv6 server causing clients to move to a different server. Is it possible (if so, how easy would it be) to misconfigure the servers involved to cause them to enter a rebind war with each other? If this is something a client might experience, is there guidance to give the client implementations on how to react when it happens?
2012-04-11
09 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2012-04-11
09 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2012-04-11
09 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2012-04-11
09 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2012-04-10
09 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica
2012-04-10
09 Sean Turner
[Ballot comment]
1) I support Stephen's discuss.

2) s4: I was having some issues tracking exactly which paragraphs in 19.1-19.3 were being updated/replaced.  Could you …
[Ballot comment]
1) I support Stephen's discuss.

2) s4: I was having some issues tracking exactly which paragraphs in 19.1-19.3 were being updated/replaced.  Could you do the old/new so we knew which paragraphs were being replaced.  Ex (assuming I got this bit right):

4.1 Updates to Section 19.1

OLD:

A server sends a Reconfigure message to cause a client to initiate
immediately a Renew/Reply or Information-request/Reply message
exchange with the server.

NEW:

The server MUST include a Reconfigure Message option (as defined in
Section 3) to select whether the client responds with a Renew
message, a Rebind message or an Information-Request message.

3) s5: If the text replaces the text in s19.4 of RFC 3315 could you just say that? r/This section updates specific text in/This section replaces
2012-04-10
09 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2012-04-08
09 Stephen Farrell
[Ballot discuss]

Since I know squat about DHCPv6 these may be cleared up
really quickly:

- Section 7 calls out a clear vulnerability and suggests …
[Ballot discuss]

Since I know squat about DHCPv6 these may be cleared up
really quickly:

- Section 7 calls out a clear vulnerability and suggests use of the AUTH
option from RFC 3315. I'm told that nobody ever uses the v4 equivalent
functionality, is that the same for v6? If so, it would then seem
that we have a vulnerability with no practical mitigation which
would seem like a bad thing. I'd hope to see at least an honest
recognition of that, if its in fact the case.

- I don't see why the dhc-secure-dhcpv6 is non-normative since its
one of two possible ways to do a thing.

- Should one of AUTH from 3315 or dhc-secure-dhcpv6 be mandatory
to implement? If not, why not?
2012-04-08
09 Stephen Farrell
[Ballot comment]


- 1st sentence of abstract seems odd, v. hard to read anyway and that's
not so good usually. How does the "Reconfigure Message" …
[Ballot comment]


- 1st sentence of abstract seems odd, v. hard to read anyway and that's
not so good usually. How does the "Reconfigure Message" extend "the
Reconfigure Message"? (That's how I read it anyway)
2012-04-08
09 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2012-04-08
09 Adrian Farrel
[Ballot comment]
I have no objection to the publication of this document, but I
have a few comments that either reperesent my failure to grasp …
[Ballot comment]
I have no objection to the publication of this document, but I
have a few comments that either reperesent my failure to grasp what
you are doing, or would make useful improvements to the document.

---

I would prefer that Section 3 did not include the format of the
Reconfigure Message option. Rather than "update" the option with a
full replacement, isn't it enough to say that msg-type may now
additionally take the value 6 to indicate Rebind?

---

Section 4

  The server MUST include a Reconfigure Message option (as defined in
  Section 3) to select whether the client responds with a Renew
  message, a Rebind message or an Information-Request message.

Include in what?

---

Section 4 is headed "Server Behavior"

  The Reconfigure message causes the client to initiate a Renew/Reply,
  a Rebind/Reply message exchange or an Information-request/Reply
  message exchange. 

Seems to be describing the client behavior. At least give a forward
pointer to Section 5.
 
--- 

Section 4

                      The server interprets the receipt of a Renew, a
  Rebind or an Information-request message (whichever was specified in
  the original Reconfigure message) from the client as satisfying the
  Reconfigure message request.

Presumably, only if threceived message matches the msg-tpe in the
Reconfigure Message option? What if there is a mismatch? can the
mismatch be caused by a race?

---

Section 5

How is a legacy client going to handle a Reconfigure Message option
with msg-type set to Rebind? Presumably it is going to run some 3315
logic to drop or nack the message as "msg-type unknown, unexpected,
or unsupported".

I believe you should mention this as it impacts on server behavior.
2012-04-08
09 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2012-04-06
09 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2012-04-05
09 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2012-04-05
09 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2012-04-03
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tobias Gondrom
2012-04-03
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tobias Gondrom
2012-04-03
09 Brian Haberman [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman
2012-04-03
09 Brian Haberman Responsible AD changed to Brian Haberman from Jari Arkko
2012-03-22
09 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2012-03-22
09 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2012-03-22
09 Amanda Baber We understand that this document doesn't require any IANA actions.
2012-03-22
09 Ralph Droms [Ballot Position Update] New position, Recuse, has been recorded for Ralph Droms
2012-03-21
09 Amy Vezza Last call sent
2012-03-21
09 Amy Vezza
State changed to In Last Call from Last Call Requested<br><br>The following Last Call Announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org><br><br>To: IETF-Announce …
State changed to In Last Call from Last Call Requested<br><br>The following Last Call Announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org><br><br>To: IETF-Announce <ietf-announce@ietf.org><br><br>CC: <dhcwg@ietf.org><br><br>Reply-To: ietf@ietf.org<br><br>Subject: Last Call: <draft-ietf-dhc-dhcpv6-reconfigure-rebind-09.txt> (Rebind Capability in DHCPv6 Reconfigure Messages) to Proposed Standard<br><br><br><br><br><br>The IESG has received a request from the Dynamic Host Configuration WG<br><br>(dhc) to consider the following document:<br><br>- 'Rebind Capability in DHCPv6 Reconfigure Messages'<br><br>  <draft-ietf-dhc-dhcpv6-reconfigure-rebind-09.txt> as a Proposed<br><br>Standard<br><br><br><br>The IESG plans to make a decision in the next few weeks, and solicits<br><br>final comments on this action. Please send substantive comments to the<br><br>ietf@ietf.org mailing lists by 2012-04-11. Exceptionally, comments may be<br><br>sent to iesg@ietf.org instead. In either case, please retain the<br><br>beginning of the Subject line to allow automated sorting.<br><br><br><br>Abstract<br><br><br><br><br><br>  This document updates RFC 3315 to allow the Rebind message type to<br><br>  appear in the Reconfigure Message option of a Reconfigure message,<br><br>  which extends the Reconfigure message to allow a DHCPv6 server to<br><br>  cause a DHCPv6 client to send a Rebind message.  The document also<br><br>  clarifies how a DHCPv6 client responds to a received Reconfigure<br><br>  message.<br><br><br><br><br><br><br><br><br><br>The file can be obtained via<br><br>http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-reconfigure-rebind/<br><br><br><br>IESG discussion can be tracked via<br><br>http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-reconfigure-rebind/ballot/<br><br><br><br><br><br>No IPR declarations have been submitted directly on this I-D.<br><br><br><br><br><br>
2012-03-21
09 Jari Arkko Last call was requested
2012-03-21
09 Jari Arkko State changed to Last Call Requested from AD Evaluation
2012-03-21
09 Jari Arkko Last call announcement was changed
2012-03-21
09 Jari Arkko Last call announcement was generated
2012-03-21
09 Jari Arkko Placed on agenda for telechat - 2012-04-12
2012-03-21
09 Jari Arkko Last call announcement was generated
2012-03-21
09 Jari Arkko Ballot has been issued
2012-03-21
09 Jari Arkko Ballot approval text was generated
2012-03-21
09 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2012-03-21
09 Jari Arkko Ballot writeup was changed
2012-03-21
09 Jari Arkko Created "Approve" ballot
2012-03-21
09 Jari Arkko
have reviewed this draft. (Exceptionally I'm the AD to do this review for DHC WG because Ralph is one of the authors of this draft.) …
have reviewed this draft. (Exceptionally I'm the AD to do this review for DHC WG because Ralph is one of the authors of this draft.)

I have found the draft well written and have no concerns about it. I have initiated IETF last call for it. I did have a couple of editorial comments, however:

For me, Section 4 would have benefited from a clearer statement of what material from RFC 3315 was still valid. For example, when I read Section 4 and 5, I wondered what options the server was supposed to use as only the latter section talked about options. Looking at RFC 3315 Section 19.1 there's plenty of text about this.

Section 7 has nice story about the use of DHCP authentication. I would have preferred to see also a more real-world related explanation of why these attacks are no worse than other attacks on DHCP to begin with. E.g., if you disable nodes with reconfigure, you can disable them with the regular DHCP process as well.

ID nits:
>  == Outdated reference: A later version (-06) exists of
>      draft-ietf-dhc-secure-dhcpv6-03

Jari
2012-03-21
09 Jari Arkko State changed to AD Evaluation from Publication Requested
2012-03-08
09 Ralph Droms Responsible AD changed to Jari Arkko from Ralph Droms
2012-03-08
09 Ralph Droms Ballot writeup was changed
2012-03-08
09 Ralph Droms Ballot writeup was generated
2012-03-08
09 Cindy Morgan
Document Writeup

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.

Changes are expected over time. This version …
Document Writeup

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.

Changes are expected over time. This version is dated September 17, 2008.

  (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 document has not been reviewed by other working groups--it is very specific to DHCP.

  (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?
       
This is really a DHCP-specific document, so I don't see much point in broader review, although more review is always appreciated.

  (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.
       
The document mirrors some language from RFC3315 that I think isn't clearly worded.  I would like to eventually fold an update of that language into a new version of RFC3315, so I don't think it's necessary to address the problem in this draft.

  (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? 

This draft got lost in the changeover of management in the DHC working group--Ralph did the WGLC right before he retired as working group chair, and there was never a formal declaration of consensus.  However, the working group was in fact unanimously in favor of advancing the draft in response to Ralph's last call, and support remained strong when Leaf Yeh brought the draft up in August.

  (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.)
       
I haven't heard a single objection raised to this document.

  (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 draft passes idnits without any issues.

  (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].
       
The doc has been split. There is an informative reference to a document that is still in progress in the working group, but no normative references to unpublished documents.

  (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?
There are no IANA requirements imposed by this document.

  (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.

  (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 document updates RFC 3315 to allow the Rebind message type to
appear in the Reconfigure Message option of a Reconfigure message,
which extends the Reconfigure message to allow a DHCPv6 server to
cause a DHCPv6 client to send a Rebind message.  The document also
clarifies how a DHCPv6 client responds to a received Reconfigure
message.

    Working Group Summary

This document received a thorough review by the WG, and had broad support.

    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?

We are not aware of any implementations.
2012-03-08
09 Cindy Morgan Note added 'Ted Lemon (ted.lemon@nominum.com) is the document shepherd.'
2012-03-08
09 Cindy Morgan Intended Status changed to Proposed Standard
2012-03-08
09 Cindy Morgan IESG process started in state Publication Requested
2012-03-08
09 (System) Earlier history may be found in the Comment Log for <a href="/doc/draft-evans-dhc-dhcpv6-reconfigure-rebind/">draft-evans-dhc-dhcpv6-reconfigure-rebind</a>
2011-12-15
09 (System) New version available: draft-ietf-dhc-dhcpv6-reconfigure-rebind-09.txt
2011-08-22
08 (System) New version available: draft-ietf-dhc-dhcpv6-reconfigure-rebind-08.txt
2010-05-12
09 (System) Document has expired
2009-11-09
07 (System) New version available: draft-ietf-dhc-dhcpv6-reconfigure-rebind-07.txt
2008-11-17
06 (System) New version available: draft-ietf-dhc-dhcpv6-reconfigure-rebind-06.txt
2008-11-03
05 (System) New version available: draft-ietf-dhc-dhcpv6-reconfigure-rebind-05.txt
2008-09-08
04 (System) New version available: draft-ietf-dhc-dhcpv6-reconfigure-rebind-04.txt
2007-12-04
03 (System) New version available: draft-ietf-dhc-dhcpv6-reconfigure-rebind-03.txt
2007-11-13
02 (System) New version available: draft-ietf-dhc-dhcpv6-reconfigure-rebind-02.txt
2006-11-20
01 (System) New version available: draft-ietf-dhc-dhcpv6-reconfigure-rebind-01.txt
2006-08-15
00 (System) New version available: draft-ietf-dhc-dhcpv6-reconfigure-rebind-00.txt