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