idnits 2.17.1 draft-sun-softwire-stateless-4over6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2011) is 4596 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.bajko-pripaddrassign' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'I-D.bsd-softwire-stateless-port-index-analysis' is defined on line 446, but no explicit reference was found in the text == Unused Reference: 'I-D.murakami-softwire-4rd' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'I-D.sun-v6ops-laft6' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'I-D.tsou-pcp-natcoord' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC6333' is defined on line 503, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-bajko-pripaddrassign-03 == Outdated reference: A later version (-05) exists of draft-ietf-softwire-stateless-4v6-motivation-00 ** Downref: Normative reference to an Informational draft: draft-ietf-softwire-stateless-4v6-motivation (ref. 'I-D.ietf-softwire-stateless-4v6-motivation') == Outdated reference: A later version (-10) exists of draft-tsou-pcp-natcoord-03 ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 4 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 C. Xie 4 Intended status: Standards Track China Telecom 5 Expires: March 28, 2012 Y. Cui 6 J. Wu 7 P. Wu 8 Tsinghua University 9 C. Zhou 10 Huawei Technologies 11 Y. Lee 12 Comcast 13 September 25, 2011 15 Stateless 4over6 in access network 16 draft-sun-softwire-stateless-4over6-00 18 Abstract 20 This document specifies a stateless 4over6 mechanism which moves the 21 translation function from tunnel concentrator (AFTR) to initiators 22 (B4s). It is used for service providers offering residual deployment 23 of the IPv4 service across IPv6-only domains. The concentrator will 24 record the full set of prefix mapping rules independent of the number 25 of subscribers, while the initiator will only keep a single rule of 26 its own sub-domain. The BNG devices can learn the rule set further, 27 to achieve traffic optimization between initiators. In this way, it 28 not only achieve scalability and simplicity feature benefits from 29 stateless address mapping, but also keep CPE functions simple. 30 Besides, flexible addressing and scattered IPv4 address blocks can be 31 supported as well. Traffic optimization can be deployed 32 incrementally when necessary. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 28, 2012. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. Stateless 4over6 Overview . . . . . . . . . . . . . . . . . . 8 71 5. Port Restricted IPv4 Address Allocation . . . . . . . . . . . 10 72 6. Address/Prefix Mapping . . . . . . . . . . . . . . . . . . . . 11 73 6.1. Address/Prefix Mapping format . . . . . . . . . . . . . . 11 74 6.2. Address/Prefix Mapping Procedure . . . . . . . . . . . . . 11 75 6.3. Port mapping algorithm . . . . . . . . . . . . . . . . . . 12 76 7. Stateless 4over6 Initiator Behavior . . . . . . . . . . . . . 13 77 8. Stateless 4over6 Concentrator Behavior . . . . . . . . . . . . 14 78 9. CPE-CPE optimization . . . . . . . . . . . . . . . . . . . . . 15 79 10. Mechanism Analysis . . . . . . . . . . . . . . . . . . . . . . 16 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 Global IPv4 address exhaustion is becoming reality. The dramatic 87 growth of the Internet is accelerating the consumption of available 88 IPv4 addresses together with the scattered IPv4 address blocks, which 89 makes the address shortage problem even worse. It is widely accepted 90 that IPv6 is the only answer to solve the address shortage problem 91 and sustain the long-term growth of the Internet. However, IPv6 92 deployment is a huge systematic project and a lot of challenges will 93 arise, especially in large commercial operational network. 95 In the course of IPv6 transition, CPE is always a big issue for the 96 whole industry. Since CPE is a customer-side device with restricted 97 resource, it is cost sensitive. Moreover, there is lots of legacy 98 CPEs which are owned by customers, in this case, ISP can not upgrade 99 them . Besides, due to the huge number of CPEs, it is of vital 100 importance to keep it simple for easy management and trouble 101 shooting. 103 As discussed in [I-D.ietf-softwire-stateless-4v6-motivation], 104 stateless approaches would have good features of high scalability, 105 reliability and robustness, etc. It is easy to achieve multi-vendor 106 redundancy. However, since stateless solutions have essentially 107 infered the mapping relationship between IPv4 address and IPv6 108 address, it would have some kind of impact on network planning, e.g. 109 address planning, routing, CPE, etc. From service provider 110 perspective, there are several operational requirements on stateless 111 approaches. 113 Firstly, flexible addressing is needed especially when the remaining 114 IPv4 address blocks are rather scattered. Network providers might do 115 address reallocation in their network in the future, e.g. reallocate 116 global IPv4 address for address sharing. And this kind of addressing 117 adjustment need to have little impact on the whole network 118 infrastructure, e.g. informing thoudsands of CPEs within the same 119 domain. 121 Secondly, we need to keep CPE as simple as possible. This will not 122 only reduce the great burden on CPE management and trouble shooting, 123 but also reduce cost and implemenation complexity. 125 Thirdly, stateless solutions should be capable of covering a large 126 area with centralized deployment. Since stateless approaches can 127 achieve high scalability and no performance bottleneck, centralized 128 deployment is good for network management and multi-vendor industry. 129 Given the fact that large scale service providers would normally have 130 few thousand BNGs with different vendors and different versions, it 131 is a huge burden to update all existing BNGs with the new service 132 card. 134 Finally, CPE-CPE traffic optimization should be deployed 135 incrementally. Currently, network architecture for some service 136 providers is already rather flat, and there is no direct link between 137 CPEs. The traffic within the same BNG occupies a small percentage, 138 so CPE-CPE traffic optimization is NOT a MUST in general. It can be 139 only deployed incrementally when necessary. 141 In this document, we propose a stateless 4over6 approach for service 142 providers offering residual deployment of the IPv4 service across 143 IPv6-only domains. In stateless 4over6, the concentrator will record 144 the full set of prefix mapping rules including IPv4 prefix, IPv6 145 prefix and multiplexing ratio, while the initiator will only keep a 146 single rule of its own sub-domain. Thus, all traffic will be firstly 147 tunneled to concentrator by default. The BNG devices can learn the 148 rule set further, to achieve traffic optimization between initiators. 150 This procedure keeps the advantages of stateless 4over6 mechanisms, 151 and prevents the customer devices from complex configuration/ 152 delegation. It "moves" the mapping rules from customer devices up to 153 concentrator and BRAS devices, in which the amount of rules is 154 acceptable. It can still keep the flexible feature of centralized 155 addressing. This is also an extended case which covers stateless 156 addressing sharing for [I-D.cui-softwire-host-4over6]. However, this 157 extension will decrease IPv4 address utilization. Moreover, since 158 port randomization algorithm must use ports within this port-range, 159 it may cause the port randomization algorithm more predictable. 161 2. Requirements Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 3. Terminology 169 Stateless 4over6: stateless 4over6 is an IPv4-over-IPv6 hub and spoke 170 mechanism proposed in this document, which supports address sharing 171 to alleviate the problem of IPv4 address exhaustion, and places the 172 IPv4 translation on the initiator side. 174 Stateless 4over6 initiator (or "initiator" for short): the tunnel 175 client module of stateless 4over6 mechanism. The stateless 4over6 176 initiator could be a host directly connected to IPv6, or an dual- 177 stack CPE in front of an IPv4 local network. It is responsible for 178 IPv4 public-private translation besides tunnel encapsulation and 179 decapsulation. 181 Stateless 4over6 concentrator (or "concentrator" for short): the 182 tunnel servicing module in stateless 4over6 mechanism. The stateless 183 4over6 concentrator connects the ISP IPv6 network and IPv4 Internet. 184 It provides tunnel encapsulation and decapsulation but no IPv4 185 private-public translation. 187 Stateless 4over6 domain(or "SL Domain" for short): The IPv6 network a 188 concentrator covers. Its coverage depends on the placement of the 189 concentrator. For example, if the concentrator is deployed at the 190 Core of MAN, the Domain will cover the whole MAN. 192 Stateless 4over6 sub-domain(or "sub-domain" for short): A IPv6 sub- 193 network where different initiators can share a same IPv4/IPv6 prefix 194 for stateless mapping. It usually depends on the range of IPv4 195 address block and multiplexing ratio. 197 Stateless 4over6 subPre6(or "subPre6" for short): A common IPv6 198 prefix in the sub-domain for stateless address mapping. subPre6 is 199 only a part of IPv6 perfix/address delegated to customers, which will 200 be followed by "user-id" , etc.(refer to section 6 for detail). 202 Stateless 4over6 subPre4(or "subPre4" for short): A common IPv4 203 prefix in the sub-domain for stateless address mapping. Different 204 subscribers in the common sub-domain will have a different identifier 205 (indicated by "Free bits"). For example, if a given subPre4 is 206 "202.112.1/24" and the shared public address for the specific 207 subscriber is "202.112.1.5", then the "Free bits" is "5". 209 Stateless sub-domain Rule(or "sub-domain rule" for short): A mapping 210 rule inculding subPre6, subPre4 and Multiplexing ratio for a specific 211 sub-domain. 213 4. Stateless 4over6 Overview 215 Figure 1 provides an overview of the stateless 4over6 mechanism. A 216 stateless 4over6 initiator which can be either an IPv6 hosts or CPE, 217 and the stateless 4over6 concentrator are seperated by the IPv6 218 network in the middle, so they use IPv4-in-IPv6 tunnel to build IPv4 219 connectivity. One concentrator will cover a SL Domain and there will 220 be one or more sub-domains in it. Each sub-domain will only have one 221 sub-domain rule indicating the common subPre6, subPre4 and 222 multiplexing ratio. These sub-domains can be divided in a rather 223 flexible way. One BNG can have one or more sub-domains, and multiple 224 BNGs can also belong to one sub-domain. The only rule for sub-domain 225 to follow is to have a unique sub-domain rule with a unified 226 multiplexing ratio. 228 +------------------------------+ 229 | Stateless 4over6 Domain | 230 +---+---------------+--------------| 231 +--------+ + Sub-domain | | 232 | | +---------+ +--+--+ | 233 |IPv4 LAN|--|SL 4over6| | | | 234 | | |Initiator|======| BNG | ======+---------+ +-----------+ 235 +--------+ +---------+ +--|--+ |SL 4over6| | IPv4 | 236 +--------+ +---------------+ |Concen- |---| Internet | 237 | | +---|-----+ +--+--+ |trator | | | 238 |IPv4 LAN|--|SL 4over6|======| | ======+---------+ +-----------+ 239 | | |Initiator| | BNG | | 240 +--------+ +---------+ +--+--+ | 241 + Sub-domain | | 242 +-------------------+--------------+ 244 Figure 1 Stateless 4over6 overview 246 An initiator will get its sub-domain rule containing subPre6, subPre4 247 and multiplexing ratio. And it will also get a user prefix which 248 includes a user-id via PPPoE, etc. By combining the user-id and 249 multiplexing ratio, we can deduce the vaule of the "Free bits" and 250 "Port-set id". SubPre4 and "Free bits" will then construct a public 251 address for the customer, while "Port-set id" can be mapped to a 252 certain port set by port mapping algorithm. 254 In this way, an initiator has known its shared IPv4 address and valid 255 port range. For a IPv4 outbound packet arriving at initiator, it 256 will do port-restricted NAT44, then encapuslate with IPv6 header and 257 tunneled to the concentrator by default. The source address and 258 destination address format in IPv6 header will be discussed in the 259 next section. The concentrator will only do packet de-capsulation 260 for outbound packet. When the inbound traffic arriving at 261 concentrator, it will lookup sub-domain rule table based on 262 destination IPv4 address and find out its corresponding subPre6. 263 Then it will construct an IPv6 header algorithmically. Since the 264 number of sub-domain rules is independent of subscriber numbers, it 265 is still a algorithm-based stateless method. Then the inbound 266 traffic will be sent back to customer and perform NAT44 again. 268 5. Port Restricted IPv4 Address Allocation 270 As described above, a stateless 4over6 initiator needs the sub-domain 271 rule containing subPre6, subPre4 and multiplexing ratio. Since these 272 parameters are relatively stable, it can be configured in a variety 273 of provisioning methods, including 274 DHCPv6[I-D.cui-softwire-dhcp-over-tunnel], "TR-069", etc. For 275 customer's IPv6 prefix, it will be delegated just in traditional way, 276 e.g. DHCPv6, Prefix Delegation, etc. And there is no impact on 277 current IPv6 addressing model. The concentrator address can be 278 passed through the same option of ds-lite AFTR address. 280 6. Address/Prefix Mapping 282 6.1. Address/Prefix Mapping format 284 The subscriber source address mapping format is in consistent with 285 [I-D.xli-behave-divi-pd] expect for the last 64 bits. Since 286 stateless 4over6 is a tunnel-based solution, we just set the last 64 287 bits to zero (depicted in Figure2). 289 +--+---------+-------+------+-----+----+-----------+-----------+----+ 290 |PL| 0-------32------48-----56----64---72----------104---------120 | 291 +--+---------+-------+------+-----+----+-----------+-----------+----+ 292 |64| prefix | u | 0 | 293 +--+---------+-------+------+-----+----+-----------+-----------+----+ 294 |e | Prefix-sub |user(CPE)-id| 0 | u | 0 | 0 | 295 |x |-------------+------------+---+----+-----------+-----------+----| 296 |t |(d) bits |(s+k) bits |(m)|(8) | (48) |(8) | 297 +--+---------+-------+------+-----+----+-----------+-----------+----+ 299 Figure 2 Subscriber Source address mapping format 301 The user-id is consisted of the "Free Bits" and "Port-set id". 303 The destination address is the concentrator address in CPE. However, 304 when BRAS is processing traffic optimization, the destination address 305 needs to be performed in a similar way with subscriber source 306 address. 308 6.2. Address/Prefix Mapping Procedure 310 +-----------------+---------+---+---------+---------+------------------+ 311 |sub-doamin rule |subPref6 | |subPref4 | |Multiplexing Ratio| 312 +-----------------+---------+---+---------+---------+--------|---------+ 313 | 314 +-------------------------------+---------+--------+---------|---------+ 315 |IPv6 user prefix |subPref6 |user-id | | | 316 +-------------------------------+---------+----|---+---------|---------+ 317 | | 318 +---------+ +------+------+ 319 |subPref4 | | Free | Port | 320 | | | Bits |Set id| 321 +---+-----+ +--+---+---+--+ 322 | / | 323 | / | 324 +---+-----+---+--+ +---+--+ 325 |subPref4 | Free | | Port | 326 | | Bits | | Set | 327 +---------+------+ +------+ 328 Shared IPv4 address 330 Figure 2 Address/Prefix Mapping Procedure 332 The above figure depicts address mapping procedure in stateless 333 4over6. An initiator will get its sub-domain rule containing 334 subPre6, subPre4 and multiplexing ratio. And it will also get a user 335 prefix incluing subPref6 and user-id. By combining the user-id and 336 multiplexing ratio, we can deduce the vaule of the "Free bits" and 337 "Port-set id". SubPre4 and "Free bits" will then construct a public 338 address for the customer, while "Port-set id" can be mapped to a 339 certain "Port Set" by port mapping algorithm. 341 Detailed descriptions will be added soon... 343 6.3. Port mapping algorithm 345 A unified Port mapping algorithms should be defined to determine the 346 mapping rule between Port-set id and Port-set. You can refer to 347 [I-D.xli-behave-divi-pd] for example. And we will complete this 348 section soon ... 350 7. Stateless 4over6 Initiator Behavior 352 When requiring IPv4 access, the initiator needs to get its IPv6 353 address/prefix via normal IPv6 address allocation precedure first, 354 then it will calculate its port-restricted IPv4 address and valid 355 port range. 357 The data plane functions of the initiator includes translation and 358 encapsulation/decapsulation. For CPE initiator case, the initiator 359 runs a standard local NAT44 with the address pool consist of the 360 calculated port restricted address. When sending out an IPv4 packet 361 with private source address, it performs NAT44 function and 362 translates the source address into public. Then it encapsulates the 363 packet with concentrator's IPv6 address as destination IPv6 address, 364 and forwards it to the concentrator. The source address of the IPv6 365 packet will be generated as described above. When receiving an IPv4- 366 in-IPv6 packet from the concentrator, the initiator decapsulates the 367 IPv6 packet to get the IPv4 packet with public destination IPv4 368 address. Then it performs NAT44 function and translates the 369 destination address into private one. 371 For host initiator case, it is suggested that the host runs a local 372 NAT to map randomly generated ports into the restricted, valid port 373 range. Private-public address translation would not be needed in 374 this NAT. Another solution is to have the IP stack to only assign 375 ports within the restricted, vailid range to applications. Either 376 way makes sure that every port number in the packets sent out by 377 itself falls into the allocated port range. 379 8. Stateless 4over6 Concentrator Behavior 381 The stateless 4over6 concentrator should record the full set of sub- 382 domain rules. They can also be configured in a variety of methods, 383 and they can be refreshed or deleted once there is an adjustment on 384 address planning (no Initiator needs to be informed with this 385 adjustment). 387 The data plane functions of the concentrator is purely encapsulation 388 and de-capsulation. When receiving an IPv4-in-IPv6 packet from an 389 initiator, the concentrator de-capsulates it and forwards it to IPv4 390 Internet. When receiving an IPv4 packet from the Internet, it uses 391 the destination address and port from this packet to lookup the sub- 392 domain rules and calculate the specific "user-id" with port mapping 393 algorithm. Then the concentrator encapsulates this packet and 394 forwards it to the correct initiator based on native IPv6 routing. 395 The source address of IPv6 packet is just the concentrator address. 397 9. CPE-CPE optimization 399 In order to support CPE-CPE optimization, it will delegate the full 400 sub-domain rules to BRAS device in the 4over6 domain. When the IPv4 401 destination of an IPv4-in-IPv6 packet is in the 4over6 domain, BRAS 402 performs IPv6 destination address translation, according to sub- 403 domain rules from the set, and the IPv4 destination address + port in 404 the packet. After the translation, the IPv6 packet can be forwarded 405 to the destination CPE directly without going through the 406 concentrator. However, this functionality is not a must in cast the 407 network is flat and there is no direct link between different CPEs. 409 10. Mechanism Analysis 411 Stateless 4over6 does not need to inform multiple prefix mapping 412 rules to CPEs directly. Thus, there is no need to introduce dynamic 413 protocol for distributing and maintaining 4rd rules. This will turn 414 CPE to be a much simpler/dummier client, which will also 415 significantly reduce the burden of CPE management and trouble 416 shooting. 418 Besides, stateless 4over6 would be easier for address planning. SPs 419 only need to pre-determine the mapping relationship between IPv4 420 prefix and IPv6 prefix. Only concentrators( and BRAS in CPE-CPE 421 optimization case) need to be informed when changing a mapping rule. 422 And it fits well for scattered IPv4 address blocks. Moreover, 423 incremental CPE-CPE optimization can be achieved when network 424 providers would like to adjust their traffic when necessary. 426 The costs of stateless 4over6 for achieving the above benefits are 427 less optimized traffic by default. All traffic will be tunneled to 428 the concentrator when there is no prefix mapping BNGs. This is still 429 acceptable in flat network and few direct physical links between 430 different BNGs. However, if the network architecture is not flat and 431 concentrator is in the upper level of the network, it is recommended 432 that CPE-CPE optimization should be introduced. 434 11. Security Considerations 436 See security considerations presented in [RFC6052] and [RFC6145]. 438 12. References 440 [I-D.bajko-pripaddrassign] 441 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 442 "Port Restricted IP Address Assignment", 443 draft-bajko-pripaddrassign-03 (work in progress), 444 September 2010. 446 [I-D.bsd-softwire-stateless-port-index-analysis] 447 Boucadair, M., Skoberne, N., and W. Dec, "Analysis of Port 448 Indexing Algorithms", 449 draft-bsd-softwire-stateless-port-index-analysis-00 (work 450 in progress), September 2011. 452 [I-D.cui-softwire-dhcp-over-tunnel] 453 Cui, Y., Wu, P., and J. Wu, "DHCPv4 Behavior over IP-IP 454 tunnel", draft-cui-softwire-dhcp-over-tunnel-01 (work in 455 progress), July 2011. 457 [I-D.cui-softwire-host-4over6] 458 Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y. 459 Lee, "Public IPv4 over Access IPv6 Network", 460 draft-cui-softwire-host-4over6-06 (work in progress), 461 July 2011. 463 [I-D.ietf-softwire-stateless-4v6-motivation] 464 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 465 Borges, I., and G. Chen, "Motivations for Stateless IPv4 466 over IPv6 Migration Solutions", 467 draft-ietf-softwire-stateless-4v6-motivation-00 (work in 468 progress), September 2011. 470 [I-D.murakami-softwire-4rd] 471 Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual 472 Deployment on IPv6 infrastructure - protocol 473 specification", draft-murakami-softwire-4rd-01 (work in 474 progress), September 2011. 476 [I-D.sun-v6ops-laft6] 477 Sun, Q. and C. Xie, "LAFT6: Lightweight address family 478 transition for IPv6", draft-sun-v6ops-laft6-01 (work in 479 progress), March 2011. 481 [I-D.tsou-pcp-natcoord] 482 Zhou, C., ZOU), T., Deng, X., Boucadair, M., and Q. Sun, 483 "Using PCP To Coordinate Between the CGN and Home Gateway 484 Via Port Allocation", draft-tsou-pcp-natcoord-03 (work in 485 progress), July 2011. 487 [I-D.xli-behave-divi-pd] 488 Li, X., Bao, C., Dec, W., Asati, R., Xie, C., and Q. Sun, 489 "dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix 490 Delegation", draft-xli-behave-divi-pd-01 (work in 491 progress), September 2011. 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 497 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 498 October 2010. 500 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 501 Algorithm", RFC 6145, April 2011. 503 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 504 Stack Lite Broadband Deployments Following IPv4 505 Exhaustion", RFC 6333, August 2011. 507 Authors' Addresses 509 Qiong Sun 510 China Telecom 511 Room 708, No.118, Xizhimennei Street 512 Beijing 100035 513 P.R.China 515 Phone: +86-10-58552936> 516 Email: sunqiong@ctbri.com.cn 518 Chongfeng Xie 519 China Telecom 520 Room 708, No.118, Xizhimennei Street 521 Beijing 100035 522 P.R.China 524 Phone: +86-10-58552116> 525 Email: xiechf@ctbri.com.cn 527 Yong Cui 528 Tsinghua University 529 Department of Computer Science, Tsinghua University 530 Beijing 100084 531 P.R.China 533 Phone: +86-10-62603059 534 Email: yong@csnet1.cs.tsinghua.edu.cn 536 Jianping Wu 537 Tsinghua University 538 Department of Computer Science, Tsinghua University 539 Beijing 100084 540 P.R.China 542 Phone: +86-10-62785983 543 Email: jianping@cernet.edu.cn 545 Peng Wu 546 Tsinghua University 547 Department of Computer Science, Tsinghua University 548 Beijing 100084 549 P.R.China 550 Phone: +86-10-62785822 551 Email: weapon@csnet1.cs.tsinghua.edu.cn 553 Cathy Zhou 554 Huawei Technologies 555 Section B, Huawei Industrial Base, Bantian Longgang 556 Shenzhen 518129 557 P.R.China 559 Phone: +86-10-58552116> 560 Email: cathyzhou@huawei.com 562 Yiu L. Lee 563 Comcast 564 One Comcast Center 565 Philadelphia, PA 19103 566 USA 568 Email: yiu_lee@cable.comcast.com