idnits 2.17.1 draft-mawatari-softwire-464xlat-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6145], [RFC6146]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2011) is 4558 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6144' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-3gpp-eps' is defined on line 356, but no explicit reference was found in the text == Unused Reference: 'I-D.murakami-softwire-4v6-translation' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'I-D.xli-behave-divi' is defined on line 368, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-17) exists of draft-ietf-behave-nat64-discovery-heuristic-03 == Outdated reference: A later version (-08) exists of draft-xli-behave-divi-04 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Mawatari 3 Internet-Draft Japan Internet Exchange Co.,Ltd. 4 Intended status: Informational M. Kawashima 5 Expires: May 3, 2012 NEC AccessTechnica, Ltd. 6 C. Byrne 7 T-Mobile USA 8 October 31, 2011 10 464XLAT: Combination of Stateful and Stateless Translation 11 draft-mawatari-softwire-464xlat-02 13 Abstract 15 This document describes a method (464XLAT) for IPv4 connectivity 16 across IPv6 network by combination of stateful translation and 17 stateless translation. 464XLAT is a simple technique to provide IPv4 18 access service while avoiding encapsulation by using twice IPv4/IPv6 19 translation standardized in [RFC6145] and [RFC6146]. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 3, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Network Architecture . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Wireline Network Architecture . . . . . . . . . . . . . . 4 60 4.2. Wireless 3GPP Network Architecture . . . . . . . . . . . . 5 61 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.1. Wireline Network Applicability . . . . . . . . . . . . . . 5 63 5.2. Wireless 3GPP Network Applicability . . . . . . . . . . . 6 64 6. Implementation Considerations . . . . . . . . . . . . . . . . 6 65 6.1. IPv6 Address Format . . . . . . . . . . . . . . . . . . . 6 66 6.2. DNS Proxy Implementation . . . . . . . . . . . . . . . . . 7 67 6.3. IPv6 Fragment Header Consideration . . . . . . . . . . . . 7 68 6.4. Auto Prefix Assignment . . . . . . . . . . . . . . . . . . 7 69 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 75 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 The IANA unallocated IPv4 address pool was exhasuted on February 3, 81 2011. It is likely that each RIR's unallocated IPv4 address pool 82 will exhaust in the near future. In this situation, it will be 83 difficult for many networks to assign IPv4 address to end users 84 despite substantial IPv4 connectivity required for mobile devices, 85 smart-grid, and cloud nodes. 87 This document describes an IPv4 over IPv6 solution as one of the 88 measures of IPv4 address extension and encouragement of IPv6 89 deployment. 91 The 464XLAT method described in this document uses twice IPv4/IPv6 92 translation standardized in [RFC6145] and [RFC6146]. It does not 93 require DNS64 [RFC6147], but it may use DNS64. It is also possible 94 to provide single IPv4/IPv6 translation service, which will be needed 95 in the near future. This feature is one of the advantages, because 96 it can be an encouragement to gradually transition to IPv6. 98 2. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Terminology 106 PLAT: PLAT is Provider side translator(XLAT). A stateful 107 translator complies with [RFC6146] that performs 1:N 108 translation. It translates global IPv6 address to global 109 IPv4 address, and vice versa. 111 CLAT: CLAT is Customer side translator(XLAT). A stateless 112 translator complies with [RFC6145] that performs 1:1 113 translation. It algorithmically translates private IPv4 114 address to global IPv6 address, and vice versa. It has also 115 IPv6 router function that can forward IPv6 packet for IPv6 116 hosts in end-user network. Furthermore, it has DNS Proxy 117 function with IPv6 transport that provides name resolution 118 for IPv4 hosts and IPv6 hosts in end-user network. The 119 presence of DNS64 [RFC6147] and any port mapping algorithm 120 are not required. 122 4. Network Architecture 124 464XLAT method is shown in the following figure. 126 4.1. Wireline Network Architecture 128 ---- 129 | v6 | 130 ---- 131 | 132 ---- | .---+---. .------. 133 | v6 |-----+ / \ / \ 134 ---- | ------ / IPv6 \ ------ / IPv4 \ 135 +---| CLAT |---+ Internet +---| PLAT |---+ Internet | 136 ------- | ------ \ / ------ \ / 137 |v4p/v6 |--+ `---------' `----+----' 138 ------- | | 139 ----- | ----- 140 | v4p |----+ | v4g | 141 ----- | ----- 143 <- v4p -> XLAT <--------- v6 --------> XLAT <- v4g -> 145 v6 : Global IPv6 146 v4p : Private IPv4 147 v4g : Global IPv4 149 Figure 1: Wireline Network Topology 151 4.2. Wireless 3GPP Network Architecture 153 ---- 154 | v6 | 155 ---- 156 | 157 .---+---. 158 / \ 159 / IPv6 \ 160 | Internet | 161 \ / 162 UE / Mobile Phone `---------' 163 +----------------------+ | 164 | ---- | | .---+---. .------. 165 | | v6 |----+ | / \ / \ 166 | ---- | ------| / IPv6 PDP \ ------ / IPv4 \ 167 | +---| CLAT |---+ Mobile Core +---| PLAT |--+ Internet | 168 | | ------| \ GGSN / ------ \ / 169 | | | \ ' `----+---' 170 | ------ | | `-------' | 171 | | v4p |---+ | ----- 172 | ------ | | | v4g | 173 +----------------------+ ----- 175 <- v4p -> XLAT <--------- v6 --------> XLAT <- v4g -> 177 v6 : Global IPv6 178 v4p : Private IPv4 179 v4g : Global IPv4 181 Figure 2: Wireless 3GPP Network Topology 183 5. Applicability 185 5.1. Wireline Network Applicability 187 When ISP has IPv6 access network infrastructure and 464XLAT, ISP can 188 provide IPv4 service to end users. 190 If the IXP or another provider operates the PLAT, all ISPs have to do 191 is to deploy IPv6 access network. All ISPs do not need IPv4 192 facilities. They can migrate quickly their operation to an IPv6-only 193 environment. Incidentally, Japan Internet Exchange(JPIX) is 194 providing 464XLAT trial service since July 2010. 196 5.2. Wireless 3GPP Network Applicability 198 In pre-release 9 3GPP networks, GSM and UMTS networks must signal and 199 support both IPv4 and IPv6 PDP attachments to access IPv4 and IPv6 200 network destinations. This is generally not operationally viable 201 since much of the network cost is derived from the number of PDP 202 attachments, both in terms of licenses from the network hardware 203 vendors and in terms of actual hardware resources required to support 204 and maintain the PDP signaling and mobility events. This has been 205 one of the operational challenges of bringing IPv6 to mobile 206 networks, it simply costs more from the network provider perspective 207 and does not result in any new revenues, since customers are not 208 willing to pay for IPv6 access. 210 Now that both global and private IPv4 addresses are scarce to the 211 extent that it is a substantial business risk and limiting growth in 212 many areas, the mobile network providers must support IPv6 address 213 which solve the IP address scarcity issue, but it is not feasible to 214 simply turn on additional IPv6 PDP network attachments since that 215 does not solve the near-term IPv4 scarcity issues and at it also 216 increases cost. The most logical path forward is to replace IPv6 217 with IPv4 and replace the common NAT44 with NAT64 and DNS64. 218 Extensive live network testing with hundreds of friendly-users has 219 shown that IPv6-only network attachments for mobile devices covers 220 over 90% of the common use-cases in Symbian and Android mobile 221 operating systems. The remaining 10% of use-cases do not work 222 because the application requires an IPv4 socket or the application 223 references an IPv4-literal. 225 464XLAT in combination with NAT64 and DNS64 allows 90% of the 226 applications to continue to work with single translation while at the 227 sametime facilitating legacy IPv4-only applications by providing a 228 private IPv4 address and IPv4 route on the host for the applications 229 to reference and bind to. Traffic sourced from the IPv4 interface is 230 immediately routed the NAT46 CLAT function and passed to the IPv6- 231 only mobile network and destine to the PLAT NAT64. 233 6. Implementation Considerations 235 6.1. IPv6 Address Format 237 IPv6 address format in 464XLAT is presented in the following format. 239 +-----------------------------------------------+---------------+ 240 | XLAT prefix(96) | IPv4(32) | 241 +-----------------------------------------------+---------------+ 243 IPv6 Address Format for 464XLAT 245 Source address and destination address have IPv4 address embedded in 246 the low-order 32 bits of the IPv6 address. The format is defined in 247 Section 2.2 of [RFC6052]. However, 464XLAT does not use the Well- 248 Known Prefix "64:ff9b::/96". 250 6.2. DNS Proxy Implementation 252 CLAT perform DNS Proxy for IPv4 hosts and IPv6 hosts in end-user 253 network. It MUST provide name resolution with IPv6 transport. It 254 does not need DNS64 [RFC6147] function. 256 6.3. IPv6 Fragment Header Consideration 258 In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 259 Fragment Header, since IPv4 host does not set the DF bit. However, 260 the IPv6 Fragment Header has been shown to cause operational 261 difficulties in practice due to limited firewall fragmentation 262 support, etc. Therefore, the PLAT and CLAT may provide a 263 configuration function that allows the PLAT and CLAT not to include 264 the Fragment Header for the non-fragmented IPv6 packets. At any 265 rate, both behaviors SHOULD match. 267 6.4. Auto Prefix Assignment 269 Source IPv6 prefix assignment in CLAT is via DHCPv6 prefix delegation 270 or another method. Destination IPv6 prefix assignment in CLAT is via 271 some method. (e.g., DHCPv6 option, TR-069, DNS, HTTP, 272 [I-D.ietf-behave-nat64-discovery-heuristic], etc.) 274 7. Deployment Considerations 276 Even if the Internet access provider for consumers is different from 277 the PLAT provider (another Internet access provider or Internet 278 exchange provider, etc.), it can implement traffic engineering 279 independently from the PLAT provider. Detailed reasons are below. 281 1. The Internet access provider for consumers can figure out IPv4 282 source address and IPv4 destination address from translated IPv6 283 packet header, so it can implement traffic engineering based on 284 IPv4 source address and IPv4 destination address (e.g. traffic 285 monitoring for each IPv4 destination address, packet filtering 286 for each IPv4 destination address, etc.). The Tunneling methods 287 do not have such a advantage, without any deep packet inspection 288 for visualizing the inner IPv4 packet of the tunnel packet. 290 2. If the Internet access provider for consumers can assign IPv6 291 prefix greater than /64 for each subscriber, this 464XLAT method 292 can separate IPv6 prefix for native IPv6 packets and XLAT prefix 293 for IPv4/IPv6 translation packets. Accordingly, it can identify 294 the type of packets ("native IPv6 packets" and "IPv4/IPv6 295 translation packets"), and implement traffic engineering based on 296 IPv6 prefix. 298 This 464XLAT method have two capabilities. One is a IPv6 -> IPv4 -> 299 IPv6 translation for sharing global IPv4 addresses, another is a IPv4 300 -> IPv6 translation for reaching IPv6 only servers from IPv4 only 301 clients that can not support IPv6. IPv4 only clients will remain for 302 a while. 304 8. Security Considerations 306 To implement a PLAT, see security considerations presented in Section 307 5 of [RFC6146]. 309 To implement a CLAT, see security considerations presented in Section 310 7 of [RFC6145]. And furthermore, the CLAT SHOULD perform Bogon 311 filter, and SHOULD have IPv6 firewall function as a IPv6 router. It 312 is useful function for native IPv6 packet and translated IPv6 packet. 313 The CLAT SHOULD check IPv6 packet received from WAN interface. If 314 the packet is invalid prefix (i.e., it is not XLAT prefix), then 315 SHOULD silently drop the packet. In addition, the CLAT SHOULD check 316 IPv4 packet after the translation. If the packet is not match 317 private IPv4 address of LAN, then SHOULD silently drop the packet. 319 9. IANA Considerations 321 This document has no actions for IANA. 323 10. Acknowledgements 325 The authors would like to thank JPIX NOC members and Seiichi Kawamura 326 for their helpful comments. 328 11. References 329 11.1. Normative References 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, March 1997. 334 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 335 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 336 October 2010. 338 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 339 IPv4/IPv6 Translation", RFC 6144, April 2011. 341 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 342 Algorithm", RFC 6145, April 2011. 344 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 345 NAT64: Network Address and Protocol Translation from IPv6 346 Clients to IPv4 Servers", RFC 6146, April 2011. 348 11.2. Informative References 350 [I-D.ietf-behave-nat64-discovery-heuristic] 351 Savolainen, T. and J. Korhonen, "Discovery of a Network- 352 Specific NAT64 Prefix using a Well-Known Name", 353 draft-ietf-behave-nat64-discovery-heuristic-03 (work in 354 progress), October 2011. 356 [I-D.ietf-v6ops-3gpp-eps] 357 Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 358 Bajko, G., and K. Iisakkila, "IPv6 in 3GPP Evolved Packet 359 System", draft-ietf-v6ops-3gpp-eps-08 (work in progress), 360 September 2011. 362 [I-D.murakami-softwire-4v6-translation] 363 Murakami, T., Chen, G., Deng, H., Dec, W., and S. 364 Matsushima, "4via6 Stateless Translation", 365 draft-murakami-softwire-4v6-translation-00 (work in 366 progress), July 2011. 368 [I-D.xli-behave-divi] 369 Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual- 370 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-04 371 (work in progress), October 2011. 373 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 374 Beijnum, "DNS64: DNS Extensions for Network Address 375 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 376 April 2011. 378 Authors' Addresses 380 Masataka Mawatari 381 Japan Internet Exchange Co.,Ltd. 382 KDDI Otemachi Building 19F, 1-8-1 Otemachi, 383 Chiyoda-ku, Tokyo 100-0004 384 JAPAN 386 Phone: +81 3 3243 9579 387 Email: mawatari@jpix.ad.jp 389 Masanobu Kawashima 390 NEC AccessTechnica, Ltd. 391 800, Shimomata 392 Kakegawa-shi, Shizuoka 436-8501 393 JAPAN 395 Phone: +81 537 23 9655 396 Email: kawashimam@vx.jp.nec.com 398 Cameron Byrne 399 T-Mobile USA 400 Bellevue, Washington 98105 401 USA 403 Email: cameron.byrne@t-mobile.com