idnits 2.17.1 draft-nishitani-cgn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 27, 2009) is 5440 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-shirasaki-nat444-isp-shared-addr-01 ** Downref: Normative reference to an Informational draft: draft-shirasaki-nat444-isp-shared-addr (ref. 'I-D.shirasaki-nat444-isp-shared-addr') ** Downref: Normative reference to an Informational RFC: RFC 3022 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-00 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Nishitani 3 Internet-Draft I. Yamagata 4 Intended status: BCP S. Miyakawa 5 Expires: November 28, 2009 NTT Communications 6 A. Nakagawa 7 KDDI CORPORATION 8 H. Ashida 9 iTSCOM 10 May 27, 2009 12 Common Functions of Large Scale NAT (LSN) 13 draft-nishitani-cgn-02 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 28, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document defines common functions of multiple types of Large 52 Scale Network Address Translation (NAT) that handles Unicast UDP, TCP 53 and ICMP. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. The policy of assignment of LSN external IP address, port 60 and identifier . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Requirements for protocol handling . . . . . . . . . . . . . . 7 62 4.1. Unicast UDP Requirements . . . . . . . . . . . . . . . . . 7 63 4.2. TCP Requirements . . . . . . . . . . . . . . . . . . . . . 8 64 4.3. ICMP Requirements . . . . . . . . . . . . . . . . . . . . 9 65 5. Summary of Requirements . . . . . . . . . . . . . . . . . . . 9 66 6. Identifying particular users (BOTs, spammers, etc) . . . . . . 11 67 6.1. Store Translation Log . . . . . . . . . . . . . . . . . . 11 68 6.2. Fixed port assignment . . . . . . . . . . . . . . . . . . 11 69 7. Considerations about limiting the number of LSN external 70 ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 Global IPv4 address from the IANA pool will run out in a few years, 82 thus network operators such as ISPs, carriers, large enterprises, 83 universities need to shift from IPv4 services to IPv6 ones. However, 84 IPv6 deployment seems to take a long time. 86 NAT [RFC3022] is a key technology to utilize IPv4 global address 87 effectively in current practice. Operators may have to place NAT 88 devices between end-users and the public Internet to suppress global 89 IPv4 address consumption. 91 In this document, we call such a NAT device "Large Scale NAT (LSN)". 93 Variety of LSN (Large Scale NAT) have been proposed. Some of them 94 are proposed for business continuity after the exhaustion, and some 95 of them are proposed to access from IPv6 network to IPv4 Internet. 97 - NAT444 [I-D.shirasaki-nat444-isp-shared-addr] 99 - DS-Lite (NAT464) [I-D.ietf-softwire-dual-stack-lite] 101 - NAT-64 [I-D.bagnulo-behave-nat64] 103 Each types of Large Scale NAT are shared by plural users and forward 104 huge traffic. Because a demand is common, many of necessary 105 functions are common. 107 This document recommends the common function of Large Scale NAT, so 108 that developers and operators can easily implement these functions. 110 Developpers of Large Scale NAT meet this set of requirements, they 111 can consider specific functions of it. When an operator and a maker 112 chose either implementation, the implementation has necessary 113 functions. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 Readers are expected to be familiar with [RFC4787] and the terms 122 defined there. The following term are used in this document: 124 Large-Scale NAT(LSN): NAT devices placed between CPE and public 125 Internet by an operator. LSN converts CPE IP Address, CPE Port, 126 and CPE Identifier into LSN external IP Address, LSN external Port 127 and LSN external Identifier in communication between CPE and GGN 128 external. 130 LSN external realm: The realm where IPv4 global addresses are 131 assigned 133 LSN internal realm: The realm placed between LSN and CPEs 135 LSN external IP address: The IP address on LSN in LSN external 136 realm mapping to CPE IP address 138 LSN external port: The port on LSN in LSN external realm mapping 139 to CPE port 141 LSN external identifier: The identifier of ICMP on LSN in LSN 142 external realm mapping to CPE identifier 144 Customer Premises Equipment(CPE): The terminal which is placed in 145 LSN internal realm and may establish TCP sessions to LSN external 146 realm (e.g. a single PC or NATBox) 148 CPE IP address: The IP address on CPE in LSN internal realm 150 CPE port: The port on CPE in LSN internal realm 152 CPE identifier: CPE's identifier of ICMP in LSN internal realm 154 CPE 3-tuple: The tuple of TCP/UDP, CPE IP address, and CPE Port 155 Service Server (SS) The server an operator supplies various 156 services for CPE 158 Service Server (SS): The server placed in external realm 160 Service Provide Server (SPS): The server placed in external realm 161 and controlled by LSN administrators 162 ++------++ 163 | SS | 164 ++------++ 165 | 166 | 167 | 168 LSN external IP address Y1 | 169 LSN external port y1 | 170 ++------++ LSN external realm 171 ........... | LSN |............... 172 ++------++ LSN internal realm 173 | 174 CPE IP address X1 | 175 CPE port x1 | 176 ++------++ 177 | CPE | 178 ++------++ 180 Figure 1. LSN network 182 3. The policy of assignment of LSN external IP address, port and 183 identifier 185 A LSN has a pool of LSN external IP addresses, ports and identifiers. 186 CPEs share LSN external IP addresses. Each LSN occupies combination 187 of LSN external IP address, LSN external port and LSN external 188 identifier exclusively. For a fair use of limited resources, LSN has 189 a limitation for the number of the LSN external ports per CPE. LSNs 190 need to keep high transparency to continue existing services after 191 LSN is introduced. Requirement of high transparency for LSN leads to 192 high scalability of LSN. High transparency means LSN basically keeps 193 communications among CPEs except effect of limitations of the number 194 of LSN external ports and TCP sessions. 196 A CPE MAY apply UDP hole punching or TCP hole punching for 197 interactive services among CPEs like Voice over IP and P2P. LSN 198 SHOLUD NOT interfere in services using UDP hole punching or TCP hole 199 punching. 201 REQ-1: A LSN MUST allocate one external IP address to each CPE. 203 a) LSN external IP address allocated to the CPE MUST be same for 204 the UDP, TCP and ICMP. 206 Justification: If a LSN allocates multiple LSN external IP addresses 207 to each CPE, some applications might not work. 209 REQ-2: A LSN MUST allocate LSN external ports which is mapped for CPE 210 ports of UDP. 212 a) A LSN MUST NOT overload LSN external port while a NAT UDP 213 mapping timer does not expire. 215 b) A LSN MAY reuse LSN external port after a NAT UDP mapping timer 216 expires. 218 c) A LSN SHOULD limit the number of the LSN external ports of UDP 219 per CPE. 221 d) The number of the LSN external ports of UDP per CPE which LSN 222 can allocate SHOULD be configurable for the administrator of LSN. 224 Justification: CPEs can communicate to CPE external realm fairly by 225 limiting the number of LSN external ports per CPE. 227 REQ-3: A LSN MUST allocate LSN external ports which is mapped for CPE 228 ports of TCP. 230 a) A LSN MUST NOT overload LSN external port while the port is 231 allocated for one or more TCP sessions originated by another CPE. 233 b) A LSN MAY reuse LSN external port while the port is allocated 234 for no session originated by any CPE. 236 c) A LSN SHOULD limit the number of the LSN external ports of TCP 237 per CPE. 239 d) The number of the LSN external ports of TCP per CPE SHOULD be 240 an administratively configurable option. 242 e) A LSN SHOULD limit the number of the new sessions of TCP per 243 time unit and per CPE. 245 Justification: CPEs can communicate to CPE external realm fairly by 246 limiting the number of LSN external ports per CPE. In addition, TCP 247 LSN external port MAY have TCP sessions, and therefore the TCP 248 session timer is necessary for every 5-Tuple. LSN can have not only 249 the limitations of the number of LSN external ports but also TCP 250 sessions per CPE. Thus a LSN can prevent denial of service attacks 251 with the tons of TCP open and close by malicious CPEs. 253 REQ-4: A LSN MUST allocate LSN external identifiers which is mapped 254 for CPE identifiers of ICMP. 256 a) A LSN MUST NOT overload LSN external identifier before an ICMP 257 Query session timer expires. 259 b) A LSN MAY reuse LSN external identifier after an ICMP Query 260 session timer expires. 262 c) A LSN SHOULD limit the number of the LSN external identifier 263 allocated per CPE. 265 d) The number of the LSN external identifiers per CPE which LSN 266 can allocate SHOULD be an administratively configurable option. 268 Justification: CPEs can communicate to CPE external realm fairly by 269 limiting the number of LSN external identifiers every CPE. 271 If a CPE has already consumed many LSN external ports, the CPE might 272 not use new ports because LSNs limit the number of ports. 274 REQ-5: A LSN MAY have implementations that some specific applications 275 can work well even if each CPE's usable number of LSN external ports 276 have already consumed. 278 Justification: Some specific applications don't work well due to 279 limitation of number of number of ports by LSN, therefore other 280 applications might be affected in the same CPE. 282 In Section 7 we discuss in detail. 284 4. Requirements for protocol handling 286 4.1. Unicast UDP Requirements 288 [RFC4787] describes requirements of the Unicast UDP of a NAT, and the 289 behavior of "Endpoint-Independent Filtering "is RECOMMNEDED, and a 290 NAT MUST have an "Endpoint-Independent Mapping" behavior to ensure 291 transparency of LSN. 293 To have "Endpoint-Independent Filtering" and "Endpoint-Independent 294 Mapping" behaviors for LSNs, LSNs help to establish UDP Hole Punching 295 among CPEs. In other words, the possibility of the establishment of 296 UDP Hole Punching among CPEs which have LSN is equal to the 297 possibility among CPEs which don's t have LSN. If LSNs have an 298 "Address-Dependent Mapping" or "Address and Port-Dependent Mapping" 299 behavior, the possibility that establishment of UDP Hole Punching is 300 less than when LSNs have an "Endpoint-Independent Mapping" behavior. 301 If LSNs have an "Address and Port-Dependent Filtering" behavior, the 302 possibility that establishment of UDP Hole Punching is less than when 303 LSNs have an "Endpoint-Independent Filtering" or "Address Dependent 304 Filtering" behavior. 306 If a LSN supports NAT Hairpinning, a CPE can communicate other CPEs 307 in LSN internal realm of the same LSN. 309 X1:x1 310 +------+ from X1:x1 to X2':x2' 311 | CPE1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>++----++X1':x1' 312 +------+ | | 313 | L | 314 | S | 315 X2:x2 | N | 316 +------+ from X1':x1' to X2:x2 | | 317 | CPE2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<++----++X2':x2' 318 +------+ 320 Figure 2. Hairpinning 322 REQ-6: A LSN SHOULD comply with [RFC4787] for unicast UDP. 324 Justification: LSN SHOULD have to keep high transparency for unicast 325 UDP communications. And CPE MAY use P2P and interactive services 326 between CPEs after a LSN is introduced. 328 4.2. TCP Requirements 330 [RFC5382] describes requirements of TCP of a NAT, and the behavior of 331 "Endpoint-Independent Filtering" is RECOMMNEDED, and a NAT MUST have 332 an "Endpoint-Independent Mapping" behavior to ensure transparency of 333 LSN 335 To have "Endpoint-Independent Filtering" and "Endpoint-Independent 336 Mapping" behaviors for LSNs, LSNs help to establish TCP Hole Punching 337 among CPEs. In other words, the possibility of the establishment of 338 TCP Hole Punching among CPEs which have LSN is equal to the 339 possibility among CPEs which don's t have LSN. If LSNs have an 340 "Address-Dependent Mapping" or "Address and Port-Dependent Mapping" 341 behavior, the possibility that establishment of TCP Hole Punching is 342 less than when LSNs have an "Endpoint-Independent Mapping" behavior. 343 If LSNs have an "Address and Port-Dependent Filtering" behavior, the 344 possibility that establishment of TCP Hole Punching is less than when 345 LSNs have an "Endpoint-Independent Filtering" or "Address Dependent 346 Filtering" behavior. 348 If a LSN supports NAT Hairpinning, a CPE can communicate other CPEs 349 in LSN internal realm of the same LSN. 351 REQ-7: A LSN SHOULD comply with [RFC5382] for TCP. 353 Justification: LSN SHOULD have to keep high transparency for TCP 354 communications. And CPE MAY use P2P and interactive services between 355 CPEs after a LSN is introduced. 357 4.3. ICMP Requirements 359 [RFC5508] describes requirements of ICMP of a NAT. And there MAY be 360 a case that CPE cannot establish communication from CPEs to LSN 361 external realm because LSN limits the number of LSN external ports, 362 identifiers and TCP sessions per CPE. It is useful if CPE can 363 distinguish an error to occur by the limitation of the LSN external 364 ports, identifiers and TCP sessions from other errors. 366 REQ-8: A LSN SHOULD comply with [RFC5508] for ICMP. 368 Justification: LSN SHOULD have to keep high transparency for ICMP. 369 And CPE MAY use P2P and interactive services between CPEs after a LSN 370 is introduced. 372 Therefore, written in [RFC5508], when a LSN can't establish new 373 session of TCP/UDP by limiting of TCP/UDP ports per user, the LSN 374 sends an ICMP destination unreachable message, with code of 13 375 (Communication administratively prohibited) to the sender. 377 5. Summary of Requirements 379 REQ-1: A LSN MUST allocate one external IP address to each CPE. 381 a) LSN external IP address allocated to the CPE MUST be same for 382 the UDP, TCP and ICMP. 384 REQ-2: A LSN MUST allocate LSN external ports mapping to CPE ports of 385 UDP. 387 a) A LSN MUST NOT overload LSN external port while a NAT UDP 388 mapping timer does not expire. 390 b) A LSN MAY reuse LSN external port after a NAT UDP mapping timer 391 expires. 393 c) A LSN SHOULD limit the number of the LSN external ports of UDP 394 per CPE. 396 d) The number of the LSN external ports of UDP per CPE which LSN 397 can allocate SHOULD be configurable for the administrator of LSN. 399 REQ-3: A LSN MUST allocate LSN external ports mapping to CPE ports of 400 TCP. 402 a) A LSN MUST NOT overload LSN external port while the port is 403 allocated for one or more TCP sessions originated by another CPE. 405 b) A LSN MAY reuse LSN external port while the port is allocated 406 for no session originated by any CPE. 408 c) A LSN SHOULD limit the number of the LSN external ports of TCP 409 per CPE. 411 d) The number of the LSN external ports of TCP per CPE SHOULD be 412 an administratively configurable option. 414 e) A LSN SHOULD limit the number of the new sessions of TCP per 415 time unit and per CPE. 417 REQ-4: A LSN MUST allocate LSN external identifiers mapping to CPE 418 identifiers. 420 a) A LSN MUST NOT overload LSN external identifier before an ICMP 421 Query session timer expires. 423 b) A LSN MAY reuse LSN external identifier after an ICMP Query 424 session timer expires. 426 c) A LSN SHOULD limit the number of the LSN external identifier 427 allocated per CPE. 429 d) The number of the LSN external identifiers per CPE which LSN 430 can allocate SHOULD be an administratively configurable option. 432 REQ-5: A LSN MAY have implementations that some specific applications 433 can work well even if each CPE's usable number of LSN external ports 434 have already consumed. 436 REQ-6: A LSN SHOULD comply with [RFC4787] for unicast UDP. 438 REQ-7: A LSN SHOULD comply with [RFC5382] for TCP. 440 REQ-8: A LSN SHOULD comply with [RFC5508] for ICMP. 442 6. Identifying particular users (BOTs, spammers, etc) 444 It is necessary for network administrators to identify a user from an 445 IP address and a timestamp in order to deal with abuse and lawful 446 intercept. When multiple users share one external address at LSN, 447 the source address and the source port that are visible at the 448 destination host are translated ones. The following mechanisms can 449 be used to identify the user that transmitted a certain packet. 451 6.1. Store Translation Log 453 One mechanism stores the following information at LSN. 455 - destination address 457 - destination port 459 - translated source address 461 - translated source port 463 - untranslated source address 465 - untranslated source port 467 - timestamp 469 In such environment that one LSN accommodates a lot of users or 470 processes large amount of traffic, the amount of log will be so large 471 and the operator has to prepare large volume of storage. 473 6.2. Fixed port assignment 475 To save costs for storage, one can adopt this port assignment 476 mechanism at LSN. By fixing the range of external port per user/CPE, 477 and having the mapping of internal IP address to external IP address 478 and port, there will be no need to store per session log. Note that 479 this mechanism is possible only if the source port is known as well 480 as the source address, the destination address and the destination 481 port. 483 7. Considerations about limiting the number of LSN external ports 485 As discussed in section 3, LSN limits the number of LSN external 486 ports and identifier per CPE. Therefore some important applications 487 like DNS might not work well due to applications consuming many LSN 488 external ports. 490 There are two ways to solve this issue. The one is that particular 491 applications are out of the targets for the number of port limitation 492 for LSN. In the case, the applications should be configurable for 493 the administrator of LSN. 495 The other is that LSN doesn't translate address or port for some 496 specific applications, moreover it doesn't limit the number of LSN 497 external ports.(we call "LSN pass-through") Therefore, LSN behave as 498 a router. In this case, some specific applications are out of 499 limitation for the number of LSN external ports. Some applications, 500 which don't work well due to address translation like FTP, is 501 effective. Reducing costs of translation is also effective. As a 502 condition, administrators of LSN can control SPS which become a 503 target of LSN pass-through. 505 X1:x1 X1':x1' X2:x2 506 +---+from X1:x1 +---+fromX1:x1 +---+ 507 | |to X2:x2 | | to X2:x2 | | 508 | C |>>>>>>>>>>>>| L |>>>>>>>>>>>>>>| S | 509 | P | | S | | P | 510 | E |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| S | 511 | |from X2:x2 | |fromX2:x2 | | 512 +---+ to X1:x1 +---+ to X1:x1 +---+ 514 Figure 3. LSN pass-through 516 No matter which solutions you choose, you should consider which 517 applications you are out of limitation target for the number of LSN 518 external ports. When you choose too many applications, this might 519 cause LSNs large load. 521 8. IANA Considerations 523 There are no IANA considerations. 525 9. Security Considerations 527 If malicious CPE can camouflage CPE 3-Tuple, the malicious CPE MAY 528 prevent a normal CPE from sending data to external realm. Therefore, 529 an operator SHOULD make policies to prevent a spoofing of CPE 530 3-tuple. 532 10. Acknowledgements 534 Thanks for the input and review by Yasuhiro Shirasaki, Takeshi 535 Tomochika, Kousuke Shishikura, Dai Kuwabara, Tomoya Yoshida, Takanori 536 Mizuguchi, Arifumi Matsumoto, Tomohiro Fujisaki 538 11. References 540 11.1. Normative References 542 [I-D.shirasaki-nat444-isp-shared-addr] 543 Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 544 and H. Ashida, "NAT444 with ISP Shared Address", 545 draft-shirasaki-nat444-isp-shared-addr-01 (work in 546 progress), March 2009. 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, March 1997. 551 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 552 Address Translator (Traditional NAT)", RFC 3022, 553 January 2001. 555 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 556 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 557 RFC 4787, January 2007. 559 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 560 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 561 RFC 5382, October 2008. 563 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 564 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 565 April 2009. 567 11.2. Informative Reference 569 [I-D.bagnulo-behave-nat64] 570 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 571 Address and Protocol Translation from IPv6 Clients to IPv4 572 Servers", draft-bagnulo-behave-nat64-03 (work in 573 progress), March 2009. 575 [I-D.ietf-softwire-dual-stack-lite] 576 Durand, A., Droms, R., Haberman, B., and J. Woodyatt, 577 "Dual-stack lite broadband deployments post IPv4 578 exhaustion", draft-ietf-softwire-dual-stack-lite-00 (work 579 in progress), March 2009. 581 Authors' Addresses 583 Tomohiro Nishitani 584 NTT Communications Corporation 585 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 586 Tokyo 108-8118 587 Japan 589 Phone: +81 50 3812 4742 590 Email: tomohiro.nishitani@ntt.com 592 Ikuhei Yamagata 593 NTT Communications Corporation 594 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 595 Tokyo 108-8118 596 Japan 598 Phone: +81 50 3812 4704 599 Email: ikuhei@nttv6.jp 601 Shin Miyakawa 602 NTT Communications Corporation 603 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 604 Tokyo 108-8118 605 Japan 607 Phone: +81 50 3812 4695 608 Email: miyakawa@nttv6.jp 610 Akira Nakagawa 611 KDDI CORPORATION 612 GARDEN AIR TOWER, 3-10-10, Iidabashi, Chiyoda-ku 613 Tokyo 102-8460 614 Japan 616 Email: ai-nakagawa@kddi.com 617 Hiroyuki Ashida 618 its communications Inc. 619 3-5-7 Hisamoto Takatsu-ku 620 Kawasaki 213-0011 621 Japan 623 Email: ashida@itscom.ad.jp