idnits 2.17.1 draft-ietf-ngtrans-v4-over-mipv6-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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 291 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) -- The document date (January 2001) is 8501 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 16 == Missing Reference: 'MIPv6' is mentioned on line 191, but not defined == Unused Reference: 'MIPV6' is defined on line 202, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2765 (ref. 'SIIT') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NGTRANS WG G. Tsirtsis 2 A. O'Neill 3 S. Corson 4 Internet Draft Flarion Technologies 5 Document: draft-ietf-ngtrans-v4-over-mipv6-00.txt 6 Category: Informational January 2001 7 Expires: June 2001 9 IPv4 over Mobile IPv6 for Dual Stack nodes 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 25 The list of current Internet-Drafts can be accessed at 26 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 Abstract 32 In this document we show how IPv4 based communications can be 33 supported by a dual stack mobile node that only supports Mobile IPv6 34 (MIPv6). The aim is to use MIPv6 for mobility services while the 35 Mobile can still use its dual stack capabilities for IPv4 36 communications without the need for translation. 38 1. Introduction 40 Mobile IP (MIP) is capable of offering mobile services to terminals. 41 Faced with IPv4 address shortage and other shortcomings of Mobile 42 IPv4, a lot of work is now focused on the more functional Mobile 43 IPv6. This, however, creates a number of problems for migration and 44 interoperability, potentially forcing IPv6 Only deployment and 45 consequently, heavy use of Tunneling and/or Protocol Translation 46 [SIIT], [NAT-PT]. 48 1 49 <2001> 51 [SOL] combines [DSTM] and [SIIT] to allow IPv6 only nodes to 52 communicate with IPv4 only nodes and provides some support for 53 Mobile Nodes in the same domain. 55 In this document we present mechanisms to be used for support of 56 IPv4 based communication with a dual stack mobile node (IPv4v6) that 57 only supports Mobile IPv6 (MIPv6), rather than both MIPv4 and MIPv6. 58 The aim is to use MIPv6 for mobility services whilst allowing the 59 Mobile to use its dual stack capabilities for legacy IPv4 60 communications without requiring translation or MIPv4 deployment. 62 2. Dual Stack Mobile Node 64 Imagine a Dual Stack Mobile Node (MN) that only supports MIPv6 and 65 not MIPv4. While stationary and at home the MN does not use its 66 MIPv6 capabilities and thus looks like a regular Dual Stack node. In 67 an environment like that one of the most appealing interoperability 68 mechanisms proposed by the NGTRANS WG is called [DSTM]. 70 DSTM allows a dual stack node to use DHCPv6 to configure on demand 71 its IPv4 stack. This offers high utilization of IPv4 address space 72 and no requirements for IPv4 support in the domain. Additionally, 73 while the Node has an IPv4 address, it can communicate with IPv4 74 only nodes without the use of Protocol Translators and/or Address 75 Translators. 77 DSTM has been mainly designed for stationary dual stack nodes. We 78 will now examine how a MN can take advantage of DSTM in a mobile 79 environment. It is clear that if the MN is not moving, DSTM can be 80 directly applicable i.e.: the MN can use DHCPv6 over MIPv6 to 81 communicate with the DSTM server in the home network and request an 82 IPv4 address. The problem is that while MIPv6 can "move" the 83 mobile's IPv6 stack between access points in the network, it is not 84 obvious how it can move the IPv4 stack of the same MN. 86 3. Tunneling IPv4 in IPv6 88 [DSTM] assumes that IPv4 routing is not available in the DSTM 89 domain. The Dynamic Tunneling Interface (DTI)_is defined as an 90 interface that encapsulates IPv4 packets into IPv6 packets. The 91 Tunnel End Point (TEP) is also defined as the destination of the 92 IPv6 packet containing an IPv4 packet. Providing the MN node knows 93 were the TEP is, in the domain it happens to be in, it can use MIPv6 94 to send an encapsulated IPv4 packet to the IPv4 CN. 96 So, lets see how a Dual Stack MN would use DSTM and MIPv6 to 97 initiate an IPv4 based communication. The examples below are 98 borrowed from [DSTM] and modified for our purpose. Similar notation 99 is also used: 101 2 102 <2001> 104 MN will designate an IPv6 host with a dual stack, MN6 will be the 105 IPv6 address of this host and MN4 its IPv4 address. 106 TEP will designate the Dual Stack Tunnel End Point of the network. 107 CN will designate an IPv4-only host and CN4 its address. 108 ==> means an IPv6 packet 109 --> an IPv4 packet 110 ++> a tunneled IPv4 packet that is encapsulated in an IPv6 packet 111 ..> a DNS query or response. The path taken by this packet 112 does not matter in the examples. "a" means the DNS name of a 113 host 115 DNS DHCPv6 116 MN6 TEP CN4 117 | | | 118 |. . .> Z | | - MN6 asks DNS for an A6 for "CN4" 119 |<. . .error | | - the DNS answers with an error 120 |. . .> Z | | - MN6 asks for the A RR for "CN4" 121 |<. . . Z4 | | - the answer is CN4 122 | | | 123 | | | 124 | | | - MN6 needs an IPv4 address. 125 |=================> | - MN6 requests from the local DHCPv6 126 | | | server an IPv4 address 127 |<================= | - The DHCPv6 server replies to the MN 128 | | | providing temporarily an IPv4 129 | | | address and the TEP address. 130 |+++++++++++>| | - The MN sends the IPv6 packet to the 131 | | | TEP using its Home Address 132 | |----------->| - The TEP sends the packet to CN4 134 MN6 essentially uses its MIPv6 Care Of Address (COA) in the foreign 135 domain to request an IPv4 address (and the local TEP) from the local 136 DHCPv6 server. It then uses MIPv6 to communicate with the local TEP 137 and encapsulate IPv4 packets destined to external IPv4 only nodes. 138 Even if MN6 moves to a new Access Router in this domain, a BU to the 139 TEP will allow the IPv6 tunnel and the IPv4 packets it encapsulates 140 to be maintained. 142 Note that like [SOL] the level of IPv6 connectivity offered by the 143 above combination is very similar to MIPv4 without route 144 optimization since the IPv4 address used is in fact a dynamically 145 allocated IPv4 Home Address. Also like [SOL], MIPv6 Route 146 optimization is of course used for the path between the MN and the 147 TEP in that domain. 149 It might also be possible for the MN to use the Home DHCPv6 server 150 when in a foreign domain e.g: if the foreign domain does not support 151 DHCPv6. This would require DHCPv6 request to be sent through the 152 Home Agent of the MN. The reply would then include an IPv4 address 153 and a TEP address from the home domain. Data would have to be sent 154 from the MN to the HA to the TEP and eventually to the CN. 156 3 157 <2001> 159 Note that no new protocol or change to any protocol is implied in 160 this draft. We just show how MIPv6 can be combined with DSTM to give 161 basic IPv4 based communication capability to a Dual Stack MN which 162 only supports MIPv6. 164 4. Comparison with [SOL] 166 The main advantage of this approach is that no translation is used 167 for IPv4 communications. [SOL] uses translation for IPv4 168 communications. 170 The main disadvantage of this approach is that all IPv4 171 communications will have to go over one or more TEP boxes that are 172 single points of failure for the IPv4 sessions they support at any 173 one time. In [SOL] this problem is minimized due to the stateless 174 nature of [SIIT]. 176 Finally, care needs to be taken so that the COA the MN uses to 177 request an IPv4 address from the DHCPv6 server, does not expire 178 before the DHCPv6 server manages to allocate the IPv4 address. 179 Movement and thus deprecation of the COA can be handled as long as 180 packets to this COA still reach the MN. [MIPv6] provides mechanisms 181 to allow that. 183 In this draft we do not consider incoming sessions (from IPv4 only 184 nodes outside the IPv6 domain). This is because the [DSTM] 185 specification does not support that functionality but only as a 186 future work item. If and when such mechanisms are developed, they 187 are likely to apply in this draft too. 189 5. Security Considerations 191 The same as those define in [MIPv6] and [DSTM] 193 6. References 195 [DSTM], Jim Bound et.al, Dual Stack Transition Mechanism (DSTM), 196 , October 2000, Work in Progress. 198 [SOL] H. Soliman, E. Nordmark, "Extensions to SIIT and DSTM for 199 enhanced routing of inbound packets", , July 2000, Work in Progress 202 [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", 203 , Work in progress. 205 4 206 <2001> 208 [SIIT] E. Nordmark, "Stateless IP/ICMP Translation Algorithm", 209 RFC2765, February 2000. 211 [NAT-PT] G. Tsirtsis, P. Shrisuresh, "Network Address Translation - 212 Protocol Translation (NAT-PT)", RFC2766, February 2000. 214 7. Acknowledgments 216 This draft is based on [SOL] and offers an alternative to it. 218 Author's Addresses 220 George Tsirtsis 221 Flarion Technologies 222 Phone: +44-20-88260073 223 Email: G.Tsirtsis@Flarion.com 225 Alan O'Neill 226 Flarion Technologies 228 Scott Corson 229 Flarion Technologies 231 5 232 <2001> 234 Copyright Notice 236 Placeholder for ISOC copyright.