idnits 2.17.1 draft-mdt-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 7 instances 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 -- The document date (June 29, 2012) is 4319 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC791' is mentioned on line 538, but not defined == Missing Reference: 'RFC2460' is mentioned on line 538, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) == Missing Reference: 'I-D.xli-behave-icmp-address' is mentioned on line 555, but not defined == Missing Reference: 'RFC4786' is mentioned on line 623, but not defined == Missing Reference: 'RFC5798' is mentioned on line 628, but not defined == Missing Reference: 'RFC0791' is mentioned on line 692, but not defined == Missing Reference: 'RFC3022' is mentioned on line 705, but not defined == Missing Reference: 'RFC6269' is mentioned on line 766, but not defined == Unused Reference: 'I-D.murakami-softwire-4rd' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: 'I-D.xli-behave-divi' is defined on line 1139, but no explicit reference was found in the text == Unused Reference: 'I-D.xli-softwire-divi-pd' is defined on line 1144, but no explicit reference was found in the text == Unused Reference: 'RFC5342' is defined on line 1160, but no explicit reference was found in the text == Unused Reference: 'RFC6346' is defined on line 1171, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-cui-softwire-b4-translated-ds-lite-06 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-02 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-01 == Outdated reference: A later version (-03) exists of draft-mdt-softwire-map-dhcp-option-02 == Outdated reference: A later version (-08) exists of draft-xli-behave-divi-04 ** Obsolete normative reference: RFC 5342 (Obsoleted by RFC 7042) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 5 errors (**), 0 flaws (~~), 20 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: December 31, 2012 FreeBit 6 G. Chen 7 China Mobile 8 C. Sun 9 Softbank BB 10 T. Tsou 11 Huawei Technologies 12 S. Perreault 13 Viagenie 14 June 29, 2012 16 Mapping of Address and Port (MAP) - Deployment Considerations 17 draft-mdt-softwire-map-deployment-02 19 Abstract 21 This document describes when and how an operator uses the technique 22 of Mapping of Address and Port (MAP) for the IPv4 residual deployment 23 in the IPv6-dominant domain. 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 December 31, 2012. 42 Copyright Notice 44 Copyright (c) 2012 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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Fixed networks . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Mobile networks . . . . . . . . . . . . . . . . . . . . . 6 64 4. Deployment Consideration . . . . . . . . . . . . . . . . . . . 8 65 4.1. Network Models . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2. Building the MAP domain . . . . . . . . . . . . . . . . . 9 67 4.2.1. MAP deployment model planning . . . . . . . . . . . . 10 68 4.2.2. MAP domain planning . . . . . . . . . . . . . . . . . 10 69 4.2.3. MAP rule provisioning . . . . . . . . . . . . . . . . 11 70 4.2.4. MAP DHCPv6 server deployment consideration . . . . . . 12 71 4.2.5. PSID consideration . . . . . . . . . . . . . . . . . . 13 72 4.2.6. Addressing and routing . . . . . . . . . . . . . . . . 13 73 4.2.7. Translation vs. Encapsulation . . . . . . . . . . . . 14 74 4.3. BR settings . . . . . . . . . . . . . . . . . . . . . . . 14 75 4.4. CE settings . . . . . . . . . . . . . . . . . . . . . . . 17 76 4.5. Supporting system . . . . . . . . . . . . . . . . . . . . 18 77 5. MAP Address Planning . . . . . . . . . . . . . . . . . . . . . 20 78 5.1. Planning for Residual Deployment, a Step-by-step Guide . . 20 79 5.2. Remarks on Deployment Paradigms . . . . . . . . . . . . . 22 80 6. Migration Methodology . . . . . . . . . . . . . . . . . . . . 24 81 6.1. Roadmap for MAP-based Solution . . . . . . . . . . . . . . 24 82 6.1.1. Start from Scratch . . . . . . . . . . . . . . . . . . 24 83 6.1.2. Coexiting Phases . . . . . . . . . . . . . . . . . . . 24 84 6.1.3. Exit Strategy . . . . . . . . . . . . . . . . . . . . 25 85 6.2. Migration Mode . . . . . . . . . . . . . . . . . . . . . . 25 86 6.2.1. Passive Transition . . . . . . . . . . . . . . . . . . 25 87 6.2.2. Active Transition . . . . . . . . . . . . . . . . . . 26 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 94 1. Introduction 96 IPv4 address exhaustion has become world-wide reality and the primary 97 solution in the industry is to deploy IPv6-only networking. 98 Meanwhile, having access to legacy IPv4 contents and services is a 99 long-term requirement, will be so until the completion of the IPv6 100 transition. It demands sharing residual IPv4 address pools for IPv4 101 communications across the IPv6-only domain(s). 103 Mapping of Address and Port (MAP) [I-D.ietf-softwire-map] is designed 104 in response to the requirement of stateless residual deployment. The 105 term "residual deployment" refers to utilizing not-yet-assigned or 106 recalled IPv4 addresses for IPv4 communications going across the IPv6 107 domain backbone. MAP assumes the IPv6-only backbone as the 108 prerequisite of deployment so that native IPv6 services and 109 applications are fully supported and encouraged. The statelessness 110 of MAP ensures only moderate overhead is added to part of the network 111 devices. 113 Residual deployment with MAP is new to most operators. This document 114 is motivated to provide basic understanding on the usage of MAP, 115 i.e., when and how an operator can do with MAP to meet its own 116 operational requirements of IPv6 transition and its facility 117 conditions, in the phase of IPv4 residual deployment. Potential 118 readers of this document are those who want to know: 120 1. What are the requirements of MAP deployment ? 122 2. What technical options needs to be considered when deploying MAP, 123 and how? 125 3. How does MAP impact on the address planning for both IPv6 and 126 IPv4 pools? 128 4. How does MAP impact on daily network operations and 129 administrations? 131 5. How do we migrate to IPv6-only network with the help of MAP? 133 Terminology of this document, unless it is intentionally specified, 134 follows the definitions and abbreviations of [I-D.ietf-softwire-map]. 136 2. Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 3. Case Studies 144 MAP is suitable for deployment either in large-scale carrier (fixed) 145 networks or in mobile networks. They have similar but different 146 requirements. 148 3.1. Fixed networks 150 There are typically two network models for fixed broadband access 151 service: one is to use PPPoE/PPPoA authentication method while the 152 other is to use IPoE. The first one is usually applied to 153 Residential network and SOHO networks. Subscribers in CPNs can 154 access broadband network by PPP dial-up authentication. BRAS is the 155 key network element which takes full responsibility of IP address 156 assignment, user authentication, traffic aggregation, PPP session 157 termination, etc. Then IP traffic is forwarded to Core Routers 158 through Metro Area Network, and finally transited to Internet via 159 Backbone network. The second network scenario is usually applied to 160 large enterprise networks. Subscribers in CPNs can access broadband 161 network by IPoE authentication. IP address is normally assigned by 162 DHCP server, or static configuration. 164 In either case, a CPE could obtain a prefix via prefix delegation 165 procedure, and the hosts behind CPE would get its own IPv6 addresses 166 within the prefix through SLAAC or DHCPv6 statefully. A MAP CE would 167 also obtain a set of MAP rules from DHCPv6 server. In MAP solution, 168 both encapsulation and double translation can be applied. 170 Figure 1 depicts a generic model of stateless IPv4-over-IPv6 171 communication for fixed broadband access services. 173 +------------------------------+ 174 | MAP Domain | 175 +---+---------------+--------------| 176 +--------+ + | | 177 | | +---------+ +--+--+ | 178 | Host |--| CPE | | | | 179 | | |(MAP CE) |======| BNG | ======+---------+ +-----------+ 180 +--------+ +---------+ +--|--+ | | | IPv4 | 181 +--------+ +---------------+ |Core |---| Internet | 182 | | +---|-----+ +--+--+ |Router | | | 183 | Host |--| CPE |======| | ======+---------+ +-----------+ 184 | | |(MAP CE) | | BNG | | 185 +--------+ +---------+ +--+--+ | 186 + | | 187 +-------------------+--------------+ 189 Figure 1: Stateless IPv4-over-IPv6 access in fixed networks 191 3.2. Mobile networks 193 Regarding the MAP based solution, double translation is more suitable 194 in mobile environment according to the analysis in stateless 195 4V6[I-D.dec-stateless-4v6]. Figure 2 depicts a typical model of MAP 196 deployment in mobile network, where UE plays the rule of MAP CE. 197 There may be three possible cases: IPv4 only, IPv6 only or IPv6 and 198 IPv4 connection to IP devices, depicted as H1, H2 and H3, 199 respectively. The MAP CE may implement a internal NAT44 to provide 200 IPv4 connectin for multiple IP devices. The IP devices get /64 201 prefix from MAP CE through RS/RA. Such a /64 prefix is generated 202 from the prefix assigned by the network through prefix delegation. 203 In the process, IPv6 prefix delegation is asked to derive the shared 204 IPv4 address implicitly. 206 Prefix delegation is introduced in 3GPP network in Release 10. A MAP 207 CE obtains IPv6 prefix from the mobile network. It then initiates 208 DHCPv6 for prefix delegation. There are two phases for a MAP CE to 209 perform prefix delegation function. In the first phase, the MAP CE 210 attaches to the LTE network. The network provides the UE with IPv6 211 only connection and the UE obtains a /64 IPv6 prefix. In the second 212 phase, the MAP CE initiates prefix delegation procedure. The network 213 assigns a prefix shorter than 64 to the MAP CE. Figure 2 shows a 214 case where a /56 is assigned to MAP CE during prefix delegation. 216 +-------------+ 217 |Private IPv4 | 218 | Network | H1 219 +-------------+ 220 | 221 | 222 O-------------------O 223 | UE (MAP CE) | 224 | +-------+-------+ | |------------| |------------| 225 | | NAT44 | 4via6 | | | | | | 226 | | | /64 | |==| E-UTRAN |----| EPC | 227 | +-------+-------+ | |------------| |------------| 228 | | | | 229 | | /56 | | 230 O---------+-------+-O 231 | | 232 | H3 | H2 233 +-------------+ +----------+ 234 | /64 IPv6 | | /64 IPv6 | 235 |&Private IPv4| +----------+ 236 | Network | 237 +-------------+ 239 Figure 2: MAP deployment in mobile network 241 4. Deployment Consideration 243 4.1. Network Models 245 MAP domain connects IPv4 subnets, including home networks, enterprise 246 networks, and collective residence faclities, with the IPv4 Internet 247 through the IPv6 routing infrastructure. 249 A typical case of home network is shown in Figure 3. 251 +-------+-------+ +-------+-------+ \ 252 | Service | | Service | \ 253 | Provider A | | Provider B | | Service 254 | Router | | Router | | Provider 255 +-------+-------+ +-------+-------+ | network 256 | | / 257 | Customer | / 258 | Internet | / 259 | connections | | 260 +---------+---------+ \ 261 | IPv6 | \ 262 | Customer Edge | \ 263 | Router | / 264 +---------+---------+ / 265 | / 266 | | End-User 267 ---+------------+-------+--------+-------------+--- | network(s) 268 | | | | \ 269 +----+-----+ +----+-----+ +----+-----+ +-----+----+ \ 270 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 271 | | | | | | | | / 272 +----------+ +----------+ +----------+ +----------+ 274 Figure 3: Relations between home networking and MAP domain 276 Three network models are defined in [I-D.ietf-homenet-arch]: A. 277 single ISP, single CER, internal routers; B. two ISPs, two CERs, 278 shared subnet; C. two ISPs, one CER, shared subnet. Model A/B is 279 different with model C in MAP technologies. For model A/B, one CE 280 only need to correspond to a BR, while in model C one CE have to 281 correspond with multiple BRs. Figure 4 illustrate a typical case, 282 where the home network have multiple connections to multiple 283 providers or multiple logical connections to the same provider. In 284 any cases, a CE may have different paths towards multiple MAP border 285 relays. 287 +---------------------+------------------------------+ 288 | Home networking1 | MAP Domain | 289 +---------------------+---------------+--------------| 290 | +--------+ + | | | 291 | | Host | +---------+ +--+--+ | 292 | +--------+--| CPE | | | | 293 | +--------+--|(MAP CE) |======| BNG | ======+---------+ +-----------+ 294 | | Host | +---------+ +-----+ | | | | 295 | +--------+ | | | | | 296 +---------------------+ | Core | | IPv4 | 297 +---------------------+ | |---| | 298 | | | Router | | Internet | 299 | +--------+ | | | | | 300 | | Host | +---------+ +-----+ | | | | 301 | +--------+--| CPE |======| | ======+---------+ +-----------+ 302 | +--------+--|(MAP CE) | | BNG | | 303 | | Host | +---------+ +--+--+ | 304 | +--------+ | | | 305 +---------------------+---------------+--------------+ 306 | Home networking2 | 307 +---------------------+ 309 Figure 4: Network Architecture of Model C 311 4.2. Building the MAP domain 313 When deploying stateless MAP in operational network, a provider 314 should firstly do MAP domain planning based on its own network 315 condition. According to the definition of [I-D.ietf-softwire-map], a 316 MAP domain is a set of MAP CEs and BRs connected to the same virtual 317 link. One MAP domain shares a common BR and has the same set of 318 BMRs, FMRs and DMR, and it can be further divided into multiple sub- 319 domains when multiple IPv4 subnets are deployed in one MAP domain. 320 All CEs in the MAP domain are provisioned with the same set of MAP 321 rules by MAP DHCPv6 server [I-D.mdt-softwire-map-dhcp-option]. There 322 might be multiple BMRs in one MAP domain, and CE would pick up its 323 own BMR by longest prefix matching lookup. However, all CEs within 324 the sub-domain will have the same BMR. in which the BMR of all CEs is 325 the same. In hub and spoke mode, CE would use DMR as its only FMR 326 for outbound traffic; while in mesh mode, a longest-matching prefix 327 lookup is done in the IPv4 routing table and the correct FMR is 328 chosen. 330 Basically, operator should firstly determine its own deployment 331 topology for MAP domain: mesh or Hub and spoke, as different 332 considerations for different deployment models should be applied 333 accordingly. Afterwards, MAP domain planning, MAP rule provision, 334 addressing and routing, etc., for a MAP domain should be taken into 335 consideration. 337 For the scenario where one CE is corresponding to multiple MAP border 338 relays, it is possible that those MAP BRs belong to different MAP 339 domains. The CE must pick up its own MAP rules among these domains. 340 It is a typical case of multihoming. The MAP rules must have the 341 information about BR(s) and the information about the services types 342 and the ISP. 344 4.2.1. MAP deployment model planning 346 In order to do MAP domain planning, an operator should firstly make 347 the decision to choose Mesh or Hub and Spoke topology according to 348 operator's network policy. In Hub and Spoke topology, all traffic 349 within the same MAP domain has to go through BR which will result in 350 less optimized traffic; however, it would simplify the CE process 351 since there is no need to do FMR lookup for each incoming packet. 352 Besides, it would have enhanced management ability as BR can take 353 full control of all the traffic. As a result, it is reasonable to 354 deploy Hub and Spoke topology for network with relatively flat 355 architecture. 357 In mesh topology, traffic optimization can be achieved by CE to CE 358 direct path. It is recommended to apply mesh topology in case CE to 359 CE traffic is high and there are not too many MAP rules, say less 360 than 10 MAP rules, in the specific domain. 362 4.2.2. MAP domain planning 364 Stateless MAP has its own advantage in terms of scalability, high- 365 reliability, etc. As a result, it is reasonable to apply a larger 366 MAP domain to accommodate more subscribers with less BRs. Moreover, 367 a larger MAP domain would also be easier for management and 368 maintenance. However, a larger MAP domain may also result in less 369 optimized traffic in Hub and spoke case, where all traffic has to go 370 through a remote BR. Besides, it will also result in increased 371 number of MAP rules and highly centralized address management, etc. 372 It is a tradeoff to choose appropriate domain coverage. 374 Generally speaking, it is not recommended to use a large MAP domain 375 in Hub and spoke topology. While in mesh topology, it is suggested 376 to adopt a relatively larger MAP domain since traffic optimization 377 has already been guaranteed, and the only concern is to make sure 378 that the number of MAP rules is not too big. 380 Furthermore, MAP sub-domains can be divided for differentiated 381 service provision. Different sub-domains could be distinguished by 382 different Rule IPv4 prefixes. But all CEs within the same MAP sub- 383 domain would have the same Rule IPv4 prefix, Rule IPv6 prefix and 384 PSID parameters. 386 4.2.3. MAP rule provisioning 388 In stateless MAP, Mesh or Hub and Spoke communications can be 389 achieved among CEs in one MAP domain in terms of assigning 390 appropriate FMR(s) to CEs. We recommend ISP deploy the full Hub and 391 Spoke topology or full mesh topology describe below, because the 392 DHCPv6 server can simply achieve them. 394 4.2.3.1. Full Hub and Spoke Communication among CEs 396 In order to achieve the full communication in the Hub and Spoke 397 topology, no FMR is assigned to CEs. In this topology, when a CE 398 sends packets to another CE in the same MAP domain using the DMR as 399 FMR, the packets must go though BR before arriving at the 400 destination. 402 4.2.3.2. Full Mesh Communication among CEs 404 Assigning all BMRs in MAP domain to each CE as FMRs, Mesh 405 communications can be achieved among all CEs. In this case, when CE 406 receives an IPv4 packet, it looks up for an appropriate FMR with a 407 specific Rule IPv4 prefix which has the longest match with the IPv4 408 destination address. If the FMR is found (destination is one of the 409 CEs in the MAP domain), the packet will be forwarded to associated CE 410 directly without going though BR. If the FMR is not found 411 (destination is out of the MAP domain), the DMR will be selected as 412 FMR, the CE then forwards the packet to the associated BR. 414 4.2.3.3. Mesh or Hub/Spoke communication among some CEs 416 Mesh communications among some CEs along with Hub/Spoke 417 communications among some other CEs can be achieved by which 418 differentiated FMRs are assigned to CEs. For instance, as Figure 5 419 shown, Mapping rule 1, Mapping rule 2, Mapping rule 3 is provisioned 420 to CE1, CE2, CE3 respectively as BMR, and rule 1 and rule2, and rule 421 1 and rule 2 and rule 3, and rule 2 and rule 3 are assigned to CE1, 422 CE2, CE3 respectively, then CE1 and CE2, CE2 and CE3 communicate 423 directly without going though associated BR (Mesh topology), the 424 communication between CE1 and CE3 must go though BR before reaching 425 peer each other (Hub/Spoke topology). 427 +---------------+---------+---------+---------+ 428 | | CE1 | CE2 | CE3 | 429 +---------------+---------+---------+---------+ 430 | BMR | rule 1 | rule 2 | rule 3 | 431 +---------------+---------+---------+---------+ 432 | | rule 1 | rule 1 | rule 2 | 433 | FMRs | rule 2 | rule 2 | rule 3 | 434 | | | rule 3 | | 435 +---------------+---------+---------+---------+ 437 Figure 5: Mapping rules assigned to CEs in example 439 4.2.4. MAP DHCPv6 server deployment consideration 441 All the CEs within a MAP domain will get the same set of MAP rules by 442 DHCPv6 server, including BMR, FMRs and DMR. In one MAP domain, BMR 443 for different CEs might be different, but FMRs and DMR are all the 444 same. Each Mapping Rule keeps a record of Rule IPv6 prefix, Rule 445 IPv4 prefix, Rule EA-bits length and Rule Port Parameters. Section 5 446 would give a step by step example of how to calculate these 447 parameters. 449 In stateless MAP, the deployment of DHCPv6 server is independent with 450 MAP domain planning. So there are three possible ways: 452 MAP domain : DHCPv6 server = 1:1 This is the ideal solution that 453 each MAP domain would have its own MAP DHCPv6 server. In this 454 case, MAP DHCPv6 server only needs to configure parameters for 455 the specific MAP domain. It is highly recommended to adopt 456 this deployment model in stateless MAP. 458 MAP domain : DHCPv6 server = 1:N This might happen when DHCPv6 459 servers are deployed in a large MAP domain in a distributed 460 manner. In this case, all these DHCPv6 servers should be 461 configured with the same set of MAP rules for the MAP domain, 462 including mutiple BMRs, FMRs and DMRs. 464 MAP domain : DHCPv6 server = N:1 This might happen when MAP domain 465 is relatively small and a single MAP DHCPv6 server is deployed 466 in the network. In this case, multiple MAP domains should be 467 distinguished based on CE's IPv6 prefix in different MAP 468 domains. 470 Besides, the situation of remaining IPv4 address prefixes may have 471 big impact on MAP rule planning, especially for service operators who 472 only have rather scattered address space. Since the number of 473 scattered IPv4 address prefixes would be equal to the number of FMR 474 rules within a MAP domain, one should choose as large IPv4 address 475 pool as possible to reduce the number of FMR rules. 477 4.2.5. PSID consideration 479 For PSID provisioning, all the CEs, BR and DHCPv6 server within the 480 same MAP domain should be configured with the same parameter value. 481 All CEs with the same BMR should have the same PSID length. If a 482 provider would like to introduce differentiated address sharing 483 ratios for different CEs, it is better to define multiple MAP sub- 484 domains with different Rule IPv4 prefixes. In this way, MAP domain 485 division is only a logical method, rather than a geographical one. 487 The default PSID offset is chosen as 4 in [I-D.ietf-softwire-map], 488 which will exclude port range of 0-4096. Operator may adjust the 489 value based on actual usage, policy, and service model. 491 With regard to PSID format, both continuous and non-continuous port 492 set can be supported in GMA algorithm. Non-continuous port set has 493 the advantage of better security, UPnP friendly, etc., while 494 continuous port set is the simplest way to implement. Since PSID 495 format should be supported not only in CPEs, BRs and DHCPv6 server, 496 but also in other sustaining systems as well, e.g. traffic logging 497 system, user management system, a provider should make the decision 498 based on a comprehensive investigation on its demand and the reality 499 of existing equipments. 501 Note that some ISPs may need to offer services in a MAP domain with a 502 shared address, e.g. there are hosts FTP server under CEs. The 503 service provisioning may require well-know port range (i.e. port 504 range belong to 0-1023). MAP would provide operators with an option 505 to generate a port range including those in 0-1023. Afterwards, 506 operators could decide to assign it to any requesting user. 508 4.2.6. Addressing and routing 510 In MAP addressing, it should follow the MAP rule planning in the MAP 511 domain. 513 For IPv4 addressing, since the number of scattered IPv4 address 514 prefixes would be equal to the number of FMR rules within a MAP 515 domain, one should choose as large IPv4 address pool as possible to 516 reduce the number of FMR rules.For IPv6 address, the Rule IPv6 517 prefixes should be equal to the end user IPv6 prefix in MAP domain. 519 If ISP has a /24 rule IPv4 prefix with sharing ratio of 64 gives 520 16000 customers, and a /16 rule IPv4 prefix supports 4 million 521 customer. If up the sharing ratio to 256, 64000 and 16 million 522 customers can be supports respectively. For the ISP who have number 523 of scattered IPv4 address prefixes, in order to reduce the FMRs, 524 according to needs of ports they can divide different class. For 525 instance, for the enterprise customers class which need many ports to 526 use, provision them the BMR with low sharing ratio while for the 527 private customers class which don't need so many ports provision them 528 the BMR with high sharing ratio. 530 For MAP routing, there are no IPv4 routes exported to IPv6 networks. 532 4.2.7. Translation vs. Encapsulation 534 1. Option header 536 There may be some options in the IPv4 header, and some of them may 537 not be able to mapped to IPv6 option headers accurately 538 [RFC791][RFC2460]. If Translation is used, those options can not be 539 supported, and packets with those options SHOULD be dropped. 540 Encapsulation does not have this problem. 542 2. ICMP 544 Some IPv4 ICMP codes do not have a corresponding codes in ICMPv6, a 545 detailed analysis on the double translation behavior suggest that 546 some ICMPv4 messages, when they are translated to ICMPv6 and back to 547 ICMPv4 across the IPv6 domain, the accuracy might be sacrificed to 548 some extent. Encapsulation keeps the full transparency of ICMPv4 549 messages, while translation can make in-transition access through 550 either single or double translations with a unified solution. 552 In either the encapsulation or translation mode, if an intermediate 553 node generates an ICMPv6 error message, it should be converted into 554 ICMPv4 version and returned to the source with a special source 555 address set to 192.70.192.254 [I-D.xli-behave-icmp-address], in the 556 stateless MAP architecture. 558 3. PMTU and fragmentation 560 Both translation mode and encapsulation mode have PMTU and 561 fragmentation problem. [RFC6145] discusses the problem in details 562 for the translation, while [RFC2473] could be a good reference on the 563 issue in encapsulation. 565 4.3. BR settings 567 1. BR placement 569 BR placement has important impacts on the operation of a MAP domain. 571 A first concern should be the avoidance of "triangle routing". That 572 is, the path from the CE to an IPv4 peer via the BR should be close 573 to the one that would be taken if the CE had native IPv4 574 connectivity. This can be accomplished easily by placing the BR 575 close to the CE, such that the length of the path from the CE to the 576 BR is minimized. 578 However, minimizing the CE-BR path would ignore a second concern, 579 that of minimizing IPv4 operations. An ISP deploying MAP will 580 probably want to focus on IPv6 operations, while keeping IPv4 581 operational expenditures to a minimum. This would imply that the 582 size of the IPv4 network that the ISP has to administer would be kept 583 to a minimum. Placing the BR near the CE means that the length of 584 the IPv4 network between the BR and the IPv4 Internet would be 585 longer. 587 Moreover, in case where the set of CEs is geographically dispersed, 588 multiple BRs would be needed, which would further enlarge the IPv4 589 network that the ISP has to maintain. 591 Therefore, we offer the following guideline: BRs should be placed as 592 close to the border with the IPv4 Internet as possible while keeping 593 triangle routing to a minimum. Regional POPs should probably be 594 considered as potential candidates. 596 Note also that MAP being stateless, asymmetric routing is possible, 597 meaning that separate BRs can be used for traffic entering and 598 exiting a MAP domain. This option can be considered for its effects 599 on traffic engineering. 601 Anycast can be used to let the network pick BR closest to a CE for 602 traffic exiting the MAP domain. This is accomplished by provisioning 603 a Default Mapping Rule containing an anycast IPv6 address or prefix. 604 Operationally, this allows incremental deployment of BRs in strategic 605 locations without modifying the provisioning system's configuration. 606 CE's close to a newly-deployed BR will automatically start using it. 608 2. Reliability Considerations 610 Reliability of MAP is derived in major part from its statelessness. 611 This means that MAP can benefit from the usual methods of Internet 612 reliability. 614 Anycast, already mentioned in section 4.2.1, can be used to ensure 615 reliability of traffic from CE to BR. Since there can be only one 616 Default Mapping Rule per MAP domain, traffic from CE to BR will 617 always use the same destination address (in encapsulation mode) or 618 prefix (in translation mode). When this address or prefix is 619 anycast, reliability is greatly increased. If a BR goes down, it 620 stops advertising the IPv6 anycast address or prefix, and traffic is 621 automatically re-routed to other BRs. For this mechanism to work 622 correctly, it is crucial that the anycast route announcement be very 623 closely tied to BR availability. See [RFC4786] for best current 624 practices on the operation of anycast services. 626 Anycast covers global reliability. Reliability within a single link 627 can be achieved with the help of a redundancy protocol such as VRRP 628 [RFC5798]. This allows operation of a pair of BRs in active/standby 629 configuration. No state needs to be shared for the operation of MAP, 630 so there is no need to keep the standby node in a "warm" state: as 631 long as it is up and ready to take over the virtual IPv6 address, 632 quick failover can be achieved. This makes the pair behave as a 633 single, much more reliable node, with less reliance on quick routing 634 protocol convergence for reliability. 636 It is expected that production-quality MAP deployments will make use 637 of both anycast and a redundancy protocol such as VRRP. 639 3. MTU/Fragmentation 641 If the MTU is well-managed such that the IPv6 MTU on the CE WAN side 642 interface is set so that no fragmentation occurs within the boundary 643 of the MAP domain, then the 4rd Tunnel MTU can be set to the known 644 IPv6 MTU minus the size of the encapsulating IPv4 header (40 bytes). 645 For example, if the IPv6 MTU is known to be 1500 bytes, the 4rd 646 Tunnel MTU might be set to 1460 bytes. Without more specific 647 information, the 4rd Tunnel MTU SHOULD default to 1280 bytes. 649 When using encapsulation mode, it is important that fragments of a 650 MAP packet sent according to the Default Mapping Rule be handled by 651 the same BR. (This is not required for translation mode.) This can 652 be a problem when using an anycast BR address and routing 653 fluctuations cause fragments of a packet to be routed to multiple 654 BRs. 656 BRs using an anycast address as source can cause problems. If 657 traffic sent by a BR with a source anycast address causes an ICMP 658 error to be returned, that error packet's destination address will be 659 an anycast address, meaning that a different BR might receive it. In 660 the case of a Too Big ICMP error, this could cause a path MTU 661 discovery black hole. Another possible problem could occur if 662 fragmented packets from different BRs using the same anycast address 663 as source happen to contain the same fragment ID. This would break 664 fragment reassembly. 666 Therefore, when using anycast addresses, it is RECOMMENDED that they 667 be only used as destination address, and never as source addresses. 668 BRs SHOULD be configured to accept traffic sent to the anycast 669 address, but use an unicast address as source. 671 In MAP domains where IPv4 addresses are not shared, IPv6 destinations 672 are derived from IPv4 addresses alone. Thus, each IPv4 packet can be 673 encapsulated and decapsulated independently of each other. 4rd 674 processing is completely stateless. 676 On the other hand, in MAP domains where IPv4 addresses are shared, 677 BRs and CEs may have to encapsulate or translate IPv4 packets whose 678 IPv6 destinations depend on destination ports. Precautions are 679 needed, due to the fact that the destination port of a fragmented 680 datagram is available only in its first fragment. A sufficient 681 precaution consists in reassembling each datagram received in 682 multiple packets, and to treat it as though it would have been 683 received in single packet. This function is such that MAP is in this 684 case stateful at the IP layer. (This is common with DS-lite and 685 NAT64/DNS64 which, in addition, are stateful at the transport layer.) 686 At domain entrance, this ensures that all pieces of all received IPv4 687 datagrams go to the right IPv6 destinations. 689 Another peculiarity of shared IPv4 addresses is that, without 690 precaution, a destination could simultaneously receive from different 691 sources fragmented datagrams that have the same Datagram ID (the 692 Identification field of [RFC0791]). This would disturb the 693 reassembly process. To eliminate this risk, CE MUST rewrite the 694 datagram ID to a unique value among CEs sharing an IPv4 address upon 695 sending the packet over a MAP domain. This value SHOULD be generated 696 locally within the port-range assigned to a given CE. Note that 697 replacing a Datagram ID in an IPv4 header implies an update of its 698 Header-checksum field, by adding to it the one's complement 699 difference between the old and the new values. 701 4.4. CE settings 703 1. bridging vs. routing 705 In routing manner, the CE runs a standard NAT44 [RFC3022] using the 706 allocated public address as external IP and ports via DHCPv6 option. 707 When receiving an IPv4 packet with private source address from its 708 end hosts, it performs NAT44 function by translating the source 709 address into public and selecting a port from the allocated port-set. 710 Then it encapsulates/translates the packet with the concentrator's 711 IPv6 address as destination IPv6 address, and forwards it to the 712 concentrator. When receiving an IPv6 packet from the concentrator, 713 the initiator decapsulates/translates the IPv6 packet to get the IPv4 714 packet with public destination IPv4 address. Then it performs NAT44 715 function and translates the destination address into private one. 717 The CE is responsible for performing ALG functions (e.g., SIP, FTP), 718 as well as supporting NAT Traversal mechanisms (e.g., UPnP, NAT-PMP, 719 manual mapping configuration). This is no different from the 720 standard IPv4 NAT today. 722 For the bridging manner, end host would run a software performing CE 723 functionalities. In this case, end host gets public address 724 directly. It is also suggested that the host run a local NAT to map 725 randomly generated ports into the restricted, valid port-set. 726 Another solution is to have the IP stack to only assign ports within 727 the restricted, valid range to applications. Either way the host 728 guarantees that every source port number in the outgoing packets 729 falls into the allocated port-set. 731 2. CE-initiated application 733 CE-initiated case is applied for situations where applications run on 734 CE directly. If the application in CE use the public address 735 directly, it might conflict with other CEs. So it is highly 736 suggested that CE should also run a local NAT to map a private 737 address to public address in CE. In this way, the CE IPv4 address 738 passed to local applications would be conflict with other CEs. 739 Moreover, CE should guarantee that every source port number in the 740 outgoing packets falls into the allocated port-set. 742 4.5. Supporting system 744 1. Lawful Intercept 746 Sharing IPv4 addresses among multiple CEs is susceptible to issues 747 related to lawful intercept. For details, see [RFC6269] section 12. 749 2. Traffic Logging 751 It is always possible for a service provider that operates a MAP 752 domain to determine the IPv6 prefix associated with a MAP IPv4 753 address (and port number in case of a shared address). This mapping 754 is static, and it is therefore unnecessary to log every IPv4 address 755 assignment. However, changes in that static mapping, such as rule 756 changes in the provisioning system, need to be logged in order to be 757 able to know the mapping at any point in time. 759 Sharing IPv4 addresses among multiple CEs is susceptible to issues 760 related to traffic logging. For details, see [RFC6269] sections 8 761 and 13.1. 763 3. Geo-location aware service 765 Sharing IPv4 addresses among multiple CEs is susceptible to issues 766 related to geo-location. For details, see [RFC6269] section 7. 768 4. User Managment (policy control ,etc ... ) 770 MAP IPv4 address assignment, and hence the IPv4 service itself, is 771 tied to the IPv6 prefix lease; thus, the MAP service is also tied to 772 this in terms of authorization, accounting, etc. For example, the 773 MAP address has the same lifetime as its associated IPv6 prefix. 775 5. MAP Address Planning 777 This section is purposed to provide a referential guidance to 778 operators, illustrating a common fashion of address planning with MAP 779 in IPv4 residual deployment. 781 5.1. Planning for Residual Deployment, a Step-by-step Guide 783 Residual deployment starts from IPv6 address planning. 785 (A) IPv6 considerations 787 (A1) Determine the maximum number N of CEs to be supported, and, for 788 generality, suppose N = 2^n. 790 For example, we suppose n = 20. It means there will be up to 791 about one million CEs. 793 (A2) Choose the length x of IPv6 prefixes to be assigned to ordinary 794 customers. 796 Consider we have a /32 IPv6 block, it is not a problem for the 797 IPv6 deployment with the given number of CEs. Let x = 60, 798 allowing subnets inside in each CE delegated networks. 800 (A3) Multiply N by a margin coefficient K, a power of two (K = 2 ^ 801 k), to take into account that: 803 - Some privileged customers may be assigned IPv6 prefixes of 804 length x', shorter than x, to have larger addressing spaces 805 than ordinary customers, both in IPv6 and IPv4; 807 - Due to the hierarchy of routable prefixes, many theoretically 808 delegatable prefixes may not be actually delegatable (ref: host 809 density ratio of [RFC3194]). 811 In our example, let's take k = 0 for simplicity. 813 (B) IPv4 considerations 815 (B1) List all (non overlapping, not yet assigned to any in-running 816 networks) IPv4 prefixes {Hi} that are available for IPv4 817 residual deployment. 819 Suppose that we hold two blocks and not yet assigned to any 820 fixed network: 192.32.0.0/16 and 63.245.0.0/16. 822 (B2) Take enough of them, among the shortest ones, to get a total 823 whose size M is a power of two (M = 2 ^ m), and includes a good 824 proportion of the available IPv4 space. 826 If we use both blocks, M = 2^16 + 2^16, and therefore m = 17. 827 Then PSID length could be 3 bits, the corresponding sharing 828 ratio is also determined so that each CE can have 8192 ports to 829 use under the shared global IPv4 address; and accordingly the 830 EA-bit length is (32 - 16) + 3 = 19 bits. 832 (B3) For each IPv4 prefix, Hi, of length hi, choose an index, say Ri 833 of length ri = m - (32 - hi). 835 All these indexes must be non overlapping prefixes (e.g. 0, 10, 836 110, 111 for one /10, one /11, and two /12). In our example, 837 we pick 0 for a contiguous block while 1 for another. 839 Then we have: 841 H1 = 192.32.0.0./16, h1 = 16, r1 = 1 => R1 = bin(0); 842 H2 = 63.245.0.0./16, h2 = 16, r2 = 1 => R2 = bin(1); 844 Sometimes the IPv4 residual pool is not well aggregated and the 845 contiguous blocks may have different sizes. For example, in (B1), if 846 we have H1 = 59.112.0.0/13 and H2 = 219.120.0.0/16 as the IPv4 847 residual pool, then M = 2^19 + 2^16, and in such a case, we must pick 848 m so that m = ceil(log2(M)), where "ceil(x)" means the minimum 849 integer not less than x, i.e., m = 20 in this case. Therefore r1 = 850 20 - (32 - 13) = 1, while r2 = 20 - (32 - 16) = 4. Several 851 combinations are available for the R1 and R2 and one only needs to 852 pay attention to avoiding overlapping when picking up the values. 854 (C) After (A) and (B), derive the rule(s) 856 (C1) Derive the length c of the MAP domain IPv6 prefix, C, that will 857 appear at the beginning of all delegated prefixes (c = x - (n + 858 k)). 860 (C2) Take any prefix for this C of length c that starts with a RIR- 861 allocated IPv6 prefix. 863 (C3) For each IPv4 prefix Hi, make the rule, in which the key is Hi 864 and the value is the domain IPv6 prefix C followed by the rule 865 index Ri. Then this i-th rule's Rule IPv6 Prefix will have the 866 length of (c + ri). 868 Then we can do that: 870 c = 40 => C = 2001:0db8:ff00::/40 871 Rule 1: Rule IPv6 Prefix = 2001:0db8:ff00::/41 872 Rule 2: Rule IPv6 Prefix = 2001:0db8:ff80::/41 874 If we have different lengths for the Rule IPv4 prefix (as the 875 extra example discussed at the end of (B)), their Rule IPv6 876 prefixes should not have the same length, as their rule index 877 length is different. 879 As a result, for a certain CE delegating 2001:0db8:ff98: 880 7650::/60, its parameters are: 882 Rule IPv6 Prefix = 2001:0db8:ff80::/41 => Rule 2 883 IPv4 Suffix = bin(001 1000 0111 0110 0) 884 PSID = bin(101) = 0x5 885 Rule IPv4 Prefix = 63.245.0.0/16 886 CE IPv4 Address = 63.245.48.236 888 If different sharing ratio is demanded, we may partition CEs into 889 groups and do (A) and (B) for each group, determining the PSID length 890 for them separately. 892 5.2. Remarks on Deployment Paradigms 894 1. IPv6 address planning in residual deployment is independent of 895 the usage of the residual IPv4 addresses. The IPv4 address pool 896 for "residual deployment" contains IPv4 addresses not yet 897 allocated to customers/subscribers and/or those already recalled 898 from ex-customers, re-programmed into relatively well-aggregated 899 blocks. 901 2. It is recommended to have the number of rule entries as less as 902 possible so that the merit of statelss deployment is reflected in 903 practical performances. However, this effort is often 904 constrained by the condition of an operator whether (a): it holds 905 large-enough contigious IPv4 address block(s) for the residual 906 deployment, and (b): a short-enough IPv6 domain prefix so that 907 the /64 delegation is easily satisfied even the EA-bits is quite 908 long. When condition (a) is not satisfied, sub-domains have to 909 be defined for each relatively small but contigious aggregated 910 block; when condition (b) is not satisfied, one has to devide the 911 IPv4 aggregates into smaller blocks artificially in order to 912 reduce the length of EA-bits. When we have good conditions 913 fitting (a) and (b), it is NOT recommended to define short EA- 914 bits with small length of IPv4 suffix (the value p) nor to 915 increase the number of rule entries (also the number of sub- 916 domains) unless it really has to. 918 3. An extreme case is, when EA-bits contain the full IPv4 address 919 while a full IPv4 address is assigned to a CE, i.e., o = p = 32, 920 and q = 0, the MAP address format becomes almost equivalent to 921 RFC6052-format [RFC6052] except the off-domain IPv4 peer's mapped 922 IPv6 address. This frees the domain to distribute rules but the 923 DMR. In such a case, IPv6 addressing is fully dependent of IPv4, 924 which defers from the typical residual deployment case. MAP is 925 mainly designed for residual deployment but also applied for the 926 case of legacy IPv4 networks keeping communication with the IPv4 927 world over the IPv6 domain without renumbering, as long as the 928 address planning doesn't matter. 930 4. Another extreme case is, when EA-bits' length becomes to zero, 931 i.e., o = p = q = 0, a rule actually defines a correspondence 932 between an IPv6 address and an IPv4 address (or a prefix), 933 without any algorithmic correlation to each other. Using such a 934 case in practice is not prohibited by the specification, but it 935 is not recommended to deploy null EA-bits in large scale as the 936 concern discussed in the above Remark 2, and as it has the 937 limitation that the PSID must be null (q = 0) and therefore 938 multiple CEs sharing a same IPv4 address is not supported here. 939 It is recommended to apply a stateful solution, like Lightweight 940 4over6 [I-D.cui-softwire-b4-translated-ds-lite], if a full de- 941 correlation between IPv6 address and IPv4 address as well as port 942 range is demanded. 944 5. A not-so-extreme case, p = 0, o = q, i.e., only PSID is applied 945 for the EA-bits, is also a case possibly happening in practice. 946 It also potentially generates a huge number of rules and 947 therefore large-scale deployment of this case is not recommended 948 either. 950 6. For operators who would like to utilize "some bits" of IPv6 951 address to do service identification, QoS differentiation, etc., 952 it is recommended that these special-purpose bits should be 953 embedded before the EA-bits so as to reduce the possibility of 954 bit-conflict. However, it requires quite shorter IPv6 aggregate 955 prefix of the operator. The bit-conflict is more likely to 956 happen in this case if different domains have different Rule 957 prefix lengths. Operators with this demand should pay attention 958 to the impact on the domain rule planning. 960 6. Migration Methodology 962 6.1. Roadmap for MAP-based Solution 964 6.1.1. Start from Scratch 966 IPv6 deployment normally involves a step-wise approach where parts of 967 the network should properly updated gradually. As IPv6 deployment 968 progresses it may be simpler for operators to employ a single-version 969 network, since deploying both IPv4 and IPv6 in parallel would costs 970 more than IPv6-only network. Therefore switching to an IPv6-only 971 network in relatively small scale will become more prevalent. 972 Meanwhile, a significant part of network will still stay in IPv4 for 973 a long time, especially at early stage of IPv6 transition. There may 974 not be enough public or private IPv4 addresses to support end-to-end 975 network communication, without segmenting the network into small 976 parts with sharing one IPv4 address space. That is a time to 977 introduce MAP-based solution to bridge these IPv4 islands through 978 IPv6 backbone network. 980 6.1.2. Coexiting Phases 982 A operator may has various deployment strategies. The deployment of 983 MAP-based solution(i.e., MAP-encapsulation and MAP-translation) 984 should have a big tolerance to allow different deployment modes to be 985 occuring. Coexisting deployment would be a basic consideration for 986 this casualness. In a potential practice, MAP-E and MAP-T would not 987 only coexist with each other, but also can harmonize with other 988 deployment cases. Here lists some coexisting cases. (Note: more 989 coexisting cases are expected to be investigated in future.) 991 o Case 1: Coexisting between MAP Encapsulation(MAP-E) and MAP 992 Translation(MAP-T) 994 o Case 2: Coexisting between MAP translation(Double Translation) and 995 statelss NAT64 (Single Translation) 997 o Case3: Coexisting between MAP-based solution and native IPv6 998 deployement 1000 Regarding the case 1, MAP[I-D.ietf-softwire-map] has provided a good 1001 pre-condition, in which a unified address format and configuration 1002 rules have been documented to facilitate the collocation of MAP-T and 1003 MAP-E. Received data packets on CE or BR could be differentiated and 1004 processed accordingly through inspecting "Next Header" filed in IP 1005 header. 1007 Regarding the case 2, separated gateway on the ISP network edge may 1008 serve MAP BR and NAT64 respectively. In alternative case, MAP BR or 1009 NAT64 functionality could be configured on the different interfaces 1010 on a standalone gateway. In either case, traffic could be 1011 distributed into proper gateway or interface by addressing diffrent 1012 IPv6 prefix as NAT4prefix and Rule IPv6 prefix. 1014 Regarding the case 3, MAP solutions would not eliminate IPv6 host 1015 accessing MAP CE. Native IPv6 communication should get along with 1016 MAP solution. RFC6204 shoud be applied to CE in this case. Prefix 1017 delegation has two-fold, in which delegated prefix would not only 1018 help to create unique, longer IPv6 prefixes for IPv6 hosts, but also 1019 serve MAP algorithm to implicitly derive shared IPv4 address/port 1020 information. When data packages have been received at CE, it would 1021 distinguish IPv4 packets from native IPv6 packets depending on 1022 preconfigured mapping rules. 1024 6.1.3. Exit Strategy 1026 The benefits of IPv6 + MAP-based solution are that all IPv6 flows 1027 would go directly to the Internet, no need further progressing on 1028 encapsulation or translation. In this way, as more content providers 1029 and service are available over IPv6, the utilization on MAP CE and BR 1030 goes down since fewer destinations require MAP progressing. This way 1031 would advance IPv6, because it provides everyone incentives to use 1032 IPv6, and eventually the result is an pure IPv6 network with no need 1033 for IPv4. As more content providers and hosts equiped with IPv6 1034 capabilities , the MAP utilization goes down until it is eventually 1035 not used at all when all content is IPv6. In this way, MAP has an 1036 "exit strategy". The corresponding solutions will leave the network 1037 in time. 1039 6.2. Migration Mode 1041 IPv4 Residual deployment is an interim phase during IPv6 migration. 1042 It would be beneficial for ISPs, if this phase is as short as 1043 possible since end-to-end IPv6 traversal is the really goals. When 1044 IPv6 is getting more and more mature, MAP solution would be retired 1045 in a natural way or enforced by particular considerations. 1047 6.2.1. Passive Transition 1049 Passive Transition is following IPv4 retirement law. In another 1050 word, MAP would always get along with IPv4 appearance, even all nodes 1051 is dual-stack capable. At a later stage of IPv6 migration, MAP based 1052 solutions can also be served for dual-stack hosts, which is sending 1053 traffic through the IPv4 stack. There is still a value for this 1054 approach because it could steer IPv4 traffic to IPv6 going through a 1055 MAP CE processing. When it comes the time when ISP decide to turn 1056 off IPv4, MAP would be faded due to IPv4 disappearance. 1058 6.2.2. Active Transition 1060 Active Transition is targeting to accelerate IPv4 exit and increase 1061 native IPv6 utilization. A desirable way deploying MAP solution is 1062 only providing IPv6 traversal ability to an IPv4-only host. However, 1063 MAP CE can not determine received traffic is sent from an IPv4 node 1064 or a dual-stack node. In the latter case, IPv6 utilization is 1065 prefered in a common case. When a network evolves to a post-IPv6 1066 era, it might be good for ISP to consider implementing enforcements 1067 rules to help IPv6 migration. There is a set of approach would help 1068 the situation. 1070 o ISP could install only IPv6 record (i.e. AAAA) in DNS server, 1071 which would provide users with IPv6 steering effects. When a host 1072 is IPv6-capable and gets IPv6 DNS reply in advance, MAP 1073 functionalities would be restricted by IPv6-only record reply 1075 o ISP could retrieve shared IPv4 address by increasing sharing 1076 ratio. In this case, number of concurrent IPv4 sessions on MAP CE 1077 would be suppressed. It would encourage native IPv6 growth in 1078 some extent. 1080 o ISP could allocate a dedicated IPv6 prefix for MAP deployment. 1081 The allocation could not only facilitate the differentiation 1082 between MAPed traffic and native IPv6 trafffic, but also clearly 1083 observe the tendency of MAP traffic. When the traffic is getting 1084 down for while, ISP could close the MAP functionalities in some 1085 specific area. It would result networks to native IPv6-only 1086 capable. 1088 7. IANA Considerations 1090 This specification does not require any IANA actions. 1092 8. Security Considerations 1094 There are no new security considerations pertaining to this document. 1096 9. Acknowledgements 1098 Remi Despres contributed the original example of step-by-step 1099 deployment guidance in discussion with the authors. Ole Troan, as 1100 the head of MAP Design Team, joined the discussion directly and 1101 contributed a lot of ideas and comments. We also thank other members 1102 of the MAP Design Team for their comments and suggestions. 1104 10. References 1106 [I-D.cui-softwire-b4-translated-ds-lite] 1107 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1108 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 1109 Architecture", draft-cui-softwire-b4-translated-ds-lite-06 1110 (work in progress), May 2012. 1112 [I-D.dec-stateless-4v6] 1113 Dec, W., Asati, R., and H. Deng, "Stateless 4Via6 Address 1114 Sharing", draft-dec-stateless-4v6-04 (work in progress), 1115 October 2011. 1117 [I-D.ietf-homenet-arch] 1118 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1119 "Home Networking Architecture for IPv6", 1120 draft-ietf-homenet-arch-02 (work in progress), March 2012. 1122 [I-D.ietf-softwire-map] 1123 Troan, O., Dec, W., Li, X., Bao, C., Zhai, Y., Matsushima, 1124 S., and T. Murakami, "Mapping of Address and Port (MAP)", 1125 draft-ietf-softwire-map-01 (work in progress), June 2012. 1127 [I-D.mdt-softwire-map-dhcp-option] 1128 Mrugalski, T., Boucadair, M., Deng, X., Troan, O., and C. 1129 Bao, "DHCPv6 Options for Mapping of Address and Port", 1130 draft-mdt-softwire-map-dhcp-option-02 (work in progress), 1131 January 2012. 1133 [I-D.murakami-softwire-4rd] 1134 Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual 1135 Deployment on IPv6 infrastructure - protocol 1136 specification", draft-murakami-softwire-4rd-01 (work in 1137 progress), September 2011. 1139 [I-D.xli-behave-divi] 1140 Shang, W., Li, X., Zhai, Y., and C. Bao, "dIVI: Dual- 1141 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-04 1142 (work in progress), October 2011. 1144 [I-D.xli-softwire-divi-pd] 1145 Sun, Q., Asati, R., Xie, C., Li, X., Dec, W., and C. Bao, 1146 "dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix 1147 Delegation", draft-xli-softwire-divi-pd-01 (work in 1148 progress), October 2011. 1150 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1151 Requirement Levels", BCP 14, RFC 2119, March 1997. 1153 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1154 IPv6 Specification", RFC 2473, December 1998. 1156 [RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for 1157 Address Assignment Efficiency An Update on the H ratio", 1158 RFC 3194, November 2001. 1160 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 1161 for IEEE 802 Parameters", BCP 141, RFC 5342, 1162 September 2008. 1164 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1165 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1166 October 2010. 1168 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1169 Algorithm", RFC 6145, April 2011. 1171 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 1172 IPv4 Address Shortage", RFC 6346, August 2011. 1174 Authors' Addresses 1176 Qiong Sun 1177 China Telecom 1178 Room 708 No.118, Xizhimenneidajie 1179 Beijing, 100035 1180 P.R.China 1182 Phone: +86 10 5855 2923 1183 Email: sunqiong@ctbri.com.cn 1185 Maoke Chen 1186 FreeBit Co., Ltd. 1187 13F E-space Tower, Maruyama-cho 3-6 1188 Shibuya-ku, Tokyo 150-0044 1189 Japan 1191 Email: fibrib@gmail.com 1193 Gang Chen 1194 China Mobile 1195 28 Xuanwumenxi Ave; Xuanwu District 1196 Beijing 1197 P.R. China 1199 Email: chengang@chinamobile.com 1201 Chunfa Sun 1202 Softbank BB 1203 Tokyo Shiodome Building. 22F 1204 1-9-1,Higashi-Shimbashi,Minato-Ku 1205 Tokyo 105-7322 1206 JAPAN 1208 Email: chunfa.sun@g.softbank.co.jp 1209 Tina Tsou 1210 Huawei Technologies 1211 2330 Central Expressway 1212 Santa Clara, CA 95050 1213 USA 1215 Phone: +1-408-330-4424 1216 Email: tina.tsou.zouting@huawei.com 1218 Simon Perreault 1219 Viagenie 1220 246 Aberdeen 1221 Quebec, QC G1R 2E1 1222 Canada 1224 Phone: +1 418 656 9254 1225 Email: simon.perreault@viagenie.ca