idnits 2.17.1 draft-tsirtsis-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 270 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. ** There are 2 instances of lines with control characters in the document. 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 (August 2000) is 8627 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: 'DSTM' is mentioned on line 197, but not defined == Missing Reference: 'MIPv6' is mentioned on line 197, but not defined == Unused Reference: 'MIPV6' is defined on line 205, 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: 9 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Personal G. Tsirtsis 2 A. O'Neill 3 BT 4 Internet Draft S. Corson 5 Document: draft-tsirtsis-v4-over-mipv6-00.txt Ansible Systems 6 Category: Informational August 2000 7 Expires: February 2001 9 IPv4 over Mobile IPv6 for Dual Stack nodes 10 draft-tsirtsis-v4-over-mipv6-00.txt 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 either Tunneling or Protocol Translation 46 [SIIT], [NAT-PT]. 48 [SOL] combines [DSTM] and [SIIT] to allow IPv6 only nodes to 49 communicate with IPv4 only nodes and provides some support for 50 Mobile Nodes in the same domain. 52 1 54 <2000> 56 In this document we present mechanisms to be used for support of 57 IPv4 based communication with a dual stack mobile node (IPv4v6) that 58 only supports Mobile IPv6 (MIPv6), rather than both MIPv4 and MIPv6. 59 The aim is to use MIPv6 for mobility services whilst allowing the 60 Mobile to use its dual stack capabilities for legacy IPv4 61 communications without requiring translation or MIPv4 deployment. 63 2. Dual Stack Mobile Node 65 Imagine a Dual Stack Mobile Node (MN) that only supports MIPv6 and 66 not MIPv4. While stationary and at home the MN does not use its 67 MIPv6 capabilities and thus, looks like a regular Dual Stack node. 68 In an environment like that, one of the most appealing 69 interoperability mechanisms proposed by the NGTRANS WG is called 70 [DSTM]. 72 DSTM allows a dual stack node to use DHCPv6 to configure on demand 73 its IPv4 stack. This offers high utilization of IPv4 address space 74 and no requirements for IPv4 support in the domain. Additionally, 75 while the Node has an IPv4 address, it can communicate with IPv4 76 only nodes without the use of Protocol Translators and/or Address 77 Translators. 79 DSTM has been mainly designed for stationary dual stack nodes. We 80 will now examine how a MN can take advantage of DSTM in a mobile 81 environment. It is clear that if the MN is not moving, DSTM can be 82 directly applicable i.e.: the MN can use DHCPv6 over MIPv6 to 83 communicate with the DSTM server in the home network and request an 84 IPv4 address. The problem is that while MIPv6 can "move" the 85 mobile's IPv6 stack between access points in the network, it is not 86 obvious how it can move the IPv4 stack of the same MN. 88 3. Tunneling IPv4 in IPv6 90 [DSTM] assumes that IPv4 routing is not available in the DSTM 91 domain. The Dynamic Tunneling Interface (DTI)_is defined as an 92 interface that encapsulates IPv4 packets into IPv6 packets. The 93 Tunnel End Point (TEP) is also defined as the destination of the 94 IPv6 packet containing an IPv4 packet. Providing the MN node knows 95 were the TEP in the domain it happens to be in, it can use MIPv6 to 96 send an encapsulated IPv4 packet to the IPv4 CN. 98 So, lets see how a Dual Stack MN would use DSTM and MIPv6 to 99 initiate an IPv4 based communication. The examples below are 100 borrowed from [DSTM] and modified for our purpose. Similar notation 101 is also used: 103 MN will designate an IPv6 host with a dual stack, MN6 will be the 104 IPv6 address of this host and MN4 its IPv4 address. 105 TEP will designate the Dual Stack Tunnel End Point of the network. 106 CN will designate an IPv4-only host and CN4 its address. 108 2 110 <2000> 112 ==> means an IPv6 packet 113 --> an IPv4 packet 114 ++> a tunneled IPv4 packet that is encapsulated in an IPv6 packet 115 ..> a DNS query or response. The path taken by this packet 116 does not matter in the examples. "a" means the DNS name of a 117 host 119 DNS DHCPv6 120 MN6 TEP CN4 121 | | | 122 |. . .> Z | | - MN6 asks DNS for an A6 for "CN4" 123 |<. . .error | | - the DNS answers with an error 124 |. . .> Z | | - MN6 asks for the A RR for "CN4" 125 |<. . . Z4 | | - the answer is CN4 126 | | | 127 | | | 128 | | | - MN6 needs an IPv4 address. 129 |=================> | - MN6 requests from the local DHCPv6 130 | | | server an IPv4 address 131 |<================= | - The DHCPv6 server replies to the MN 132 | | | providing temporarily an IPv4 133 | | | address and the TEP address. 134 |+++++++++++>| | - The MN sends the IPv6 packet to the 135 | | | TEP using its Home Address 136 | |----------->| - The TEP sends the packet to CN4 138 MN6 essentially uses its MIPv6 CCoA in the foreign domain to request 139 an IPv4 address (and the local TEP) from the local DHCPv6 server. It 140 then uses MIPv6 to communicate with the local TEP and encapsulate 141 IPv4 packets destined to external IPv4 only nodes. Even if MN6 moves 142 to a new Access Router in this domain, a BU to the TEP will allow 143 the IPv6 tunnel and the IPv4 packets it encapsulates to be 144 maintained. 146 Note that like [SOL] the level of IPv6 connectivity offered by the 147 above combination is very similar to MIPv4 without route 148 optimization since the IPv4 address used is in fact a dynamically 149 allocated IPv4 Home Address. Also like [SOL], MIPv6 Route 150 optimization is of course used for the path between the MN and the 151 TEP in that domain. 153 It might also be possible for the MN to use the Home DHCPv6 server 154 when in a foreign domain e.g: if the foreign domain does not support 155 DHCPv6. This would require DHCPv6 request to be sent through the 156 Home Agent of the MN. The reply would then include an IPv4 address 157 and a TEP address from the home domain. Data would have to be sent 158 from the MN to the HA to the TEP and eventually to the CN. 160 Note that no new protocol or change to any protocol is implied in 161 this draft. We just show how MIPv6 can be combined with DSTM to give 163 3 165 <2000> 167 basic IPv4 based communication capability to a Dual Stack MN which 168 only supports MIPv6. 170 4. Comparison with [SOL] 172 The main advantage of this approach is that no translation is used 173 for IPv4 communications. [SOL] uses translation for IPv4 174 communications. 176 The main disadvantage of this approach is that all IPv4 177 communications will have to go over one or more TEP boxes that are 178 single points of failure) for the IPv4 sessions they support. In 179 [SOL] this problem is minimized due to the stateless nature of 180 [SIIT]. 182 Finally, care needs to be taken so that the CCoA the MN uses to 183 request an IPv4 address from the DHCPv6 server, does not expire 184 before the DHCPv6 server manages to allocate the IPv4 address. 185 Movement and thus deprecation of the CCoA can be handled as long as 186 packets to this CCoA still reach the MN. [MIPv6] provides mechanisms 187 to allow that. 189 In this draft we do not consider incoming sessions (from IPv4 only 190 nodes outside the IPv6 domain). This is because the [DSTM] 191 specification does not support that functionality but only as a 192 future work item. If and when such mechanisms are developed, they 193 are likely to apply in this draft too. 195 5. Security Considerations 197 The same as those define in [MIPv6] and [DSTM] 199 6. References 201 [SOL] H. Soliman, E. Nordmark, "Extensions to SIIT and DSTM for 202 enhanced routing of inbound packets", , July 2000, Work in Progress 205 [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", 206 , Work in progress. 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 4 216 <2000> 218 7. Acknowledgments 220 This draft is based on [SOL] and offers an alternative to it. 222 Author's Addresses 224 George Tsirtsis 225 BT 226 Phone: +44-20-88260073 227 Email: george.tsirtsis@bt.com 229 Alan O'Neill 230 BT 231 Phone: +44-20-88260073 232 Email: alan.w.oneill@bt.com 234 M. Scott Corson 235 University of Maryland 236 Ansible Systems 237 (+1) 301-405-6630 238 corson@isr.umd.edu 240 Copyright Notice 242 Placeholder for ISOC copyright.