Mobile IPv6 Fast Handovers
draft-ietf-mipshop-rfc5268bis-01
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
01 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
01 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2009-05-12
|
01 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2009-05-12
|
01 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2009-05-12
|
01 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-05-11
|
01 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-05-11
|
01 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2009-05-11
|
01 | (System) | IANA Action state changed to In Progress |
2009-05-11
|
01 | Amy Vezza | IESG state changed to Approved-announcement sent |
2009-05-11
|
01 | Amy Vezza | IESG has approved the document |
2009-05-11
|
01 | Amy Vezza | Closed "Approve" ballot |
2009-05-08
|
01 | (System) | Removed from agenda for telechat - 2009-05-07 |
2009-05-07
|
01 | Cindy Morgan | State Changes to Approved-announcement to be sent from IESG Evaluation by Cindy Morgan |
2009-05-07
|
01 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2009-05-07
|
01 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2009-05-07
|
01 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2009-05-07
|
01 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2009-05-06
|
01 | Tim Polk | [Ballot comment] From the IANA Considerations: > This document defines a new ICMPv6 message, which has been allocated > from the ICMPv6 Type registry. > … [Ballot comment] From the IANA Considerations: > This document defines a new ICMPv6 message, which has been allocated > from the ICMPv6 Type registry. > 154 FMIPv6 Messages Wasn't this message defined in 5268? |
2009-05-06
|
01 | Tim Polk | [Ballot discuss] From the IANA Considerations: > This document creates a new registry for the 'Subtype' field in the > above ICMPv6 message, called the … [Ballot discuss] From the IANA Considerations: > This document creates a new registry for the 'Subtype' field in the > above ICMPv6 message, called the "FMIPv6 Message Types". IANA has > assigned the following values. [...] > The values '0' and '1' are reserved. The upper limit is 255. An RFC > is required for new message assignment. The Subtype values 4 and 5 > are deprecated and are marked as unassigned for future allocations. As noted in Alexey's comment, it seems like a bad idea to permit reassignment of these values. |
2009-05-06
|
01 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2009-05-06
|
01 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
2009-05-06
|
01 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
2009-05-06
|
01 | Dan Romascanu | [Ballot comment] I am aware that this document is at the third RFC iteration. I would have expected however at this phase at least to … [Ballot comment] I am aware that this document is at the third RFC iteration. I would have expected however at this phase at least to have the authors add information about operational impact and manageability considerations related to mobile IPv6 fast handovers. |
2009-05-06
|
01 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2009-05-06
|
01 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
2009-05-06
|
01 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2009-05-05
|
01 | Russ Housley | [Ballot discuss] The Gen-ART Review from Brian Carpenter raised an important question that deserves a clear response. What is an implementation of this … [Ballot discuss] The Gen-ART Review from Brian Carpenter raised an important question that deserves a clear response. What is an implementation of this specification supposed to do if it receives one of the deprecated ICMPv6 messages defined in RFC 5268? |
2009-05-05
|
01 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2009-05-05
|
01 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2009-05-04
|
01 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2009-05-04
|
01 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2009-05-03
|
01 | Alexey Melnikov | [Ballot comment] 11. IANA Considerations [...] This document creates a new registry for the 'Subtype' field in the above ICMPv6 message, called the … [Ballot comment] 11. IANA Considerations [...] This document creates a new registry for the 'Subtype' field in the above ICMPv6 message, called the "FMIPv6 Message Types". IANA has assigned the following values. [...] The values '0' and '1' are reserved. The upper limit is 255. An RFC is required for new message assignment. The Subtype values 4 and 5 are deprecated and are marked as unassigned for future allocations. I don't know what is the predicted rate of allocations from this registry, but is it wise to unassign deprecated values to allow their reuse in the future? |
2009-05-03
|
01 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov |
2009-05-03
|
01 | Alexey Melnikov | [Ballot comment] 11. IANA Considerations [...] This document creates a new registry for the 'Subtype' field in the above ICMPv6 message, called the … [Ballot comment] 11. IANA Considerations [...] This document creates a new registry for the 'Subtype' field in the above ICMPv6 message, called the "FMIPv6 Message Types". IANA has assigned the following values. +---------+-------------------+-----------------+ | Subtype | Description | Reference | +---------+-------------------+-----------------+ | 2 | RtSolPr | Section 6.1.1 | | 3 | PrRtAdv | Section 6.1.2 | | 4 | HI - Deprecated | Section 6.2.1.1 | | 5 | HAck - Deprecated | Section 6.2.1.2 | +---------+-------------------+-----------------+ The values '0' and '1' are reserved. The upper limit is 255. An RFC is required for new message assignment. The Subtype values 4 and 5 are deprecated and are marked as unassigned for future allocations. I don't know what is the predicted rate of allocations from this registry, but is it wise to unassign deprecated values to allow their reuse in the future? |
2009-05-02
|
01 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Yaron Sheffer. |
2009-04-29
|
01 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
2009-04-29
|
01 | Adrian Farrel | [Ballot comment] You seem to have accidentally removed a definite article from "and MUST send an FBU to PAR" in section 3.3. Or you have … [Ballot comment] You seem to have accidentally removed a definite article from "and MUST send an FBU to PAR" in section 3.3. Or you have failed to remove the definite article from "In such networks, the PAR." 6.2.1.2 Finally, the New Access Router can always refuse handover, in which case it should indicate the reason in one of the available Code values. Is that SHOULD? And if so, why is it not MUST? (Yes, I know the text is copied from the equivalent in 5268.) Section 6.4 I know some of this is lifted from 5268, but I would prefer the prefix lengths to explicitly state that they are counting bits. The previous field called Length explicitly states "octets". |
2009-04-28
|
01 | Jari Arkko | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko |
2009-04-27
|
01 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2009-04-22
|
01 | Amanda Baber | IANA questions/comments: - The FMIPv6 Messages ICMPv6 Type has already been allocated. Is there anything you would like IANA to do for this? Should we … IANA questions/comments: - The FMIPv6 Messages ICMPv6 Type has already been allocated. Is there anything you would like IANA to do for this? Should we add a reference to this document? Replace the existing reference? - The FMIPv6 Message Types sub-registry has aleady been created. Other than marking types 4 and 5 as deprecated, is there anything else you would like IANA to do? - The Binding Authorization Data for FMIPv6 (BADF) Mobility Option has already been allocated. Is there anything you would like IANA to do for this? - The Neighbor Discovery options have already been allocated. Is there anything you would like IANA to do for this? - The Fast Binding Update and Fast Binding Acknowledgement Mobility Header Types have already been allocated. Is there anything you would like IANA to do for this? - The Mobility Header Link-Layer Address option Mobility Option has already been allocated. Is there anything you would like IANA to do for this? Action 1: Upon approval of this document, IANA will make the following assignments in the "Mobility Header Types" registry at http://www.iana.org/assignments/mobility-parameters Value Description Reference ----- -------------------------------- --------- TBD Handover Initiate Message [RFC-mipshop-rfc5268bis-01] TBD Handover Acknowledge Message [RFC-mipshop-rfc5268bis-01] Action 2: Upon approval of this document, IANA will make the following assignment in the "Mobility Options" registry at http://www.iana.org/assignments/mobility-parameters Value Description Reference ----- -------------------------------------------- --------- TBD Mobility Header IPv6 Address/Prefix option [RFC-mipshop-rfc5268bis-01] Action 3: Upon approval of this document, IANA will make the following changes in the "FMIPv6 Message Types" registry at http://www.iana.org/assignments/icmpv6-parameters OLD: Subtype Description Reference ------- ---------------------------------- --------- 4 HI [RFC5268] 5 HAck [RFC5268] NEW: Subtype Description Reference ------- ---------------------------------- --------- 4 HI - Deprecated (Available for assignment) [RFC5268][RFC-mipshop-rfc5268bis-01] 5 HAck - Deprecated (Available for assignment) [RFC5268][RFC-mipshop-rfc5268bis-01] We understand the above to be the only IANA Actions for this document. |
2009-04-16
|
01 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2009-04-16
|
01 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2009-04-13
|
01 | Amy Vezza | Last call sent |
2009-04-13
|
01 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2009-04-13
|
01 | Jari Arkko | Placed on the agenda. |
2009-04-13
|
01 | Jari Arkko | Placed on agenda for telechat - 2009-05-07 by Jari Arkko |
2009-04-13
|
01 | Jari Arkko | State Changes to Last Call Requested from AD Evaluation by Jari Arkko |
2009-04-13
|
01 | Jari Arkko | Last Call was requested by Jari Arkko |
2009-04-13
|
01 | Jari Arkko | [Note]: 'http://www.arkko.com/ietf/mipshop/draft-ietf-mipshop-rfc5268bis-01-from-rfc5268.diff.html' added by Jari Arkko |
2009-04-13
|
01 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2009-04-13
|
01 | Jari Arkko | Ballot has been issued by Jari Arkko |
2009-04-13
|
01 | Jari Arkko | Created "Approve" ballot |
2009-04-13
|
01 | (System) | Ballot writeup text was added |
2009-04-13
|
01 | (System) | Last call text was added |
2009-04-13
|
01 | (System) | Ballot approval text was added |
2009-04-13
|
01 | Jari Arkko | State Changes to AD Evaluation from Publication Requested by Jari Arkko |
2009-04-08
|
01 | Amy Vezza | ------------------------------------------------------------------------ (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of … ------------------------------------------------------------------------ (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? Vijay Devarapalli is the Document Shepherd for this document. I have reviewed the document and it is ready for forwarding to the IESG 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 have been performed? This document has had adequate reviews from the members in the MIPSHOP WG. This document is a revision of RFC 5268 which has had a substantial number of reviews. I have no concerns about the depth or breadth of the reviews that have been performed. (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? None. (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. No specific concerns. The main change in this document from RFC 5268 is the change in messages format for the Handover Initiate (HI) and Handover Acknowledge (HACK ) messages between the access routers. RFC 5268 uses ICMPv6 for the HI and HACK messages. This document updates these messages to use the Mobility Header Protocol. It obsoletes RFC 5268. (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 WG consensus in advancing this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html 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? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. No nits were found. (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 document splits the references into normative and informative references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations 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 [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The IANA considerations section exists and is consistent with the body of the document. The document requests reservations in the appropriate IANA registries. The IANA registries that need to be modified/created are clearly identified. (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? Does not apply. (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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care-of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP (VoIP). This documents updates the packet formats for the Handover Initiate (HI) and Handover Acknowledgement (HAck) messages to Mobility Header Type. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? None. 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? There are multiple implementations of the FMIPv6 protocol. There are also some folks wanting to deploy this protocol for fast PMIPv6 handovers. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Document shepherd: Vijay Devarapalli Responsible AD: Jari Arkko |
2009-04-08
|
01 | Amy Vezza | Draft Added by Amy Vezza in state Publication Requested |
2009-03-04
|
01 | (System) | New version available: draft-ietf-mipshop-rfc5268bis-01.txt |
2009-02-15
|
00 | (System) | New version available: draft-ietf-mipshop-rfc5268bis-00.txt |