idnits 2.17.1 draft-nishitani-cgn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (November 30, 2009) is 5262 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) ** Downref: Normative reference to an Informational RFC: RFC 3022 == Outdated reference: A later version (-08) exists of draft-shirasaki-nat444-isp-shared-addr-02 ** Downref: Normative reference to an Informational draft: draft-shirasaki-nat444-isp-shared-addr (ref. 'I-D.shirasaki-nat444-isp-shared-addr') == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-02 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: June 3, 2010 NTT Communications 6 A. Nakagawa 7 KDDI CORPORATION 8 H. Ashida 9 iTSCOM 10 November 30, 2009 12 Common Functions of Large Scale NAT (LSN) 13 draft-nishitani-cgn-03 15 Abstract 17 This document defines common functions of multiple types of Large 18 Scale Network Address Translation (NAT) that handles Unicast UDP, TCP 19 and ICMP. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on June 3, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. The policy of assignment of LSN external IP address, port 64 and identifier . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Requirements for protocol handling . . . . . . . . . . . . . . 7 66 4.1. Unicast UDP Requirements . . . . . . . . . . . . . . . . . 7 67 4.2. TCP Requirements . . . . . . . . . . . . . . . . . . . . . 8 68 4.3. ICMP Requirements . . . . . . . . . . . . . . . . . . . . 9 69 5. Summary of Requirements . . . . . . . . . . . . . . . . . . . 9 70 6. Identifying particular users (BOTs, spammers, etc) . . . . . . 11 71 6.1. Store Translation Log . . . . . . . . . . . . . . . . . . 11 72 6.2. Fixed port assignment . . . . . . . . . . . . . . . . . . 11 73 7. Considerations about limiting the number of LSN external 74 ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 80 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 Global IPv4 address from the IANA pool will run out in a few years, 86 thus network operators such as ISPs, carriers, large enterprises, 87 universities need to shift from IPv4 services to IPv6 ones. However, 88 IPv6 deployment seems to take a long time. 90 NAT [RFC3022] is a key technology to utilize IPv4 global address 91 effectively in current practice. Operators may have to place NAT 92 devices between end-users and the public Internet to suppress global 93 IPv4 address consumption. 95 In this document, we call such a NAT device "Large Scale NAT (LSN)". 97 Variety of LSN (Large Scale NAT) have been proposed. Some of them 98 are proposed for business continuity after the exhaustion, and some 99 of them are proposed to access from IPv6 network to IPv4 Internet. 101 - NAT444 [I-D.shirasaki-nat444-isp-shared-addr] 103 - DS-Lite (NAT464) [I-D.ietf-softwire-dual-stack-lite] 105 - NAT-64 [I-D.bagnulo-behave-nat64] 107 Each types of Large Scale NAT are shared by plural users and forward 108 huge traffic. Because a demand is common, many of necessary 109 functions are common. 111 This document recommends the common function of Large Scale NAT, so 112 that developers and operators can easily implement these functions. 114 Developpers of Large Scale NAT meet this set of requirements, they 115 can consider specific functions of it. When an operator and a maker 116 chose either implementation, the implementation has necessary 117 functions. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 Readers are expected to be familiar with [RFC4787] and the terms 126 defined there. The following term are used in this document: 128 Large-Scale NAT(LSN): NAT devices placed between CPE and public 129 Internet by an operator. LSN converts CPE IP Address, CPE Port, 130 and CPE Identifier into LSN external IP Address, LSN external Port 131 and LSN external Identifier in communication between CPE and GGN 132 external. 134 LSN external realm: The realm where IPv4 global addresses are 135 assigned 137 LSN internal realm: The realm placed between LSN and CPEs 139 LSN external IP address: The IP address on LSN in LSN external 140 realm mapping to CPE IP address 142 LSN external port: The port on LSN in LSN external realm mapping 143 to CPE port 145 LSN external identifier: The identifier of ICMP on LSN in LSN 146 external realm mapping to CPE identifier 148 Customer Premises Equipment(CPE): The terminal which is placed in 149 LSN internal realm and may establish TCP sessions to LSN external 150 realm (e.g. a single PC or NATBox) 152 CPE IP address: The IP address on CPE in LSN internal realm 154 CPE port: The port on CPE in LSN internal realm 156 CPE identifier: CPE's identifier of ICMP in LSN internal realm 158 CPE 3-tuple: The tuple of TCP/UDP, CPE IP address, and CPE Port 159 Service Server (SS) The server an operator supplies various 160 services for CPE 162 Service Server (SS): The server placed in external realm 164 Service Provide Server (SPS): The server placed in external realm 165 and controlled by LSN administrators 166 ++------++ 167 | SS | 168 ++------++ 169 | 170 | 171 | 172 LSN external IP address Y1 | 173 LSN external port y1 | 174 ++------++ LSN external realm 175 ........... | LSN |............... 176 ++------++ LSN internal realm 177 | 178 CPE IP address X1 | 179 CPE port x1 | 180 ++------++ 181 | CPE | 182 ++------++ 184 Figure 1. LSN network 186 3. The policy of assignment of LSN external IP address, port and 187 identifier 189 A LSN has a pool of LSN external IP addresses, ports and identifiers. 190 CPEs share LSN external IP addresses. Each LSN occupies combination 191 of LSN external IP address, LSN external port and LSN external 192 identifier exclusively. For a fair use of limited resources, LSN has 193 a limitation for the number of the LSN external ports per CPE. LSNs 194 need to keep high transparency to continue existing services after 195 LSN is introduced. Requirement of high transparency for LSN leads to 196 high scalability of LSN. High transparency means LSN basically keeps 197 communications among CPEs except effect of limitations of the number 198 of LSN external ports and TCP sessions. 200 A CPE MAY apply UDP hole punching or TCP hole punching for 201 interactive services among CPEs like Voice over IP and P2P. LSN 202 SHOLUD NOT interfere in services using UDP hole punching or TCP hole 203 punching. 205 REQ-1: A LSN MUST allocate one external IP address to each CPE. 207 a) LSN external IP address allocated to the CPE MUST be same for 208 the UDP, TCP and ICMP. 210 Justification: If a LSN allocates multiple LSN external IP addresses 211 to each CPE, some applications might not work. 213 REQ-2: A LSN MUST allocate LSN external ports which is mapped for CPE 214 ports of UDP. 216 a) A LSN MUST NOT overload LSN external port while a NAT UDP 217 mapping timer does not expire. 219 b) A LSN MAY reuse LSN external port after a NAT UDP mapping timer 220 expires. 222 c) A LSN SHOULD limit the number of the LSN external ports of UDP 223 per CPE. 225 d) The number of the LSN external ports of UDP per CPE which LSN 226 can allocate SHOULD be configurable for the administrator of LSN. 228 Justification: CPEs can communicate to CPE external realm fairly by 229 limiting the number of LSN external ports per CPE. 231 REQ-3: A LSN MUST allocate LSN external ports which is mapped for CPE 232 ports of TCP. 234 a) A LSN MUST NOT overload LSN external port while the port is 235 allocated for one or more TCP sessions originated by another CPE. 237 b) A LSN MAY reuse LSN external port while the port is allocated 238 for no session originated by any CPE. 240 c) A LSN SHOULD limit the number of the LSN external ports of TCP 241 per CPE. 243 d) The number of the LSN external ports of TCP per CPE SHOULD be 244 an administratively configurable option. 246 e) A LSN SHOULD limit the number of the new sessions of TCP per 247 time unit and per CPE. 249 Justification: CPEs can communicate to CPE external realm fairly by 250 limiting the number of LSN external ports per CPE. In addition, TCP 251 LSN external port MAY have TCP sessions, and therefore the TCP 252 session timer is necessary for every 5-Tuple. LSN can have not only 253 the limitations of the number of LSN external ports but also TCP 254 sessions per CPE. Thus a LSN can prevent denial of service attacks 255 with the tons of TCP open and close by malicious CPEs. 257 REQ-4: A LSN MUST allocate LSN external identifiers which is mapped 258 for CPE identifiers of ICMP. 260 a) A LSN MUST NOT overload LSN external identifier before an ICMP 261 Query session timer expires. 263 b) A LSN MAY reuse LSN external identifier after an ICMP Query 264 session timer expires. 266 c) A LSN SHOULD limit the number of the LSN external identifier 267 allocated per CPE. 269 d) The number of the LSN external identifiers per CPE which LSN 270 can allocate SHOULD be an administratively configurable option. 272 Justification: CPEs can communicate to CPE external realm fairly by 273 limiting the number of LSN external identifiers every CPE. 275 If a CPE has already consumed many LSN external ports, the CPE might 276 not use new ports because LSNs limit the number of ports. 278 REQ-5: A LSN MAY have implementations that some specific applications 279 can work well even if each CPE's usable number of LSN external ports 280 have already consumed. 282 Justification: Some specific applications don't work well due to 283 limitation of number of number of ports by LSN, therefore other 284 applications might be affected in the same CPE. 286 In Section 7 we discuss in detail. 288 4. Requirements for protocol handling 290 4.1. Unicast UDP Requirements 292 [RFC4787] describes requirements of the Unicast UDP of a NAT, and the 293 behavior of "Endpoint-Independent Filtering "is RECOMMNEDED, and a 294 NAT MUST have an "Endpoint-Independent Mapping" behavior to ensure 295 transparency of LSN. 297 To have "Endpoint-Independent Filtering" and "Endpoint-Independent 298 Mapping" behaviors for LSNs, LSNs help to establish UDP Hole Punching 299 among CPEs. In other words, the possibility of the establishment of 300 UDP Hole Punching among CPEs which have LSN is equal to the 301 possibility among CPEs which don's t have LSN. If LSNs have an 302 "Address-Dependent Mapping" or "Address and Port-Dependent Mapping" 303 behavior, the possibility that establishment of UDP Hole Punching is 304 less than when LSNs have an "Endpoint-Independent Mapping" behavior. 305 If LSNs have an "Address and Port-Dependent Filtering" behavior, the 306 possibility that establishment of UDP Hole Punching is less than when 307 LSNs have an "Endpoint-Independent Filtering" or "Address Dependent 308 Filtering" behavior. 310 If a LSN supports NAT Hairpinning, a CPE can communicate other CPEs 311 in LSN internal realm of the same LSN. 313 X1:x1 314 +------+ from X1:x1 to X2':x2' 315 | CPE1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>++----++X1':x1' 316 +------+ | | 317 | L | 318 | S | 319 X2:x2 | N | 320 +------+ from X1':x1' to X2:x2 | | 321 | CPE2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<++----++X2':x2' 322 +------+ 324 Figure 2. Hairpinning 326 REQ-6: A LSN SHOULD comply with [RFC4787] for unicast UDP. 328 Justification: LSN SHOULD have to keep high transparency for unicast 329 UDP communications. And CPE MAY use P2P and interactive services 330 between CPEs after a LSN is introduced. 332 4.2. TCP Requirements 334 [RFC5382] describes requirements of TCP of a NAT, and the behavior of 335 "Endpoint-Independent Filtering" is RECOMMNEDED, and a NAT MUST have 336 an "Endpoint-Independent Mapping" behavior to ensure transparency of 337 LSN 339 To have "Endpoint-Independent Filtering" and "Endpoint-Independent 340 Mapping" behaviors for LSNs, LSNs help to establish TCP Hole Punching 341 among CPEs. In other words, the possibility of the establishment of 342 TCP Hole Punching among CPEs which have LSN is equal to the 343 possibility among CPEs which don's t have LSN. If LSNs have an 344 "Address-Dependent Mapping" or "Address and Port-Dependent Mapping" 345 behavior, the possibility that establishment of TCP Hole Punching is 346 less than when LSNs have an "Endpoint-Independent Mapping" behavior. 347 If LSNs have an "Address and Port-Dependent Filtering" behavior, the 348 possibility that establishment of TCP Hole Punching is less than when 349 LSNs have an "Endpoint-Independent Filtering" or "Address Dependent 350 Filtering" behavior. 352 If a LSN supports NAT Hairpinning, a CPE can communicate other CPEs 353 in LSN internal realm of the same LSN. 355 REQ-7: A LSN SHOULD comply with [RFC5382] for TCP. 357 Justification: LSN SHOULD have to keep high transparency for TCP 358 communications. And CPE MAY use P2P and interactive services between 359 CPEs after a LSN is introduced. 361 4.3. ICMP Requirements 363 [RFC5508] describes requirements of ICMP of a NAT. And there MAY be 364 a case that CPE cannot establish communication from CPEs to LSN 365 external realm because LSN limits the number of LSN external ports, 366 identifiers and TCP sessions per CPE. It is useful if CPE can 367 distinguish an error to occur by the limitation of the LSN external 368 ports, identifiers and TCP sessions from other errors. 370 REQ-8: A LSN SHOULD comply with [RFC5508] for ICMP. 372 Justification: LSN SHOULD have to keep high transparency for ICMP. 373 And CPE MAY use P2P and interactive services between CPEs after a LSN 374 is introduced. 376 Therefore, written in [RFC5508], when a LSN can't establish new 377 session of TCP/UDP by limiting of TCP/UDP ports per user, the LSN 378 sends an ICMP destination unreachable message, with code of 13 379 (Communication administratively prohibited) to the sender. 381 5. Summary of Requirements 383 REQ-1: A LSN MUST allocate one external IP address to each CPE. 385 a) LSN external IP address allocated to the CPE MUST be same for 386 the UDP, TCP and ICMP. 388 REQ-2: A LSN MUST allocate LSN external ports mapping to CPE ports of 389 UDP. 391 a) A LSN MUST NOT overload LSN external port while a NAT UDP 392 mapping timer does not expire. 394 b) A LSN MAY reuse LSN external port after a NAT UDP mapping timer 395 expires. 397 c) A LSN SHOULD limit the number of the LSN external ports of UDP 398 per CPE. 400 d) The number of the LSN external ports of UDP per CPE which LSN 401 can allocate SHOULD be configurable for the administrator of LSN. 403 REQ-3: A LSN MUST allocate LSN external ports mapping to CPE ports of 404 TCP. 406 a) A LSN MUST NOT overload LSN external port while the port is 407 allocated for one or more TCP sessions originated by another CPE. 409 b) A LSN MAY reuse LSN external port while the port is allocated 410 for no session originated by any CPE. 412 c) A LSN SHOULD limit the number of the LSN external ports of TCP 413 per CPE. 415 d) The number of the LSN external ports of TCP per CPE SHOULD be 416 an administratively configurable option. 418 e) A LSN SHOULD limit the number of the new sessions of TCP per 419 time unit and per CPE. 421 REQ-4: A LSN MUST allocate LSN external identifiers mapping to CPE 422 identifiers. 424 a) A LSN MUST NOT overload LSN external identifier before an ICMP 425 Query session timer expires. 427 b) A LSN MAY reuse LSN external identifier after an ICMP Query 428 session timer expires. 430 c) A LSN SHOULD limit the number of the LSN external identifier 431 allocated per CPE. 433 d) The number of the LSN external identifiers per CPE which LSN 434 can allocate SHOULD be an administratively configurable option. 436 REQ-5: A LSN MAY have implementations that some specific applications 437 can work well even if each CPE's usable number of LSN external ports 438 have already consumed. 440 REQ-6: A LSN SHOULD comply with [RFC4787] for unicast UDP. 442 REQ-7: A LSN SHOULD comply with [RFC5382] for TCP. 444 REQ-8: A LSN SHOULD comply with [RFC5508] for ICMP. 446 6. Identifying particular users (BOTs, spammers, etc) 448 It is necessary for network administrators to identify a user from an 449 IP address and a timestamp in order to deal with abuse and lawful 450 intercept. When multiple users share one external address at LSN, 451 the source address and the source port that are visible at the 452 destination host are translated ones. The following mechanisms can 453 be used to identify the user that transmitted a certain packet. 455 6.1. Store Translation Log 457 One mechanism stores the following information at LSN. 459 - destination address 461 - destination port 463 - translated source address 465 - translated source port 467 - untranslated source address 469 - untranslated source port 471 - timestamp 473 In such environment that one LSN accommodates a lot of users or 474 processes large amount of traffic, the amount of log will be so large 475 and the operator has to prepare large volume of storage. 477 6.2. Fixed port assignment 479 To save costs for storage, one can adopt this port assignment 480 mechanism at LSN. By fixing the range of external port per user/CPE, 481 and having the mapping of internal IP address to external IP address 482 and port, there will be no need to store per session log. Note that 483 this mechanism is possible only if the source port is known as well 484 as the source address, the destination address and the destination 485 port. 487 7. Considerations about limiting the number of LSN external ports 489 As discussed in section 3, LSN limits the number of LSN external 490 ports and identifier per CPE. Therefore some important applications 491 like DNS might not work well due to applications consuming many LSN 492 external ports. 494 There are two ways to solve this issue. The one is that particular 495 applications are out of the targets for the number of port limitation 496 for LSN. In the case, the applications should be configurable for 497 the administrator of LSN. 499 The other is that LSN doesn't translate address or port for some 500 specific applications, moreover it doesn't limit the number of LSN 501 external ports.(we call "LSN pass-through") Therefore, LSN behave as 502 a router. In this case, some specific applications are out of 503 limitation for the number of LSN external ports. Some applications, 504 which don't work well due to address translation like FTP, is 505 effective. Reducing costs of translation is also effective. As a 506 condition, administrators of LSN can control SPS which become a 507 target of LSN pass-through. 509 X1:x1 X1':x1' X2:x2 510 +---+from X1:x1 +---+fromX1:x1 +---+ 511 | |to X2:x2 | | to X2:x2 | | 512 | C |>>>>>>>>>>>>| L |>>>>>>>>>>>>>>| S | 513 | P | | S | | P | 514 | E |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| S | 515 | |from X2:x2 | |fromX2:x2 | | 516 +---+ to X1:x1 +---+ to X1:x1 +---+ 518 Figure 3. LSN pass-through 520 No matter which solutions you choose, you should consider which 521 applications you are out of limitation target for the number of LSN 522 external ports. When you choose too many applications, this might 523 cause LSNs large load. 525 8. IANA Considerations 527 There are no IANA considerations. 529 9. Security Considerations 531 If malicious CPE can camouflage CPE 3-Tuple, the malicious CPE MAY 532 prevent a normal CPE from sending data to external realm. Therefore, 533 an operator SHOULD make policies to prevent a spoofing of CPE 534 3-tuple. 536 10. Acknowledgements 538 Thanks for the input and review by Yasuhiro Shirasaki, Takeshi 539 Tomochika, Kousuke Shishikura, Dai Kuwabara, Tomoya Yoshida, Takanori 540 Mizuguchi, Arifumi Matsumoto, Tomohiro Fujisaki 542 11. References 544 11.1. Normative References 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, March 1997. 549 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 550 Address Translator (Traditional NAT)", RFC 3022, 551 January 2001. 553 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 554 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 555 RFC 4787, January 2007. 557 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 558 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 559 RFC 5382, October 2008. 561 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 562 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 563 April 2009. 565 [I-D.shirasaki-nat444-isp-shared-addr] 566 Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 567 and H. Ashida, "NAT444 with ISP Shared Address", 568 draft-shirasaki-nat444-isp-shared-addr-02 (work in 569 progress), September 2009. 571 11.2. Informative Reference 573 [I-D.ietf-softwire-dual-stack-lite] 574 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 575 Y., and R. Bush, "Dual-stack lite broadband deployments 576 post IPv4 exhaustion", 577 draft-ietf-softwire-dual-stack-lite-02 (work in progress), 578 October 2009. 580 [I-D.bagnulo-behave-nat64] 581 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 582 Address and Protocol Translation from IPv6 Clients to IPv4 583 Servers", draft-bagnulo-behave-nat64-03 (work in 584 progress), March 2009. 586 Authors' Addresses 588 Tomohiro Nishitani 589 NTT Communications Corporation 590 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 591 Tokyo 108-8118 592 Japan 594 Phone: +81 50 3812 4742 595 Email: tomohiro.nishitani@ntt.com 597 Ikuhei Yamagata 598 NTT Communications Corporation 599 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 600 Tokyo 108-8118 601 Japan 603 Phone: +81 50 3812 4704 604 Email: ikuhei@nttv6.jp 606 Shin Miyakawa 607 NTT Communications Corporation 608 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 609 Tokyo 108-8118 610 Japan 612 Phone: +81 50 3812 4695 613 Email: miyakawa@nttv6.jp 615 Akira Nakagawa 616 KDDI CORPORATION 617 GARDEN AIR TOWER, 3-10-10, Iidabashi, Chiyoda-ku 618 Tokyo 102-8460 619 Japan 621 Email: ai-nakagawa@kddi.com 622 Hiroyuki Ashida 623 its communications Inc. 624 541-1 Ichigao-cho Aoba-ku 625 Yokohama 225-0024 626 Japan 628 Email: ashida@itscom.ad.jp