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 |