idnits 2.17.00 (12 Aug 2021) /tmp/idnits57719/draft-murakami-softwire-4v6-translation-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 4, 2011) is 3967 days in the past. Is this intentional? 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: 'RFC2460' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'I-D.despres-softwire-sam' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-softwire-dual-stack-lite' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'RFC3513' is defined on line 333, but no explicit reference was found in the text -- No information found for draft-murakami-softwire-4rd - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.murakami-softwire-4rd' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: draft-ietf-softwire-dual-stack-lite has been published as RFC 6333 -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Murakami, Ed. 3 Internet-Draft IP Infusion 4 Intended status: Standards Track G. Chen 5 Expires: January 5, 2012 H. Deng 6 China Mobile 7 W. Dec 8 Cisco Systems 9 S. Matsushima 10 SoftBank Telecom 11 July 4, 2011 13 4via6 Stateless Translation 14 draft-murakami-softwire-4v6-translation-00 16 Abstract 18 This document specify 4via6, a solution for IPv4 connectivity across 19 IPv6 network utilizes 4rd algorithmic address mapping rule as a 20 series of stateless IPv4 over IPv6 migration solutions. 4via6 employ 21 stateless address translation techniques. It is useful for operators 22 who want to provide IPv4 connectivity across restricted bandwidth 23 IPv6 network with stateless operation. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 5, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. 4via6 Translation Framework . . . . . . . . . . . . . . . . . . 4 63 5. Stateless Translation Algorithm . . . . . . . . . . . . . . . . 5 64 6. Behavior of 4via6 Stateless Translation . . . . . . . . . . . . 5 65 6.1. Behavior on 4via6 CE . . . . . . . . . . . . . . . . . . . 5 66 6.2. Behavior on 4via6 BR . . . . . . . . . . . . . . . . . . . 6 67 7. Path MTU and Fragmentation Consideration . . . . . . . . . . . 6 68 8. Comparison with 4rd . . . . . . . . . . . . . . . . . . . . . . 7 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 7 71 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 12.1. Normative References . . . . . . . . . . . . . . . . . . . 7 74 12.2. Informative References . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 4via6 is a solution utilizes the same algorithmic address mapping 80 rule between IPv4 addresses and IPv6 addresses defined in 4rd 81 [I-D.murakami-softwire-4rd]. 4via6 employ stateless address 82 translation techniques well specified in [RFC6145] with the mapping 83 rule in order to communicate IPv4 islands across IPv6 network, 84 instead of IPv6 encapsulation mechanism in 4rd. Address mapping rule 85 defined in [RFC6052] is also employed to preserve correspondant 86 address of outside 4via6 domain. 88 Since additional IP header is required and the size of the packet is 89 increasing in encapsulation solutions, limited bandwidth resource in 90 a network would be consumed by un-negligible overhead. It is 91 undesirable in that has that limitation like wireless network. 4via6 92 is useful for operators who want to provide IPv4 connectivity across 93 restricted bandwidth IPv6 network with stateless operation described 94 in [I-D.operators-softwire-stateless-4v6-motivation]. 96 2. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 3. Terminology 104 4via6 domain (Domain): A set of 4via6 CEs and BRs connected to the 105 same virtual link. A service provider may 106 deploy 4via6 with a single 4via6 domain, or may 107 utilize multiple 4via6 domains. Each domain 108 requires a separate 4via6 prefix. 110 4via6 Border Relay (BR): A 4via6-enabled router managed by the 111 service provider at the edge of a 4via6 domain. 112 A Border Relay router has at least an IPv6- 113 enabled interface and an IPv4 interface 114 connected to the native IPv4 network. A 4via6 115 BR may also be referred to simply as a "BR" 116 within the context of 4via6. 118 4via6 Customer Edge (CE): A device functioning as a Customer Edge 119 router in a 4via6 deployment. In a residential 120 broadband deployment, this type of device is 121 sometimes referred to as a "Residential 122 Gateway" (RG) or "Customer Premises Equipment" 123 (CPE). A typical 4via6 CE adopting 4rd rules 124 will serve a residential site with one WAN side 125 interface, one or more LAN side interfaces. A 126 4via6 CE may also be referred to simply as a 127 "CE" within the context of 4via6. 129 Shared IPv4 address: An IPv4 address that is shared among multiple 130 nodes. Each node has a separate part of the 131 transport layer port space. 133 4. 4via6 Translation Framework 135 Figure 1 depicts the overall architecture with IPv4 users networks 136 connected through routed IPv6 networks. Therein, IPv4 users are 137 connected to IPv6 network via CPE with 4via6 translation modules. 139 > 140 Private IPv4 141 | Network 142 | 143 O-------------------O 144 | CPE | 145 | +-------+-------+ | 146 | | NAT44 | 4via6 | | 147 | | | CE | |\ 148 | +-------+-------+ | \ ,-------. /------. 149 | | \,-' `-. ,-/ `-. 150 O-------------------O / Routed \ O---------O / Public \ 151 / IPv6 \ | |/ IPv4 \ 152 | Network --+ 4via6 +- Network | 153 \ / | BR |\ / 154 \ / O---------O \ / 155 ". ,-' `-. ,-' 156 `-------' `------' 158 Figure 1: Network Topology 160 4via6 CE has two functionalities. The first is to generate an IPv4 161 address or an shared IPv4 address and port-set. The second is to 162 translate an IPv4 packet from/to an IPv6 packet across IPv6 network. 164 When an unique IPv6 prefix is assigned to each CPE from SP's network, 165 4via6 CE in the CPE generates IPv4 address or shared IPv4 address and 166 port-set with 4rd address mapping rule defined in 167 [I-D.murakami-softwire-4rd]. 169 The address mapping rule is also used in 4via6 CE to forward the 170 packets. When 4via6 CE sends a packet to BR, the source address is 171 translated from IPv4 to IPv6 address with 4rd mapping rule and the 172 destination address is translated from IPv4 to IPv6 address with 173 [RFC6052]. In the case of sending the packet to another CE, the 174 destination address is translated with 4rd address mapping rule. 176 NAT44 must be implemented in 4via6 CPE with the behavior conforming 177 to the best current practice documented in [RFC4787], [RFC5508] and 178 [RFC5382]. The NAT44 must translate the port number into the port- 179 set generated in a given 4via6 CE. 181 At a BR side, when the BR sends a packet to a CE, the source address 182 is translated from IPv4 to IPv6 address with [RFC6052] and the 183 destination address is translated from IPv4 to IPv6 with 4rd mapping 184 rule. 186 5. Stateless Translation Algorithm 188 The stateless translation between IPv6 and IPv4 must conform to 189 [RFC6145]. The address mapping rule must be based on 190 [I-D.murakami-softwire-4rd] and [RFC6052]. 192 In 4via6 stateless translation, the only difference is the forwarding 193 mechanism across IPv6 network infrastructure. The automatic 194 tunneling mechanism such as IPv4-in-IPv6 is used in 195 [I-D.murakami-softwire-4rd]. Instead, for the outband direction, the 196 source address is translated with 4rd mapping rule and the 197 destination address is translated with [RFC6052]. From the inbound 198 direction, the source address is translated with [RFC6052] and the 199 destination address is translated with 4rd mapping rule. For the 200 direct communication among CEs, both source address and destination 201 address are translated with only 4rd mapping rule. 203 6. Behavior of 4via6 Stateless Translation 205 6.1. Behavior on 4via6 CE 207 A 4via6 CE that receives IPv4 packets from CE LAN side checks the 208 validity of its source and destination address. It also checks that 209 the packet size is acceptable. If yes, NAT44 changes the IPv4 source 210 address and the source port to its generated global IPv4 address and 211 the port within the generated port-range. After that, 4via6 CE 212 performs the translation of IPv4 source address and IPv4 destination 213 address. The IPv4 source address is changed to the IPv6 address that 214 is assigned to the 4via6 CE. The IPv4 destination address is 215 translated based on [RFC6052]. And the IPv4 header is replaced to 216 the IPv6 header that is generated from the IPv4 header based on 217 [RFC6145]. 219 The 4via6 CE that receives IPv6 packet from CE WAN side checks the 220 validity of its source and destination address. It also checks that 221 the packet size is acceptable. If yes, it translates the IPv6 source 222 and the IPv6 destination address in the received packets. The IPv6 223 destination address is changed to the IPv4 address that is generated 224 in the 4via6 CE based on [I-D.murakami-softwire-4rd]. The IPv6 225 source address is translated based on [RFC6052]. After that, the 226 IPv6 header is replaced to the IPv4 header that is generated from the 227 IPv6 header based on [RFC6145]. 229 6.2. Behavior on 4via6 BR 231 A 4rd BR that receives IPv4 packets from the outside IPv4 network 232 checks the validity of its source and destination address. It also 233 checks that the packet size is acceptable. If yes, it generates the 234 IPv6 destination address from the IPv4 destination address based on 235 [I-D.murakami-softwire-4rd] and translates the IPv4 source address to 236 the IPv6 source address based on [RFC6052]. As the result, the IPv4 237 header is replaced to the IPv6 header based on [RFC6145]. 239 The 4rd BR that receives IPv6 packets from IPv6 network 240 infrastructure checks the validity of its source and destination 241 address. It also checks that the packet size is accpetable. If yes, 242 it generates the IPv4 source address from the IPv6 source address 243 based on [I-D.murakami-softwire-4rd] and translates the IPv6 244 destination address to the IPv4 destination address based on 245 [RFC6052]. As the result, the IPv6 header is replaced to the IPv4 246 header based on [RFC6145]. 248 7. Path MTU and Fragmentation Consideration 250 Basically, Path MTU and Fragmentation must confirm to Section 1.4 of 251 [RFC6145]. 253 In 4via6 stateless transition, a 4via6 BR and a 4via6 CE replace an 254 IPv6 header to an IPv4 header in a received IPv6 packet upon 255 forwarding the packet to a native IPv4 interface. If the size of the 256 IPv4 packet might exceed to the IPv4 MTU on the native IPv4 257 interface, the 4via6 BR and the 4via6 CE might fragment the packet. 258 In order for the receiver to reassemble the fragmented packet 259 correctly, the 4via6 BR and the 4via6 CE must assign an unique value 260 to a datagram ID in IPv4 header upon forwarding the packet to the 261 native IPv4 interface. 263 8. Comparison with 4rd 265 Differing from encapsulation model, translation approach doesn't need 266 to know BR IPv6 address. Instead of that, a IPv6 mapping prefix 267 should be delivered to 4via6 CPEs or 4via6 hosts for generating IPv6 268 address by catenating IPv4 destination address with IPv6 mapping 269 prefix. Such IPv6 mapping prefix shall be either the "Well-Known 270 Prefix" or a "Network-Specific Prefix" unique to the organization 271 deploying the address translators. 273 9. Security Considerations 275 The security consideration is same as [I-D.murakami-softwire-4rd]. 277 10. IANA Consideration 279 This document has no IANA actions. 281 11. Acknowledgements 283 12. References 285 12.1. Normative References 287 [I-D.murakami-softwire-4rd] 288 Murakami, T. and T. Troan, "IPv4 Residual Deployment on 289 IPv6 infrastructure - protocol specification (work in 290 progress)", June 2011. 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 296 (IPv6) Specification", RFC 2460, December 1998. 298 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 299 Architecture", RFC 4291, February 2006. 301 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 302 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 303 October 2010. 305 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 306 Algorithm", RFC 6145, April 2011. 308 12.2. Informative References 310 [I-D.despres-softwire-sam] 311 Despres, R., "Stateless Address Mapping (SAM) - a 312 Simplified Mesh-Softwire Model", 313 draft-despres-softwire-sam-01 (work in progress), 314 July 2010. 316 [I-D.ietf-softwire-dual-stack-lite] 317 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 318 Stack Lite Broadband Deployments Following IPv4 319 Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work 320 in progress), May 2011. 322 [I-D.operators-softwire-stateless-4v6-motivation] 323 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 324 Borges, I., and G. Chen, "Motivations for Stateless IPv4 325 over IPv6 Migration Solutions", 326 draft-operators-softwire-stateless-4v6-motivation-02 (work 327 in progress), June 2011. 329 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 330 E. Lear, "Address Allocation for Private Internets", 331 BCP 5, RFC 1918, February 1996. 333 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 334 (IPv6) Addressing Architecture", RFC 3513, April 2003. 336 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 337 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 338 RFC 4787, January 2007. 340 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 341 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 342 RFC 5382, October 2008. 344 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 345 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 346 April 2009. 348 Authors' Addresses 350 Tetsuya Murakami (editor) 351 IP Infusion 352 1188 East Arques Avenue 353 Sunnyvale 354 USA 356 Email: tetsuya@ipinfusion.com 358 Gang Chen 359 China Mobile 360 53A,Xibianmennei Ave., 361 Xuanwu District, 362 Beijing 100053 363 China 365 Email: chengang@chinamobile.com 367 Hui Deng 368 China Mobile 369 53A,Xibianmennei Ave. 370 Beijing 100053 371 P.R.China 373 Phone: +86-13910750201 374 Email: denghui02@gmail.com 376 Wojciech Dec 377 Cisco Systems 378 Haarlerbergpark Haarlerbergweg 13-19 379 Amsterdam, NOORD-HOLLAND 1101 CH 380 Netherlands 382 Phone: 383 Email: wdec@cisco.com 384 Satoru Matsushima 385 SoftBank Telecom 386 1-9-1 Higashi-Shinbashi, Munato-ku 387 Tokyo 388 Japan 390 Email: satoru.matsushima@tm.softbank.co.jp