idnits 2.17.1 draft-yang-v6ops-fast6-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 31, 2013) is 4044 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.arkko-ipv6-transition-guidelines' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-behave-lsn-requirements' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-softwire-dual-stack-lite' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'I-D.kuarsingh-lsn-deployment' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'I-D.shirasaki-nat444' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'I-D.shirasaki-nat444-isp-shared-addr' is defined on line 519, but no explicit reference was found in the text == Unused Reference: 'I-D.yang-v6ops-fast6-tools-selection' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'RFC1661' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC2516' is defined on line 538, but no explicit reference was found in the text == Unused Reference: 'RFC2661' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'RFC3022' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'RFC4029' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'RFC4213' is defined on line 554, but no explicit reference was found in the text == Unused Reference: 'RFC4241' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'RFC5569' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC5969' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'RFC6036' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 571, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-05 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-10 == Outdated reference: A later version (-06) exists of draft-kuarsingh-lsn-deployment-01 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-03 == Outdated reference: A later version (-08) exists of draft-shirasaki-nat444-isp-shared-addr-05 == Outdated reference: A later version (-01) exists of draft-yang-v6ops-fast6-tools-selection-00 -- Obsolete informational reference (is this intentional?): RFC 6036 (Obsoleted by RFC 9386) Summary: 0 errors (**), 0 flaws (~~), 29 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Y. Wu 3 Internet-Draft J. Tan 4 Intended status: Informational Y. Li 5 Expires: September 31, 2013 China Telecom 6 March 31, 2013 8 Fundamental Architecture of Services Provider's network Transitioning to 9 IPv6 (FAST6) 10 draft-yang-v6ops-fast6-02 12 Abstract 14 The IANA free pool of IPv4 addresses was depleted, IPv6 migration has 15 become the most imperative task. There are many transition 16 mechanisms designed for different scenarios, however, some problems 17 arosed in the practice. FAST6, specified in this draft, is based on 18 the ideas of native dual stack and address sharing. It can solves 19 the mixed route problem and simplify the planning of private IPv4 20 address space by using tunnel technology. FAST6 is an economical and 21 stable technology for smooth network transition. 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 September 31, 2013. 40 Copyright Notice 42 Copyright (c) 2012 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. FAST6 Architecture . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. FTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. FTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. FAST6 Tunnel South(FTS) . . . . . . . . . . . . . . . . . . . 6 64 4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6 66 4.3. Fragmentation and Reassembly . . . . . . . . . . . . . . . 6 67 4.4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. FAST6 Tunnel Nouth(FTN) . . . . . . . . . . . . . . . . . . . 6 69 5.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7 71 5.3. Resource Pool Maintenance . . . . . . . . . . . . . . . . 7 72 5.4. FAST6 NAT . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.5. address mapping table maintenance . . . . . . . . . . . . 7 74 6. FAST6 Data Flow . . . . . . . . . . . . . . . . . . . . . . . 8 75 7. FAST6 Deployment . . . . . . . . . . . . . . . . . . . . . . . 9 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 As we known, available transition mechanisms have their 87 own drawbacks in practice. Nowadays, most applications don't 88 support IPv6 and the protocol translation technologies, such as 89 NAT64 which cannot help in the application level.Therefore it is 90 necessary to provide the IPv4 and IPv6 service separately. However, 91 4over6 technology is a risky method for network migration since any 92 troubles happen in the IPv6 network will influence the IPv4 service, 93 especially in the period when IPv4 flows are dominant in the network. 94 Simultaneously, 4over6 technology doesn't help to stimulate 95 applications translation of ICPs who are unaware of the well prepared 96 IPv6 network. In the mean time, 6over4 technology is not proper 97 for the continuously expanding network. Native dual stack technology 98 can avoid those problems essentially for it can provide dual stack 99 service separately, making IPv4 decoupling from IPv6 and providing 100 network environment for IPv6 service migration. However, native dual 101 stack is not enough and IP address sharing has to be used when the 102 IPv4 addresses were exhausted. 104 NAT444 seems to be a good solution except some carrier grade problems 105 such as mixed routing (private address routing and public address 106 routing), additional unified arrangement of private IPv4 address 107 spaces among BNGs and so on. All these problems will cause overload 108 maintenance cost. This document specifies the FAST6 technology, 109 which is aimed at balancing the costs and benefits in service 110 provider networks better. FAST6 is based on native dual-stack. By 111 taking the advantages of tunnel technology and native dual-stack 112 technology, FAST6 overcomes carrier grade NAT problems. It 113 stimulates the IPv6 migration and also decouples the IPv4 from IPv6, 114 making network transition smoother and guaranteeing the user 115 experience effectively. 117 This document will first briefly introduce the overall architecture 118 of FAST6 and then describe the detailed behaviors of FAST6 elements. 119 It will then depict an intuitive example about FAST6 through data 120 flow. At last, we will present the FAST6 implementation in current 121 network and show some of its advantages. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. Terminologies 131 The technology described in this document is known as FAST6. The 132 abbreviation "FAST6" will be used throughout this text. 134 FAST6: Fundamental Architecture of Services Provider's network 135 Transitioning to IPv6 137 FTN: FAST6 tunnel North 139 FTS: FAST6 tunnel South. 141 Resource Pool: One of the element in FTN, including address pool, 142 Tunnel ID-address pool mapping table, port resource pool. 144 FAST6 NAT: A module use triple-tuple for NAT. 146 CR: Core Router (CR) in a metropolitan area network is the 147 egress router of the MAN and connecting to the ISP's 148 backbone in upstream and connecting to BRASs for 149 downstream. 151 BNG: Broadband Network Gateway, BRAS and SR 153 Dual stack: Defined in RFC 4213 155 Nat related terminology: Defined in RFC 1417 157 IP-in-IP tunnel: Defined in RFC 2003 159 3. FAST6 Architecture 161 FAST6 consists of two functional modules. One is FTS (FAST6 tunnel 162 south) , the other is FTN(FAST6 tunnel north). FTS is the tunnel 163 endpoint present at the user side. FTN is the tunnel endpoint 164 present at the network side. 166 +-----+-----+ +-----+-----+ 167 | IPv4 host| | IPv6 host| 168 +-----------+ +-----------+ 169 | | 170 --------|--------------|------ 171 / | | \ 172 | Internet | | 173 \ | | / 174 --------|--------------|------ 175 |-------------------|--------------|--------------| 176 | +-------------------+ | FAST6 | 177 | | FTN | | | 178 | +---------|---------+ | | 179 | ||| | | 180 | ||| IP in IP Tunnel | 181 | +-------------------+ | | 182 | | FTS | | | 183 | +---------|---------+ | | 184 | | | | 185 |____________________|_____________|______________| 186 +-----+-----+ | 187 | CPE/ host|-------| 188 +-----------+ 190 Figure 1: FAST6 architecture 192 3.1. FTS 194 As the tunnel endpoint at user side, FTS is responsible for 195 encapsulating private IPv4 packet within a public IPv4 packet to 196 establish an IP-in-IP tunnel, or decapsulating private IPv4 packet 197 from the tunnel. 199 3.2. FTN 201 FTN is the tunnel endpoint at network side. It has four functions: 202 encapsulation and decapsulation, address translation, address mapping 203 table maintenance, resource pool maintenance. 205 From south to north, FTN decapsulates the private IP address packet 206 from the tunnel, marking the public IPv4 address as the tunnel ID and 207 finding the corresponding IP address pool and port resource in the 208 resource pool based on the tunnel ID. Then FTN replaces the private 209 IPv4 address header with the public IPv4 address header and generates 210 an address mapping entry. 212 From the north to south, FTN searches the address mapping table for 213 the corresponding triple tuple ( tunnel ID, private address, port) 214 according to the received public IPv4 address and port. Then FTN 215 forwards the packet to the corresponding tunnel. 217 4. FAST6 Tunnel South(FTS) 219 4.1. Definition 221 As defined above, FTS is a function module used to establish the 222 IPv4-in-IPv4 tunnel to FTN, encapsulating and decapsulating the 223 packet. 225 4.2. Encapsulation 227 FTS uses a public IPv4 address to encapsulate the private IPv4 228 packet. The packet encapsulation structure is as below. 230 +-----+-----+-----+-----+-----+-----+ 231 |Public IPv4|private IPv4|payload | 232 +-----------+-----------+-----------+ 234 Figure 2: The encapsulation module 236 For the encapsulation format and parameters, please refer to RFC2003 237 and other encapsulation mode will be considered in the future. 239 4.3. Fragmentation and Reassembly 241 The encapsulation of IPv4 packet over IPv4 packet will increase 20 242 extra bytes in IP headerGBP[not]it is necessary for the service 243 provider to manually increase the MTU size for all the links between 244 the FTS element and the FTN elements, by at least 20 bytes to 245 accommodate both the IPv4 encapsulation header and the IPv4 datagram 246 without fragmenting the IPv4 packet. 248 4.4. Discovery 250 The number of FTSs (the number of the tunnels) is very limited, so 251 the IPv4-in-IPv4 tunnel establishment between FTN and FTS can be 252 configured manually. 254 5. FAST6 Tunnel Nouth(FTN) 256 5.1. Definition 258 As defined above, FTN has four functions: encapsulation and 259 decapsulation, address translation, address mapping table 260 maintenance, resource pool maintenance. 262 +----------------------------------------------------+ 263 |resource pool | 264 | +-------------------+ +----------+ +-----------+ | 265 | |tunnel ID-address pool|address pool| port resource 266 | |mapping table | | | | | | 267 | +---------|---------+ +-----|----+ +-|---------+ | 268 +------------|------------------ /------/------------+ 269 | / / 270 +------+ +-----------------+/ / +---------------+ 271 | encap| |address traslation------/ | mapping table | 272 | decap| | | | | 273 +----- + +-----------------+ +---------------+ 275 Figure 3: FTN architecture 277 5.2. Encapsulation 279 The encapsulation format of FTN is the same as FTS. The 280 fragmentation and reassembly mode are also the same as FTS. 282 5.3. Resource Pool Maintenance 284 The resource pool includes the !otunnel ID "C IP address pool!+/- 285 mapping table, address pool and port resource pool. The planning of 286 address pool depends on the specific network deployment. Usually, 287 each tunnel ID has its own IP address pool. In addition, the 288 resource pool has to maintain the available port resource and address 289 for each address pool. 291 5.4. FAST6 NAT 293 From south to north, FTN assign a public address and port after 294 checking the resource table according to the triple tuple (Tunnel ID, 295 private address, port). From north to south, FTN searches the 296 address mapping table after receiving the packet and finds the 297 corresponding tunnel ID, private address and port information, then 298 forwards the packet to corresponding tunnel. 300 5.5. address mapping table maintenance 302 From south to north, FTN will generate a network address mapping 303 table. The parameters listed in the entry is in the following order: 304 GBP"converted public IPv4 address, converted port, tunnel ID, private 305 IPv4 address, port). 307 6. FAST6 Data Flow 309 The following picture describes the procedure of accessing internet 310 from user end through FAST6. Users visit the IPv4 internet resources 311 through IPv4 network and use IPv6 network to access the IPv6 internet 312 resources. 314 +-----+-----+ +-----+-----+ 315 | IPv4 host| | IPv6 host| 316 +-----------+ +-----------+ 317 | | 318 --------|--------------|----- 319 / | | \ 320 | Internet | | 321 \ | | / 322 --------|--------------|------ 323 |--------120.0.0.1--|--------------|--------------| 324 | +-------------------+ | FAST6 | 325 | | FTN | | | 326 | +---------|---------+ | | 327 | ||| | | 328 | 59.43.0.1 ||| IPv4-in-IPv4 Tunnel | 329 | +-------------------+ | | 330 | | FTS | | | 331 | +---------|---------+ | | 332 | | | | 333 |___________10.0.1.1_|_____________|______________| 334 +-----+-----+ | 335 | CPE/ host|-------| 336 +-----------+ 338 Figure 4: FAST6 Data Flow 340 Customer 1 sends a TCP packet with source address 10.0.1.1 and port 341 1000 to the ICP server whose address is 198.8.8.8. When the packet 342 arrives at the FTS, FTS encapsulates the private IPv4 packet in a 343 public IPv4 header (59.43.0.1) with the destination 59.43.0.2, the 344 other end of tunnel. When the packet arrives at the FTN, FTN 345 decapsulates it , checks the corresponding IP address pool based on 346 Tunnel ID and chooses 120.0.0.1 and port 2000 to replace the former 347 header. Then FTN generates a mapping 348 entryGBP"120.0.0.1,2000,59.43.0.2,10.0.1.1,1000GBP(C). 350 From north to south, when FTN receives the packet with the 351 destination address 120.0.0.1/2000, it checks the address mapping 352 table , finds the 353 entryGBP"120.0.0.1,2000,59.43.0.2,10.0.1.1,1000GBP(C)and forwards the 354 packet to tunnel established by FTS1 according to the last 3 355 parameters. 357 +-----------------+--------------+-----------------+ 358 | Datagram | Header field | Contents | 359 +-----------------+--------------+-----------------+ 360 | IPv4 datagram 1 | IPv4 Dst | 198.8.8.8 | 361 | | IPv4 Src | 10.0.0.1 | 362 | | TCP Dst | 80 | 363 | | TCP Src | 1000 | 364 | --------------- | ------------ | ------------- | 365 | IPv4 datagram 2 |IPv4 Dst outer| 59.43.0.2 | 366 | |IPv4 Src outer| 59.43.0.1 | 367 | | IPv4 Dst | 198.8.8.8 | 368 | | IPv4 Src | 10.0.0.1 | 369 | | TCP Dst | 80 | 370 | | TCP Src | 1000 | 371 | --------------- | ------------ | ------------- | 372 | IPv4 datagram 3 | IPv4 Dst | 198.8.8..8 | 373 | | IPv4 Src | 120.0.0.1 | 374 | | TCP Dst | 80 | 375 | | TCP Src | 2000 | 376 +-----------------+--------------+-----------------+ 378 Figure 5: packet header translation table 380 7. FAST6 Deployment 382 This chapter will briefly introduce the FAST6 deployment in real 383 network and some of its advantages. The following picture only 384 depicts IPv4 part of FAST6.The detailed deployment, cutover and 385 network transition will be stated in other document. 387 +-----+-----+ 388 | IPv4 host| 389 +-----------+ 390 | 391 --------|------------ 392 / | \ 393 | Internet | 394 \ | / 395 --------|------------- 396 | 397 +---------------------------+ 398 | CR | 399 +---|---------|---------|---+ 400 | | | 401 120.0.0.1 120.0.0.2 120.0.1.1 402 +----------------------------+ 403 | FTN | 404 +----------------------------+ 405 || || \\ 406 || || \\ 407 59.43.0.1 59.43.0.3 59.43.0.5 408 +------//----BNG1--//----+ + \\---BNG2-----+ 409 | || || | | \\ | 410 | +--//----+ +--//----+ | | +-\\-----+ | 411 | | FTS | | FTS | | | | FTS | | 412 | +---|----+ +---|----+ | | +--|-----+ | 413 +-----|-----------|------+ +----|----------+ 414 10.0.1.1 10.0.1.2 10.0.1.1 415 +-----+-----+ +-----+-----+ +-----+-----+ 416 | host1 | | host2 | | host3 | 417 +-----------+ +-----------+ +-----------+ 419 Figure 6: FAST6 Deployment 421 FAST6 is suitable for layer 2 and layer3 access modes. The FTS 422 component can be installed in BNG equipments tunnel interface. The 423 FTN unit is similar to CGN device and can be embedded in the CR as a 424 card or deployed as an independent device. 426 FAST6 can eliminate the mixed routing problem by establish a tunnel 427 from BNG to FTN. In the mean time, since it uses the public address 428 as the tunnel ID to separate different BNGs, the private address pool 429 can be overlapped among BNGs, saving the workload for arranging the 430 private IPv4 address pool in the whole network uniformly. Besides, 431 since FTS can be configured in the ingress direction of user 432 interface on BNG, the tunnel can also isolate the mixed route within 433 the device. This feature fits BNG for providing multiple services 434 which are running behind different address distribution policies (for 435 example, private address for common users and public address for VIP 436 customers.). 438 The IPv4 address used for tunnel encapsulation is different for 439 different FTS. The address pool can be overlapped for each FTS. FTS 440 can be deployed flexibly in centralized and distributed form in the 441 network depending on private IPv4 traffic flow amount. When the FTN 442 is distributed, FTN and FTS may probably be in the same card in this 443 case, FAST6 is as same as NAT444. 445 In addition, FAST6 have some the following advantages: 447 (1) Retaining the current access method and customer behaviors, 448 modifications of CPE are not required. 450 (2) Providing dual stack services for users, no need for protocol 451 translation and consequently decreasing the influence on 452 applications. 454 (3) Easier for troubleshooting. IPv4 is decoupled from IPv6, so it 455 will not be influenced by IPv6. 457 (4) Suitable for the initial period of network transition, and it can 458 be seamlessly compatible with any other technologies used for later 459 stage of transition. 461 8. Acknowledgements 463 TBD... 465 9. IANA Considerations 467 This memo includes no request to IANA. 469 10. Security Considerations 471 This document has no impact on the security properties of specific 472 IPv6 transition tools. When introducing IPv6, it is important to 473 ensure that the necessary security capabilities exist on the network 474 components even when dealing with IPv6 traffic. The security issues 475 should be considered when deploying any transition technology. For 476 instance, firewall and logging system for illegal activity tracing is 477 still a challenge in IPv6 and NAT deployments. 479 11. References 481 11.1. Normative References 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, March 1997. 486 [min_ref] authSurName, authInitials., "Minimal Reference", 2012. 488 11.2. Informative References 490 [I-D.arkko-ipv6-transition-guidelines] 491 Arkko, J. and F. Baker, "Guidelines for Using IPv6 492 Transition Mechanisms during IPv6 Deployment", 493 draft-arkko-ipv6-transition-guidelines-14 (work in 494 progress), December 2010. 496 [I-D.ietf-behave-lsn-requirements] 497 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 498 and H. Ashida, "Common requirements for Carrier Grade NATs 499 (CGNs)", draft-ietf-behave-lsn-requirements-05 (work in 500 progress), November 2011. 502 [I-D.ietf-softwire-dual-stack-lite] 503 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 504 Stack Lite Broadband Deployments Following IPv4 505 Exhaustion", draft-ietf-softwire-dual-stack-lite-10 (work 506 in progress), May 2011. 508 [I-D.kuarsingh-lsn-deployment] 509 Kuarsingh, V. and J. Cianfarani, "NAT44/LSN Deployment 510 Options and Experiences", 511 draft-kuarsingh-lsn-deployment-01 (work in progress), 512 January 2011. 514 [I-D.shirasaki-nat444] 515 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 516 and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work 517 in progress), January 2011. 519 [I-D.shirasaki-nat444-isp-shared-addr] 520 Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 521 and H. Ashida, "NAT444 addressing models", 522 draft-shirasaki-nat444-isp-shared-addr-05 (work in 523 progress), January 2011. 525 [I-D.yang-v6ops-fast6-tools-selection] 526 Yang, G. and C. Huang, "The analysis of tools selection 527 for broadband ISP", 528 draft-yang-v6ops-fast6-tools-selection-00 (work in 529 progress), May 2011. 531 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 532 RFC 1661, July 1994. 534 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 535 E. Lear, "Address Allocation for Private Internets", 536 BCP 5, RFC 1918, February 1996. 538 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 539 and R. Wheeler, "A Method for Transmitting PPP Over 540 Ethernet (PPPoE)", RFC 2516, February 1999. 542 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 543 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 544 RFC 2661, August 1999. 546 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 547 Address Translator (Traditional NAT)", RFC 3022, 548 January 2001. 550 [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. 551 Savola, "Scenarios and Analysis for Introducing IPv6 into 552 ISP Networks", RFC 4029, March 2005. 554 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 555 for IPv6 Hosts and Routers", RFC 4213, October 2005. 557 [RFC4241] Shirasaki, Y., Miyakawa, S., Yamasaki, T., and A. 558 Takenouchi, "A Model of IPv6/IPv4 Dual Stack Internet 559 Access Service", RFC 4241, December 2005. 561 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 562 Infrastructures (6rd)", RFC 5569, January 2010. 564 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 565 Infrastructures (6rd) -- Protocol Specification", 566 RFC 5969, August 2010. 568 [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider 569 Scenarios for IPv6 Deployment", RFC 6036, October 2010. 571 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 572 NAT64: Network Address and Protocol Translation from IPv6 573 Clients to IPv4 Servers", RFC 6146, April 2011. 575 Authors' Addresses 577 Youming Wu 578 China Telecom 579 109, Zhongshan Ave. West, 580 Guangzhou, Tianhe District 510630 581 P.R. China 583 Phone: 584 Email: 13316090389@189.cn 586 Jinhua Tan 587 China Telecom 588 109, Zhongshan Ave. West, 589 Guangzhou, Tianhe District 510630 590 P.R. China 592 Phone: 593 Email: 13316097209@189.cn 595 YangChun Li 596 China Telecom 597 109, Zhongshan Ave. West, 598 Guangzhou, Tianhe District 510630 599 P.R. China 601 Phone: 602 Email: liyc_gsta@189.cn