Problem Statement: Dual Stack Mobility
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, mip6 mailing list <email@example.com>, mip6 chair <firstname.lastname@example.org> Subject: Document Action: 'Problem Statement: Dual Stack Mobility' to Informational RFC The IESG has approved the following document: - 'Problem Statement: Dual Stack Mobility ' <draft-ietf-mip6-dsmip-problem-04.txt> as an Informational RFC This document is the product of the Mobility for IPv6 Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-dsmip-problem-04.txt
Technical Summary This draft discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of inefficiencies. Deployment and operational issues motivate the use of a single mobility management protocol. This draft discusses such motivations. The draft also hints on how the current MIP4 and MIP6 protocols could be extended so that they can support mobility management for a dual stack node. Working Group Summary This I-D was initially produced as a problem statement for the MIP6 WG. However subsequently it was noted that it applied to MIP4 as well. Hence the I-D is now considered as being applicable to the MIP4 and MIP6 WGs. There is consensus behind this document and the need to address the problem. Protocol Quality This specification has been reviewed by Jari Arkko for the IESG. Note to RFC Editor Please ignore the "Intended status: Standards Track" header in the document. The intended status is really Informational RFC. Please change the following in Section 4.3: OLD: possible to optimize some of these processes. NEW: possible to rely on one set of set common credentials. Similarly, change the contents of Section 4.2 to the following: As mentioned above, a node that is IPv4 and IPv6 capable must also be MIPv4 and MIPv6 capable to roam within the Internet. The ability to employ both IP versions from one mobility protocol makes it possible to implement just that one protocol, assuming the protocol choice is known. However, in situations where the mobile node must be capable of working in any network it may still need two protocols. And change the contents of Section 4.5 to this: The IETF has standardized a number of transition mechanisms to allow networks and end nodes to gain IPv6 connectivity while the Internet is migrating from IPv4 to IPv6. However, while some transition mechanisms can be combined with Mobile IPv4 or Mobile IPv6, none of the known mechanisms have been shown to assist with the issues described in this document. In Section 4.1 title, change "impossibility" to "Impossibility". Please remove Section 8 prior to publication as an RFC. Please remove Section 1 and the associated reference (the document does not use RFC 2119 terms). Please change the following in Section 5: OLD In order to allow for a gradual transition based on current standards and deployment, the following work areas seem to be reasonable: NEW The Mobile IPv6 Working Group has reached the view that to allow for a gradual transition based on current standards and deployment, the following work areas would be reasonable: OLD Following the steps listed above, a vendor can choose to support one mobility management protocol while avoiding the incompatibility and inefficiency problems listed in this document. Similarly, operators can decide to continue using one mobility management protocol while addressing the transition scenarios that a mobile node is likely to face when roaming within the Internet. NEW If the IETF chooses to pursue all these paths, a vendor could choose to support one mobility management protocol while avoiding the incompatibility and inefficiency problems listed in this document. Similarly, operators could decide to continue using one mobility management protocol throughout the period of IPv4 and IPv6 coexistence. However, a mobile node would be forced to choose one approach or the other, or nevertheless to install both and use one or the other according to circumstances.