idnits 2.17.1 draft-ietf-softwire-map-deployment-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 189 has weird spacing: '... access netwo...' -- The document date (July 15, 2013) is 3928 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.tsou-softwire-port-set-algorithms-analysis' is mentioned on line 412, but not defined == Missing Reference: 'RFC791' is mentioned on line 474, but not defined == Missing Reference: 'RFC2460' is mentioned on line 474, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) == Missing Reference: 'RFC4786' is mentioned on line 579, but not defined == Missing Reference: 'RFC5798' is mentioned on line 584, but not defined == Missing Reference: 'RFC0791' is mentioned on line 643, but not defined == Missing Reference: 'RFC3022' is mentioned on line 656, but not defined == Missing Reference: 'RFC6269' is mentioned on line 716, but not defined == Unused Reference: 'RFC5342' is defined on line 1069, but no explicit reference was found in the text == Unused Reference: 'RFC6346' is defined on line 1076, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-06 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-07 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-03 == Outdated reference: A later version (-08) exists of draft-ietf-softwire-map-t-03 ** Obsolete normative reference: RFC 5342 (Obsoleted by RFC 7042) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-08 Summary: 3 errors (**), 0 flaws (~~), 18 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Sun 3 Internet-Draft China Telecom 4 Intended status: Informational M. Chen 5 Expires: January 16, 2014 FreeBit 6 G. Chen 7 China Mobile 8 T. Tsou 9 Huawei Technologies 10 S. Perreault 11 Viagenie 12 July 15, 2013 14 Mapping of Address and Port (MAP) - Deployment Considerations 15 draft-ietf-softwire-map-deployment-02 17 Abstract 19 This document describes when and how an operator uses the technique 20 of Mapping of Address and Port (MAP) for the IPv4 residual deployment 21 in the IPv6-dominant domain. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 16, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Deployment Consideration . . . . . . . . . . . . . . . . . . . 6 61 4.1. Network Models . . . . . . . . . . . . . . . . . . . . . . 6 62 4.2. Building the MAP Domain . . . . . . . . . . . . . . . . . 7 63 4.2.1. MAP Deployment Model Planning . . . . . . . . . . . . 7 64 4.2.2. MAP Domain Planning . . . . . . . . . . . . . . . . . 8 65 4.2.3. MAP Rule Provisioning . . . . . . . . . . . . . . . . 8 66 4.2.4. MAP DHCPv6 server deployment consideration . . . . . . 9 67 4.2.5. PSID Consideration . . . . . . . . . . . . . . . . . . 10 68 4.2.6. Addressing and Routing . . . . . . . . . . . . . . . . 11 69 4.2.7. MAP vs. MAP-T vs. 4rd . . . . . . . . . . . . . . . . 11 70 4.3. BR Settings . . . . . . . . . . . . . . . . . . . . . . . 13 71 4.4. CE Settings . . . . . . . . . . . . . . . . . . . . . . . 15 72 4.5. Supporting System . . . . . . . . . . . . . . . . . . . . 16 73 5. MAP Address Planning . . . . . . . . . . . . . . . . . . . . . 18 74 5.1. Planning for Residual Deployment, a Step-by-step Guide . . 18 75 5.2. Remarks on Deployment Paradigms . . . . . . . . . . . . . 20 76 6. Migration Methodology . . . . . . . . . . . . . . . . . . . . 22 77 6.1. Roadmap for MAP-based Solution . . . . . . . . . . . . . . 22 78 6.1.1. Start from Scratch . . . . . . . . . . . . . . . . . . 22 79 6.1.2. Coexiting Phases . . . . . . . . . . . . . . . . . . . 22 80 6.1.3. Exit Strategy . . . . . . . . . . . . . . . . . . . . 22 81 6.2. Migration Mode . . . . . . . . . . . . . . . . . . . . . . 23 82 6.2.1. Passive Transition . . . . . . . . . . . . . . . . . . 23 83 6.2.2. Active Transition . . . . . . . . . . . . . . . . . . 23 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 86 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 28 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 29 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 93 1. Introduction 95 IPv4 address exhaustion has become world-wide reality and the primary 96 solution in the industry is to deploy IPv6-only networking. 97 Meanwhile, having access to legacy IPv4 contents and services is a 98 long-term requirement, will be so until the completion of the IPv6 99 transition. It demands sharing residual IPv4 address pools for IPv4 100 communications across the IPv6-only domain(s). 102 Mapping of Address and Port (MAP) [I-D.ietf-softwire-map] is designed 103 in response to the requirement of stateless residual deployment. The 104 term "residual deployment" refers to utilizing not-yet-assigned or 105 recalled IPv4 addresses for IPv4 communications going across the IPv6 106 domain backbone. MAP assumes the IPv6-only backbone as the 107 prerequisite of deployment so that native IPv6 services and 108 applications are fully supported and encouraged. The statelessness 109 of MAP ensures only moderate overhead is added to part of the network 110 devices. 112 Residual deployment with MAP is new to most operators. This document 113 is motivated to provide basic understanding on the usage of MAP, 114 i.e., when and how an operator can do with MAP to meet its own 115 operational requirements of IPv6 transition and its facility 116 conditions, in the phase of IPv4 residual deployment. Potential 117 readers of this document are those who want to know: 119 1. What are the requirements of MAP deployment ? 121 2. What technical options needs to be considered when deploying MAP, 122 and how? 124 3. How does MAP impact on the address planning for both IPv6 and 125 IPv4 pools? 127 4. How does MAP impact on daily network operations and 128 administrations? 130 5. How do we migrate to IPv6-only network with the help of MAP? 132 Terminology of this document, unless it is intentionally specified, 133 follows the definitions and abbreviations of [I-D.ietf-softwire-map]. 135 Unless it is specifically specified, the deployment considerations 136 and guidance proposed in this document are also applied to MAP-T 137 [I-D.ietf-softwire-map-t], the translation variation of MAP, and 4rd 138 [I-D.ietf-softwire-4rd], the reversible translation approach that 139 aims to improve end-to-end consistency of double translation. 141 2. Conventions 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 3. Case Studies 149 MAP can be deployed for large-scale carrier networks. There are 150 typically two network models for broadband access service: one is to 151 use PPPoE/PPPoA authentication method while the other is to use IPoE. 152 The first one is usually applied to Residential network and SOHO 153 networks. Subscribers in CPNs can access broadband network by PPP 154 dial-up authentication. BRAS is the key network element which takes 155 full responsibility of IP address assignment, user authentication, 156 traffic aggregation, PPP session termination, etc. Then IP traffic 157 is forwarded to Core Routers through Metro Area Network, and finally 158 transited to Internet via Backbone network. The second network 159 scenario is usually applied to large enterprise networks. 160 Subscribers in CPNs can access broadband network by IPoE 161 authentication. IP address is normally assigned by DHCP server, or 162 static configuration. 164 In either case, a Customer Premise Equipment(CPE) could obtain a 165 prefix via prefix delegation procedure, and the hosts behind CPE 166 would get its own IPv6 addresses within the prefix through SLAAC or 167 DHCPv6 statefully. A MAP CE would also obtain a set of MAP rules 168 from DHCPv6 server. 170 Figure 1 depicts a generic model of stateless IPv4-over-IPv6 171 communication for broadband access services. 173 +------------------------------+ 174 | MAP Domain | 175 +---+---------------+--------------| 176 +--------+ + | | 177 | | +---------+ +--+--+ | 178 | Host |--| CPE | | | | 179 | | |(MAP CE) |======| BNG | ======+---------+ +-----------+ 180 +--------+ +---------+ +--|--+ | Core | | IPv4 | 181 +--------+ +---------------+ | Router |---| Internet | 182 | | +---|-----+ +--+--+ |(MAP BR) | | | 183 | Host |--| CPE |======| | ======+---------+ +-----------+ 184 | | |(MAP CE) | | BNG | | 185 +--------+ +---------+ +--+--+ | 186 + | | 187 +-------------------+--------------+ 189 Figure 1: Stateless IPv4-over-IPv6 broadband access network 190 architecture 192 4. Deployment Consideration 194 4.1. Network Models 196 A MAP domain connects IPv4 subnets, including home networks, 197 enterprise networks, and collective residence faclities, with the 198 IPv4 Internet through the IPv6 routing infrastructure. 200 In home network, three network models are defined in 201 [I-D.ietf-homenet-arch]: A. single ISP, single customer edge router 202 (CER), internal routers; B. two ISPs, two CERs, shared subnet; C. two 203 ISPs, one CER, shared subnet. Models A and B are different from 204 model C when using MAP. For models A and B, the CE (=CER) needs to 205 correspond with only one BR, while in model C one CE has to 206 correspond with multiple BRs. Figure 2 illustrates a typical case, 207 where the home network has multiple connections to multiple providers 208 or multiple logical connections to the same provider. In general, a 209 CE may have different paths towards multiple MAP border relays. 211 +-------+-------+ +-------+-------+ \ 212 | Service | | Service | \ 213 | Provider A | | Provider B | | Service 214 | Router | | Router | | Provider 215 +-------+-------+ +-------+-------+ | network 216 | | / 217 | Customer | / 218 | Internet | / 219 | connections | | 220 +---------+---------+ \ 221 | IPv6 | \ 222 | Customer Edge | \ 223 | Router | / 224 +---------+---------+ / 225 | / 226 | | End-User 227 ---+------------+-------+--------+-------------+--- | network(s) 228 | | | | \ 229 +----+-----+ +----+-----+ +----+-----+ +-----+----+ \ 230 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 231 | | | | | | | | / 232 +----------+ +----------+ +----------+ +----------+ 234 Figure 2: Relations between home networking and MAP domain 236 4.2. Building the MAP Domain 238 When deploying stateless MAP in an operational network, a provider 239 should firstly do MAP domain planning based on that existing network. 240 According to the definition of [I-D.ietf-softwire-map], a MAP domain 241 is a set of MAP CEs and BRs connected to the same virtual link. One 242 MAP domain shares a common BR. When multiple IPv4 subnets are 243 deployed in one MAP domain, it is recommanded to further divide the 244 MAP domain into mutiple sub-domains, each with only one IPv4 subnet. 245 This can simplify the MAP domain planning. All CEs in the MAP domain 246 are provisioned with the same set of MAP rules by MAP DHCPv6 server 247 [I-D.ietf-softwire-map-dhcp]. There might be multiple BMRs in one 248 MAP domain, and CE would pick up its own BMR by longest prefix 249 matching lookup. However, all CEs within the sub-domain will have 250 the same BMR. In hub and spoke mode, CE would use DMR as its only 251 FMR for outbound traffic; while in mesh mode, a longest-matching 252 prefix lookup is done in the IPv4 routing table and the correct FMR 253 is chosen. 255 [Note:Currently, there is no DMR in MAP-E. The IPv6 address of the 256 BR could be provisioned by the DS-Lite AFTR Name option. But the DMR 257 is still in use in MAP-T. Is this the final decision ?] 259 Basically, operator should firstly determine its own deployment 260 topology for MAP domain as described in Section 4.2.1, as different 261 considerations apply for different deployment models. Next, MAP 262 domain planning, MAP rule provision, addressing and routing, etc., 263 for a MAP domain should be taken into consideration, as discussed in 264 the sections following Section 4.2.1. 266 For the scenario where one CE is corresponding with multiple MAP 267 border relays, it is possible that those MAP BRs belong to different 268 MAP domains. The CE must pick up its own MAP rules and domain 269 parameters in each domain. This is a typical case of multihoming. 270 The MAP rules must have the information about BR(s) and information 271 about the service types and the ISP. 273 4.2.1. MAP Deployment Model Planning 275 In order to do MAP domain planning, an operator should firstly make 276 the decision to choose mesh or hub and spoke topology according to 277 the operator's network policy. In the hub and spoke topology, all 278 traffic within the same MAP domain has to go through the BR, result 279 in less optimal traffic flow; however, it simplifies CE processing 280 since there is no need to do FMR lookup for each incoming packet. 281 Moreover, it provides enhanced manageability as the BR can tak full 282 control of all the traffic. As a result, it is reasonable to deploy 283 hub and spoke topology for a network with a relatively flat 284 architecture. 286 In mesh topology, CE to CE traffic flows are optimized since they 287 pass directly between the two nodes. Mesh topology is recommended 288 when CE to CE traffic is high and there are not too many MAP rules, 289 say fewer than 10 MAP rules, in the given domain. 291 4.2.2. MAP Domain Planning 293 Stateless MAP offers advantages in terms of scalability, high 294 reliability, etc. As a result, it is reasonable to plan for a larger 295 MAP domain to accommodate more subscribers with fewer BRs. Moreover, 296 a larger MAP domain will also be easier for management and 297 maintenance. However, a larger MAP domain may also result in less 298 optimized traffic in the hub and spoke case, where all traffic has to 299 go through a remote BR. In addition, it will also result in an 300 increased number of MAP rules and highly centralized address 301 management. Choosing appropriate domain coverage requires the 302 evaluation of tradeoffs. 304 MAP subdomains can be defined to support provision of differentiated 305 service. Different subdomains could be distinguished by different 306 Rule IPv4 prefixes. As stated previously, all CEs within the same 307 MAP subdomain will have the same Rule IPv4 prefix, Rule IPv6 prefix 308 and PSID parameters. 310 4.2.3. MAP Rule Provisioning 312 In stateless MAP, Mesh or Hub and Spoke communications can be 313 achieved among CEs in one MAP domain in terms of assigning 314 appropriate FMR(s) to CEs. We recommend ISP deploy the full Hub and 315 Spoke topology or full mesh topology describe below, because the 316 DHCPv6 server can simply achieve them. 318 4.2.3.1. Full Hub and Spoke Communication among CEs 320 In order to achieve the full communication in the Hub and Spoke 321 topology, no FMR is assigned to CEs. In this topology, when a CE 322 sends packets to another CE in the same MAP domain using the DMR as 323 FMR, the packets must go though BR before arriving at the 324 destination. 326 4.2.3.2. Full Mesh Communication among CEs 328 By assigning all BMRs in MAP domain to each CE as FMRs, Mesh 329 communications can be achieved among all CEs. In this case, when CE 330 receives an IPv4 packet, it looks up for an appropriate FMR with a 331 specific Rule IPv4 prefix which has the longest match with the IPv4 332 destination address. If the FMR is found (destination is one of the 333 CEs in the MAP domain), the packet will be forwarded to associated CE 334 directly without going though BR. If the FMR is not found 335 (destination is out of the MAP domain), the DMR will be selected as 336 FMR, the CE then forwards the packet to the associated BR. 338 4.2.3.3. Mesh or Hub/Spoke communication among some CEs 340 Mesh communications among some CEs along with Hub/Spoke 341 communications among some other CEs can be achieved by which 342 differentiated FMRs are assigned to CEs. For instance, as Figure 3 343 shown, Mapping rule 1, Mapping rule 2, Mapping rule 3 is provisioned 344 to CE1, CE2, CE3 respectively as BMR, and rule 1 and rule2, and rule 345 1 and rule 2 and rule 3, and rule 2 and rule 3 are assigned to CE1, 346 CE2, CE3 respectively, then CE1 and CE2, CE2 and CE3 communicate 347 directly without going though associated BR (Mesh topology), the 348 communication between CE1 and CE3 must go though BR before reaching 349 peer each other (Hub/Spoke topology). 351 +---------------+---------+---------+---------+ 352 | | CE1 | CE2 | CE3 | 353 +---------------+---------+---------+---------+ 354 | BMR | rule 1 | rule 2 | rule 3 | 355 +---------------+---------+---------+---------+ 356 | | rule 1 | rule 1 | rule 2 | 357 | FMRs | rule 2 | rule 2 | rule 3 | 358 | | | rule 3 | | 359 +---------------+---------+---------+---------+ 361 Figure 3: Mapping rules assigned to CEs in example 363 4.2.4. MAP DHCPv6 server deployment consideration 365 All the CEs within a MAP domain will get a set of MAP rules by DHCPv6 366 server. Each Mapping Rule keeps a record of Rule IPv6 prefix, Rule 367 IPv4 prefix and Rule EA-bits length. Section 5 would give a step by 368 step example of how to calculate these parameters. 370 As the MAP is stateless, the deployment of DHCPv6 server is 371 independent of MAP domain planning. So there are three possible 372 cases: 374 MAP domain : DHCPv6 server = 1:1 This is the ideal solution that 375 each MAP domain would have its own MAP DHCPv6 server. In this 376 case, MAP DHCPv6 server only needs to configure parameters for 377 the specific MAP domain. It is highly recommended to adopt 378 this deployment model in stateless MAP. 380 MAP domain : DHCPv6 server = 1:N This might happen when DHCPv6 381 servers are deployed in a large MAP domain in a distributed 382 manner. In this case, all these DHCPv6 servers should be 383 configured with the same set of MAP rules for the MAP domain, 384 including mutiple BMRs, FMRs and DMRs. 386 MAP domain : DHCPv6 server = N:1 This might happen when MAP domain 387 is relatively small and a single MAP DHCPv6 server is deployed 388 in the network. In this case, multiple MAP domains should be 389 distinguished based on CE's IPv6 prefix in different MAP 390 domains. 392 Besides, the situation of remaining IPv4 address prefixes may have 393 big impact on MAP rule planning, especially for service operators who 394 only have rather scattered address space. Since the number of 395 scattered IPv4 address prefixes would be equal to the number of FMR 396 rules within a MAP domain, one should choose as large IPv4 address 397 pool as possible to reduce the number of FMR rules. 399 4.2.5. PSID Consideration 401 For PSID provisioning, all CEs with the same BMR should have the same 402 PSID length. If a provider would like to introduce differentiated 403 address sharing ratios for different CEs, it is better to define 404 multiple MAP sub-domains with different Rule IPv4 prefixes. In this 405 way, MAP domain division is only a logical method, rather than a 406 geographical one. 408 The default PSID offset(a) is chosen as 6 in [I-D.ietf-softwire-map] 409 and this excludes the system ports (0-1023). The initial part of the 410 port number (the a-bits) cannot be zero (see Appendix B of 411 [I-D.ietf-softwire-map].) As is shown in the section 3.2.4 of 412 [I-D.tsou-softwire-port-set-algorithms-analysis], it is possible that 413 a lower value of 'a' will give a higher sharing ratio even though 414 more than 1024 ports are excluded as a result, which is due to the 415 effects of rounding. The value of 'a' should be made explicitly 416 provisionable by operators. 418 With regard to PSID format, both continuous and non-continuous port 419 set can be supported in GMA algorithm. Non-continuous port set has 420 the advantage of better UPnP friendly, while continuous port set is 421 the simplest way to implement. Since PSID format should be supported 422 not only in CPEs, BRs and DHCPv6 server, but also in other sustaining 423 systems as well, e.g. traffic logging system, user management system, 424 a provider should make the decision based on a comprehensive 425 investigation on its demand and the reality of existing equipments. 427 Note that some ISPs may need to offer services in a MAP domain with a 428 shared address, e.g. there are hosts FTP server under CEs. The 429 service provisioning may require well-know port range (i.e. port 430 range belong to 0-1023). MAP would provide operators with an option 431 to generate a port range including those in 0-1023. Afterwards, 432 operators could decide to assign it to any requesting user. However, 433 if the port-set is too small, it is not suggested to assign one with 434 only the port set 0~1023 or even less. Considerable non-well-known 435 ports are surely needed. Another easier approach is assigning a 436 dedicated IPv4 address to such a CE if the demand really exists. 438 4.2.6. Addressing and Routing 440 In MAP addressing, it should follow the MAP rule planning in the MAP 441 domain. 443 For IPv4 addressing, since the number of scattered IPv4 address 444 prefixes would be equal to the number of FMR rules within a MAP 445 domain, one should choose as large IPv4 address pool as possible to 446 reduce the number of FMR rules.For IPv6 address, the Rule IPv6 447 prefixes should be equal to the end user IPv6 prefix in MAP domain. 449 If ISP has a /24 rule IPv4 prefix with sharing ratio of 64 gives 450 16000 customers, and a /16 rule IPv4 prefix supports 4 million 451 customer. If up the sharing ratio to 256, 64000 and 16 million 452 customers can be supports respectively. For the ISP who has 453 scattered IPv4 address prefixes, in order to reduce the number of 454 FMRs, according to needs of ports they can divide different classes. 455 For instance, for the enterprise customers class which need many 456 ports to use, provision them the BMR with low sharing ratio while for 457 the private customers class which don't need so many ports provision 458 them the BMR with high sharing ratio. 460 For MAP routing, there are no IPv4 routes exported to IPv6 networks. 462 4.2.7. MAP vs. MAP-T vs. 4rd 464 Basically, encapsulation provides an architectural building block of 465 virtual link where the underlay behavior is fully hidden, while 466 translation does a delivery participating into the end-to-end 467 transferring path where behaviors are exposed. It is reflected in 468 the following aspects. 470 1. Option header 472 There may be some options in the IPv4 header, and some of them may 473 not be able to mapped to IPv6 option headers accurately 474 [RFC791][RFC2460]. If translation or 4rd 'reversible translation' is 475 applied, those options can not be supported, and packets with those 476 options SHOULD be dropped. Encapsulation does not have this problem. 478 2. ICMP 480 Some IPv4 ICMP codes do not have a corresponding codes in ICMPv6, a 481 detailed analysis on the double translation behavior suggest that 482 some ICMPv4 messages, when they are translated to ICMPv6 and back to 483 ICMPv4 across the IPv6 domain, the accuracy might be sacrificed to 484 some extent. Encapsulation keeps the full transparency of ICMPv4 485 messages. 487 Reversible translation approach of 4rd, however, does not translate 488 ICMPv4 messages into ICMPv6 version. Instead, it treats ICMP as same 489 as a transport layer protocol data unit. This behavior is similar to 490 the encapsulation and keeps ICMP end-to-end transparency as well. 492 In either the encapsulation or translation mode, if an intermediate 493 node generates an ICMPv6 error message, it should be converted into 494 ICMPv4 version and returned to the source with a special source 495 address and following the behavior specified in [RFC6791]. However, 496 the behavior and semantics of the translation from ICMPv6 to ICMPv4 497 is different among encapsulation, translation and 4rd reversible 498 translation approaches. Encapsulation treats routing error in the 499 IPv6 domain as an (virtual)link error between the tunnel end points, 500 while translation translate IPv6 routing error into corresponding 501 IPv4 version, and 4rd, however, behaves according to whether the 502 Tunnel Traffic Class option is set. The TTL behavior also reflect 503 the differences among different approaches, which is worth paying 504 attention to for the operating engineers. MAP-T translator is 505 compatible with single translation approach. 507 3. PMTU and fragmentation 509 Both translation mode and encapsulation mode have PMTU and 510 fragmentation problem. [RFC6145] discusses the problem in details 511 for the translation, while [RFC2473] could be a reference on the 512 issue in encapsulation. 514 If the fragment happens in the IPv6 stack, then only the first 515 fragement contains full IPv4 destination address so that BR cannot do 516 the decapsulation well until all fragments has been received. This 517 disables the funtionality of anycast BR. To prevent this problem, 518 MAP require the fragmentation is done in the IPv4 stack to fit the 519 IPv6 domain path MTU. MAP-T and 4rd has not this problem as every 520 IPv6 packet contains the full IPv4 address embedded into the IPv6 521 address and end-point reassembly is ensured. 523 4.3. BR Settings 525 1. BR placement 527 BR placement has important impacts on the operation of a MAP domain. 529 A first concern should be the avoidance of "triangle routing". That 530 is, the path from the CE to an IPv4 peer via the BR should be closer 531 than that would be taken if the CE had native IPv4 connectivity. 532 This can be accomplished easily by placing the BR close to the CE, 533 such that the length of the path from the CE to the BR is minimized. 535 However, minimizing the CE-BR path would ignore a second concern, 536 that of minimizing IPv4 operations. An ISP deploying MAP will 537 probably want to focus on IPv6 operations, while keeping IPv4 538 operational expenditures to a minimum. This would imply that the 539 size of the IPv4 network that the ISP has to administer would be kept 540 to a minimum. Placing the BR near the CE means that the length of 541 the IPv4 network between the BR and the IPv4 Internet would be 542 longer. 544 Moreover, in case where the set of CEs is geographically dispersed, 545 multiple BRs would be needed, which would further enlarge the IPv4 546 network that the ISP has to maintain. 548 Therefore, we offer the following guideline: BRs should be placed as 549 close to the border with the IPv4 Internet as possible while keeping 550 triangle routing to a minimum. Regional POPs should probably be 551 considered as potential candidates. 553 Note also that MAP being stateless, asymmetric routing is possible, 554 meaning that separate BRs can be used for traffic entering and 555 exiting a MAP domain. This option can be considered for its effects 556 on traffic engineering. 558 Anycast can be used to let the network pick BR closest to a CE for 559 traffic exiting the MAP domain. This is accomplished by provisioning 560 a Default Mapping Rule containing an anycast IPv6 address or prefix. 561 Operationally, this allows incremental deployment of BRs in strategic 562 locations without modifying the provisioning system's configuration. 563 CE's close to a newly-deployed BR will automatically start using it. 565 2. Reliability Considerations 567 Reliability of MAP is derived in major part from its statelessness. 568 This means that MAP can benefit from the usual methods of Internet 569 reliability. 571 Anycast, already mentioned in section 4.2.1, can be used to ensure 572 reliability of traffic from CE to BR. Since there can be only one 573 Default Mapping Rule per MAP domain, traffic from CE to BR will 574 always use the same destination address. When this address is 575 anycast, reliability is greatly increased. If a BR goes down, it 576 stops advertising the IPv6 anycast address, and traffic is 577 automatically re-routed to other BRs. For this mechanism to work 578 correctly, it is crucial that the anycast route announcement be very 579 closely tied to BR availability. See [RFC4786] for best current 580 practices on the operation of anycast services. 582 Anycast covers global reliability. Reliability within a single link 583 can be achieved with the help of a redundancy protocol such as VRRP 584 [RFC5798]. This allows operation of a pair of BRs in active/standby 585 configuration. No state needs to be shared for the operation of MAP, 586 so there is no need to keep the standby node in a "warm" state: as 587 long as it is up and ready to take over the virtual IPv6 address, 588 quick failover can be achieved. This makes the pair behave as a 589 single, much more reliable node, with less reliance on quick routing 590 protocol convergence for reliability. 592 It is expected that production-quality MAP deployments will make use 593 of both anycast and a redundancy protocol such as VRRP. 595 3. MTU/Fragmentation 597 If the MTU is well-managed such that the IPv6 MTU on the CE WAN side 598 interface is set so that no fragmentation occurs within the boundary 599 of the MAP domain, then the Tunnel MTU can be set to the known IPv6 600 MTU minus the size of the encapsulating IPv4 header (40 bytes). For 601 example, if the IPv6 MTU is known to be 1500 bytes, the Tunnel MTU 602 might be set to 1460 bytes. Without more specific information, the 603 Tunnel MTU SHOULD default to 1280 bytes. 605 It is important that fragments of a MAP packet sent according to the 606 Default Mapping Rule be handled by the same BR. This can be a 607 problem when using an anycast BR address and routing fluctuations 608 cause fragments of a packet to be routed to multiple BRs. 610 BRs using an anycast address as source can cause problems. If 611 traffic sent by a BR with a source anycast address causes an ICMP 612 error to be returned, that error packet's destination address will be 613 an anycast address, meaning that a different BR might receive it. In 614 the case of a Too Big ICMP error, this could cause a path MTU 615 discovery black hole. Another possible problem could occur if 616 fragmented packets from different BRs using the same anycast address 617 as source happen to contain the same fragment ID. This would break 618 fragment reassembly. Since there is still no simple way to solve it 619 completely, it is recommended to increase the MTU of the IPv6 network 620 so that no fragmentation and Too Big ICMP error occurs. 622 In MAP domains where IPv4 addresses are not shared, IPv6 destinations 623 are derived from IPv4 addresses alone. Thus, each IPv4 packet can be 624 encapsulated and decapsulated independently of each other. The 625 processing is completely stateless. 627 On the other hand, in MAP domains where IPv4 addresses are shared, 628 BRs and CEs may have to encapsulate or translate IPv4 packets whose 629 IPv6 destinations depend on destination ports. Precautions are 630 needed, due to the fact that the destination port of a fragmented 631 datagram is available only in its first fragment. A sufficient 632 precaution consists in reassembling each datagram received in 633 multiple packets, and to treat it as though it would have been 634 received in single packet. This function is such that MAP is in this 635 case stateful at the IP layer. (This is common with DS-lite and 636 NAT64/DNS64 which, in addition, are stateful at the transport layer.) 637 At domain entrance, this ensures that all pieces of all received IPv4 638 datagrams go to the right IPv6 destinations. 640 Another peculiarity of shared IPv4 addresses is that, without 641 precaution, a destination could simultaneously receive from different 642 sources fragmented datagrams that have the same Datagram ID (the 643 Identification field of [RFC0791]). This would disturb the 644 reassembly process. To eliminate this risk, CE MUST rewrite the 645 datagram ID to a unique value among CEs sharing an IPv4 address upon 646 ending the packet over a MAP domain. This value SHOULD be generated 647 locally within the port-range ssigned to a given CE. Note that 648 replacing a Datagram ID in an IPv4 header implies an update of its 649 Header-checksum field, by adding to it the one's complement 650 difference between the old and the new values. 652 4.4. CE Settings 654 1. bridging vs. routing 656 In routing manner, the CE runs a standard NAT44 [RFC3022] using the 657 allocated public address as external IP and ports via DHCPv6 option. 658 When receiving an IPv4 packet with private source address from its 659 end hosts, it performs NAT44 function by translating the source 660 address into public and selecting a port from the allocated port-set. 661 Then it encapsulates/translates the packet with the concentrator's 662 IPv6 address as destination IPv6 address, and forwards it to the 663 concentrator. When receiving an IPv6 packet from the concentrator, 664 the initiator decapsulates/translates the IPv6 packet to get the IPv4 665 packet with public destination IPv4 address. Then it performs NAT44 666 function and translates the destination address into private one. 668 The CE is responsible for performing ALG functions (e.g., SIP, FTP), 669 as well as supporting NAT Traversal mechanisms (e.g., UPnP, NAT-PMP, 670 manual mapping configuration). This is no different from the 671 standard IPv4 NAT today. 673 For the bridging manner, end host would run a software performing CE 674 functionalities. In this case, end host gets public address 675 directly. It is also suggested that the host run a local NAT to map 676 randomly generated ports into the restricted, valid port-set. 677 Another solution is to have the IP stack to only assign ports within 678 the restricted, valid range to applications. Either way the host 679 guarantees that every source port number in the outgoing packets 680 falls into the allocated port-set. 682 2. CE-initiated application 684 CE-initiated case is applied for situations where applications run on 685 CE directly. If the application in CE use the public address 686 directly, it might conflict with other CEs. So it is highly 687 suggested that CE should also run a local NAT to map a private 688 address to public address in CE. In this way, the CE IPv4 address 689 passed to local applications would be conflict with other CEs. 690 Moreover, CE should guarantee that every source port number in the 691 outgoing packets falls into the allocated port-set. 693 4.5. Supporting System 695 1. Lawful Intercept 697 Sharing IPv4 addresses among multiple CEs is susceptible to issues 698 related to lawful intercept. For details, see [RFC6269] section 12. 700 2. Traffic Logging 702 It is always possible for a service provider that operates a MAP 703 domain to determine the IPv6 prefix associated with a MAP IPv4 704 address (and port number in case of a shared address). This mapping 705 is static, and it is therefore unnecessary to log every IPv4 address 706 assignment. However, changes in that static mapping, such as rule 707 changes in the provisioning system, need to be logged in order to be 708 able to know the mapping at any point in time. 710 Sharing IPv4 addresses among multiple CEs is susceptible to issues 711 related to traffic logging. For details, see [RFC6269] sections 8 712 and 13.1. 714 3. Geo-location aware service 715 Sharing IPv4 addresses among multiple CEs is susceptible to issues 716 related to geo-location. For details, see [RFC6269] section 7. 718 4. User Managment 720 MAP IPv4 address assignment, and hence the IPv4 service itself, is 721 tied to the IPv6 prefix lease; thus, the MAP service is also tied to 722 this in terms of authorization, accounting, etc. For example, the 723 MAP address has the same lifetime as its associated IPv6 prefix. 725 5. MAP Address Planning 727 This section is purposed to provide a referential guidance to 728 operators, illustrating a common fashion of address planning with MAP 729 in IPv4 residual deployment. 731 5.1. Planning for Residual Deployment, a Step-by-step Guide 733 Residual deployment starts from IPv6 address planning. 735 (A) IPv6 considerations 737 (A1) Determine the maximum number N of CEs to be supported, and, for 738 generality, suppose N = 2^n. 740 For example, we suppose n = 20. It means there will be up to 741 about one million CEs. 743 (A2) Choose the length x of IPv6 prefixes to be assigned to ordinary 744 customers. 746 Consider we have a /32 IPv6 block, it is not a problem for the 747 IPv6 deployment with the given number of CEs. Let x = 60, 748 allowing subnets inside in each CE delegated networks. 750 (A3) Multiply N by a margin coefficient K, a power of two (K = 2 ^ 751 k), to take into account that: 753 - Some privileged customers may be assigned IPv6 prefixes of 754 length x', shorter than x, to have larger addressing spaces 755 than ordinary customers, both in IPv6 and IPv4; 757 - Due to the hierarchy of routable prefixes, many theoretically 758 delegatable prefixes may not be actually delegatable (ref: host 759 density ratio of [RFC3194]). 761 In our example, let's take k = 0 for simplicity. 763 (B) IPv4 considerations 765 (B1) List all (non overlapping, not yet assigned to any in-running 766 networks) IPv4 prefixes {Hi} that are available for IPv4 767 residual deployment. 769 Suppose that we hold two blocks and not yet assigned to any 770 fixed network: 192.0.2.0/24 and 198.51.100.0/24. 772 (B2) Take enough of them, among the shortest ones, to get a total 773 whose size M is a power of two (M = 2 ^ m), and includes a good 774 proportion of the available IPv4 space. 776 If we use both blocks, M = 2^24 + 2^24, and therefore m = 25. 777 Suppose the intended sharing ratio is 8 subscribers per 778 address, resulting in (65536 - 1024)/8 = 8064 ports per 779 subscriber assuming that the well-known ports are excluded. 780 Then the PSID length to achieve this will be log2(8) = 3 bits. 781 Bearing in mind the IPv4 24 bit prefix length for each of our 782 two prefixes, the EA-bit length is (32 - 24) + 3 = 11 bits. 784 (B3) For each IPv4 prefix, Hi, of length hi, choose an prefix 785 extension, say Ri of length ri = m - (32 - hi). 787 All these indexes must be non overlapping prefixes (e.g. 0, 10, 788 110, 111 for one /10, one /11, and two /12). In our example, 789 we pick 0 for a contiguous address block while 1 for another. 791 Then we have: 793 H1 = 192.0.2.0/24, h1 = 24, r1 = 17 => R1 = bin(0); 794 H2 = 198.51.100.0/24, h2 = 24, r2 = 17 => R2 = bin(1); 796 Sometimes the IPv4 residual pool is not well aggregated and the 797 contiguous address blocks may have different sizes. For example, in 798 (B1), if we have H1 = 59.112.0.0/13 and H2 = 219.120.0.0/16 as the 799 IPv4 residual pool, then M = 2^19 + 2^16, and in such a case, we must 800 pick m so that m = ceil(log2(M)), where "ceil(x)" means the minimum 801 integer not less than x, i.e., m = 20 in this case. Therefore r1 = 802 20 - (32 - 13) = 1, while r2 = 20 - (32 - 16) = 4. Several 803 combinations are available for the R1 and R2 and one only needs to 804 pay attention to avoiding overlapping when picking up the values. 806 (C) After (A) and (B), derive the rule(s) 808 (C1) Derive the length c of the MAP domain IPv6 prefix, C, that will 809 appear at the beginning of all delegated prefixes (c = x - (n + 810 k)). 812 (C2) Take any prefix for this C of length c that starts with a RIR- 813 allocated IPv6 prefix. 815 (C3) For each IPv4 prefix Hi, make the rule, in which the key is Hi 816 and the value is the domain IPv6 prefix C followed by the rule 817 index Ri. Then this i-th rule's Rule IPv6 Prefix will have the 818 length of (c + ri). 820 Then we can do that: 822 c = 40 => C = 2001:0db8:ff00::/40 823 Rule 1: Rule IPv6 Prefix = 2001:0db8:ff00::/41 824 Rule 2: Rule IPv6 Prefix = 2001:0db8:ff80::/41 826 If we have different lengths for the Rule IPv4 prefix (as the 827 extra example discussed at the end of (B)), their Rule IPv6 828 prefixes should not have the same length, as their rule index 829 length is different. 831 As a result, for a certain CE delegating 2001:0db8:ff98: 832 7650::/60, its parameters are: 834 Rule IPv6 Prefix = 2001:0db8:ff80::/41 => Rule 2 835 IPv4 Suffix = bin(111 0110 0) 836 PSID = bin(101) = 0x5 837 Rule IPv4 Prefix = 198.51.100.0/24 838 CE IPv4 Address = 198.51.100.236 840 If different sharing ratio is demanded, we may partition CEs into 841 groups and do (A) and (B) for each group, determining the PSID length 842 for them separately. 844 5.2. Remarks on Deployment Paradigms 846 1. IPv6 address planning in residual deployment is independent of 847 the usage of the residual IPv4 addresses. The IPv4 address pool 848 for "residual deployment" contains IPv4 addresses not yet 849 allocated to customers/subscribers and/or those already recalled 850 from ex-customers, re-programmed into relatively well-aggregated 851 blocks. 853 2. It is recommended to have the number of rule entries as less as 854 possible so that the merit of statelss deployment is reflected in 855 practical performances. However, this effort is often 856 constrained by the condition of an operator whether (a): it holds 857 large-enough contigious IPv4 address block(s) for the residual 858 deployment, and (b): a short-enough IPv6 domain prefix so that 859 the /64 delegation is easily satisfied even the EA-bits is quite 860 long. When condition (a) is not satisfied, sub-domains have to 861 be defined for each relatively small but contigious aggregated 862 block; when condition (b) is not satisfied, one has to devide the 863 IPv4 aggregates into smaller blocks artificially in order to 864 reduce the length of EA-bits. When we have good conditions 865 fitting (a) and (b), it is NOT recommended to define short EA- 866 bits with small length of IPv4 suffix (the value p) nor to 867 increase the number of rule entries (also the number of sub- 868 domains) unless it really has to. 870 3. An extreme case is, when EA-bits contain the full IPv4 address 871 while a full IPv4 address is assigned to a CE, i.e., o = p = 32, 872 and q = 0, the MAP address format becomes almost equivalent to 873 RFC6052-format [RFC6052] except the off-domain IPv4 peer's mapped 874 IPv6 address. This frees the domain to distribute rules but the 875 DMR. In such a case, IPv6 addressing is fully dependent of IPv4, 876 which defers from the typical residual deployment case. MAP is 877 mainly designed for residual deployment but also applied for the 878 case of legacy IPv4 networks keeping communication with the IPv4 879 world over the IPv6 domain without renumbering, as long as the 880 address planning doesn't matter. 882 4. Another extreme case is, when EA-bits' length becomes to zero, 883 i.e., o = p = q = 0, a rule actually defines a correspondence 884 between an IPv6 address and an IPv4 address (or a prefix), 885 without any algorithmic correlation to each other. Using such a 886 case in practice is not prohibited by the specification, but it 887 is not recommended to deploy null EA-bits in large scale as the 888 concern discussed in the above Remark 2, and as it has the 889 limitation that the PSID must be null (q = 0) and therefore 890 multiple CEs sharing a same IPv4 address is not supported here. 891 It is recommended to apply a stateful solution, like Lightweight 892 4over6 [I-D.cui-softwire-b4-translated-ds-lite], if a full de- 893 correlation between IPv6 address and IPv4 address as well as port 894 range is demanded. 896 5. A not-so-extreme case, p = 0, o = q, i.e., only PSID is applied 897 for the EA-bits, is also a case possibly happening in practice. 898 It also potentially generates a huge number of rules and 899 therefore large-scale deployment of this case is not recommended 900 either. 902 6. For operators who would like to utilize "some bits" of IPv6 903 address to do service identification, QoS differentiation, etc., 904 it is recommended that these special-purpose bits should be 905 embedded before the EA-bits so as to reduce the possibility of 906 bit-conflict. However, it requires quite shorter IPv6 aggregate 907 prefix of the operator. The bit-conflict is more likely to 908 happen in this case if different domains have different Rule 909 prefix lengths. Operators with this demand should pay attention 910 to the impact on the domain rule planning. 912 6. Migration Methodology 914 6.1. Roadmap for MAP-based Solution 916 6.1.1. Start from Scratch 918 IPv6 deployment normally involves a step-wise approach where parts of 919 the network should properly updated gradually. As IPv6 deployment 920 progresses it may be simpler for operators to employ a single-version 921 network, since deploying both IPv4 and IPv6 in parallel would cost 922 more than IPv6-only network. Therefore switching to an IPv6-only 923 network in realtively small scale will become more prevalent. 924 Meanwhile, a significant part of network will still stay in IPv4 for 925 long time, especially at early stage of IPv6 transition. There may 926 not be enough public or private IPv4 addresses to support end-to-end 927 network communication, without segmenting the network into small 928 parts with sharing one IPv4 address space. That is a time to 929 introduce MAP to bridge these IPv4 islands through IPv6 network. 931 6.1.2. Coexiting Phases 933 SP has various deployment strategy in the middle of transition. It's 934 foreseeable that IPv6 would likely coexist with IPv4 in a long 935 period. The MAP deployment would also fit into the coexisting mode. 936 To be specific, dual-stack technology is recommended in RFC6180 as 937 the simplest deployment model to advance IPv6 deployment. MAP 938 technology could get along well with native IPv6 connections and 939 compatible with residual IPv4 networks. RFC6264 described a 940 incremental transition approach in order to migrate networks to IPv6- 941 only. DS-Lite is treated as a technology to accelerate the whole 942 process. MAP can also take the same role to achieve a smooth 943 transition. 945 6.1.3. Exit Strategy 947 The benefit of IPv6-only + MAP is that all IPv6 flows would go 948 directly to the Internet, no need further progressing on 949 encapsulation or translation. In this way, as more content providers 950 and service are available over IPv6, the utilization on MAP CE and BR 951 goes down since fewer destinations require MAP progressing. This way 952 would advance IPv6, because it provides everyone incentives to use 953 IPv6, and eventually the result is an pure IPv6 network with no need 954 for IPv4. As more content providers and hosts equiped with IPv6 955 capabilities , the MAP utilization goes down until it is eventually 956 not used at all when all content is IPv6. In this way, MAP has an 957 "exit strategy". The corresponding solutions will leave the network 958 in time. 960 6.2. Migration Mode 962 IPv4 Residual deployment is a interim phase during IPv6 migration. 963 It would be beneficial to ISPs, if this phase is as short as possible 964 since end-to-end IPv6 traversal is the really goals. When IPv6 is 965 getting more and more mature, MAP would be retired in a natural way 966 or enforced by particular considerations. 968 6.2.1. Passive Transition 970 Passive Transition is following IPv4 retirement law. In another 971 word, MAP would always get along with IPv4 appearance, even all nodes 972 is dual-stack capable. At a later stage of IPv6 migration, MAP can 973 also be served for dual-stack hosts, which is sending traffic through 974 the IPv4 stack. There is still a value for this approach because it 975 could steer IPv4 traffic to IPv6 going through a MAP CE processing. 976 When it comes the time ISP decide to turn off IPv4, MAP would be 977 faded due to IPv4 disappearance. 979 6.2.2. Active Transition 981 Active Transition is targeting to acclerate IPv4 exit and increase 982 native IPv6 utilization. A desirable way deploying MAP is only 983 providing IPv6 traversal ability to a IPv4-only host. However, MAP 984 CE can not determine received traffic is send from a IPv4 node or a 985 dual-stack node. In the latter case, IPv6 utilization is prefered in 986 a common case. When a network evolves to a post-IPv6 era, it might 987 be good for ISPs to consider to implement enforcement rules to help 988 IPv6 migration. 990 o ISP could install only IPv6 record (i.e. AAAA) in DNS server, 991 which would provide users with IPv6 steering effects. When a host 992 is IPv6-capable and gets IPv6 DNS reply in advance, MAP 993 functionalities would be restricted by IPv6-only record response. 995 o ISP could retrieve shared IPv4 address by increasing sharing 996 ratio. In this case, number of concurrent IPv4 sessions on MAP CE 997 would be suppressed. It would encourage native IPv6 growth in 998 some extent. 1000 o ISP could allocate a dedicated IPv6 prefix for MAP deployment. 1001 The allocation could not only facilitate the differentiation 1002 between MAPed traffic and native IPv6 trafffic, but also clearly 1003 observe the tendency of MAP traffic. When the traffic is getting 1004 down for while, ISP could close the MAP functionalities in some 1005 specific area. It would result networks to native IPv6-only 1006 capable. 1008 7. IANA Considerations 1010 This specification does not require any IANA actions. 1012 8. Security Considerations 1014 There are no new security considerations pertaining to this document. 1016 9. Contributors 1018 The members of the MAP design team are: 1020 Congxiao Bao, Mohamed Boucadair, Gang Chen, Maoke Chen, Wojciech 1021 Dec, Xiaohong Deng, Remi Despres, Jouni Korhonen, Xing Li, Satoru 1022 Matsushima, Tomasz Mrugalski, Tetsuya Murakami, Jacni Qin, Qiong 1023 Sun, Tina Tsou, Dan Wing, Leaf Yeh, and Jan Zorz. 1025 Thanks to Chunfa Sun who was an active co-author of some earlier 1026 versions of this draft. Thanks to Shishio Tsuchiya's valueable 1027 suggestion for this document. 1029 10. Acknowledgements 1031 Remi Despres contributed the original example of step-by-step 1032 deployment guidance in discussion with the authors. Ole Troan, as 1033 the head of MAP Design Team, joined the discussion directly and 1034 contributed a lot of ideas and comments. We also thank other members 1035 of the MAP Design Team for their comments and suggestions. 1037 11. References 1039 11.1. Normative References 1041 [I-D.ietf-softwire-4rd] 1042 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 1043 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 1044 Solution (4rd)", draft-ietf-softwire-4rd-06 (work in 1045 progress), July 2013. 1047 [I-D.ietf-softwire-map] 1048 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 1049 Murakami, T., and T. Taylor, "Mapping of Address and Port 1050 with Encapsulation (MAP)", draft-ietf-softwire-map-07 1051 (work in progress), May 2013. 1053 [I-D.ietf-softwire-map-dhcp] 1054 Mrugalski, T., Troan, O., Dec, W., Bao, C., 1055 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 1056 for Mapping of Address and Port", 1057 draft-ietf-softwire-map-dhcp-03 (work in progress), 1058 February 2013. 1060 [I-D.ietf-softwire-map-t] 1061 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 1062 T. Murakami, "Mapping of Address and Port using 1063 Translation (MAP-T)", draft-ietf-softwire-map-t-03 (work 1064 in progress), July 2013. 1066 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1067 Requirement Levels", BCP 14, RFC 2119, March 1997. 1069 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 1070 for IEEE 802 Parameters", BCP 141, RFC 5342, 1071 September 2008. 1073 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1074 Algorithm", RFC 6145, April 2011. 1076 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 1077 IPv4 Address Shortage", RFC 6346, August 2011. 1079 [RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. 1080 Huston, "Stateless Source Address Mapping for ICMPv6 1081 Packets", RFC 6791, November 2012. 1083 11.2. Informative References 1085 [I-D.cui-softwire-b4-translated-ds-lite] 1086 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1087 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 1088 Architecture", draft-cui-softwire-b4-translated-ds-lite-11 1089 (work in progress), February 2013. 1091 [I-D.ietf-homenet-arch] 1092 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1093 "Home Networking Architecture for IPv6", 1094 draft-ietf-homenet-arch-08 (work in progress), May 2013. 1096 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1097 IPv6 Specification", RFC 2473, December 1998. 1099 [RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for 1100 Address Assignment Efficiency An Update on the H ratio", 1101 RFC 3194, November 2001. 1103 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1104 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1105 October 2010. 1107 Authors' Addresses 1109 Qiong Sun 1110 China Telecom 1111 Room 708 No.118, Xizhimenneidajie 1112 Beijing, 100035 1113 P.R.China 1115 Phone: +86 10 5855 2923 1116 Email: sunqiong@ctbri.com.cn 1118 Maoke Chen 1119 FreeBit Co., Ltd. 1120 13F E-space Tower, Maruyama-cho 3-6 1121 Shibuya-ku, Tokyo 150-0044 1122 Japan 1124 Email: fibrib@gmail.com 1126 Gang Chen 1127 China Mobile 1128 28 Xuanwumenxi Ave; Xuanwu District 1129 Beijing 1130 P.R. China 1132 Email: chengang@chinamobile.com 1134 Tina Tsou 1135 Huawei Technologies 1136 2330 Central Expressway 1137 Santa Clara, CA 95050 1138 USA 1140 Phone: +1-408-330-4424 1141 Email: tina.tsou.zouting@huawei.com 1142 Simon Perreault 1143 Viagenie 1144 246 Aberdeen 1145 Quebec, QC G1R 2E1 1146 Canada 1148 Phone: +1 418 656 9254 1149 Email: simon.perreault@viagenie.ca