One document matched: draft-nishitani-cgn-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml">
<!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.ymbk-aplusp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ymbk-aplusp.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">
]>
<?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-05" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="Large Scale NAT">
Common requirements for IP address sharing schemes
</title>
<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="Japan Internet Exchange (JPIX)">
Japan Internet Exchange Co., Ltd. (JPIX)</organization>
<address>
<postal>
<street>Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku</street>
<city>Tokyo</city>
<code>100-0004</code>
<country>Japan</country>
</postal>
<phone>+81 90 9242 2717</phone>
<email>a-nakagawa@jpix.ad.jp</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="July" year="2010" />
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>Large-Scale,NAT</keyword>
<abstract>
<t>This document defines common requirements 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>
Now there are several IPv4 address sharing schemes such as Large Scale NAT (as known as NAT444<xref target="I-D.shirasaki-nat444-isp-shared-addr" />) , DS-Lite<xref target="I-D.ietf-softwire-dual-stack-lite" />, A+P<xref target="I-D.ymbk-aplusp" /> and so on under the discussion.
</t>
<t>
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;
</t>
<t>
<list style='empty'>
<t>
- RFC4787 : NAT Behavioral Requirements for Unicast UDP
</t>
<t>
- RFC5382 : NAT Behavioral Requirements for TCP
</t>
<t>
- RFC5508 : NAT Behavioral Requirements for ICMP
</t>
</list>
</t>
<t>
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.
</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="Requirements for UDP">
<t>
Based on RFC4787, we'd like to compile the list of the requirements as follows.
</t>
<t>
Please note that REQ-8 is slightly different for original RFC.
And some of requirements have additional justification.
</t>
<t>REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior.
<list style="empty">
<t>Status: Same as REQ-1 in RFC4787</t>
<t>Justification: This is needed to use UNilateral Self-Address Fixing (UNSAF) which plays important role in STUN / TURN. More detailed description can be found in the original RFC. But to be more precise, in the LSN case, it may not be needed for some specific protocol such as DNS query and response.</t>
</list>
</t>
<t>REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" behavior of "Paired". Note that this requirement is not applicable to NATs that do not support IP address pooling.
<list style="empty">
<t>Status: Same as REQ-2 in RFC4787</t>
<t>Justification: This allows applications that use multiple ports originating from the same internal IP address to also have the same external IP address. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading".
<list style="empty">
<t>Status: Same as REQ-3 in RFC4787</t>
<t>Justification: This requirement must be met in order to enable two applications on the internal side of the NAT both to use the same port to try to communicate with the same destination. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-3-a: If the host's source port was in the range 0-1023, it is RECOMMENDED the NAT's source port be in the same range. If the host's source port was in the range 1024-65535, it is RECOMMENDED that the NAT's source port be in that range.
<list style="empty">
<t>Status: Same as REQ-3-a in RFC4787</t>
<t>Justification: Certain applications expect the source UDP port to be in the well-known range. More detailed description can be found in original RFC. On the other hand, almost application probably not use range 0-1023 for source port. Using ports as many as possible, it may not be needed this requirement.</t>
</list>
</t>
<t>REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" behavior of "Yes".
<list style="empty">
<t>Status: Same as REQ-4 in RFC4787</t>
<t>Justification: This is avoid breaking peer-to-peer applications that do not explicitly and separately specify RTP and RTCP port numbers and that follow the RFC 3550 rule to decrement an odd RTP port to make it even. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two minutes, unless REQ-5-a applies.</t>
<t>REQ-5-a: For specific destination ports in the well-known port range (ports 0-1023), a NAT MAY have shorter UDP mapping timers that are specific to the IANA-registered application running over that specific destination port.</t>
<t>REQ-5-b: The value of the NAT UDP mapping timer SHOULD be configurable.</t>
<t>REQ-5-c: A default value of five minutes or more for the NAT UDP mapping timer is RECOMMENDED.
<list style="empty">
<t>Status: Same as REQ-5, REQ-5-a, REQ-5-b, REQ-5-c in RFC4787</t>
</list>
</t>
<t>REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound refresh behavior" of "True".
<list style="empty">
<t>Status: Same as REQ-6 in RFC4787</t>
<t>Justification: Outbound refresh is necessary for allowing the client to keep the mapping alive. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-6-a: The NAT mapping Refresh Direction MAY have a "NAT Inbound refresh behavior" of "True".
<list style="empty">
<t>Status: Same as REQ-6-a in RFC4787</t>
<t>Justification: Allowing inbound refresh may allow an external attacker or misbehaving application to keep a mapping alive indefinitely. Also, it the process is repeated with different ports, over time, it could use up all the ports on the NAT. But this requirement is maybe needed for some applications occurring only incoming inbound traffic. In LSN, Making much of transparency, this requirement is more necessary.</t>
</list>
</t>
<t>REQ-7: A NAT device whose external IP interface can be configured dynamically MUST either
<list style="empty">
<t>(1) Automatically ensure that its internal network uses IP addresses that do not conflict with its external network, or
</t>
<t>(2) Be able to translate and forward traffic between all internal nodes and all external nodes whose IP addresses numerically conflict with the internal network.
</t>
</list>
<list style="empty">
<t>Status: Same as REQ-7 in RFC4787</t>
</list>
</t>
<t>REQ-8: It is RECOMMENDED that a NAT have "Endpoint-Independent Filtering" behavior.
<list style="empty">
<t>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. In this draft, we pick up only first requirement.</t>
<t>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.</t>
</list>
</t>
<t>REQ-8-a: The filtering behavior MAY be an option configurable by the administrator of the NAT.
<list style="empty">
<t>Status: Same as REQ-8-a in RFC4787</t>
<t>Justification: Having the filtering behavior being an option configurable by the administrator of the NAT ensures that a NAT can be used in the widest variety of deployment scenarios. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-9: A NAT MUST support "Hairpinning".</t>
<t>REQ-9-a: A NAT Hairpinning behavior MUST be "External source IP address and port".
<list style="empty">
<t>Status: Same as REQ-9 in RFC4787</t>
<t>Justification: These requirements are to allow communications between two endpoints behind the same NAT when they are trying each other's external IP address. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-10: To eliminate interference with UNSAF NAT traversal mechanisms and allow integrity protection of UDP communications, NAT ALGs for UDP-based protocols SHOULD be turned off. Future standards track specifications that define an ALG can update this to recommend the ALGs on which they define default.</t>
<t>REQ-10-a: If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the NAT administrator to enable or disable each ALG separately.
<list style="empty">
<t>Status: Same as REQ-10, REQ-10-a in RFC4787</t>
<t>Justification: NAT ALGs may interfere with UNSAF methods. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT change the NAT translation or the Filtering Behavior at any point in time, or under any particular conditions.
<list style="empty">
<t>Status: Same as REQ-11 in RFC4787</t>
<t>Justification: Non-deterministic NATs are very difficult to troubleshoot. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping.</t>
<t>REQ-12-a: The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address.</t>
<t>REQ-12-b: It is RECOMMENDED that a NAT support ICMP Destination Unreachable messages.
<list style="empty">
<t>Status: Same as REQ-12, REQ-12-a, REQ-12-b in RFC4787</t>
<t>Justification: This is easy to do and is used for many things including MTU discovery and rapid detection of error conditions, and has no negative consequences. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-13: If the packet received on an internal IP address has DF=1, the NAT MUST send back an ICMP message "Fragmentation needed and DF set" to the host, as described in <xref target="RFC0792" />.</t>
<t>REQ-13-a: If the packet has DF=0, the NAT MUST fragment the packet and SHOULD send the fragments in order.
<list style="empty">
<t>Status: Same as REQ-13, REQ-13-a in RFC4787</t>
<t>Justification: This is the same function a router performs in a similar situation. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-14: A NAT MUST support receiving in-order and out-of-order fragments, so it MUST have "Received Fragment Out of Order" behavior.</t>
<t>REQ-14-a: A NAT's out-of-order fragment processing mechanism MUST be designed so that fragmentation-based DoS attacks do not compromise the NAT's ability to process in-order and unfragmented IP packets.
<list style="empty">
<t>Status: Same as REQ-14, REQ-14-a in RFC4787</t>
<t>Justification: Since some networks deliver small packets ahead of large ones, there can be many out-of order fragments. NATs that are capable of delivering these out-of-order packets are possible, but they need to store the out-of-order fragments which can open up a Denial-of-Service (DoS) opportunity, if done incorrectly. More detailed description can be found in original RFC.</t>
</list>
</t>
</section>
<section title="Requirements for TCP">
<t>
Based on RFC5382, we'd like to compile the list of the requirements as follows.
</t>
<t>
Please note that REQ-17 is slightly different for original RFC.
And some of requirements have additional justification.
</t>
<t>REQ-15: A NAT MUST have an "Endpoint Independent Mapping" behavior for TCP.
<list style="empty">
<t>Status: Same as REQ-1 in RFC5382</t>
<t>Justification: This is needed to use UNilateral Self-Address Fixing (UNSAF) which plays important role in STUN / TURN. More detailed description can be found in the original RFC. But to be more precise, in the LSN case, it may not be needed for some specific protocols.</t>
</list>
</t>
<t>REQ-16: A NAT MUST support all valid sequences of TCP packets for connections initiated both internally as well as externally when the connection is permitted by the NAT.</t>
<t>REQ-16-a: In addition to handling the TCP 3-way handshake mode of connection initiation, A NAT MUST handle the TCP simultaneous-open mode of connection initiation.
<list style="empty">
<t>Status: Same as REQ-2,REQ-2-a in RFC5382</t>
<t>Justification: This is to allow standards compliant TCP stacks to traverse NATs. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-17: It is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior for TCP.
<list style="empty">
<t>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. In this draft, we pick up only first requirement.</t>
<t>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.</t>
</list>
</t>
<t>REQ-17-a: The filtering behavior MAY be an option configurable by the administrator of the NAT.</t>
<t>REQ-17-b: The filtering behavior for TCP MAY be independent of the filtering behavior for UDP.
<list style="empty">
<t>Status: Same as REQ-3-a, REQ-3-b in RFC5382</t>
</list>
</t>
<t>REQ-18: A NAT MUST NOT respond to an unsolicited inbound SYN packet for at least 6 seconds after the packet is received. If during this interval the NAT receives and translates an outbound SYN for the connection the NAT MUST silently drop the original unsolicited inbound SYN packet. Otherwise the NAT SHOULD send an ICMP Port Unreachable error (Type 3, Code 3) for the original SYN, unless REQ-18-a applies.</t>
<t>REQ-18-a: The NAT MUST silently drop the original SYN packet if sending a response violates the security policy of the NAT.
<list style="empty">
<t>Status: Same as REQ-4, REQ-4-a in RFC5382</t>
<t>Justification: This intent of this requirement is to allow simultaneous-open to work reliably in the presence of NATs. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-19: If a NAT cannot determine whether the endpoints of a TCP connection are active, it MAY abandon the session if it has been idle for some time. In such cases, the value of the "established connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. The value of the "transitory connection idle-timeout" MUST NOT be less than 4 minutes.</t>
<t>REQ-19-a: The value of the NAT idle-timeouts MAY be configurable.
<list style="empty">
<t>Status: Same as REQ-5, REQ-5-a in RFC5382</t>
<t>Justification: The intent of this requirement is to minimize the cases where a NAT abandons session state for a live connection. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-20: If a NAT includes ALGs that affect TCP, it is RECOMMENDED that all of those ALGs (except for FTP) be disabled by default.
<list style="empty">
<t>Status: Same as REQ-6 in RFC5382</t>
<t>Justification: The intent of this requirement is to prevent ALGs from interfering with UNSAF methods. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-21: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading" for TCP.
<list style="empty">
<t>Status: Same as REQ-7 in RFC5382</t>
<t>Justification: This requirement allows two applications on the internal side of the NAT to consistently communicate with the same destination.</t>
</list>
</t>
<t>REQ-22: A NAT MUST support "Hairpinning" for TCP.</t>
<t>REQ-22-a: A NAT's Hairpinning behavior MUST be of type "External source IP address and port".
<list style="empty">
<t>Status: Same as REQ-8, REQ-8-a in RFC5382</t>
<t>Justification: This requirement allows two applications behind the same NAT that are trying to communicate with each other using their external addresses. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-23: If a NAT translates TCP, it SHOULD translate ICMP Destination Unreachable (Type 3) messages.
<list style="empty">
<t>Status: Same as REQ-9 in RFC5382</t>
<t>Justification: Translating ICMP Destination Unreachable messages avoids communication failures. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-24: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping or TCP connection for which the ICMP was generated.
<list style="empty">
<t>Status: Same as REQ-10 in RFC5382</t>
<t>Justification: This is necessary for reliably performing TCP simultaneous-open where a remote NAT may temporarily signal an ICMP error. More detailed description can be found in original RFC.</t>
</list>
</t>
</section>
<section title="Requirements for ICMP">
<t>
Based on RFC5508, we'd like to compile the list of the requirements as follows.
</t>
<t>
Some of requirements have additional justification.
</t>
<t>REQ-25: Unless explicitly overridden by local policy, a NAT device MUST permit ICMP Queries and their associated responses, when the Query is initiated from a private host to the external hosts.</t>
<t>REQ-25-a: NAT mapping of ICMP Query Identifiers SHOULD be external host independent.
<list style="empty">
<t>Status: Same as REQ-1 in RFC5508</t>
<t>Justification: ICMP Query mapping by NAT devices is necessary for current ICMP-Query-based applications to work. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-26: An ICMP Query session timer MUST NOT expire in less than 60 seconds.</t>
<t>REQ-26-a: It is RECOMMENDED that the ICMP Query session timer be made configurable.
<list style="empty">
<t>Status: Same as REQ-2, REQ-2-a in RFC5508</t>
<t>Justification: Setting the ICMP NAT session timeout to a very large duration ( say, 240 seconds) could potentially tie up precious NAT resources for the whole duration. On the other hand, setting the timeout very low can result in premature freeing of NAT resources and applications failing to complete gracefully. A 60-second timeout is a balance between the two extremes. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-27: When an ICMP Error packet is received, if the ICMP checksum fails to validate, the NAT SHOULD silently drop the ICMP Error packet. If the ICMP checksum is valid, do the following.
<list style="letters">
<t>If the IP checksum of the embedded packet fails to validate, the NAT SHOULD silently drop the Error packet; and</t>
<t>If the embedded packet includes IP options, the NAT device MUST traverse past the IP options to locate the start of transport header for the embedded packet; and</t>
<t>The NAT device SHOULD NOT validate the transport checksum of the embedded packet within an ICMP Error message, even when it is possible to do so; and</t>
<t>If the ICMP Error payload contains ICMP extensions, the NAT device MUST exclude the optional zero-padding and the ICMP extensions when evaluating transport checksum for the embedded packet.</t>
</list>
<list style="empty">
<t>Status: Same as REQ-3 in RFC5508</t>
<t>Justification: An ICMP Error message checksum covers the entire ICMP message, including the payload. NAT uses the embedded IP and transport headers for forwarding and translating the ICMP Error message.
More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-28: If a NAT device receives an ICMP Error packet from external realm, and the NAT device does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP Error packet. If the NAT has active mapping for the embedded payload, then the NAT MUST do the following prior to forwarding the packet, unless local policy explicitly overridden by local policy:
<list style="letters">
<t>Revert the IP and transport headers of the embedded IP packet to their original form, using the matching mapping; and</t>
<t>Leave the ICMP Error type and code unchanged; and</t>
<t>Modify the destination IP address of the outer IP header to be same as the source IP address of the embedded packet after translation.</t>
</list>
<list style="empty">
<t>Status: Same as REQ-4 in RFC5508</t>
</list>
</t>
<t>REQ-29: If a NAT device receives an ICMP Error packet from the private realm, and the NAT does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP Error packet. If the NAT has active mapping for the embedded payload, then the NAT MUST do the following prior to forwarding the packet, unless explicitly overridden by local policy.
<list style="letters">
<t>Revert the IP and transport headers of the embedded IP packet to their original form, using the matching mapping; and</t>
<t>Leave the ICMP Error type and code unchanged; and</t>
<t>If the NAT enforces Basic NAT function, and the NAT has active mapping for the IP address that sent the ICMP Error, translate the source IP address of the ICMP Error packet with the public IP address in the mapping. In all other cases, translate the source IP address of the ICMP Error packet with its own public IP address.</t>
</list>
<list style="empty">
<t>Status: Same as REQ-5 in RFC5508</t>
</list>
</t>
<t>REQ-30: While processing an ICMP Error packet pertaining to an ICMP Query or Query response message, a NAT device MUST NOT refresh or delete the NAT Session that pertains to the embedded payload within the ICMP Error packet.
<list style="empty">
<t>Status: Same as REQ-6 in RFC5508</t>
<t>Justification: This requirement ensures that the NAT Session will not be modified if someone is able to spoof ICMP Error messages for the session. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-31: LSN devices MUST support the traversal of hairpinned ICMP Query sessions and Error messages.
<list style="letters">
<t>When forwarding a hairpinned ICMP Error message, the NAT device MUST translate the destination IP address of the outer IP header to be same as the source IP address of the embedded IP packet after the translation</t>
</list>
<list style="empty">
<t>Status: "NAT devices enforcing Basic NAT MUST support the traversal of hairpinned ICMP Query sessions. All NAT devices (i.e., Basic NAT as well as NAPT devices) MUST support the traversal of hairpinned ICMP Error messages." is REQ-7 in RFC5508. LSN is kind of Basic NATs, and is enforced Basic NAT behavior, so LSN MUST support ICMP Query and Error messages.</t>
<t>Justification: This requirement is necessary for current applications to work correctly. More detailed description can be found in original RFC.</t>
</list>
</t>
<t>REQ-32: When a NAT device is unable to establish a NAT Session for a new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource constraints or administrative restrictions, the NAT device SHOULD send an ICMP destination unreachable message, with a code of 13 (Communication administratively prohibited) to the sender, and drop the original packet.
<list style="empty">
<t>Status: Same as REQ-8 in RFC5508</t>
<t>Justification: LSN, limiting the number of the LSN external ports of UDP/TCP per CPE, often unable to establish new NAT session for a CPE, because the CPE use many sessions. In this case, LSN SHOULD send an ICMP destination unreachable message or some applications maybe not work well.</t>
</list>
</t>
<t>REQ-33: A NAT device MAY implement a policy control that prevents ICMP messages being generated toward certain interface(s). Implementation of such a policy control overrides the MUSTs and SHOULDs in REQ-34.</t>
<t>REQ-34: Unless overridden by REQ-33's policy, a NAT device needs to support ICMP messages as below, some conforming to Section 4.3 of [RFC1812] and some superseding the requirements of Section 4.3 of [RFC1812]:
<list style="empty">
<t>a) MUST support:
<list style="numbers">
<t>Destination Unreachable Message</t>
<t>Time Exceeded Message</t>
<t>Echo Request/Reply Messages</t>
</list>
</t>
<t>b) MAY support:
<list style="numbers">
<t>Redirect Message</t>
<t>Timestamp and Timestamp Reply Messages</t>
<t>Source Route Options</t>
<t>Address Mask Request/Reply Message</t>
<t>Parameter Problem Message</t>
<t>Router Advertisement and Solicitations</t>
</list>
</t>
<t>c) SHOULD NOT support
<list style="numbers">
<t>Source Quench Message</t>
<t>Information Request/reply</t>
</list>
</t>
</list>
</t>
<t>
In addition, a NAT device is RECOMMENDED to conform to the following implementation considerations:
<list style="letters">
<t>d) DS Field Usage</t>
<t>e) When Not to Send ICMP Errors</t>
<t>f) Rate Limiting</t>
</list>
<list style="empty">
<t>Status: Same as REQ-9, REQ-10 in RFC5508</t>
<t>Justification: These are for conformance to RFC 1812.</t>
</list>
</t>
<t>REQ-35: A NAT MAY drop or appropriately handle Non-QueryError ICMP messages.
<list style="empty">
<t>Status: Same as REQ-11 in RFC5508</t>
<t>Justification: NAT devices may handle of Non-QueryError ICMP messages.</t>
</list>
</t>
</section>
<section title="LSN specified Requirements">
<t>REQ-36: 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-37: A LSN MUST allocate LSN external ports which is mapped for CPE ports of UDP.
<list style='empty'>
<t>
a) A LSN MAY reuse LSN external port after a NAT UDP mapping timer expires.
</t>
<t>
b) A LSN SHOULD limit the number of the LSN external ports of UDP per CPE.
</t>
<t>
c) 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-38: A LSN MUST allocate LSN external ports which is mapped for CPE ports of TCP.
<list style='empty'>
<t>
a) A LSN MAY reuse LSN external port while the port is allocated for no session originated by any CPE.
</t>
<t>
b) A LSN SHOULD limit the number of the LSN external ports of TCP per CPE.
</t>
<t>
c) 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-39: A LSN MUST allocate LSN external identifiers which is mapped for CPE identifiers of ICMP.
<list style='empty'>
<t>
a) A LSN MAY reuse LSN external identifier after an ICMP Query session timer expires.
</t>
<t>
b) A LSN SHOULD limit the number of the LSN external identifier allocated per CPE.
</t>
<t>
c) 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-40: 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=" 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,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.
</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 Tomohiro Nishitani, Yasuhiro Shirasaki, Takeshi Tomochika, Kousuke Shishikura, Dai Kuwabara, Tomoya Yoshida, Takanori
Mizuguchi, Arifumi Matsumoto, Tomohiro Fujisaki and Dan Wing.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC0792;
&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.ymbk-aplusp;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:07:41 |