One document matched: draft-nishitani-cgn-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022.xml">
<!ENTITY RFC4787 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC5382 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5382.xml">
<!ENTITY RFC5508 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5508.xml">
<!ENTITY I-D.shirasaki-nat444-isp-shared-addr SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shirasaki-nat444-isp-shared-addr.xml">
<!ENTITY I-D.ietf-softwire-dual-stack-lite SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-dual-stack-lite.xml">
<!ENTITY I-D.bagnulo-behave-nat64 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bagnulo-behave-nat64.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="bcp" docName="draft-nishitani-cgn-03" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="Large Scale NAT">
Common Functions of Large Scale NAT (LSN)
</title>
<author fullname="Tomohiro Nishitani" initials="T." surname="Nishitani">
<organization abbrev="NTT Communications">
NTT Communications Corporation</organization>
<address>
<postal>
<street>Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku</street>
<city>Tokyo</city>
<code>108-8118</code>
<country>Japan</country>
</postal>
<phone>+81 50 3812 4742</phone>
<email>tomohiro.nishitani@ntt.com</email>
</address>
</author>
<author fullname="Ikuhei Yamagata" initials="I." surname="Yamagata">
<organization abbrev="NTT Communications">
NTT Communications Corporation</organization>
<address>
<postal>
<street>Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku</street>
<city>Tokyo</city>
<code>108-8118</code>
<country>Japan</country>
</postal>
<phone>+81 50 3812 4704</phone>
<email>ikuhei@nttv6.jp</email>
</address>
</author>
<author fullname="Shin Miyakawa" initials="S." surname="Miyakawa">
<organization abbrev="NTT Communications">
NTT Communications Corporation</organization>
<address>
<postal>
<street>Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku</street>
<city>Tokyo</city>
<code>108-8118</code>
<country>Japan</country>
</postal>
<phone>+81 50 3812 4695</phone>
<email>miyakawa@nttv6.jp</email>
</address>
</author>
<author fullname="Akira Nakagawa" initials="A." surname="Nakagawa">
<organization abbrev="KDDI CORPORATION">
KDDI CORPORATION</organization>
<address>
<postal>
<street>GARDEN AIR TOWER, 3-10-10, Iidabashi, Chiyoda-ku</street>
<city>Tokyo</city>
<code>102-8460</code>
<country>Japan</country>
</postal>
<email>ai-nakagawa@kddi.com</email>
</address>
</author>
<author fullname="Hiroyuki Ashida" initials="H." surname="Ashida">
<organization abbrev="iTSCOM">
its communications Inc.</organization>
<address>
<postal>
<street>541-1 Ichigao-cho Aoba-ku</street>
<city>Yokohama</city>
<code>225-0024</code>
<country>Japan</country>
</postal>
<email>ashida@itscom.ad.jp</email>
</address>
</author>
<date month="November" year="2009" />
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>Large-Scale,NAT</keyword>
<abstract>
<t>This document defines common functions of multiple types of Large Scale
Network Address Translation (NAT) that handles Unicast UDP, TCP and ICMP.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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.
</t>
<t>
NAT <xref target="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.
</t>
<t>
In this document, we call such a NAT device "Large Scale NAT (LSN)".
</t>
<t>
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.
</t>
<t>
<list style='empty'>
<t>
- NAT444 <xref target="I-D.shirasaki-nat444-isp-shared-addr" />
</t>
<t>
- DS-Lite (NAT464) <xref target="I-D.ietf-softwire-dual-stack-lite" />
</t>
<t>
- NAT-64 <xref target="I-D.bagnulo-behave-nat64" />
</t>
</list>
</t>
<t>
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.
</t>
<t>
This document recommends the common function of Large Scale NAT, so
that developers and operators can easily implement these functions.
</t>
<t>
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.
</t>
</section>
<section title="Terminology">
<t>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 <xref target="RFC2119" />.
</t>
<t>
Readers are expected to be familiar with <xref target="RFC4787" /> and the
terms defined there. The following term are used in this document:
<list style='empty'>
<t>
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.
</t>
<t>
LSN external realm:
The realm where IPv4 global addresses are assigned
</t>
<t>
LSN internal realm:
The realm placed between LSN and CPEs
</t>
<t>
LSN external IP address:
The IP address on LSN in LSN external realm mapping to CPE IP address
</t>
<t>
LSN external port:
The port on LSN in LSN external realm mapping to CPE port
</t>
<t>
LSN external identifier:
The identifier of ICMP on LSN in LSN external realm mapping to CPE identifier
</t>
<t>
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)
</t>
<t>
CPE IP address:
The IP address on CPE in LSN internal realm
</t>
<t>
CPE port:
The port on CPE in LSN internal realm
</t>
<t>
CPE identifier:
CPE's identifier of ICMP in LSN internal realm
</t>
<t>
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
</t>
<t>
Service Server (SS):
The server placed in external realm
</t>
<t>
Service Provide Server (SPS):
The server placed in external realm and controlled by LSN administrators
</t>
</list>
</t>
<figure title="Figure 1. LSN network ">
<artwork><![CDATA[
++------++
| 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 |
++------++
]]></artwork>
</figure>
</section>
<section title="The policy of assignment of LSN external IP address, port and identifier">
<t>
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.
</t>
<t>
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.
</t>
<t>REQ-1: A LSN MUST allocate one external IP address to each CPE.
<list style="empty">
<t>a) LSN external IP address allocated to the CPE MUST be same for the UDP, TCP and ICMP.</t>
</list>
</t>
<t>
Justification: If a LSN allocates multiple LSN external IP addresses to each CPE, some applications might not work.
</t>
<t>
REQ-2: A LSN MUST allocate LSN external ports which is mapped for CPE ports of UDP.
<list style='empty'>
<t>
a) A LSN MUST NOT overload LSN external port while a NAT UDP mapping timer does not expire.
</t>
<t>
b) A LSN MAY reuse LSN external port after a NAT UDP mapping timer expires.
</t>
<t>
c) A LSN SHOULD limit the number of the LSN external ports of UDP per CPE.
</t>
<t>
d) The number of the LSN external ports of UDP per CPE which LSN can allocate SHOULD be
configurable for the administrator of LSN.
</t>
</list>
</t>
<t>
Justification: CPEs can communicate to CPE external realm fairly by limiting the number of LSN external ports per CPE.
</t>
<t>
REQ-3: A LSN MUST allocate LSN external ports which is mapped for CPE ports of TCP.
<list style='empty'>
<t>
a) A LSN MUST NOT overload LSN external port while the port is allocated for one or more
TCP sessions originated by another CPE.
</t>
<t>
b) A LSN MAY reuse LSN external port while the port is allocated for no session originated by any CPE.
</t>
<t>
c) A LSN SHOULD limit the number of the LSN external ports of TCP per CPE.
</t>
<t>
d) The number of the LSN external ports of TCP per CPE SHOULD be an administratively configurable option.
</t>
<t>
e) A LSN SHOULD limit the number of the new sessions of TCP per time unit and per CPE.
</t>
</list>
</t>
<t>
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.
</t>
<t>
REQ-4: A LSN MUST allocate LSN external identifiers which is mapped for CPE identifiers of ICMP.
<list style='empty'>
<t>
a) A LSN MUST NOT overload LSN external identifier before an ICMP Query session timer expires.
</t>
<t>
b) A LSN MAY reuse LSN external identifier after an ICMP Query session timer expires.
</t>
<t>
c) A LSN SHOULD limit the number of the LSN external identifier allocated per CPE.
</t>
<t>
d) The number of the LSN external identifiers per CPE which LSN can allocate SHOULD be an administratively configurable option.
</t>
</list>
</t>
<t>
Justification: CPEs can communicate to CPE external realm fairly by limiting the number of LSN external identifiers every CPE.
</t>
<t>
If a CPE has already consumed many LSN external ports, the CPE might not use new ports because LSNs limit the number of ports.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
In Section 7 we discuss in detail.
</t>
</section>
<section title="Requirements for protocol handling">
<section title="Unicast UDP Requirements">
<t> <xref target="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.
</t>
<t>
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.
</t>
<t>
If a LSN supports NAT Hairpinning, a CPE can communicate other CPEs in LSN internal realm of the same LSN.
</t>
<figure title="Figure 2. Hairpinning ">
<artwork><![CDATA[
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'
+------+
]]></artwork>
</figure>
<t>
REQ-6: A LSN SHOULD comply with <xref target="RFC4787" /> for unicast UDP.
</t>
<t>
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.
</t>
</section>
<section title="TCP Requirements">
<t>
<xref target="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
</t>
<t>
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.
</t>
<t>
If a LSN supports NAT Hairpinning, a CPE can communicate other CPEs in LSN internal realm of the same LSN.
</t>
<t>
REQ-7: A LSN SHOULD comply with <xref target="RFC5382" /> for TCP.
</t>
<t>
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.
</t>
</section>
<section title="ICMP Requirements">
<t>
<xref target="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.
</t>
<t>
REQ-8: A LSN SHOULD comply with <xref target="RFC5508" /> for ICMP.
</t>
<t>
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.
</t>
<t>
Therefore, written in <xref target="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.
</t>
</section>
</section>
<section title="Summary of Requirements">
<t>REQ-1: A LSN MUST allocate one external IP address to each CPE.
<list style="empty">
<t>a) LSN external IP address allocated to the CPE MUST be same for the UDP, TCP and ICMP.</t>
</list>
</t>
<t>
REQ-2: A LSN MUST allocate LSN external ports mapping to CPE ports of UDP.
<list style='empty'>
<t>
a) A LSN MUST NOT overload LSN external port while a NAT UDP mapping timer does not expire.
</t>
<t>
b) A LSN MAY reuse LSN external port after a NAT UDP mapping timer expires.
</t>
<t>
c) A LSN SHOULD limit the number of the LSN external ports of UDP per CPE.
</t>
<t>
d) The number of the LSN external ports of UDP per CPE which LSN can allocate SHOULD be
configurable for the administrator of LSN.
</t>
</list>
</t>
<t>
REQ-3: A LSN MUST allocate LSN external ports mapping to CPE ports of TCP.
<list style='empty'>
<t>
a) A LSN MUST NOT overload LSN external port while the port is allocated for one or more
TCP sessions originated by another CPE.
</t>
<t>
b) A LSN MAY reuse LSN external port while the port is allocated for no session originated by any CPE.
</t>
<t>
c) A LSN SHOULD limit the number of the LSN external ports of TCP per CPE.
</t>
<t>
d) The number of the LSN external ports of TCP per CPE SHOULD be an administratively configurable option.
</t>
<t>
e) A LSN SHOULD limit the number of the new sessions of TCP per time unit and per CPE.
</t>
</list>
</t>
<t>
REQ-4: A LSN MUST allocate LSN external identifiers mapping to CPE identifiers.
<list style='empty'>
<t>
a) A LSN MUST NOT overload LSN external identifier before an ICMP Query session timer expires.
</t>
<t>
b) A LSN MAY reuse LSN external identifier after an ICMP Query session timer expires.
</t>
<t>
c) A LSN SHOULD limit the number of the LSN external identifier allocated per CPE.
</t>
<t>
d) The number of the LSN external identifiers per CPE which LSN can allocate SHOULD be an administratively configurable option.
</t>
</list>
</t>
<t>
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.
</t>
<t>
REQ-6: A LSN SHOULD comply with <xref target="RFC4787" /> for unicast UDP.
</t>
<t>
REQ-7: A LSN SHOULD comply with <xref target="RFC5382" /> for TCP.
</t>
<t>
REQ-8: A LSN SHOULD comply with <xref target="RFC5508" /> for ICMP.
</t>
</section>
<section title=" Identifying particular users (BOTs, spammers, etc)">
<t>
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.
</t>
<section title="Store Translation Log">
<t>
One mechanism stores the following information at LSN.
</t>
<t>
<list style="empty">
<t>- destination address</t>
<t>- destination port</t>
<t>- translated source address</t>
<t>- translated source port</t>
<t>- untranslated source address</t>
<t>- untranslated source port</t>
<t>- timestamp</t>
</list>
</t>
<t>
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.
</t>
</section>
<section title="Fixed port assignment">
<t>
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.
</t>
</section>
</section>
<section anchor="port_limitation" title="Considerations about limiting the number of LSN external ports">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<figure title="Figure 3. LSN pass-through">
<artwork><![CDATA[
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 +---+
]]></artwork>
</figure>
<t>
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.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>There are no IANA considerations.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
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.
</t>
</section>
<section title="Acknowledgements">
<t>
Thanks for the input and review by Yasuhiro Shirasaki, Takeshi
Tomochika, Kousuke Shishikura, Dai Kuwabara, Tomoya Yoshida, Takanori
Mizuguchi, Arifumi Matsumoto, Tomohiro Fujisaki
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3022;
&RFC4787;
&RFC5382;
&RFC5508;
&I-D.shirasaki-nat444-isp-shared-addr;
</references>
<references title="Informative Reference">
&I-D.ietf-softwire-dual-stack-lite;
&I-D.bagnulo-behave-nat64;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:38:00 |