INTERNET DRAFT P. Engelstad Telenor R&D Expires February 2002 August 14. 2001 Requirements to mobility while transitioning from IPv4 to IPv6. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is an individual submission for the NGTRANS Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ngtrans@sunroof.eng.sun.com mailing list. Abstract This document explores how layer-3 mobility can be provided to mobile nodes that are subjects to and affected by the transition mechanisms specified by the NGTRANS Working Group. It points out that the combination of mobility and transition mechanisms might lead to problems that will require a solution, and suggests requirements that a solution should meet. 1. Introduction Engelstad [Page 1] INTERNET DRAFT Transition Mobility Requirements 1.1 Intent of this draft This draft is a working document, intended to represent the ideas of people in the NGTRANS Working Group that are interested in IP mobility and are concerned with how mobility can be accommodated during the transition from IPv4 to IPv6. The content of this first version is intended to trigger interest for and discussion around the problem presented - more than being prescriptive in any form. Thus, others are invited to contribute to the content and structure of the document. Comments and minor contributions, as well as co-authoring and major restructuring are welcome. 1.2. Assumptions related to transition mechanisms This draft assumes that there will be a need for connectivity between IPv4-only nodes, dual stack nodes, and IPv6-only nodes that are moving and changing network access. A fully inter-connected IPv6 Internet (with capital 'I') will probably be formed gradually as different IPv6 islands chooses to inter-connect. Thus, a mobile node cannot expect that the IPv6-only access networks have native IPv6 connection with any node on the IPv6 Internet. Hopefully a transition mechanism can accommodate connectivity. The connectivity between the mobile nodes (including correspondent nodes) may rely on some of the many transition mechanism that are being specified in the NGTRANS Working Group. These include [6to4], [6over4], [SIIT], [NAT-PT], [ISATAP] and [DSTM] -just to mention a few of them. [NGTRANS-MECH] gives a detailed overview. Other mechanisms may also be defined at a later stage. 1.3. Assumptions related to mobility It is also assumed that the mobile nodes would like to be able to move between IPv4-only, dual stack, and IPv6-only access network (although IP4-only nodes cannot expect to be able to connect to IPv6-only networks, and vice versa). Mobile IPv4 is assumed to be the preferred protocol that supports transparent, layer-3 mobility for IPv4 flows, while Mobile IPv6 is the corresponding protocol for IPv6 mobility. Both protocols support transparent layer-3 mobility across different Engelstad [Page 2] INTERNET DRAFT Transition Mobility Requirements (heterogeneous) underlying technologies, but there are no protocols that support transparent mobility across different layer-3 protocols (i.e. between IPv4 and IPv6). 1.4. Problem statement is required It is not obvious how transparent, layer-3 mobility will be supported when the flows involve both IPv4 and IPv6 communication, i.e. when end-to-end connectivity requires that both IPv4 and IPv6 be used along the communication path. People interested in this problem would probably need to work out a problem statement document that clarifies this issue, e.g.: - Will an IPv6-only node that relies on transition mechanisms for communication need transparent layer-3 mobility while roaming IPv6-only networks? - Will a dual stack node that relies on transition mechanisms need transparent layer-3 mobility while roaming between IPv4-only and IPv6-only networks? (Nodes that visit dual stack networks can probably choose from both IPv4-only and IPv6-only solution space.) - Are there any schemes at hand today to address these problems, or are separate protocols or solutions required? This draft assumes that a separate solution is required to address these problems, and proposes a set of requirements that should be met by this "transition-mobility" solution. The requirements are listed in the next section. 2. Requirements that should be met by a "transition-mobility" solution In the following is listed a number of proposed requirements to a solution for mobility during IPv4-to-IPv6 transition. Some general design issues of the architectural principles of the Internet ([IP- ARCH]) become particularly relevant for such a solution. 2.1 Transparent layer-3 mobility The transparency requirement dictates that a change of network connection should not break the transport layer connection of transport layer protocols. Thus, the tuple of IP-address(es), Engelstad [Page 3] INTERNET DRAFT Transition Mobility Requirements transport-protocol and port(s) in the packets that are received by the mobile node must not be changed as the node moves. Moreover, the change of connection should not make the mobile node unreachable for incoming traffic, if it was reachable to a fixed IP address in the first place. 2.2 Flexibility Since it is difficult to foresee the future, a transition-mobility solution should be independent on how the transition process will evolve; i.e. it should be flexible to accommodate a wide range of transition scenarios. However, as a guideline one may make the following assumption about pre-transition and post-transition mobility: - Prior to the transition IPv4-only nodes communicate with IPv4-only nodes over the IPv4 Internet, and Mobile IPv4 is the preferred protocol for layer-3 mobility. - After the transition IPv6-only nodes communicate with IPv6-only nodes over the IPv6 Internet, and Mobile IPv6 is the preferred protocol for layer-3 mobility. 2.3 Independence of Transition Mechanisms The optimal solution should be able to handle the majority of transition mechanisms that exist today, and it should not hinder development of new and better mechanism; i.e. it should make few assumptions about the transition mechanism in use. Another option is to split the solution into a number of sub- solutions; e.g. each transition mechanism offers its own (sub-)solution to the mobility problem. 2.4 Modularity Hopefully the transition process will go on for only a limited period of time, and the process will probably evolve gradually. A modular transition-mobility solution it therefore preferred. This means that it may be plugged into and unplugged from the network without altering neither the existing IPv4-based pre-transition protocols nor IPv6-based post-transition protocols. 2.5 Simplicity Engelstad [Page 4] INTERNET DRAFT Transition Mobility Requirements The transition-mobility solution should not delay the transition process. Thus, it must be an easy solution that does not take many years to develop. It should be easy to implement and easy to ensure inter-operability between different implementations. 2.6 The solution should consume as little IPv4 address space as possible The main reason for converting to IPv6 is the lack of IPv4 addresses. The enormous IPv6 address space will solve that problem, although a great portion of the IPv6 address space may also be "wasted" on routing mechanisms (e.g. hierarchical routing?) that minimize the routing table problem as well. In the worst case, the transition-mobility solution may be around for a long time. It is therefore important that it consumes as little IPv4 addresses as possible. A significant number of users today acquire their IP addresses dynamically (PPP dial-up, DHCPv4, etc.) and use it for only a limited period of time. Many of them obviously do not need to be reachable for incoming traffic; they initiate the communication session themselves (e-mail, web-browsing etc.). However, they still would prefer to be able to move after they initiated the communication. These users should be able to be mobile without the fixed permanent IPv4 home address that the basic mode of Mobile IPv4 prescribes, because permanently assigned addresses occupy the address even when it is not needed. Dynamic home address discovery, as specified in [HADDR-DISC], might be one way out of this problem. The transition- mobility solution may alternatively support other dynamic address allocation schemes. It could for example be based on DHCP, which is proposed in [DSTM]. 2.7 The "end-to-end argument" revisited A transition-mobility solution that pushes the logic and the complexity of the solution to the end host should be preferred. Dual stack hosts must be configured to handle mobility and/or the transition from IPv4 to IPv6, anyway, and putting transition-mobility functionality in the host could be an integrated part of this configuration. Network Address Translation (NAT) is the classic example that shows that putting the (lack of) logic in the NAT-boxes and deviating from the end-to-end-principle to solve a temporary problem, easily leads Engelstad [Page 5] INTERNET DRAFT Transition Mobility Requirements to complex inter-network behavior and new problems. It should be noted that most transition mechanisms inherently places the logic in the network. 3. Security Issues The mobility mechanism that is used to re-direct the flow to the mobile node must be protected by authentication and authorization. Layer-3 mobility solutions often include either host-based routing or relaying of traffic by a mobility agent. In both cases the flow is re-directed as the mobile node moves. (Mobile IPv6, for example, solves this problem by requiring a security association between the mobile node and the home agent. The binding updates are authenticated and authorized before the flow is forwarded to the subnet where the mobile node is located.) Denial-of-service attacks may be a relevant security threat to statefull transition-mobility solutions where the states of the flows are maintained in one single node. References [MIPv4] C.E. Perkins, "IP Mobility Support", IETF RFC 2002, October 1996. [MIPv6] D.B. Johnson and C.E. Perkins, "Mobility Support in IPv6", , Work in Progress. [6to4] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", IETF RFC 3056, IETF, February 2001. [DSTM] J. Bound, L. Toutain, H. Affifi, "Dual Stack Transition Mechanism (DSTM)", , IETF, Work in Progress. [6over4] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC2529, IETF, March 1999. [SIIT] E. Nordmark, "Stateless IP/ICMP Translator", RFC 2765, IETF, February 2000. [NAT-PT] G. Tsirtsis, P. Srisuresh, "Network Address Translation - Engelstad [Page 6] INTERNET DRAFT Transition Mobility Requirements Protocol Translation (NAT-PT)", RFC 2766, IETF, February 2000. [ISATAP] F.L. Templin, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).", , IETF, Work in Progress. [NGTRANS-MECH] W. Biemolt et. al., "An overview of the introduction of IPv6 in the Internet", IETF, Work in Progress. [HADDR-DISC] P. Calhoun and C.E. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, IETF, January 2000. [IP-ARCH] B. Carpenter (ed.), "Architectural Principles of the Internet", RFC 1958, IETF, June 1996. Author's address Paal E. Engelstad Telenor R&D, Palo Alto 399 Sherman Ave. Suite #12 Palo Alto, CA 94306, USA Tel.: + 1-650- 714 7537 e-mail: paal@telenorisv.com Feel free to contact me directly on this e-mail address, or through NGTRANS WG's mailing list on ngtrans@sunroof.eng.sun.com, if you have comments or opinions regarding this draft. Your comments are welcome! Engelstad [Page 7]