idnits 2.17.1 draft-nishitani-cgn-05.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 : ---------------------------------------------------------------------------- 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 (July 12, 2010) is 5037 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) == Missing Reference: 'RFC1812' is mentioned on line 677, but not defined == Unused Reference: 'RFC3022' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'RFC5382' is defined on line 917, but no explicit reference was found in the text == Unused Reference: 'RFC5508' is defined on line 921, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3022 == Outdated reference: A later version (-08) exists of draft-shirasaki-nat444-isp-shared-addr-03 ** 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-05 == Outdated reference: A later version (-10) exists of draft-ymbk-aplusp-05 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force I. Yamagata 3 Internet-Draft S. Miyakawa 4 Intended status: BCP NTT Communications 5 Expires: January 13, 2011 A. Nakagawa 6 Japan Internet Exchange (JPIX) 7 H. Ashida 8 iTSCOM 9 July 12, 2010 11 Common requirements for IP address sharing schemes 12 draft-nishitani-cgn-05 14 Abstract 16 This document defines common requirements of multiple types of Large 17 Scale Network Address Translation (NAT) that handles Unicast UDP, TCP 18 and ICMP. 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 January 13, 2011. 37 Copyright Notice 39 Copyright (c) 2010 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Requirements for UDP . . . . . . . . . . . . . . . . . . . . . 5 57 4. Requirements for TCP . . . . . . . . . . . . . . . . . . . . . 9 58 5. Requirements for ICMP . . . . . . . . . . . . . . . . . . . . 12 59 6. LSN specified Requirements . . . . . . . . . . . . . . . . . . 16 60 7. Identifying particular users (BOTs, spammers, etc) . . . . . . 18 61 7.1. Store Translation Log . . . . . . . . . . . . . . . . . . 18 62 7.2. Fixed port assignment . . . . . . . . . . . . . . . . . . 19 63 8. Considerations about limiting the number of LSN external 64 ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 66 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 67 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 68 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 69 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 70 12.2. Informative Reference . . . . . . . . . . . . . . . . . . 21 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 73 1. Introduction 75 Now there are several IPv4 address sharing schemes such as Large 76 Scale NAT (as known as NAT444[I-D.shirasaki-nat444-isp-shared-addr]) 77 , DS-Lite[I-D.ietf-softwire-dual-stack-lite], A+P[I-D.ymbk-aplusp] 78 and so on under the discussion. 80 Those IPv4 address sharing schemes are intended to be used in the 81 middle of the ISP access network against IPv4 address shortage 82 problem by sharing one global IPv4 address by multiple users. 83 Authors believe that there are common requirements among all IPv4 84 address sharing schemes to make them "transparent" as much as 85 possible. At the BEHAVE working group of IETF, following RFCs have 86 already defined to achieve maximum transparency at the residential 87 CPE which has NAT function; 89 - RFC4787 : NAT Behavioral Requirements for Unicast UDP 91 - RFC5382 : NAT Behavioral Requirements for TCP 93 - RFC5508 : NAT Behavioral Requirements for ICMP 95 However so, because those RFCs are mainly aimed at residential CPE 96 and any IPv4 address sharing schemes are a bit different from it, we 97 believe that requirements for LSN and other schemes should be defined 98 alternatively to those RFCs. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 Readers are expected to be familiar with [RFC4787] and the terms 107 defined there. The following term are used in this document: 109 Large-Scale NAT(LSN): NAT devices placed between CPE and public 110 Internet by an operator. LSN converts CPE IP Address, CPE Port, 111 and CPE Identifier into LSN external IP Address, LSN external Port 112 and LSN external Identifier in communication between CPE and GGN 113 external. 115 LSN external realm: The realm where IPv4 global addresses are 116 assigned 118 LSN internal realm: The realm placed between LSN and CPEs 119 LSN external IP address: The IP address on LSN in LSN external 120 realm mapping to CPE IP address 122 LSN external port: The port on LSN in LSN external realm mapping 123 to CPE port 125 LSN external identifier: The identifier of ICMP on LSN in LSN 126 external realm mapping to CPE identifier 128 Customer Premises Equipment(CPE): The terminal which is placed in 129 LSN internal realm and may establish TCP sessions to LSN external 130 realm (e.g. a single PC or NATBox) 132 CPE IP address: The IP address on CPE in LSN internal realm 134 CPE port: The port on CPE in LSN internal realm 136 CPE identifier: CPE's identifier of ICMP in LSN internal realm 138 CPE 3-tuple: The tuple of TCP/UDP, CPE IP address, and CPE Port 139 Service Server (SS) The server an operator supplies various 140 services for CPE 142 Service Server (SS): The server placed in external realm 144 Service Provide Server (SPS): The server placed in external realm 145 and controlled by LSN administrators 147 ++------++ 148 | SS | 149 ++------++ 150 | 151 | 152 | 153 LSN external IP address Y1 | 154 LSN external port y1 | 155 ++------++ LSN external realm 156 ........... | LSN |............... 157 ++------++ LSN internal realm 158 | 159 CPE IP address X1 | 160 CPE port x1 | 161 ++------++ 162 | CPE | 163 ++------++ 164 Figure 1. LSN network 166 3. Requirements for UDP 168 Based on RFC4787, we'd like to compile the list of the requirements 169 as follows. 171 Please note that REQ-8 is slightly different for original RFC. And 172 some of requirements have additional justification. 174 REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior. 176 Status: Same as REQ-1 in RFC4787 178 Justification: This is needed to use UNilateral Self-Address 179 Fixing (UNSAF) which plays important role in STUN / TURN. More 180 detailed description can be found in the original RFC. But to be 181 more precise, in the LSN case, it may not be needed for some 182 specific protocol such as DNS query and response. 184 REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" 185 behavior of "Paired". Note that this requirement is not applicable 186 to NATs that do not support IP address pooling. 188 Status: Same as REQ-2 in RFC4787 190 Justification: This allows applications that use multiple ports 191 originating from the same internal IP address to also have the 192 same external IP address. More detailed description can be found 193 in original RFC. 195 REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port 196 overloading". 198 Status: Same as REQ-3 in RFC4787 200 Justification: This requirement must be met in order to enable two 201 applications on the internal side of the NAT both to use the same 202 port to try to communicate with the same destination. More 203 detailed description can be found in original RFC. 205 REQ-3-a: If the host's source port was in the range 0-1023, it is 206 RECOMMENDED the NAT's source port be in the same range. If the 207 host's source port was in the range 1024-65535, it is RECOMMENDED 208 that the NAT's source port be in that range. 210 Status: Same as REQ-3-a in RFC4787 212 Justification: Certain applications expect the source UDP port to 213 be in the well-known range. More detailed description can be 214 found in original RFC. On the other hand, almost application 215 probably not use range 0-1023 for source port. Using ports as 216 many as possible, it may not be needed this requirement. 218 REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" 219 behavior of "Yes". 221 Status: Same as REQ-4 in RFC4787 223 Justification: This is avoid breaking peer-to-peer applications 224 that do not explicitly and separately specify RTP and RTCP port 225 numbers and that follow the RFC 3550 rule to decrement an odd RTP 226 port to make it even. More detailed description can be found in 227 original RFC. 229 REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two 230 minutes, unless REQ-5-a applies. 232 REQ-5-a: For specific destination ports in the well-known port range 233 (ports 0-1023), a NAT MAY have shorter UDP mapping timers that are 234 specific to the IANA-registered application running over that 235 specific destination port. 237 REQ-5-b: The value of the NAT UDP mapping timer SHOULD be 238 configurable. 240 REQ-5-c: A default value of five minutes or more for the NAT UDP 241 mapping timer is RECOMMENDED. 243 Status: Same as REQ-5, REQ-5-a, REQ-5-b, REQ-5-c in RFC4787 245 REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound 246 refresh behavior" of "True". 248 Status: Same as REQ-6 in RFC4787 250 Justification: Outbound refresh is necessary for allowing the 251 client to keep the mapping alive. More detailed description can 252 be found in original RFC. 254 REQ-6-a: The NAT mapping Refresh Direction MAY have a "NAT Inbound 255 refresh behavior" of "True". 257 Status: Same as REQ-6-a in RFC4787 259 Justification: Allowing inbound refresh may allow an external 260 attacker or misbehaving application to keep a mapping alive 261 indefinitely. Also, it the process is repeated with different 262 ports, over time, it could use up all the ports on the NAT. But 263 this requirement is maybe needed for some applications occurring 264 only incoming inbound traffic. In LSN, Making much of 265 transparency, this requirement is more necessary. 267 REQ-7: A NAT device whose external IP interface can be configured 268 dynamically MUST either 270 (1) Automatically ensure that its internal network uses IP 271 addresses that do not conflict with its external network, or 273 (2) Be able to translate and forward traffic between all internal 274 nodes and all external nodes whose IP addresses numerically 275 conflict with the internal network. 277 Status: Same as REQ-7 in RFC4787 279 REQ-8: It is RECOMMENDED that a NAT have "Endpoint-Independent 280 Filtering" behavior. 282 Status: "If application transparency is most important, it is 283 RECOMMENDED that a NAT have Endpoint-Independent Filtering 284 behavior. If a more stringent filtering behavior is most 285 important, it is RECOMMENDED that a NAT have Address-Dependent 286 Filtering behavior." is written at REQ-8 in RFC4787. In this 287 draft, we pick up only first requirement. 289 Justification: LSN which is placed at ISP/Carrier makes much of 290 transparency. In particular, for applications that receive media 291 simultaneously from multiple locations (e.g., gaming), or 292 applications that use rendezvous techniques. But to be more 293 precise, in the LSN case, it may not be needed for some specific 294 protocol such as DNS query and response. 296 REQ-8-a: The filtering behavior MAY be an option configurable by the 297 administrator of the NAT. 299 Status: Same as REQ-8-a in RFC4787 301 Justification: Having the filtering behavior being an option 302 configurable by the administrator of the NAT ensures that a NAT 303 can be used in the widest variety of deployment scenarios. More 304 detailed description can be found in original RFC. 306 REQ-9: A NAT MUST support "Hairpinning". 308 REQ-9-a: A NAT Hairpinning behavior MUST be "External source IP 309 address and port". 311 Status: Same as REQ-9 in RFC4787 313 Justification: These requirements are to allow communications 314 between two endpoints behind the same NAT when they are trying 315 each other's external IP address. More detailed description can 316 be found in original RFC. 318 REQ-10: To eliminate interference with UNSAF NAT traversal mechanisms 319 and allow integrity protection of UDP communications, NAT ALGs for 320 UDP-based protocols SHOULD be turned off. Future standards track 321 specifications that define an ALG can update this to recommend the 322 ALGs on which they define default. 324 REQ-10-a: If a NAT includes ALGs, it is RECOMMENDED that the NAT 325 allow the NAT administrator to enable or disable each ALG separately. 327 Status: Same as REQ-10, REQ-10-a in RFC4787 329 Justification: NAT ALGs may interfere with UNSAF methods. More 330 detailed description can be found in original RFC. 332 REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT 333 change the NAT translation or the Filtering Behavior at any point in 334 time, or under any particular conditions. 336 Status: Same as REQ-11 in RFC4787 338 Justification: Non-deterministic NATs are very difficult to 339 troubleshoot. More detailed description can be found in original 340 RFC. 342 REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the 343 NAT mapping. 345 REQ-12-a: The NAT's default configuration SHOULD NOT filter ICMP 346 messages based on their source IP address. 348 REQ-12-b: It is RECOMMENDED that a NAT support ICMP Destination 349 Unreachable messages. 351 Status: Same as REQ-12, REQ-12-a, REQ-12-b in RFC4787 352 Justification: This is easy to do and is used for many things 353 including MTU discovery and rapid detection of error conditions, 354 and has no negative consequences. More detailed description can 355 be found in original RFC. 357 REQ-13: If the packet received on an internal IP address has DF=1, 358 the NAT MUST send back an ICMP message "Fragmentation needed and DF 359 set" to the host, as described in [RFC0792]. 361 REQ-13-a: If the packet has DF=0, the NAT MUST fragment the packet 362 and SHOULD send the fragments in order. 364 Status: Same as REQ-13, REQ-13-a in RFC4787 366 Justification: This is the same function a router performs in a 367 similar situation. More detailed description can be found in 368 original RFC. 370 REQ-14: A NAT MUST support receiving in-order and out-of-order 371 fragments, so it MUST have "Received Fragment Out of Order" behavior. 373 REQ-14-a: A NAT's out-of-order fragment processing mechanism MUST be 374 designed so that fragmentation-based DoS attacks do not compromise 375 the NAT's ability to process in-order and unfragmented IP packets. 377 Status: Same as REQ-14, REQ-14-a in RFC4787 379 Justification: Since some networks deliver small packets ahead of 380 large ones, there can be many out-of order fragments. NATs that 381 are capable of delivering these out-of-order packets are possible, 382 but they need to store the out-of-order fragments which can open 383 up a Denial-of-Service (DoS) opportunity, if done incorrectly. 384 More detailed description can be found in original RFC. 386 4. Requirements for TCP 388 Based on RFC5382, we'd like to compile the list of the requirements 389 as follows. 391 Please note that REQ-17 is slightly different for original RFC. And 392 some of requirements have additional justification. 394 REQ-15: A NAT MUST have an "Endpoint Independent Mapping" behavior 395 for TCP. 397 Status: Same as REQ-1 in RFC5382 398 Justification: This is needed to use UNilateral Self-Address 399 Fixing (UNSAF) which plays important role in STUN / TURN. More 400 detailed description can be found in the original RFC. But to be 401 more precise, in the LSN case, it may not be needed for some 402 specific protocols. 404 REQ-16: A NAT MUST support all valid sequences of TCP packets for 405 connections initiated both internally as well as externally when the 406 connection is permitted by the NAT. 408 REQ-16-a: In addition to handling the TCP 3-way handshake mode of 409 connection initiation, A NAT MUST handle the TCP simultaneous-open 410 mode of connection initiation. 412 Status: Same as REQ-2,REQ-2-a in RFC5382 414 Justification: This is to allow standards compliant TCP stacks to 415 traverse NATs. More detailed description can be found in original 416 RFC. 418 REQ-17: It is RECOMMENDED that a NAT have an "Endpoint independent 419 filtering" behavior for TCP. 421 Status: "If application transparency is most important, it is 422 RECOMMENDED that a NAT have an "Endpoint independent filtering" 423 behavior for TCP. If a more stringent filtering behavior is most 424 important, it is RECOMMENDED that a NAT have an "Address dependent 425 filtering" behavior." is REQ-3 in RFC5382. In this draft, we pick 426 up only first requirement. 428 Justification: LSN which is placed at ISP/Carrier makes much of 429 transparency. But to be more precise, in the LSN case, it may not 430 be needed for some specific protocols. 432 REQ-17-a: The filtering behavior MAY be an option configurable by the 433 administrator of the NAT. 435 REQ-17-b: The filtering behavior for TCP MAY be independent of the 436 filtering behavior for UDP. 438 Status: Same as REQ-3-a, REQ-3-b in RFC5382 440 REQ-18: A NAT MUST NOT respond to an unsolicited inbound SYN packet 441 for at least 6 seconds after the packet is received. If during this 442 interval the NAT receives and translates an outbound SYN for the 443 connection the NAT MUST silently drop the original unsolicited 444 inbound SYN packet. Otherwise the NAT SHOULD send an ICMP Port 445 Unreachable error (Type 3, Code 3) for the original SYN, unless REQ- 446 18-a applies. 448 REQ-18-a: The NAT MUST silently drop the original SYN packet if 449 sending a response violates the security policy of the NAT. 451 Status: Same as REQ-4, REQ-4-a in RFC5382 453 Justification: This intent of this requirement is to allow 454 simultaneous-open to work reliably in the presence of NATs. More 455 detailed description can be found in original RFC. 457 REQ-19: If a NAT cannot determine whether the endpoints of a TCP 458 connection are active, it MAY abandon the session if it has been idle 459 for some time. In such cases, the value of the "established 460 connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. 461 The value of the "transitory connection idle-timeout" MUST NOT be 462 less than 4 minutes. 464 REQ-19-a: The value of the NAT idle-timeouts MAY be configurable. 466 Status: Same as REQ-5, REQ-5-a in RFC5382 468 Justification: The intent of this requirement is to minimize the 469 cases where a NAT abandons session state for a live connection. 470 More detailed description can be found in original RFC. 472 REQ-20: If a NAT includes ALGs that affect TCP, it is RECOMMENDED 473 that all of those ALGs (except for FTP) be disabled by default. 475 Status: Same as REQ-6 in RFC5382 477 Justification: The intent of this requirement is to prevent ALGs 478 from interfering with UNSAF methods. More detailed description 479 can be found in original RFC. 481 REQ-21: A NAT MUST NOT have a "Port assignment" behavior of "Port 482 overloading" for TCP. 484 Status: Same as REQ-7 in RFC5382 486 Justification: This requirement allows two applications on the 487 internal side of the NAT to consistently communicate with the same 488 destination. 490 REQ-22: A NAT MUST support "Hairpinning" for TCP. 492 REQ-22-a: A NAT's Hairpinning behavior MUST be of type "External 493 source IP address and port". 495 Status: Same as REQ-8, REQ-8-a in RFC5382 497 Justification: This requirement allows two applications behind the 498 same NAT that are trying to communicate with each other using 499 their external addresses. More detailed description can be found 500 in original RFC. 502 REQ-23: If a NAT translates TCP, it SHOULD translate ICMP Destination 503 Unreachable (Type 3) messages. 505 Status: Same as REQ-9 in RFC5382 507 Justification: Translating ICMP Destination Unreachable messages 508 avoids communication failures. More detailed description can be 509 found in original RFC. 511 REQ-24: Receipt of any sort of ICMP message MUST NOT terminate the 512 NAT mapping or TCP connection for which the ICMP was generated. 514 Status: Same as REQ-10 in RFC5382 516 Justification: This is necessary for reliably performing TCP 517 simultaneous-open where a remote NAT may temporarily signal an 518 ICMP error. More detailed description can be found in original 519 RFC. 521 5. Requirements for ICMP 523 Based on RFC5508, we'd like to compile the list of the requirements 524 as follows. 526 Some of requirements have additional justification. 528 REQ-25: Unless explicitly overridden by local policy, a NAT device 529 MUST permit ICMP Queries and their associated responses, when the 530 Query is initiated from a private host to the external hosts. 532 REQ-25-a: NAT mapping of ICMP Query Identifiers SHOULD be external 533 host independent. 535 Status: Same as REQ-1 in RFC5508 537 Justification: ICMP Query mapping by NAT devices is necessary for 538 current ICMP-Query-based applications to work. More detailed 539 description can be found in original RFC. 541 REQ-26: An ICMP Query session timer MUST NOT expire in less than 60 542 seconds. 544 REQ-26-a: It is RECOMMENDED that the ICMP Query session timer be made 545 configurable. 547 Status: Same as REQ-2, REQ-2-a in RFC5508 549 Justification: Setting the ICMP NAT session timeout to a very 550 large duration ( say, 240 seconds) could potentially tie up 551 precious NAT resources for the whole duration. On the other hand, 552 setting the timeout very low can result in premature freeing of 553 NAT resources and applications failing to complete gracefully. A 554 60-second timeout is a balance between the two extremes. More 555 detailed description can be found in original RFC. 557 REQ-27: When an ICMP Error packet is received, if the ICMP checksum 558 fails to validate, the NAT SHOULD silently drop the ICMP Error 559 packet. If the ICMP checksum is valid, do the following. 561 a. If the IP checksum of the embedded packet fails to validate, the 562 NAT SHOULD silently drop the Error packet; and 564 b. If the embedded packet includes IP options, the NAT device MUST 565 traverse past the IP options to locate the start of transport 566 header for the embedded packet; and 568 c. The NAT device SHOULD NOT validate the transport checksum of the 569 embedded packet within an ICMP Error message, even when it is 570 possible to do so; and 572 d. If the ICMP Error payload contains ICMP extensions, the NAT 573 device MUST exclude the optional zero-padding and the ICMP 574 extensions when evaluating transport checksum for the embedded 575 packet. 577 Status: Same as REQ-3 in RFC5508 579 Justification: An ICMP Error message checksum covers the entire 580 ICMP message, including the payload. NAT uses the embedded IP and 581 transport headers for forwarding and translating the ICMP Error 582 message. More detailed description can be found in original RFC. 584 REQ-28: If a NAT device receives an ICMP Error packet from external 585 realm, and the NAT device does not have an active mapping for the 586 embedded payload, the NAT SHOULD silently drop the ICMP Error packet. 587 If the NAT has active mapping for the embedded payload, then the NAT 588 MUST do the following prior to forwarding the packet, unless local 589 policy explicitly overridden by local policy: 591 a. Revert the IP and transport headers of the embedded IP packet to 592 their original form, using the matching mapping; and 594 b. Leave the ICMP Error type and code unchanged; and 596 c. Modify the destination IP address of the outer IP header to be 597 same as the source IP address of the embedded packet after 598 translation. 600 Status: Same as REQ-4 in RFC5508 602 REQ-29: If a NAT device receives an ICMP Error packet from the 603 private realm, and the NAT does not have an active mapping for the 604 embedded payload, the NAT SHOULD silently drop the ICMP Error packet. 605 If the NAT has active mapping for the embedded payload, then the NAT 606 MUST do the following prior to forwarding the packet, unless 607 explicitly overridden by local policy. 609 a. Revert the IP and transport headers of the embedded IP packet to 610 their original form, using the matching mapping; and 612 b. Leave the ICMP Error type and code unchanged; and 614 c. If the NAT enforces Basic NAT function, and the NAT has active 615 mapping for the IP address that sent the ICMP Error, translate 616 the source IP address of the ICMP Error packet with the public IP 617 address in the mapping. In all other cases, translate the source 618 IP address of the ICMP Error packet with its own public IP 619 address. 621 Status: Same as REQ-5 in RFC5508 623 REQ-30: While processing an ICMP Error packet pertaining to an ICMP 624 Query or Query response message, a NAT device MUST NOT refresh or 625 delete the NAT Session that pertains to the embedded payload within 626 the ICMP Error packet. 628 Status: Same as REQ-6 in RFC5508 630 Justification: This requirement ensures that the NAT Session will 631 not be modified if someone is able to spoof ICMP Error messages 632 for the session. More detailed description can be found in 633 original RFC. 635 REQ-31: LSN devices MUST support the traversal of hairpinned ICMP 636 Query sessions and Error messages. 638 a. When forwarding a hairpinned ICMP Error message, the NAT device 639 MUST translate the destination IP address of the outer IP header 640 to be same as the source IP address of the embedded IP packet 641 after the translation 643 Status: "NAT devices enforcing Basic NAT MUST support the 644 traversal of hairpinned ICMP Query sessions. All NAT devices 645 (i.e., Basic NAT as well as NAPT devices) MUST support the 646 traversal of hairpinned ICMP Error messages." is REQ-7 in RFC5508. 647 LSN is kind of Basic NATs, and is enforced Basic NAT behavior, so 648 LSN MUST support ICMP Query and Error messages. 650 Justification: This requirement is necessary for current 651 applications to work correctly. More detailed description can be 652 found in original RFC. 654 REQ-32: When a NAT device is unable to establish a NAT Session for a 655 new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource 656 constraints or administrative restrictions, the NAT device SHOULD 657 send an ICMP destination unreachable message, with a code of 13 658 (Communication administratively prohibited) to the sender, and drop 659 the original packet. 661 Status: Same as REQ-8 in RFC5508 663 Justification: LSN, limiting the number of the LSN external ports 664 of UDP/TCP per CPE, often unable to establish new NAT session for 665 a CPE, because the CPE use many sessions. In this case, LSN 666 SHOULD send an ICMP destination unreachable message or some 667 applications maybe not work well. 669 REQ-33: A NAT device MAY implement a policy control that prevents 670 ICMP messages being generated toward certain interface(s). 671 Implementation of such a policy control overrides the MUSTs and 672 SHOULDs in REQ-34. 674 REQ-34: Unless overridden by REQ-33's policy, a NAT device needs to 675 support ICMP messages as below, some conforming to Section 4.3 of 676 [RFC1812] and some superseding the requirements of Section 4.3 of 677 [RFC1812]: 679 a) MUST support: 681 1. Destination Unreachable Message 683 2. Time Exceeded Message 684 3. Echo Request/Reply Messages 686 b) MAY support: 688 1. Redirect Message 690 2. Timestamp and Timestamp Reply Messages 692 3. Source Route Options 694 4. Address Mask Request/Reply Message 696 5. Parameter Problem Message 698 6. Router Advertisement and Solicitations 700 c) SHOULD NOT support 702 1. Source Quench Message 704 2. Information Request/reply 706 In addition, a NAT device is RECOMMENDED to conform to the following 707 implementation considerations: 709 a. d) DS Field Usage 711 b. e) When Not to Send ICMP Errors 713 c. f) Rate Limiting 715 Status: Same as REQ-9, REQ-10 in RFC5508 717 Justification: These are for conformance to RFC 1812. 719 REQ-35: A NAT MAY drop or appropriately handle Non-QueryError ICMP 720 messages. 722 Status: Same as REQ-11 in RFC5508 724 Justification: NAT devices may handle of Non-QueryError ICMP 725 messages. 727 6. LSN specified Requirements 729 REQ-36: A LSN MUST allocate one external IP address to each CPE. 731 a) LSN external IP address allocated to the CPE MUST be same for 732 the UDP, TCP and ICMP. 734 Justification: If a LSN allocates multiple LSN external IP addresses 735 to each CPE, some applications might not work. 737 REQ-37: A LSN MUST allocate LSN external ports which is mapped for 738 CPE ports of UDP. 740 a) A LSN MAY reuse LSN external port after a NAT UDP mapping timer 741 expires. 743 b) A LSN SHOULD limit the number of the LSN external ports of UDP 744 per CPE. 746 c) The number of the LSN external ports of UDP per CPE which LSN 747 can allocate SHOULD be configurable for the administrator of LSN. 749 Justification: CPEs can communicate to CPE external realm fairly by 750 limiting the number of LSN external ports per CPE. 752 REQ-38: A LSN MUST allocate LSN external ports which is mapped for 753 CPE ports of TCP. 755 a) A LSN MAY reuse LSN external port while the port is allocated 756 for no session originated by any CPE. 758 b) A LSN SHOULD limit the number of the LSN external ports of TCP 759 per CPE. 761 c) The number of the LSN external ports of TCP per CPE SHOULD be 762 an administratively configurable option. 764 e) A LSN SHOULD limit the number of the new sessions of TCP per 765 time unit and per CPE. 767 Justification: CPEs can communicate to CPE external realm fairly by 768 limiting the number of LSN external ports per CPE. In addition, TCP 769 LSN external port MAY have TCP sessions, and therefore the TCP 770 session timer is necessary for every 5-Tuple. LSN can have not only 771 the limitations of the number of LSN external ports but also TCP 772 sessions per CPE. Thus a LSN can prevent denial of service attacks 773 with the tons of TCP open and close by malicious CPEs. 775 REQ-39: A LSN MUST allocate LSN external identifiers which is mapped 776 for CPE identifiers of ICMP. 778 a) A LSN MAY reuse LSN external identifier after an ICMP Query 779 session timer expires. 781 b) A LSN SHOULD limit the number of the LSN external identifier 782 allocated per CPE. 784 c) The number of the LSN external identifiers per CPE which LSN 785 can allocate SHOULD be an administratively configurable option. 787 Justification: CPEs can communicate to CPE external realm fairly by 788 limiting the number of LSN external identifiers every CPE. 790 If a CPE has already consumed many LSN external ports, the CPE might 791 not use new ports because LSNs limit the number of ports. 793 REQ-40: A LSN MAY have implementations that some specific 794 applications can work well even if each CPE's usable number of LSN 795 external ports have already consumed. 797 Justification: Some specific applications don't work well due to 798 limitation of number of number of ports by LSN, therefore other 799 applications might be affected in the same CPE. 801 In Section 7 we discuss in detail. 803 7. Identifying particular users (BOTs, spammers, etc) 805 It is necessary for network administrators to identify a user from an 806 IP address and a timestamp in order to deal with abuse and lawful 807 intercept. When multiple users share one external address at LSN, 808 the source address and the source port that are visible at the 809 destination host are translated ones. The following mechanisms can 810 be used to identify the user that transmitted a certain packet. 812 7.1. Store Translation Log 814 One mechanism stores the following information at LSN. 816 - destination address 818 - destination port 820 - translated source address 822 - translated source port 823 - untranslated source address 825 - untranslated source port 827 - timestamp 829 In such environment that one LSN accommodates a lot of users or 830 processes large amount of traffic, the amount of log will be so large 831 and the operator has to prepare large volume of storage. 833 7.2. Fixed port assignment 835 To save costs for storage, one can adopt this port assignment 836 mechanism at LSN. By fixing the range of external port per user/CPE, 837 and having the mapping of internal IP address to external IP address 838 and port, there will be no need to store per session log. Note that 839 this mechanism is possible only if the source port is known as well 840 as the source address, the destination address and the destination 841 port. 843 8. Considerations about limiting the number of LSN external ports 845 As discussed in section 3,4 and 5, LSN limits the number of LSN 846 external ports and identifier per CPE. Therefore some important 847 applications like DNS might not work well due to applications 848 consuming many LSN external ports. 850 There are two ways to solve this issue. The one is that particular 851 applications are out of the targets for the number of port limitation 852 for LSN. In the case, the applications should be configurable for 853 the administrator of LSN. 855 The other is that LSN doesn't translate address or port for some 856 specific applications, moreover it doesn't limit the number of LSN 857 external ports.(we call "LSN pass-through") Therefore, LSN behave as 858 a router. In this case, some specific applications are out of 859 limitation for the number of LSN external ports. Some applications, 860 which don't work well due to address translation like FTP, is 861 effective. Reducing costs of translation is also effective. As a 862 condition, administrators of LSN can control SPS which become a 863 target of LSN pass-through. 865 X1:x1 X1':x1' X2:x2 866 +---+from X1:x1 +---+fromX1:x1 +---+ 867 | |to X2:x2 | | to X2:x2 | | 868 | C |>>>>>>>>>>>>| L |>>>>>>>>>>>>>>| S | 869 | P | | S | | P | 870 | E |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| S | 871 | |from X2:x2 | |fromX2:x2 | | 872 +---+ to X1:x1 +---+ to X1:x1 +---+ 874 Figure 3. LSN pass-through 876 No matter which solutions you choose, you should consider which 877 applications you are out of limitation target for the number of LSN 878 external ports. When you choose too many applications, this might 879 cause LSNs large load. 881 9. IANA Considerations 883 There are no IANA considerations. 885 10. Security Considerations 887 If malicious CPE can camouflage CPE 3-Tuple, the malicious CPE MAY 888 prevent a normal CPE from sending data to external realm. Therefore, 889 an operator SHOULD make policies to prevent a spoofing of CPE 890 3-tuple. 892 11. Acknowledgements 894 Thanks for the input and review by Tomohiro Nishitani, Yasuhiro 895 Shirasaki, Takeshi Tomochika, Kousuke Shishikura, Dai Kuwabara, 896 Tomoya Yoshida, Takanori Mizuguchi, Arifumi Matsumoto, Tomohiro 897 Fujisaki and Dan Wing. 899 12. References 901 12.1. Normative References 903 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 904 RFC 792, September 1981. 906 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 907 Requirement Levels", BCP 14, RFC 2119, March 1997. 909 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 910 Address Translator (Traditional NAT)", RFC 3022, 911 January 2001. 913 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 914 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 915 RFC 4787, January 2007. 917 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 918 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 919 RFC 5382, October 2008. 921 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 922 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 923 April 2009. 925 [I-D.shirasaki-nat444-isp-shared-addr] 926 Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 927 and H. Ashida, "NAT444 addressing models", 928 draft-shirasaki-nat444-isp-shared-addr-03 (work in 929 progress), March 2010. 931 12.2. Informative Reference 933 [I-D.ietf-softwire-dual-stack-lite] 934 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 935 Y., and R. Bush, "Dual-Stack Lite Broadband Deployments 936 Following IPv4 Exhaustion", 937 draft-ietf-softwire-dual-stack-lite-05 (work in progress), 938 July 2010. 940 [I-D.ymbk-aplusp] 941 Bush, R., "The A+P Approach to the IPv4 Address Shortage", 942 draft-ymbk-aplusp-05 (work in progress), October 2009. 944 Authors' Addresses 946 Ikuhei Yamagata 947 NTT Communications Corporation 948 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 949 Tokyo 108-8118 950 Japan 952 Phone: +81 50 3812 4704 953 Email: ikuhei@nttv6.jp 955 Shin Miyakawa 956 NTT Communications Corporation 957 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 958 Tokyo 108-8118 959 Japan 961 Phone: +81 50 3812 4695 962 Email: miyakawa@nttv6.jp 964 Akira Nakagawa 965 Japan Internet Exchange Co., Ltd. (JPIX) 966 Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku 967 Tokyo 100-0004 968 Japan 970 Phone: +81 90 9242 2717 971 Email: a-nakagawa@jpix.ad.jp 973 Hiroyuki Ashida 974 its communications Inc. 975 541-1 Ichigao-cho Aoba-ku 976 Yokohama 225-0024 977 Japan 979 Email: ashida@itscom.ad.jp