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