Internet Engineering Task Force T. Nishitani
Internet-Draft I. Yamagata
Intended status: BCP S. Miyakawa
Expires: November 28, 2009 NTT Communications
A. Nakagawa
KDDI CORPORATION
H. Ashida
iTSCOM
May 27, 2009
Common Functions of Large Scale NAT (LSN)
draft-nishitani-cgn-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 28, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Nishitani, et al. Expires November 28, 2009 [Page 1]
Internet-Draft Large Scale NAT May 2009
Abstract
This document defines common functions of multiple types of Large
Scale Network Address Translation (NAT) that handles Unicast UDP, TCP
and ICMP.
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 protocol handling . . . . . . . . . . . . . . 7
4.1. Unicast UDP Requirements . . . . . . . . . . . . . . . . . 7
4.2. TCP Requirements . . . . . . . . . . . . . . . . . . . . . 8
4.3. ICMP Requirements . . . . . . . . . . . . . . . . . . . . 9
5. Summary of Requirements . . . . . . . . . . . . . . . . . . . 9
6. Identifying particular users (BOTs, spammers, etc) . . . . . . 11
6.1. Store Translation Log . . . . . . . . . . . . . . . . . . 11
6.2. Fixed port assignment . . . . . . . . . . . . . . . . . . 11
7. Considerations about limiting the number of LSN external
ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative Reference . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Nishitani, et al. Expires November 28, 2009 [Page 2]
Internet-Draft Large Scale NAT May 2009
1. Introduction
Global IPv4 address from the IANA pool will run out in a few years,
thus network operators such as ISPs, carriers, large enterprises,
universities need to shift from IPv4 services to IPv6 ones. However,
IPv6 deployment seems to take a long time.
NAT [RFC3022] is a key technology to utilize IPv4 global address
effectively in current practice. Operators may have to place NAT
devices between end-users and the public Internet to suppress global
IPv4 address consumption.
In this document, we call such a NAT device "Large Scale NAT (LSN)".
Variety of LSN (Large Scale NAT) have been proposed. Some of them
are proposed for business continuity after the exhaustion, and some
of them are proposed to access from IPv6 network to IPv4 Internet.
- NAT444 [I-D.shirasaki-nat444-isp-shared-addr]
- DS-Lite (NAT464) [I-D.ietf-softwire-dual-stack-lite]
- NAT-64 [I-D.bagnulo-behave-nat64]
Each types of Large Scale NAT are shared by plural users and forward
huge traffic. Because a demand is common, many of necessary
functions are common.
This document recommends the common function of Large Scale NAT, so
that developers and operators can easily implement these functions.
Developpers of Large Scale NAT meet this set of requirements, they
can consider specific functions of it. When an operator and a maker
chose either implementation, the implementation has necessary
functions.
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,
Nishitani, et al. Expires November 28, 2009 [Page 3]
Internet-Draft Large Scale NAT May 2009
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
Nishitani, et al. Expires November 28, 2009 [Page 4]
Internet-Draft Large Scale NAT May 2009
++------++
| 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 |
++------++
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.
Nishitani, et al. Expires November 28, 2009 [Page 5]
Internet-Draft Large Scale NAT May 2009
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.
Nishitani, et al. Expires November 28, 2009 [Page 6]
Internet-Draft Large Scale NAT May 2009
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 7 we discuss in detail.
4. Requirements for protocol handling
4.1. Unicast UDP Requirements
[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
Nishitani, et al. Expires November 28, 2009 [Page 7]
Internet-Draft Large Scale NAT May 2009
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
REQ-6: A LSN SHOULD comply with [RFC4787] for unicast UDP.
Justification: LSN SHOULD have to keep high transparency for unicast
UDP communications. And CPE MAY use P2P and interactive services
between CPEs after a LSN is introduced.
4.2. TCP Requirements
[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.
Nishitani, et al. Expires November 28, 2009 [Page 8]
Internet-Draft Large Scale NAT May 2009
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.
Justification: LSN SHOULD have to keep high transparency for TCP
communications. And CPE MAY use P2P and interactive services between
CPEs after a LSN is introduced.
4.3. ICMP Requirements
[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.
5. Summary of Requirements
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.
REQ-2: A LSN MUST allocate LSN external ports mapping to 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.
Nishitani, et al. Expires November 28, 2009 [Page 9]
Internet-Draft Large Scale NAT May 2009
d) The number of the LSN external ports of UDP per CPE which LSN
can allocate SHOULD be configurable for the administrator of LSN.
REQ-3: A LSN MUST allocate LSN external ports mapping to 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.
REQ-4: A LSN MUST allocate LSN external identifiers mapping to CPE
identifiers.
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.
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.
REQ-6: A LSN SHOULD comply with [RFC4787] for unicast UDP.
REQ-7: A LSN SHOULD comply with [RFC5382] for TCP.
REQ-8: A LSN SHOULD comply with [RFC5508] for ICMP.
Nishitani, et al. Expires November 28, 2009 [Page 10]
Internet-Draft Large Scale NAT May 2009
6. 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.
6.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.
6.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.
7. Considerations about limiting the number of LSN external ports
As discussed in section 3, 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.
Nishitani, et al. Expires November 28, 2009 [Page 11]
Internet-Draft Large Scale NAT May 2009
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 +---+
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.
8. IANA Considerations
There are no IANA considerations.
9. 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.
Nishitani, et al. Expires November 28, 2009 [Page 12]
Internet-Draft Large Scale NAT May 2009
10. Acknowledgements
Thanks for the input and review by Yasuhiro Shirasaki, Takeshi
Tomochika, Kousuke Shishikura, Dai Kuwabara, Tomoya Yoshida, Takanori
Mizuguchi, Arifumi Matsumoto, Tomohiro Fujisaki
11. References
11.1. Normative References
[I-D.shirasaki-nat444-isp-shared-addr]
Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444 with ISP Shared Address",
draft-shirasaki-nat444-isp-shared-addr-01 (work in
progress), March 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.
11.2. Informative Reference
[I-D.bagnulo-behave-nat64]
Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-bagnulo-behave-nat64-03 (work in
progress), March 2009.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
"Dual-stack lite broadband deployments post IPv4
exhaustion", draft-ietf-softwire-dual-stack-lite-00 (work
Nishitani, et al. Expires November 28, 2009 [Page 13]
Internet-Draft Large Scale NAT May 2009
in progress), March 2009.
Authors' Addresses
Tomohiro Nishitani
NTT Communications Corporation
Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Phone: +81 50 3812 4742
Email: tomohiro.nishitani@ntt.com
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
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
KDDI CORPORATION
GARDEN AIR TOWER, 3-10-10, Iidabashi, Chiyoda-ku
Tokyo 102-8460
Japan
Email: ai-nakagawa@kddi.com
Nishitani, et al. Expires November 28, 2009 [Page 14]
Internet-Draft Large Scale NAT May 2009
Hiroyuki Ashida
its communications Inc.
3-5-7 Hisamoto Takatsu-ku
Kawasaki 213-0011
Japan
Email: ashida@itscom.ad.jp
Nishitani, et al. Expires November 28, 2009 [Page 15]