idnits 2.17.1 draft-sun-intarea-4rd-applicability-01.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.) ** There are 21 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 15, 2011) is 4790 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2460' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 503, 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: 'RFC3849' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'RFC5737' is defined on line 548, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-despres-intarea-4rd-00 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-04) exists of draft-ietf-intarea-server-logging-recommendations-03 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-07 == Outdated reference: A later version (-06) exists of draft-tsou-behave-natx4-log-reduction-02 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Sun 3 Internet-Draft Softbank BB 4 Intended status: Informational S. Matsushima 5 Expires: September 16, 2011 Softbank Telecom 6 J. Jiao 7 Softbank BB 8 March 15, 2011 10 4rd Applicability Statement 11 draft-sun-intarea-4rd-applicability-01 13 Abstract 15 This document discusses the applicability of the IPv4 Residual 16 Deployment (4rd) protocol, and an address sharing mechanism, NAT44 on 17 4rd CE side, and routing optimization to provide IPv4 connectivity in 18 4rd capable IPv6-only networks. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 16, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Overview of 4rd . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. IPv4 Address Assignment . . . . . . . . . . . . . . . . . 4 58 3.2. IPv4 Address Sharing . . . . . . . . . . . . . . . . . . . 5 59 3.3. Distributing NAT function to CEs . . . . . . . . . . . . . 7 60 3.4. Routing optimization to provide IPv4 connectivity . . . . 9 61 3.5. Gateway Redundancy Considerations . . . . . . . . . . . . 10 62 3.6. NAT Log Considerations . . . . . . . . . . . . . . . . . . 11 63 4. Constraint Considerations . . . . . . . . . . . . . . . . . . 11 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 The Internet continues to grow beyond the capabilities of IPv4. The 75 tremendous success of the Internet has strained the address space, 76 which is no longer sufficient to support future growth. The IANA 77 free pool of IPv4 address have been depleted already. With its 78 increase in the number of available prefixes and addresses in a 79 subnet, and improvement in address management, IPv6 is the only real 80 option on the table. During the long transition period from only 81 IPv4 to IPv6, the networks of Internet Service Providers (ISPs) will 82 have to offer more than just IPv6 connectivity. Both outgoing and 83 incoming connections will have to be supported. 85 IPv4 Residual Deployment (4rd) enables a service provider to share 86 IPv4 addresses among its customers by combining the well-known 87 technologies of stateless address mapping and tunneling, NAT44, and 88 IPv4 in IPv6 encapsulation. 90 This document discusses the applicability of the 4rd protocol, and an 91 address sharing mechanism, NAT44 on 4rd CE side, and routing 92 optimization to provide IPv4 connectivity in 4rd capable IPv6-only 93 networks. 95 2. Overview of 4rd 97 If 4rd [I-D.despres-intarea-4rd] is to be actually used across a 98 IPv6-only network to offer IPv4 connectivity 99 [I-D.arkko-ipv6-transition-guidelines], the network must have 4rd 100 Border Relay Router (BR) and 4rd Customer Edge Router (CE). 102 With 4rd, we need not worry that well-known (reserved) IPv4 addresses 103 (such as 000/8) are generated, because all 4rd CEs generating IPv4 104 addresses are in the range of domain 4rd prefix. (Section 3.1). The 105 4rd model is built on IPv4 over IPv6 stateless tunnels to reach 4rd 106 CEs where customers will share IPv4 addresses if the CE 4rd prefix is 107 longer than 32-bits (Section 3.2). 4rd differs from other solutions 108 such as Dual-Stack-lite [I-D.ietf-softwire-dual-stack-lite] since the 109 4rd CE is used to implement the NAT44 (Section 3.3). 4rd also can 110 implement Routing Optimization to Provide IPv4 Connectivity while the 111 4rd CE communicates with other 4rd CE (Section 3.4). 113 3. Applicability 115 In this section, we describe 4rd applicability with Figure 1 as an 116 example of 4rd enabled network. It is helpful to explain 4rd and 117 underdtand 4rd applicability. 119 +------------------------+ 120 / \ 121 | IPv4 Internet | 122 \ / 123 +------------------------+ 124 | 125 | 126 +----------------------+ 127 | 4rd BR | 128 +----------------------+ 129 | 130 | 131 + --------------------------------+ 132 / \ 133 | ISP's IPv6 network | 134 \ 2001:db8::/32 / 135 --------------------------------- 136 / | \ 137 / | \ 138 / | \ 139 2001:db8:cdab::/48 2001:db8:cdef::/48 2001:db8:cda1::/48 140 +-----------+ +------------+ +------------+ 141 | 4rd CE1 | | 4rd CE2 | *** | 4rd CEn | 142 +-----------+ +------------+ + -----------+ 144 Figure 1: A 4rd network model example 146 3.1. IPv4 Address Assignment 148 [I-D.despres-intarea-4rd] specify 4rd address mapping rule. When 4rd 149 address mapping rule apply to the Figure 1, as Figure 2 shown, a 4rd 150 CE1's IPv4 address, which is in the range of domain 4rd prefix, is 151 generated from CE IPv6 prefix. As the prerequisite of 4rd, Domain 152 IPv6 prefix and Domain 4rd prefix must be given to all 4rd CEs and 153 4rd BRs in a specified 4rd domain. CE IPv6 prefix for all 4rd CEs in 154 the specified 4rd domain must be in same Domain IPv6 prefix but must 155 be unique for each 4rd CE. 157 <------------ CE IPv6 prefix (max length 64) ------------> 158 +-------------------------------+-------------------------+ 159 | 2001:db8::/32 | 0xcdab | 160 +-------------------------------+-------------------------+ 161 <-- Domain IPv6 prefix length --|<----CE index length---->| 162 : || : 163 Domain 4rd prefix : \/ : 164 |<----------------->|<-- suffix-->| | 165 +-------------------+-------------------------+ 166 CE 4rd prefix | 192.0.2.0/24 | 0xcd | 0xab | 167 +-------------------+-------------------------+ 168 |<----4rd CE1's IPv4 address----->|<--------->| 169 192.0.2.205(0xcd) Port-set ID 171 Figure 2: An example of 4rd address mapping for 4rd CE1 173 All 4rd CEs IPv4 addresses are in the range fo domain of domain 4rd 174 prefix. Figure 2 shows an example that 4rd CE1's IPv4 address how to 175 be genarated. This means that it is not necessary for 4rd operators 176 to pay attention to what IPv4 address is generated by 4rd CE. In the 177 case of all 32 bits of IPv4 address is mapped to IPv6 prefix, 4rd CE 178 must not generate well-known IPv4 address (such as 0/8, 127/8, etc., 179 for example) so that IPv6 prefix assignment should be taken careful 180 to avoid it. 4rd is recommended to operators who do not want IPv6 181 prefix assignment of which takes into account what IPv4 address 182 generated from IPv6 prefix. 184 As example (Figure 1) shown, the 4rd model is built on IPv4 over IPv6 185 tunnels to reach 4rd CEs where up to 256 customers can share a IPv4 186 addresse. In the given example, the IPv6 ISP aggregate Domain IPv6 187 prefix is 2001:db8::/32. Out of this aggregate, a /48 CE IPv6 prefix 188 for each 4rd CE is assumed to be issued, this allowing for a 16-bits 189 CE index. Since remaining bits to mapping IPv4 address is 8 bit, 190 "0xab" is a part of last octet of CE1's IPv4 address. As a result, 191 192.0.2.205 is shared with 256 4rd-CEs. 193 3.2. IPv4 Address Sharing 195 When the CE 4rd prefix is longer than 32 bits, IPv4 address will be 196 shared by muliple 4rd CEs. As Figure 3 shown, the suffix of shared 197 IPv4 address and Port-set ID are derived from CE index of CE IPv6 198 prefix. CEs have same 4rd shared IPv4 address and unique Port-set 199 ID, so CEs can be identified using IPv4 address and unique Port-set 200 ID. 202 <------------ CE IPv6 prefix length (max 64) -------------> 203 +-------------------------------+-------------------------+ 204 | 2001:db8::/32 | CE index | 205 +-------------------------------+-------------------------+ 206 <-- Domain IPv6 Prefix length --|<----CE index length---->| 207 : || : 208 Domain 4rd prefix : \/ : 209 |<----------------->|<-- suffix-->| | 210 +-------------------+-------------------------+ 211 CE 4rd prefix | 192.0.2.0/24 | 0xcd |Port-set ID| 212 +-------------------+-------------------------+ 213 |<---4rd shared IPv4 address----->| CE1: Oxab 214 192.0.2.205(0xcd) CE2: Oxef 215 ... ... 216 CEn: Oxa1 218 Figure 3: Port-set ID generation example 220 As shown in Figure 3 , the available port-set ID for IPv4 address 221 sharing is derived form the remaining 8-bits, e.g. 0xab, 0xef, 0xa1 222 used by 4rd CE1, 4rd CE2, 4rd CEn respectively. With this particular 223 scheme shown in the example, up to 256 4rd CEs can share the IPv4 224 address. 226 According to [I-D.despres-intarea-4rd],each 4rd CE has its unique 227 port-ranges which is calculated based on the 4rd mapping rule with 228 their Port-set ID. The 4rd port mapping rule uses four heads, as 229 shown in the Figure 4 below. This allows 4rd CEs to avoid using well 230 known (reserved) TCP/UDP ports 0-4095. 232 <------- Port (16bit) ----------> 233 Port-range a +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 (head=0001) |0|0|0|1|1 0 1 0|1 0 1 1| | 0x1AB0 - 0x1ABF 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 / 0xA / 0xB / 237 Port-range b +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 (head=001) |0|0|1|1 0 1 0|1 0 1 1| | 0x3560 - 0x356F 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 / 0xA / 0xB / 241 Port-range c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 (head=01) |0|1|1 0 1 0|1 0 1 1| | 0x6AC0 - 0x6AFF 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 / 0xA / 0xB / 245 Port-range d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 (head=1) |1|1 0 1 0|1 0 1 1| | 0xD570 - 0xD5FF 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 / 0xA / 0xB / 249 Port-set ID +-+-+-+-+-+-+-+-+ 250 (CE1,0xAB) |1 0 1 0|1 0 1 1| 251 +-+-+-+-+-+-+-+-+ 253 Figure 4: Port-range calculation example for 4rd CE1 255 3.3. Distributing NAT function to CEs 257 Since 4rd distributes NAT44 function to the 4rd CE, the CE side NAT44 258 manages user's NATed session in general of each 4rd CE unit. 259 According to their own infrastructure and management systems, if ISPs 260 think 4rd CE Side NAT is easier to manage than gateway side NAT, they 261 can adopt the 4rd technology. 263 The capex and opex costs of an ISP vary from network to network. The 264 4rd solution is an ideal fit for those where a CE based NAT solution 265 is acceptable, and where investment in operating and managing of a 266 centralized NAPT 44 gateway is not desired. 268 For an CE IPv6 prefix of a given length, e.g. a /56 PD, as more and 269 more bits are used to express the shared IPv4 address, the less bits 270 are available to express the port range. It is not 4rd specific 271 issue, but a method that supports NAT Port Mapping needs to be 272 devised. For example, 256 ports can be used by 4rd CE, but access to 273 host A, B, and C requires 100 ports each. If the 4rd CE ports are 274 distributed when A,B,C are accessed at the same time from the same 275 4rd CE, Ports 0 - 99 are used to access host A, Ports 100 - 199 are 276 used to access host B, but host C cannot be accessed because the 277 remaining ports are not enough. As Figure 5, 4rd can reuse the 4rd 278 CE Port by terms of recognizing the destination addresses in order to 279 reduce the aspect of this problem. It is noted that the problem can 280 not be solved if the multiple users under same 4rd CE access the same 281 host (e.g. host A) exceed the number of ports. 283 ----------------------------------- 284 / \ 285 / IPv4 Internet \ 286 | +--------+ +--------+ +--------+ | 287 \ | host A | | host B | | host C | / 288 \ +--------+ +--------+ +--------+ / 289 -------------------------------------- 290 | 291 +---------------------+ 292 | 4rd BR | 293 +---------------------+ 294 | 295 +---------------------------------+ 296 / \ 297 | ISP's IPv6 network | 298 \ / 299 +---------------------------------+ 300 | 301 4rd CE | 302 +--------------------------------------------------+ 303 | Port number Port number Port number | 304 | pool for pool for pool for | 305 | +--host A --+ +--host B --+ +--host C --+ | 306 | | Port0-255 | | Port0-255 | | Port0-255 | | 307 | +-----------+ +-----------+ +-----------+ | 308 +--------------------------------------------------+ 310 Figure 5: Reuse port number on 4rd CE side NAT 312 Figure 6 quantifies address sharing rates for different port range 313 lengths, along with the overall number of ports available to a give 314 CE. The 4rd allows 16 bits to be used by NAPT. In theory, one IPv4 315 address can be shared by 65536 (2 to 16th power) customers. However, 316 at least 1 bit is needed for Port-range Index. The greatest bit 317 range that can be used to share address are 15 bits. 319 +------------+-------------------------+---------------+------------+ 320 | Port | User numbers that can | # of ports | Relative | 321 | prefix | share one v4 address | for a 4rd CE | to a /8 | 322 | length | | | | 323 +------------+-------------------------+---------------+------------+ 324 | 1 | 1 - 2 | 30720 | /9 | 325 | 2 | 1 - 4 | 15360 | /10 | 326 | 3 | 1 - 8 | 7680 | /11 | 327 | 4 | 1 - 16 | 3840 | /12 | 328 | 5 | 1 - 32 | 1920 | /13 | 329 | 6 | 1 - 64 | 960 | /14 | 330 | 7 | 1 - 128 | 480 | /15 | 331 | 8 | 1 - 256 | 240 | /16 | 332 | 9 | 1 - 512 | 120 | /17 | 333 | 10 | 1 - 1024 | 60 | /18 | 334 | 11 | 1 - 2048 | 30 | /19 | 335 | 12 | 1 - 4096 | 15 | /20 | 336 | 13 | 1 - 8192 | 7 | /21 | 337 | 14 | 1 - 16384 | 3 | /22 | 338 | 15 | 1 - 32768 | 1 | /23 | 339 +------------+-------------------------+---------------+------------+ 341 Figure 6: 4rd CE available port 343 3.4. Routing optimization to provide IPv4 connectivity 345 Figure 7 shows that 4rd can implement IPv6 routing with direct IP 346 forwarding between the two 4rd CEs. In other words, 4rd allows 347 direct packet forwarding between CEs that share a 4rd domain, without 348 the need of forwarding such traffic through the gateway. 350 When V4a under 4rd CE1 send packets to V4b under 4rd CE2, the packets 351 need not go through the gateway (Hub&Spoke) before going to 4rd CE2, 352 they can go to 4rd CE2 directly (mesh). This section describes this 353 in more detail from two perspectives: Network matching and Network 354 Load. 356 +------------------------+ 357 / IPv4 Network \ 358 \ / 359 +-------------------------+ 360 | 361 +---------------------+ 362 | gateway (e.g. BR) | 363 +---------------------+ 364 | 365 +------------------------+ 366 / \ +----------------------+ 367 | ISP's IPv6 access NW | -------| 4rd CE2 (V4b) | 368 \ [//]===/========+== >------------------+ 369 +-----------------[//]---+ 370 | [//] 371 +---------------[//]---+ 372 | 4rd CE1 (V4a) | 373 +----------------------+ 375 Figure 7 377 Taking network matching into account, 4rd should be chosen if the 378 ISP's IPv6 network allows direct CE-CE traffic forwarding (eg: IPv6 379 Flat Routing Network). 381 Compared to Hub & Spoke architecture solutions, mesh architecture 382 solutions can achieve a smaller network load when the 4rd CE 383 communicate frequently. If the ISP thinks that its network has 384 insufficient bandwidth or it wants to lower the load imposed by IPv4 385 connections, they should choose a mesh architecture solution such as 386 4rd. 388 Note: Softwire mesh [RFC5565] is also a mesh architecture solution, 389 but it does not provide the IPv4 sharing function. Softwire mesh can 390 be adopted if IPv4 address sharing is not needed. 392 3.5. Gateway Redundancy Considerations 394 Since in 4rd the BR side does not implement the NAT function, the BR 395 can be easily replicated. For instance, there can be N:1 redundant 396 BRs in the network. Reliable network operation can be guaranteed 397 because a failed BR can be immediately and easily replicated by any 398 one of the N BRs. 400 If the gateway side implements NAT, 1:1 gateway redundancy is the 401 choice, and also upstream and downstream traffic from the same user 402 must go through the same gateway. 4rd easily realizes load balancing 403 because upstream and downstream traffic from the same user can go 404 through different gateways. 406 3.6. NAT Log Considerations 408 4rd CE uses fixed NAT rules and IPv4 users can be directly identified 409 by means of their IPv6 address, so the NAT log does not need to be 410 left. In other words, 4rd allows an operator to save on the need to 411 perform NAT log collection and retention. On the other hand, other 412 solutions may achieve higher address sharing rate than 4rd. If 413 operators want to reduce NAT log with these solutions, their NATs 414 have to be configured with [I-D.tsou-behave-natx4-log-reduction], or 415 allocate fixed port range for NAT rules regardless of the advantage. 417 It is noted that another logging necessity coming from 418 [I-D.ietf-intarea-shared-addressing-issues] is described in 419 [I-D.ietf-intarea-server-logging-recommendations] for Internet facing 420 servers. 422 4. Constraint Considerations 424 This section describes the constraint on user number when addresses 425 are shared. As Section 3.3 stated, the maximum bit range that can be 426 used by Port-set ID is 15 bits. In this case, 4rd CE is restricted 427 to one private port. In fact, it is not able to provide service. So 428 the customer numbers per IPv4 address that can be shared need to be 429 considered along with the ports needed by 4rd CE. 431 It is noted that deriving IPv4 addresses from CE IPv6 prefix 432 generated by 4rd mapping rule may lead to a low rate of IPv4 address 433 sharing because it does not allow for statistical multipexing gains. 434 ISPs who feel that this is not desirable and want to achieve high 435 sharing rates can select centralized gateway/NAPT solutions, which 436 can have a high sharing rate because allow for such statistical 437 multipexing gains. 439 5. Security Considerations 441 The sharing of IPv4 address reduces the port selection space per 4rd 442 CE, so a blind attack can be performed easily. An attack can be 443 performed if the attacker is able to correctly guess the source 444 address and source port. Address and Port Dependent Filtering (APDF) 445 need be implemented in order to counter blind attack. In APDF, not 446 only source address and source port but also destination address and 447 destination port need to be checked. Even so, a blind attack that 448 can be performed against TCP relies on the attacker's ability to 449 guess the 5-ruple (Protocol, Source address, Destination address, 450 Source Port, Destination Port). Shared address issues 451 [I-D.ietf-intarea-shared-addressing-issues] describes a method for 452 the random selection of TCP Sequence Number, that reduces the ability 453 of attacker to correctly guess the 5-ruple. 455 DNS is one of the important protocols to use UDP. In 4rd CE, all DNS 456 reply packets should be discarded, expect for the packets from 457 forward destinations. If DNS implements Port Randomization, the 458 attack success rate can be reduced. 460 We describe here a method for reducing Spoofing Attack under 4rd CE. 461 Using the 4rd mapping rule, the IPv4 address can be derived from IPv6 462 address, so we can check the IPv4 address thus derived and the IPv4 463 address in the header of received packet. If they are same, the 464 packet is forwarded, otherwise, it is dropped. 466 6. Conclusions 468 This document described the ability of 4rd to support the IPv6-only 469 access network. We conclude that the 4rd solution is a viable choice 470 when the ISP desires a stateless IPv4 address sharing option, based 471 on CE side NAT functionality, along with a high degree of freedom in 472 terms of redundancy and optimal traffic forwarding. 4rd is also 473 recommended to operators who do not want IPv6 prefix assignment of 474 which takes into account what IPv4 address generated from IPv6 475 prefix. When only one 4rd applicable character is needed, 4rd may be 476 used to only that purpose with other solutions. 478 7. Acknowledgements 480 The authors would like to thank Remi Despres for his enormous effort 481 to work for 4rd architecture and protocol. The authors also thank to 482 people who provided encouragements concerning the 4rd approach and 483 lead to consider 4rd in Japan. In particular, we would like to thank 484 Toshiya Asaba, Yoshiki Ishida, Tetsuya Innami, Ruri Hiromi, Masataka 485 Mawatari, Akira Nakagawa, Tomoyuki Sahara, Taisuke Sasaki, Katsuyasu 486 Toyama, Mark Townsley, Wojciech Dec, Yuji Yamazaki, have provided 487 useful discussion and comments on the document and review. 489 8. References 491 8.1. Normative References 493 [I-D.despres-intarea-4rd] 494 Despres, R., Matsushima, S., Murakami, T., and O. Troan, 495 "IPv4 Residual Deployment across IPv6-Service networks 496 (4rd) ISP-NAT's made optional", 497 draft-despres-intarea-4rd-00 (work in progress), 498 March 2011. 500 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 501 (IPv6) Specification", RFC 2460, December 1998. 503 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 504 Architecture", RFC 4291, February 2006. 506 8.2. Informative References 508 [I-D.arkko-ipv6-transition-guidelines] 509 Arkko, J. and F. Baker, "Guidelines for Using IPv6 510 Transition Mechanisms during IPv6 Deployment", 511 draft-arkko-ipv6-transition-guidelines-14 (work in 512 progress), December 2010. 514 [I-D.ietf-intarea-server-logging-recommendations] 515 Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 516 "Logging recommendations for Internet facing servers", 517 draft-ietf-intarea-server-logging-recommendations-03 (work 518 in progress), February 2011. 520 [I-D.ietf-intarea-shared-addressing-issues] 521 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 522 Roberts, "Issues with IP Address Sharing", 523 draft-ietf-intarea-shared-addressing-issues-05 (work in 524 progress), March 2011. 526 [I-D.ietf-softwire-dual-stack-lite] 527 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 528 Stack Lite Broadband Deployments Following IPv4 529 Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work 530 in progress), March 2011. 532 [I-D.tsou-behave-natx4-log-reduction] 533 ZOU), T., Li, W., and T. Taylor, "Port Management To 534 Reduce Logging In Large-Scale NATs", 535 draft-tsou-behave-natx4-log-reduction-02 (work in 536 progress), September 2010. 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 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 543 Reserved for Documentation", RFC 3849, July 2004. 545 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 546 Framework", RFC 5565, June 2009. 548 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 549 Reserved for Documentation", RFC 5737, January 2010. 551 Authors' Addresses 553 Chunfa Sun 554 Softbank BB 555 Tokyo Shiodome Building. 22F 556 1-9-1,Higashi-Shimbashi,Minato-Ku 557 Tokyo 105-7322 558 JAPAN 560 Email: c-sun@bb.softbank.co.jp 562 Satoru Matsushima 563 Softbank Telecom 564 Tokyo Shiodome Building. 22F 565 1-9-1,Higashi-Shimbashi,Minato-Ku 566 Tokyo 105-7322 567 JAPAN 569 Email: satoru.matsushima@tm.softbank.co.jp 571 Jie Jiao 572 Softbank BB 573 Tokyo Shiodome Building. 12F 574 1-9-1,Higashi-Shimbashi,Minato-Ku 575 Tokyo 105-7322 576 JAPAN 578 Email: j-jiao@bb.softbank.co.jp