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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Terminology
3.  The policy of assignment of LSN external IP address, port and identifier
4.  Requirements for UDP
5.  Requirements for TCP
6.  Requirements for ICMP
7.  Identifying particular users (BOTs, spammers, etc)
    7.1.  Store Translation Log
    7.2.  Fixed port assignment
8.  Considerations about limiting the number of LSN external ports
9.  IANA Considerations
10.  Security Considerations
11.  Acknowledgements
12.  References
    12.1.  Normative References
    12.2.  Informative Reference
§  Authors' Addresses

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] (Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, “NAT444 addressing models,” July 2010.)) , DS-Lite[I‑D.ietf‑softwire‑dual‑stack‑lite] (Durand, A., Droms, R., Woodyatt, J., and Y. Lee, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion,” August 2010.), A+P[I‑D.ymbk‑aplusp] (Bush, R., “The A+P Approach to the IPv4 Address Shortage,” October 2009.) 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Readers are expected to be familiar with [RFC4787] (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.) 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

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   |
                        ++------++

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.

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 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] (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.) 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'
  +------+

REQ-6: A LSN SHOULD comply with [RFC4787] (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.) 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] (Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “NAT Behavioral Requirements for TCP,” October 2008.) 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] (Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “NAT Behavioral Requirements for TCP,” October 2008.) for TCP, unless a) applies.

a) It is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior for TCP.

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] (Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, “NAT Behavioral Requirements for ICMP,” April 2009.) 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] (Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, “NAT Behavioral Requirements for ICMP,” April 2009.) 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] (Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, “NAT Behavioral Requirements for ICMP,” April 2009.), 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

- 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.

  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     +---+

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

12.2. Informative Reference

Authors' Addresses