Internet Engineering Task Force I. Yamagata Internet-Draft S. Miyakawa Intended status: BCP NTT Communications Expires: April 21, 2011 A. Nakagawa Japan Internet Exchange (JPIX) H. Ashida iTSCOM October 18, 2010 Common requirements for IP address sharing schemes draft-ietf-behave-lsn-requirements-00 Abstract This document defines common requirements of multiple types of Large Scale Network Address Translation (NAT) that handles Unicast UDP, TCP and ICMP. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 21, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Yamagata, et al. Expires April 21, 2011 [Page 1] Internet-Draft Large Scale NAT October 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The policy of assignment of LSN external IP address, port and identifier . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements for UDP . . . . . . . . . . . . . . . . . . . . . 7 5. Requirements for TCP . . . . . . . . . . . . . . . . . . . . . 8 6. Requirements for ICMP . . . . . . . . . . . . . . . . . . . . 9 7. Identifying particular users (BOTs, spammers, etc) . . . . . . 9 7.1. Store Translation Log . . . . . . . . . . . . . . . . . . 9 7.2. Fixed port assignment . . . . . . . . . . . . . . . . . . 10 8. Considerations about limiting the number of LSN external ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 12.2. Informative Reference . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Yamagata, et al. Expires April 21, 2011 [Page 2] Internet-Draft Large Scale NAT October 2010 1. Introduction Now there are several IPv4 address sharing schemes such as Large Scale NAT (as known as NAT444[I-D.shirasaki-nat444-isp-shared-addr]) , DS-Lite[I-D.ietf-softwire-dual-stack-lite], A+P[I-D.ymbk-aplusp] and so on under the discussion. Those IPv4 address sharing schemes are intended to be used in the middle of the ISP access network against IPv4 address shortage problem by sharing one global IPv4 address by multiple users. Authors believe that there are common requirements among all IPv4 address sharing schemes to make them "transparent" as much as possible. At the BEHAVE working group of IETF, following RFCs have already defined to achieve maximum transparency at the residential CPE which has NAT function; - RFC4787 : NAT Behavioral Requirements for Unicast UDP - RFC5382 : NAT Behavioral Requirements for TCP - RFC5508 : NAT Behavioral Requirements for ICMP However so, because those RFCs are mainly aimed at residential CPE and any IPv4 address sharing schemes are a bit different from it, we believe that requirements for LSN and other schemes should be defined alternatively to those RFCs. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Readers are expected to be familiar with [RFC4787] and the terms defined there. The following term are used in this document: Large-Scale NAT(LSN): NAT devices placed between CPE and public Internet by an operator. LSN converts CPE IP Address, CPE Port, and CPE Identifier into LSN external IP Address, LSN external Port and LSN external Identifier in communication between CPE and GGN external. LSN external realm: The realm where IPv4 global addresses are assigned LSN internal realm: The realm placed between LSN and CPEs Yamagata, et al. Expires April 21, 2011 [Page 3] Internet-Draft Large Scale NAT October 2010 LSN external IP address: The IP address on LSN in LSN external realm mapping to CPE IP address LSN external port: The port on LSN in LSN external realm mapping to CPE port LSN external identifier: The identifier of ICMP on LSN in LSN external realm mapping to CPE identifier Customer Premises Equipment(CPE): The terminal which is placed in LSN internal realm and may establish TCP sessions to LSN external realm (e.g. a single PC or NATBox) CPE IP address: The IP address on CPE in LSN internal realm CPE port: The port on CPE in LSN internal realm CPE identifier: CPE's identifier of ICMP in LSN internal realm CPE 3-tuple: The tuple of TCP/UDP, CPE IP address, and CPE Port Service Server (SS) The server an operator supplies various services for CPE Service Server (SS): The server placed in external realm Service Provide Server (SPS): The server placed in external realm and controlled by LSN administrators ++------++ | SS | ++------++ | | | LSN external IP address Y1 | LSN external port y1 | ++------++ LSN external realm ........... | LSN |............... ++------++ LSN internal realm | CPE IP address X1 | CPE port x1 | ++------++ | CPE | ++------++ Yamagata, et al. Expires April 21, 2011 [Page 4] Internet-Draft Large Scale NAT October 2010 Figure 1. LSN network 3. The policy of assignment of LSN external IP address, port and identifier A LSN has a pool of LSN external IP addresses, ports and identifiers. CPEs share LSN external IP addresses. Each LSN occupies combination of LSN external IP address, LSN external port and LSN external identifier exclusively. For a fair use of limited resources, LSN has a limitation for the number of the LSN external ports per CPE. LSNs need to keep high transparency to continue existing services after LSN is introduced. Requirement of high transparency for LSN leads to high scalability of LSN. High transparency means LSN basically keeps communications among CPEs except effect of limitations of the number of LSN external ports and TCP sessions. A CPE MAY apply UDP hole punching or TCP hole punching for interactive services among CPEs like Voice over IP and P2P. LSN SHOLUD NOT interfere in services using UDP hole punching or TCP hole punching. REQ-1: A LSN MUST allocate one external IP address to each CPE. a) LSN external IP address allocated to the CPE MUST be same for the UDP, TCP and ICMP. Justification: If a LSN allocates multiple LSN external IP addresses to each CPE, some applications might not work. REQ-2: A LSN MUST allocate LSN external ports which is mapped for CPE ports of UDP. a) A LSN MUST NOT overload LSN external port while a NAT UDP mapping timer does not expire. b) A LSN MAY reuse LSN external port after a NAT UDP mapping timer expires. c) A LSN SHOULD limit the number of the LSN external ports of UDP per CPE. d) The number of the LSN external ports of UDP per CPE which LSN can allocate SHOULD be configurable for the administrator of LSN. Justification: CPEs can communicate to CPE external realm fairly by limiting the number of LSN external ports per CPE. Yamagata, et al. Expires April 21, 2011 [Page 5] Internet-Draft Large Scale NAT October 2010 REQ-3: A LSN MUST allocate LSN external ports which is mapped for CPE ports of TCP. a) A LSN MUST NOT overload LSN external port while the port is allocated for one or more TCP sessions originated by another CPE. b) A LSN MAY reuse LSN external port while the port is allocated for no session originated by any CPE. c) A LSN SHOULD limit the number of the LSN external ports of TCP per CPE. d) The number of the LSN external ports of TCP per CPE SHOULD be an administratively configurable option. e) A LSN SHOULD limit the number of the new sessions of TCP per time unit and per CPE. Justification: CPEs can communicate to CPE external realm fairly by limiting the number of LSN external ports per CPE. In addition, TCP LSN external port MAY have TCP sessions, and therefore the TCP session timer is necessary for every 5-Tuple. LSN can have not only the limitations of the number of LSN external ports but also TCP sessions per CPE. Thus a LSN can prevent denial of service attacks with the tons of TCP open and close by malicious CPEs. REQ-4: A LSN MUST allocate LSN external identifiers which is mapped for CPE identifiers of ICMP. a) A LSN MUST NOT overload LSN external identifier before an ICMP Query session timer expires. b) A LSN MAY reuse LSN external identifier after an ICMP Query session timer expires. c) A LSN SHOULD limit the number of the LSN external identifier allocated per CPE. d) The number of the LSN external identifiers per CPE which LSN can allocate SHOULD be an administratively configurable option. Justification: CPEs can communicate to CPE external realm fairly by limiting the number of LSN external identifiers every CPE. If a CPE has already consumed many LSN external ports, the CPE might not use new ports because LSNs limit the number of ports. REQ-5: A LSN MAY have implementations that some specific applications Yamagata, et al. Expires April 21, 2011 [Page 6] Internet-Draft Large Scale NAT October 2010 can work well even if each CPE's usable number of LSN external ports have already consumed. Justification: Some specific applications don't work well due to limitation of number of number of ports by LSN, therefore other applications might be affected in the same CPE. In Section 8 we discuss in detail. 4. Requirements for UDP [RFC4787] describes requirements of the Unicast UDP of a NAT, and the behavior of "Endpoint-Independent Filtering "is RECOMMNEDED, and a NAT MUST have an "Endpoint-Independent Mapping" behavior to ensure transparency of LSN. To have "Endpoint-Independent Filtering" and "Endpoint-Independent Mapping" behaviors for LSNs, LSNs help to establish UDP Hole Punching among CPEs. In other words, the possibility of the establishment of UDP Hole Punching among CPEs which have LSN is equal to the possibility among CPEs which don's t have LSN. If LSNs have an "Address-Dependent Mapping" or "Address and Port-Dependent Mapping" behavior, the possibility that establishment of UDP Hole Punching is less than when LSNs have an "Endpoint-Independent Mapping" behavior. If LSNs have an "Address and Port-Dependent Filtering" behavior, the possibility that establishment of UDP Hole Punching is less than when LSNs have an "Endpoint-Independent Filtering" or "Address Dependent Filtering" behavior. If a LSN supports NAT Hairpinning, a CPE can communicate other CPEs in LSN internal realm of the same LSN. X1:x1 +------+ from X1:x1 to X2':x2' | CPE1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>++----++X1':x1' +------+ | | | L | | S | X2:x2 | N | +------+ from X1':x1' to X2:x2 | | | CPE2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<++----++X2':x2' +------+ Figure 2. Hairpinning Yamagata, et al. Expires April 21, 2011 [Page 7] Internet-Draft Large Scale NAT October 2010 REQ-6: A LSN SHOULD comply with [RFC4787] for unicast UDP, unless a) applies. a)It is RECOMMENDED that a NAT have "Endpoint-Independent Filtering" behavior. Status: "If application transparency is most important, it is RECOMMENDED that a NAT have Endpoint-Independent Filtering behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have Address-Dependent Filtering behavior." is written at REQ-8 in RFC4787. Justification: LSN which is placed at ISP/Carrier makes much of transparency. In particular, for applications that receive media simultaneously from multiple locations (e.g., gaming), or applications that use rendezvous techniques. But to be more precise, in the LSN case, it may not be needed for some specific protocol such as DNS query and response. 5. Requirements for TCP [RFC5382] describes requirements of TCP of a NAT, and the behavior of "Endpoint-Independent Filtering" is RECOMMNEDED, and a NAT MUST have an "Endpoint-Independent Mapping" behavior to ensure transparency of LSN To have "Endpoint-Independent Filtering" and "Endpoint-Independent Mapping" behaviors for LSNs, LSNs help to establish TCP Hole Punching among CPEs. In other words, the possibility of the establishment of TCP Hole Punching among CPEs which have LSN is equal to the possibility among CPEs which don's t have LSN. If LSNs have an "Address-Dependent Mapping" or "Address and Port-Dependent Mapping" behavior, the possibility that establishment of TCP Hole Punching is less than when LSNs have an "Endpoint-Independent Mapping" behavior. If LSNs have an "Address and Port-Dependent Filtering" behavior, the possibility that establishment of TCP Hole Punching is less than when LSNs have an "Endpoint-Independent Filtering" or "Address Dependent Filtering" behavior. If a LSN supports NAT Hairpinning, a CPE can communicate other CPEs in LSN internal realm of the same LSN. REQ-7: A LSN SHOULD comply with [RFC5382] for TCP, unless a) applies. a) It is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior for TCP. Yamagata, et al. Expires April 21, 2011 [Page 8] Internet-Draft Large Scale NAT October 2010 Status: "If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior for TCP. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address dependent filtering" behavior." is REQ-3 in RFC5382. Justification: LSN which is placed at ISP/Carrier makes much of transparency. But to be more precise, in the LSN case, it may not be needed for some specific protocols. 6. Requirements for ICMP [RFC5508] describes requirements of ICMP of a NAT. And there MAY be a case that CPE cannot establish communication from CPEs to LSN external realm because LSN limits the number of LSN external ports, identifiers and TCP sessions per CPE. It is useful if CPE can distinguish an error to occur by the limitation of the LSN external ports, identifiers and TCP sessions from other errors. REQ-8: A LSN SHOULD comply with [RFC5508] for ICMP. Justification: LSN SHOULD have to keep high transparency for ICMP. And CPE MAY use P2P and interactive services between CPEs after a LSN is introduced. Therefore, written in [RFC5508], when a LSN can't establish new session of TCP/UDP by limiting of TCP/UDP ports per user, the LSN sends an ICMP destination unreachable message, with code of 13 (Communication administratively prohibited) to the sender. 7. Identifying particular users (BOTs, spammers, etc) It is necessary for network administrators to identify a user from an IP address and a timestamp in order to deal with abuse and lawful intercept. When multiple users share one external address at LSN, the source address and the source port that are visible at the destination host are translated ones. The following mechanisms can be used to identify the user that transmitted a certain packet. 7.1. Store Translation Log One mechanism stores the following information at LSN. - destination address Yamagata, et al. Expires April 21, 2011 [Page 9] Internet-Draft Large Scale NAT October 2010 - destination port - translated source address - translated source port - untranslated source address - untranslated source port - timestamp In such environment that one LSN accommodates a lot of users or processes large amount of traffic, the amount of log will be so large and the operator has to prepare large volume of storage. 7.2. Fixed port assignment To save costs for storage, one can adopt this port assignment mechanism at LSN. By fixing the range of external port per user/CPE, and having the mapping of internal IP address to external IP address and port, there will be no need to store per session log. Note that this mechanism is possible only if the source port is known as well as the source address, the destination address and the destination port. 8. Considerations about limiting the number of LSN external ports As discussed in section 3,4 and 5, LSN limits the number of LSN external ports and identifier per CPE. Therefore some important applications like DNS might not work well due to applications consuming many LSN external ports. There are two ways to solve this issue. The one is that particular applications are out of the targets for the number of port limitation for LSN. In the case, the applications should be configurable for the administrator of LSN. The other is that LSN doesn't translate address or port for some specific applications, moreover it doesn't limit the number of LSN external ports.(we call "LSN pass-through") Therefore, LSN behave as a router. In this case, some specific applications are out of limitation for the number of LSN external ports. Some applications, which don't work well due to address translation like FTP, is effective. Reducing costs of translation is also effective. As a condition, administrators of LSN can control SPS which become a target of LSN pass-through. Yamagata, et al. Expires April 21, 2011 [Page 10] Internet-Draft Large Scale NAT October 2010 X1:x1 X1':x1' X2:x2 +---+from X1:x1 +---+fromX1:x1 +---+ | |to X2:x2 | | to X2:x2 | | | C |>>>>>>>>>>>>| L |>>>>>>>>>>>>>>| S | | P | | S | | P | | E |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| S | | |from X2:x2 | |fromX2:x2 | | +---+ to X1:x1 +---+ to X1:x1 +---+ Figure 3. LSN pass-through No matter which solutions you choose, you should consider which applications you are out of limitation target for the number of LSN external ports. When you choose too many applications, this might cause LSNs large load. 9. IANA Considerations There are no IANA considerations. 10. Security Considerations If malicious CPE can camouflage CPE 3-Tuple, the malicious CPE MAY prevent a normal CPE from sending data to external realm. Therefore, an operator SHOULD make policies to prevent a spoofing of CPE 3-tuple. 11. Acknowledgements Thanks for the input and review by Tomohiro Nishitani, Yasuhiro Shirasaki, Takeshi Tomochika, Kousuke Shishikura, Dai Kuwabara, Tomoya Yoshida, Takanori Mizuguchi, Arifumi Matsumoto, Tomohiro Fujisaki and Dan Wing. 12. References 12.1. Normative References [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Yamagata, et al. Expires April 21, 2011 [Page 11] Internet-Draft Large Scale NAT October 2010 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009. [I-D.shirasaki-nat444-isp-shared-addr] Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444 addressing models", draft-shirasaki-nat444-isp-shared-addr-04 (work in progress), July 2010. 12.2. Informative Reference [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work in progress), August 2010. [I-D.ymbk-aplusp] Bush, R., "The A+P Approach to the IPv4 Address Shortage", draft-ymbk-aplusp-05 (work in progress), October 2009. Authors' Addresses Ikuhei Yamagata NTT Communications Corporation Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan Phone: +81 50 3812 4704 Email: ikuhei@nttv6.jp Yamagata, et al. Expires April 21, 2011 [Page 12] Internet-Draft Large Scale NAT October 2010 Shin Miyakawa NTT Communications Corporation Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan Phone: +81 50 3812 4695 Email: miyakawa@nttv6.jp Akira Nakagawa Japan Internet Exchange Co., Ltd. (JPIX) Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku Tokyo 100-0004 Japan Phone: +81 90 9242 2717 Email: a-nakagawa@jpix.ad.jp Hiroyuki Ashida its communications Inc. 541-1 Ichigao-cho Aoba-ku Yokohama 225-0024 Japan Email: ashida@itscom.ad.jp Yamagata, et al. Expires April 21, 2011 [Page 13]