idnits 2.17.1 draft-nishitani-cgn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 618. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 2, 2008) is 5770 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.shirasaki-isp-shared-addr' is defined on line 550, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3022 ** Downref: Normative reference to an Informational RFC: RFC 5128 == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-07 == Outdated reference: A later version (-12) exists of draft-ietf-behave-nat-icmp-08 == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-15 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-08 == Outdated reference: A later version (-08) exists of draft-shirasaki-isp-shared-addr-00 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 7 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 S. Miyakawa 4 Expires: January 3, 2009 NTT Communications 5 July 2, 2008 7 Carrier Grade Network Address Translator (NAT) Behavioral Requirements 8 for Unicast UDP, TCP and ICMP 9 draft-nishitani-cgn-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 3, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document defines basic terminology for describing different 43 types of carrier-grade Network Address Translation (NAT) behavior 44 when handling Unicast UDP, TCP and ICMP. Developing carrier-grade 45 NATs that meet this set of requirements increase transparency of data 46 between carrier networks. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. The policy of assignment of CGN external IP address, port 53 and identifier . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Unicast UDP Requirements . . . . . . . . . . . . . . . . . . . 8 55 5. TCP Requirements . . . . . . . . . . . . . . . . . . . . . . . 9 56 6. ICMP Requirements . . . . . . . . . . . . . . . . . . . . . . 9 57 7. Summary of Requirements . . . . . . . . . . . . . . . . . . . 10 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 60 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 61 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 63 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 13 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 65 Intellectual Property and Copyright Statements . . . . . . . . . . 15 67 1. Introduction 69 Global IPv4 address from the IANA pool will run out in a few years, 70 thus carriers need to shift from IPv4 services to IPv6 ones. 71 However, IPv6 deployment seems to take a long time. 73 NAT [RFC3022] is a key technology to utilize IPv4 global address 74 effectively in current practice. ISP may have to place NAT devices 75 between end-users and the public Internet to suppress global IPv4 76 address consumption. 78 In this document, we call carrier's NAT device Carrier Grade NAT 79 (CGN). This document describes behavioral requirements of CGN for 80 unicast UDP, TCP and ICMP. [RFC4787], [I-D.ietf-behave-tcp] and 81 [I-D.ietf-behave-nat-icmp] describes requirements of unicast UDP, TCP 82 and ICMP for NAT which is placed on network edge and is intended for 83 high transparency of NAT. CGNs also need interoperability and high 84 transparency among carriers to make end-users be able to use various 85 services like Peer-to-Peer(P2P) applications and Instant Messenger. 86 [RFC5128] is nominated for an NAT traversal condition in P2P. 88 The main target of this document is 4-4-4 model which uses IPv4 89 address both internal and external side of CGN. 90 [I-D.durand-v6ops-natv4v6v4] describes 4-6-4 model, and CGN may apply 91 to 4-6-4 model. 93 Interaction of this requirements and security of Customer Premises 94 Equipment(CPE) is out of scope because CPE should defend itself. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 Readers are expected to be familiar with [RFC4787] and the terms 103 defined there. The following term are used in this document: 105 Carrier-grade NAT(CGN): NAT devices placed between CPE and public 106 Internet by a carrier. CGN converts CPE IP Address, CPE Port, and 107 CPE Identifier into CGN external IP Address, CGN external Port and 108 CGN external Identifier in communication between CPE and GGN 109 external. 111 CGN external realm: The realm where IPv4 global addresses are 112 assigned 113 CGN internal realm: The realm placed between CGN and CPEs 115 CGN external IP address: The IP address on CGN in CGN external 116 realm corresponding to CPE IP address 118 CGN external port: The port on CGN in CGE external realm 119 corresponding to CPE port 121 CGN external identifier: The identifier of ICMP on CGN in CGN 122 external realm corresponding to CPE identifier 124 Customer Premises Equipment(CPE): The terminal which is placed in 125 CGN internal realm and may establish TCP sessions to CGN external 126 realm 128 CPE IP address: The IP address on CPE in CGN internal realm 130 CPE port: The port on CPE in CGN internal realm 132 CPE identifier: CPE's identifier of ICMP in CGN internal realm 134 CPE 3-tuple: The tuple of TCP/UDP, CPE IP address, and CPE Port 135 Carrier Service Server (CSS) The server a carrier supplies various 136 services for CPE 138 Carrier Service Server (CSS): The server a carrier supplies 139 various services for CPE 141 ++------++ 142 | CSS | 143 ++------++ 144 | 145 | 146 | 147 CGN external IP address Y1 | 148 CGN external port y1 | 149 ++------++ CGN external realm 150 ........... | CGN |............... 151 ++------++ CGN internal realm 152 | 153 CPE IP address X1 | 154 CPE port x1 | 155 ++------++ 156 | CPE | 157 ++------++ 158 CGN network 160 3. The policy of assignment of CGN external IP address, port and 161 identifier 163 A CGN has a pool of CGN external IP addresses, ports and identifiers. 164 CPEs share CGN external IP addresses. Each CGN occupies combination 165 of CGN external IP address and CGN external port exclusively. For a 166 fair use of limited resources, CGN has a limitation for the number of 167 the CGN external ports per CPE. CGNs need to keep high transparency 168 to continue existing services after a carrier introduces CGN. 169 Requirement of high transparency for CGN leads to high scalability of 170 CGN. High transparency means CGN basically keeps communications 171 among CPEs except effect of limitations of the number of CGN external 172 ports and TCP sessions. 174 A CPE MAY apply UDP hole punching or TCP hole punching for 175 interactive services among CPEs like Voice over IP and P2P. CGN 176 SHOLUD NOT interfere in services using UDP hole punching or TCP hole 177 punching. 179 REQ-1: A CGN MUST allocate one external IP address to each CPE. 181 a) CGN external IP address of the UDP, TCP and ICMP MUST be same. 183 Justification: If a CGN allocates multiple CGN external IP addresses 184 to each CPE, some applications might not work. 186 REQ-2: A CGN MUST allocate CGN external ports corresponding to CPE 187 ports of UDP. 189 a) A CGN MUST NOT overload CGN external port while a NAT UDP 190 mapping timer does not expire. 192 b) A CGN MAY overload CGN external port after a NAT UDP mapping 193 timer expires. 195 c) A CGN SHOULD limit the number of the CGN external ports of UDP 196 per CPE. 198 d) The number of the CGN external ports of UDP per CPE which CGN 199 can allocate SHOULD be configurable for the administrator of CGN. 201 e) A CGN SHOULD NOT allocate well-known ports as CGN external 202 ports. 204 Justification: CPEs can communicate to CPE external realm fairly by 205 limiting the number of CGN external ports per CPE. 207 REQ-3: A CGN MUST allocate CGN external ports corresponding to CPE 208 ports of TCP. 210 a) A CGN MUST NOT overload CGN external port while the port is 211 allocated for one or more TCP sessions originated by another CPE. 213 b) A CGN MAY reuse CGN external port while the port is allocated 214 for no session originated by any CPE. 216 c) A CGN SHOULD limit the number of the CGN external ports of TCP 217 per CPE. 219 d) The number of the CGN external ports of TCP per CPE SHOULD be 220 an administratively configurable option. 222 e) A CGN SHOULD limit the number of the new sessions of TCP per 223 time unit and per CPE. 225 f) A CGN SHOULD NOT allocate well-known ports as CGN external 226 ports. 228 Justification: CPEs can communicate to CPE external realm fairly by 229 limiting the number of CGN external ports per CPE. In addition, TCP 230 CGN external port MAY have TCP sessions, and therefore the TCP 231 session timer is necessary for every 5-Tuple. CGN can have not only 232 the limitations of the number of CGN external ports but also TCP 233 sessions per CPE. Thus a CGN can prevent denial of service attacks 234 with the tons of TCP open and close by malicious CPEs. 236 REQ-4: A CGN MUST allocate CGN external identifiers corresponding to 237 CPE identifiers. 239 a) A CGN MUST NOT overload CGN external identifier before an ICMP 240 Query session timer expires. 242 b) A CGN MAY overload CGN external identifier after an ICMP Query 243 session timer expires. 245 c) A CGN SHOULD limit the number of the CGN external identifier 246 allocated per CPE. 248 d) The number of the CGN external identifiers per CPE which CGN 249 can allocate SHOULD be an administratively configurable option. 251 Justification: CPEs can communicate to CPE external realm fairly by 252 limiting the number of CGN external identifiers every CPE. 254 When a CGN limits the number of CGN external ports and TCP sessions, 255 CPE may not use TCP services during using web and P2P services. For 256 example, some services using Ajax demand few dozens of TCP sessions. 257 P2P software like BitTorrent demands also TCP sessions more than few 258 dozens. Some CPEs MAY use E-mail services like POP3 and SMTP even 259 though CPE uses the services which demand many TCP sessions at the 260 same time. Therefore it is important to reserve CGN external ports 261 for such administratively configured services. 263 REQ-5: Reserving CGN external ports per CPE for the always-available 264 services are RECOMENDED. 266 a) The destination port which is used for reservation of CGN 267 external ports SHOULD be administratively configurable. 269 Justification: To reserve the CGN external ports for specific 270 services, CPE can avoid the effect of the limitation of CGN external 271 ports by CGN. 273 In addition, it MAY not be necessary to set a limit to the number of 274 CGN external ports for the communications between CPEs and CSS. The 275 reason is because CGN should pass-through the communications between 276 CPEs and CSS. 278 X1:x1 X1':x1' X2:x2 279 +---+from X1:x1 +---+fromX1:x1 +---+ 280 | |to X2:x2 | | to X2:x2 | | 281 | C |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| C | 282 | P | | G | | S | 283 | E |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| S | 284 | |from X2:x2 | |fromX2:x2 | | 285 +---+ to X1:x1 +---+ to X1:x1 +---+ 287 pass-through 289 REQ-6: A CGN SHOULD pass-through the communication between CPEs and 290 CSS. 292 Justification: Using pass-through, CGN does not have to assign CGN 293 external IP address, ports, and identifiers and limit to the number 294 of ports and TCP sessions for the services that a carrier manages. 296 4. Unicast UDP Requirements 298 [RFC4787] describes requirements of the Unicast UDP of a NAT, and the 299 behavior of "Endpoint-Independent Filtering "is RECOMMNEDED, and a 300 NAT MUST have an "Endpoint-Independent Mapping" behavior to ensure 301 transparency of CGN. 303 To have "Endpoint-Independent Filtering" and "Endpoint-Independent 304 Mapping" behaviors for CGNs, CGNs help to establish UDP Hole Punching 305 among CPEs. In other words, the possibility of the establishment of 306 UDP Hole Punching among CPEs which have CGN is equal to the 307 possibility among CPEs which don's t have CGN. If CGNs have an 308 "Address-Dependent Mapping" or "Address and Port-Dependent Mapping" 309 behavior, the possibility that establishment of UDP Hole Punching is 310 less than when CGNs have an "Endpoint-Independent Mapping" behavior. 311 And if CGNs have an "Address and Port-Dependent Filtering" behavior, 312 the possibility that establishment of UDP Hole Punching is less than 313 when CGNs have an "Endpoint-Independent Filtering" or "Address 314 Dependent Filtering" behavior. Because a CSS is placed external CGN 315 realm, the source IP address and port of the communication from CPE 316 to CSS is CGN external IP address and port. It is RECOMMENDED to use 317 STUN[I-D.ietf-behave-rfc3489bis] if CPEs check the CGN external IP 318 address and port for CPE. 320 A carrier MAY introduce TURN [I-D.ietf-behave-turn] to support 321 communications among CPEs. If CGN supports "Hairpinning", CGN can 322 hairpin the communications between CPEs in the same CGN. Therefore 323 the requirements of Hairpinning for CGN MAY reduce requirements for 324 the performance of TURN servers. When CPEs decide the course of UDP 325 between CPEs, CPE MAY use [I-D.ietf-mmusic-ice] . 327 X1:x1 328 +------+ from X1:x1 to X2':x2' 329 | CPE1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>++----++X1':x1' 330 +------+ | C | 331 | G | 332 | N | 333 X2:x2 | | 334 +------+ from X1':x1' to X2:x2 | | 335 | CPE2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<++----++X2':x2' 336 +------+ 338 Haripinning 340 REQ-7: A CGN SHOULD comply with [RFC4787] for unicast UDP. 342 Justification: CGN SHOULD have to keep high transparency for unicast 343 UDP communications. And CPE MAY use P2P and interactive services 344 between CPEs after a carrier introduces CGN. 346 5. TCP Requirements 348 [I-D.ietf-behave-tcp] describes requirements of TCP of a NAT, and the 349 behavior of "Endpoint-Independent Filtering" is RECOMMNEDED, and a 350 NAT MUST have an "Endpoint-Independent Mapping" behavior to ensure 351 transparency of CGN 353 To have "Endpoint-Independent Filtering" and "Endpoint-Independent 354 Mapping" behaviors for CGNs, CGNs help to establish TCP Hole Punching 355 among CPEs. In other words, the possibility of the establishment of 356 TCP Hole Punching among CPEs which have CGN is equal to the 357 possibility among CPEs which don's t have CGN. If CGNs have an 358 "Address-Dependent Mapping" or "Address and Port-Dependent Mapping" 359 behavior, the possibility that establishment of TCP Hole Punching is 360 less than when CGNs have an "Endpoint-Independent Mapping" behavior. 361 And if CGNs have an "Address and Port-Dependent Filtering" behavior, 362 the possibility that establishment of TCP Hole Punching is less than 363 when CGNs have an "Endpoint-Independent Filtering" or "Address 364 Dependent Filtering" behavior. Because a CSS is placed external CGN 365 realm, the source of IP address and port of the communication from 366 CPE to CSS is CGN external IP address and port. It is RECOMMENDED to 367 use STUN[I-D.ietf-behave-rfc3489bis] if CPEs want to check the CGN 368 external IP address and port for CPE. 370 A carrier MAY introduce TURN [I-D.ietf-behave-turn] to support 371 communications among CPEs. If CGN supports "Hairpinning", CGN can 372 hairpin the communications between CPEs in the same CGN. Therefore 373 the requirements of Hairpinning for CGN MAY reduce requirements for 374 the performance of TURN servers. When CPEs decide the course of TCP 375 between CPEs, CPE MAY use [I-D.ietf-mmusic-ice] . 377 REQ-8: A CGN SHOULD comply with [I-D.ietf-behave-tcp] for TCP. 379 Justification: CGN SHOULD have to keep high transparency for TCP 380 communications. And CPE MAY use P2P and interactive services between 381 CPEs after a carrier introduces CGN. 383 6. ICMP Requirements 385 [I-D.ietf-behave-nat-icmp] describes requirements of ICMP of a NAT. 386 And there MAY be a case that CPE cannot establish communication from 387 CPEs to CGN external realm because CGN limits the number of CGN 388 external ports, identifiers and TCP sessions per CPE. It is useful 389 if CPE can distinguish an error to occur by the limitation of the CGN 390 external ports, identifiers and TCP sessions from other errors. 392 REQ-9: A CGN SHOULD comply with [I-D.ietf-behave-nat-icmp] for ICMP. 394 a) When a CGN can't establish new session of TCP/UDP by limiting 395 of TCP/UDP ports per user, the CGN sends an ICMP destination 396 unreachable message, with code of 13 (Communication 397 administratively prohibited) to the sender. 399 Justification: CGN SHOULD have to keep high transparency for ICMP. 400 And CPE MAY use P2P and interactive services between CPEs after a 401 carrier introduces CGN. And it is necessary to be able to 402 distinguish an error to occur by the limitation of the CGN external 403 ports and TCP sessions from a network error. 405 7. Summary of Requirements 407 REQ-1: A CGN MUST allocate one external IP address to each CPE. 409 a) CGN external IP address of the UDP, TCP and ICMP MUST be same. 411 REQ-2: A CGN MUST allocate CGN external ports corresponding to CPE 412 ports of UDP. 414 a) A CGN MUST NOT overload CGN external port while a NAT UDP 415 mapping timer does not expire. 417 b) A CGN MAY overload CGN external port after a NAT UDP mapping 418 timer expires. 420 c) A CGN SHOULD limit the number of the CGN external ports of UDP 421 per CPE. 423 d) The number of the CGN external ports of UDP per CPE which CGN 424 can allocate SHOULD be configurable for the administrator of CGN. 426 e) A CGN SHOULD NOT allocate well-known ports as CGN external 427 ports. 429 REQ-3: A CGN MUST allocate CGN external ports corresponding to CPE 430 ports of TCP. 432 a) A CGN MUST NOT overload CGN external port while the port is 433 allocated for one or more TCP sessions originated by another CPE. 435 b) A CGN MAY reuse CGN external port while the port is allocated 436 for no session originated by any CPE. 438 c) A CGN SHOULD limit the number of the CGN external ports of TCP 439 per CPE. 441 d) The number of the CGN external ports of TCP per CPE SHOULD be 442 an administratively configurable option. 444 e) A CGN SHOULD limit the number of the new sessions of TCP per 445 time unit and per CPE. 447 f) A CGN SHOULD NOT allocate well-known ports as CGN external 448 ports. 450 REQ-4: A CGN MUST allocate CGN external identifiers corresponding to 451 CPE identifiers. 453 a) A CGN MUST NOT overload CGN external identifier before an ICMP 454 Query session timer expires. 456 b) A CGN MAY overload CGN external identifier after an ICMP Query 457 session timer expires. 459 c) A CGN SHOULD limit the number of the CGN external identifier 460 allocated per CPE. 462 d) The number of the CGN external identifiers per CPE which CGN 463 can allocate SHOULD be an administratively configurable option. 465 REQ-5: Reserving CGN external ports per CPE for the always-available 466 services are RECOMENDED. 468 a) The destination port which is used for reservation of CGN 469 external ports SHOULD be administratively configurable. 471 REQ-6: A CGN SHOULD pass-through the communication between CPEs and 472 CSS. 474 REQ-7: A CGN SHOULD comply with [RFC4787] for unicast UDP. 476 REQ-8: A CGN SHOULD comply with [I-D.ietf-behave-tcp] for TCP. 478 REQ-9: A CGN SHOULD comply with [I-D.ietf-behave-nat-icmp] for ICMP. 480 a) When a CGN can't establish new session of TCP/UDP by limiting 481 of TCP/UDP ports per user, the CGN sends an ICMP destination 482 unreachable message, with code of 13 (Communication 483 administratively prohibited) to the sender. 485 8. IANA Considerations 487 There are no IANA considerations. 489 9. Security Considerations 491 If malicious CPE can camouflage CPE 3-Tuple, the malicious CPE MAY 492 prevent a normal CPE from sending data to external realm. Therefore, 493 a carrier SHOULD make p olicies to prevent a spoofing of CPE 3-tuple. 495 10. Acknowledgements 497 Thanks for the input and review by Yasuhiro Shirasaki, Takeshi 498 Tomochika, Kousuke Shishikura, Dai Kuwabara, Tomoya Yoshida, Takanori 499 Mizuguchi. 501 11. References 503 11.1. Normative References 505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 506 Requirement Levels", BCP 14, RFC 2119, March 1997. 508 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 509 Address Translator (Traditional NAT)", RFC 3022, 510 January 2001. 512 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 513 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 514 RFC 4787, January 2007. 516 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 517 Peer (P2P) Communication across Network Address 518 Translators (NATs)", RFC 5128, March 2008. 520 [I-D.ietf-behave-tcp] 521 Guha, S., "NAT Behavioral Requirements for TCP", 522 draft-ietf-behave-tcp-07 (work in progress), April 2007. 524 [I-D.ietf-behave-nat-icmp] 525 Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 526 Behavioral Requirements for ICMP protocol", 527 draft-ietf-behave-nat-icmp-08 (work in progress), 528 June 2008. 530 [I-D.ietf-behave-rfc3489bis] 531 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 532 "Session Traversal Utilities for (NAT) (STUN)", 533 draft-ietf-behave-rfc3489bis-15 (work in progress), 534 February 2008. 536 [I-D.ietf-mmusic-ice] 537 Rosenberg, J., "Interactive Connectivity Establishment 538 (ICE): A Protocol for Network Address Translator (NAT) 539 Traversal for Offer/Answer Protocols", 540 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 542 [I-D.ietf-behave-turn] 543 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 544 Relays around NAT (TURN): Relay Extensions to Session 545 Traversal Utilities for NAT (STUN)", 546 draft-ietf-behave-turn-08 (work in progress), June 2008. 548 11.2. Informative Reference 550 [I-D.shirasaki-isp-shared-addr] 551 Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, 552 "ISP Shared Address after IPv4 Address Exhaustion", 553 draft-shirasaki-isp-shared-addr-00 (work in progress), 554 June 2008. 556 [I-D.durand-v6ops-natv4v6v4] 557 Durand, A., "Distributed NAT for broadband deployments 558 post IPv4 exhaustion", draft-durand-v6ops-natv4v6v4-01 559 (work in progress), February 2008. 561 Authors' Addresses 563 Tomohiro Nishitani 564 NTT Communications Corporation 565 Tokyo Opera City Tower 21F, 3-20-2 Nishi-Shinjuku, Shinjuku-ku 566 Tokyo 163-1421 567 Japan 569 Phone: +81 3 6800 3214 570 Email: tomohiro.nishitani@ntt.com 571 Shin Miyakawa 572 NTT Communications Corporation 573 Tokyo Opera City Tower 21F, 3-20-2 Nishi-Shinjuku, Shinjuku-ku 574 Tokyo 163-1421 575 Japan 577 Phone: +81 3 6800 3262 578 Email: miyakawa@nttv6.jp 580 Full Copyright Statement 582 Copyright (C) The IETF Trust (2008). 584 This document is subject to the rights, licenses and restrictions 585 contained in BCP 78, and except as set forth therein, the authors 586 retain all their rights. 588 This document and the information contained herein are provided on an 589 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 590 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 591 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 592 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 593 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 594 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 596 Intellectual Property 598 The IETF takes no position regarding the validity or scope of any 599 Intellectual Property Rights or other rights that might be claimed to 600 pertain to the implementation or use of the technology described in 601 this document or the extent to which any license under such rights 602 might or might not be available; nor does it represent that it has 603 made any independent effort to identify any such rights. Information 604 on the procedures with respect to rights in RFC documents can be 605 found in BCP 78 and BCP 79. 607 Copies of IPR disclosures made to the IETF Secretariat and any 608 assurances of licenses to be made available, or the result of an 609 attempt made to obtain a general license or permission for the use of 610 such proprietary rights by implementers or users of this 611 specification can be obtained from the IETF on-line IPR repository at 612 http://www.ietf.org/ipr. 614 The IETF invites any interested party to bring to its attention any 615 copyrights, patents or patent applications, or other proprietary 616 rights that may cover technology that may be required to implement 617 this standard. Please address the information to the IETF at 618 ietf-ipr@ietf.org. 620 Acknowledgment 622 Funding for the RFC Editor function is provided by the IETF 623 Administrative Support Activity (IASA).