idnits 2.17.1 draft-engelstad-ngtrans-mobility-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'MIPv4' is defined on line 247, but no explicit reference was found in the text == Unused Reference: 'MIPv6' is defined on line 250, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. 'MIPv4') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. 'MIPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSTM' ** Obsolete normative reference: RFC 2765 (ref. 'SIIT') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISATAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'NGTRANS-MECH' ** Downref: Normative reference to an Informational RFC: RFC 1958 (ref. 'IP-ARCH') Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT P. Engelstad 3 Telenor R&D 4 Expires February 2002 August 14. 2001 6 Requirements to mobility while transitioning from IPv4 to IPv6. 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This document is an individual submission for the NGTRANS Working 31 Group of the Internet Engineering Task Force (IETF). Comments should 32 be submitted to the ngtrans@sunroof.eng.sun.com mailing list. 34 Abstract 36 This document explores how layer-3 mobility can be provided to mobile 37 nodes that are subjects to and affected by the transition mechanisms 38 specified by the NGTRANS Working Group. It points out that the 39 combination of mobility and transition mechanisms might lead to 40 problems that will require a solution, and suggests requirements that 41 a solution should meet. 43 1. Introduction 44 1.1 Intent of this draft 46 This draft is a working document, intended to represent the ideas of 47 people in the NGTRANS Working Group that are interested in IP 48 mobility and are concerned with how mobility can be accommodated 49 during the transition from IPv4 to IPv6. 51 The content of this first version is intended to trigger interest for 52 and discussion around the problem presented - more than being 53 prescriptive in any form. Thus, others are invited to contribute to 54 the content and structure of the document. Comments and minor 55 contributions, as well as co-authoring and major restructuring are 56 welcome. 58 1.2. Assumptions related to transition mechanisms 60 This draft assumes that there will be a need for connectivity between 61 IPv4-only nodes, dual stack nodes, and IPv6-only nodes that are 62 moving and changing network access. 64 A fully inter-connected IPv6 Internet (with capital 'I') will 65 probably be formed gradually as different IPv6 islands chooses to 66 inter-connect. Thus, a mobile node cannot expect that the IPv6-only 67 access networks have native IPv6 connection with any node on the IPv6 68 Internet. Hopefully a transition mechanism can accommodate 69 connectivity. 71 The connectivity between the mobile nodes (including correspondent 72 nodes) may rely on some of the many transition mechanism that are 73 being specified in the NGTRANS Working Group. These include [6to4], 74 [6over4], [SIIT], [NAT-PT], [ISATAP] and [DSTM] -just to mention a 75 few of them. [NGTRANS-MECH] gives a detailed overview. Other 76 mechanisms may also be defined at a later stage. 78 1.3. Assumptions related to mobility 80 It is also assumed that the mobile nodes would like to be able to 81 move between IPv4-only, dual stack, and IPv6-only access network 82 (although IP4-only nodes cannot expect to be able to connect to 83 IPv6-only networks, and vice versa). 85 Mobile IPv4 is assumed to be the preferred protocol that supports 86 transparent, layer-3 mobility for IPv4 flows, while Mobile IPv6 is 87 the corresponding protocol for IPv6 mobility. 89 Both protocols support transparent layer-3 mobility across different 90 (heterogeneous) underlying technologies, but there are no protocols 91 that support transparent mobility across different layer-3 protocols 92 (i.e. between IPv4 and IPv6). 94 1.4. Problem statement is required 96 It is not obvious how transparent, layer-3 mobility will be supported 97 when the flows involve both IPv4 and IPv6 communication, i.e. when 98 end-to-end connectivity requires that both IPv4 and IPv6 be used 99 along the communication path. 101 People interested in this problem would probably need to work out a 102 problem statement document that clarifies this issue, e.g.: 104 - Will an IPv6-only node that relies on transition mechanisms for 105 communication need transparent layer-3 mobility while roaming 106 IPv6-only networks? 108 - Will a dual stack node that relies on transition mechanisms need 109 transparent layer-3 mobility while roaming between IPv4-only and 110 IPv6-only networks? (Nodes that visit dual stack networks can 111 probably choose from both IPv4-only and IPv6-only solution space.) 113 - Are there any schemes at hand today to address these problems, or 114 are separate protocols or solutions required? 116 This draft assumes that a separate solution is required to address 117 these problems, and proposes a set of requirements that should be met 118 by this "transition-mobility" solution. The requirements are listed 119 in the next section. 121 2. Requirements that should be met by a "transition-mobility" 122 solution 124 In the following is listed a number of proposed requirements to a 125 solution for mobility during IPv4-to-IPv6 transition. Some general 126 design issues of the architectural principles of the Internet ([IP- 127 ARCH]) become particularly relevant for such a solution. 129 2.1 Transparent layer-3 mobility 131 The transparency requirement dictates that a change of network 132 connection should not break the transport layer connection of 133 transport layer protocols. Thus, the tuple of IP-address(es), 134 transport-protocol and port(s) in the packets that are received by 135 the mobile node must not be changed as the node moves. Moreover, the 136 change of connection should not make the mobile node unreachable for 137 incoming traffic, if it was reachable to a fixed IP address in the 138 first place. 140 2.2 Flexibility 142 Since it is difficult to foresee the future, a transition-mobility 143 solution should be independent on how the transition process will 144 evolve; i.e. it should be flexible to accommodate a wide range of 145 transition scenarios. 147 However, as a guideline one may make the following assumption about 148 pre-transition and post-transition mobility: 149 - Prior to the transition IPv4-only nodes communicate with IPv4-only 150 nodes over the IPv4 Internet, and Mobile IPv4 is the preferred 151 protocol for layer-3 mobility. 152 - After the transition IPv6-only nodes communicate with IPv6-only 153 nodes over the IPv6 Internet, and Mobile IPv6 is the preferred 154 protocol for layer-3 mobility. 156 2.3 Independence of Transition Mechanisms 158 The optimal solution should be able to handle the majority of 159 transition mechanisms that exist today, and it should not hinder 160 development of new and better mechanism; i.e. it should make few 161 assumptions about the transition mechanism in use. 163 Another option is to split the solution into a number of sub- 164 solutions; e.g. each transition mechanism offers its own 165 (sub-)solution to the mobility problem. 167 2.4 Modularity 169 Hopefully the transition process will go on for only a limited period 170 of time, and the process will probably evolve gradually. A modular 171 transition-mobility solution it therefore preferred. This means that 172 it may be plugged into and unplugged from the network without 173 altering neither the existing IPv4-based pre-transition protocols nor 174 IPv6-based post-transition protocols. 176 2.5 Simplicity 177 The transition-mobility solution should not delay the transition 178 process. Thus, it must be an easy solution that does not take many 179 years to develop. It should be easy to implement and easy to ensure 180 inter-operability between different implementations. 182 2.6 The solution should consume as little IPv4 address space as 183 possible 185 The main reason for converting to IPv6 is the lack of IPv4 addresses. 186 The enormous IPv6 address space will solve that problem, although a 187 great portion of the IPv6 address space may also be "wasted" on 188 routing mechanisms (e.g. hierarchical routing?) that minimize the 189 routing table problem as well. 191 In the worst case, the transition-mobility solution may be around for 192 a long time. It is therefore important that it consumes as little 193 IPv4 addresses as possible. 195 A significant number of users today acquire their IP addresses 196 dynamically (PPP dial-up, DHCPv4, etc.) and use it for only a limited 197 period of time. Many of them obviously do not need to be reachable 198 for incoming traffic; they initiate the communication session 199 themselves (e-mail, web-browsing etc.). However, they still would 200 prefer to be able to move after they initiated the communication. 202 These users should be able to be mobile without the fixed permanent 203 IPv4 home address that the basic mode of Mobile IPv4 prescribes, 204 because permanently assigned addresses occupy the address even when 205 it is not needed. Dynamic home address discovery, as specified in 206 [HADDR-DISC], might be one way out of this problem. The transition- 207 mobility solution may alternatively support other dynamic address 208 allocation schemes. It could for example be based on DHCP, which is 209 proposed in [DSTM]. 211 2.7 The "end-to-end argument" revisited 213 A transition-mobility solution that pushes the logic and the 214 complexity of the solution to the end host should be preferred. Dual 215 stack hosts must be configured to handle mobility and/or the 216 transition from IPv4 to IPv6, anyway, and putting transition-mobility 217 functionality in the host could be an integrated part of this 218 configuration. 220 Network Address Translation (NAT) is the classic example that shows 221 that putting the (lack of) logic in the NAT-boxes and deviating from 222 the end-to-end-principle to solve a temporary problem, easily leads 223 to complex inter-network behavior and new problems. 225 It should be noted that most transition mechanisms inherently places 226 the logic in the network. 228 3. Security Issues 230 The mobility mechanism that is used to re-direct the flow to the 231 mobile node must be protected by authentication and authorization. 233 Layer-3 mobility solutions often include either host-based routing or 234 relaying of traffic by a mobility agent. In both cases the flow is 235 re-directed as the mobile node moves. (Mobile IPv6, for example, 236 solves this problem by requiring a security association between the 237 mobile node and the home agent. The binding updates are authenticated 238 and authorized before the flow is forwarded to the subnet where the 239 mobile node is located.) 241 Denial-of-service attacks may be a relevant security threat to 242 statefull transition-mobility solutions where the states of the flows 243 are maintained in one single node. 245 References 247 [MIPv4] C.E. Perkins, "IP Mobility Support", IETF RFC 2002, October 248 1996. 250 [MIPv6] D.B. Johnson and C.E. Perkins, "Mobility Support in IPv6", 251 , Work in Progress. 253 [6to4] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 254 Clouds", IETF RFC 3056, IETF, February 2001. 256 [DSTM] J. Bound, L. Toutain, H. Affifi, "Dual Stack Transition 257 Mechanism (DSTM)", , IETF, Work in 258 Progress. 260 [6over4] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 261 Domains without Explicit Tunnels", RFC2529, IETF, March 1999. 263 [SIIT] E. Nordmark, "Stateless IP/ICMP Translator", RFC 2765, IETF, 264 February 2000. 266 [NAT-PT] G. Tsirtsis, P. Srisuresh, "Network Address Translation - 267 Protocol Translation (NAT-PT)", RFC 2766, IETF, February 2000. 269 [ISATAP] F.L. Templin, "Intra-Site Automatic Tunnel Addressing 270 Protocol (ISATAP).", , IETF, Work 271 in Progress. 273 [NGTRANS-MECH] W. Biemolt et. al., "An overview of the introduction 274 of IPv6 in the Internet", IETF, Work in Progress. 276 [HADDR-DISC] P. Calhoun and C.E. Perkins, "Mobile IP Network Access 277 Identifier Extension for IPv4", RFC 2794, IETF, January 2000. 279 [IP-ARCH] B. Carpenter (ed.), "Architectural Principles of the 280 Internet", RFC 1958, IETF, June 1996. 282 Author's address 284 Paal E. Engelstad 285 Telenor R&D, Palo Alto 286 399 Sherman Ave. Suite #12 287 Palo Alto, CA 94306, USA 288 Tel.: + 1-650- 714 7537 289 e-mail: paal@telenorisv.com 291 Feel free to contact me directly on this e-mail address, or through 292 NGTRANS WG's mailing list on ngtrans@sunroof.eng.sun.com, if you have 293 comments or opinions regarding this draft. Your comments are welcome!