Internet DRAFT - draft-sunjianping-behave-nat-port-expand
draft-sunjianping-behave-nat-port-expand
Internet Engineering Task Force J. Sun, Ed.
Internet-Draft China Telecom
Intended status: Informational May 2012
Expires: November 2, 2012
Expand NAT TCP/UDP ports deferring IPv4 Exhaustion
draft-sunjianping-behave-nat-port-expand-02
Abstract
This document describes the TCP/UDP port extension (EPORT) model to
enhance Network Address Translation (NAT)capability. EPORT based NAT
helps service provider and enterprise to save mass public IPv4
addresses with enough application sessions offered at same time.
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 November 2, 2012.
Copyright Notice
Copyright (c) 2012 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.
Sun Expires November 2, 2012 [Page 1]
Internet-Draft Expand NAT TCP/UDP Ports May 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. EPORT IP option defination . . . . . . . . . . . . . . . . 4
3.1.1. Figure 1. EPORT IP option . . . . . . . . . . . . . . 5
3.2. Elements description and behaviors . . . . . . . . . . . . 5
3.2.1. Figure 2. NAT with EPORT option . . . . . . . . . . . 7
3.2.2. Internal host . . . . . . . . . . . . . . . . . . . . 8
3.2.3. NAT device . . . . . . . . . . . . . . . . . . . . . . 8
3.2.4. Internet intermedia router . . . . . . . . . . . . . . 10
3.2.5. External host . . . . . . . . . . . . . . . . . . . . 10
4. Best practice of EPORT . . . . . . . . . . . . . . . . . . . . 11
4.1. Natural arrangement . . . . . . . . . . . . . . . . . . . 11
4.2. Proactive arrangement . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Sun Expires November 2, 2012 [Page 2]
Internet-Draft Expand NAT TCP/UDP Ports May 2012
1. Introduction
NAT is one of mainstream solutions to save public IPv4 addresses and
has been employed widely, it maintains address and port mapping
mechanism to translate between external address port pair and
internal address port pair.The IANA IPv4 addresses pool has now
depleted before internet move from IPv4 to IPv6 sufficiently.As a
result,NAT(NAPT) becomes the important part of IPv6 transitional
technologies such as DS-lite,NAT444 and NAT64. See [I-D.gundavelli-
softwire-gateway-init-ds-lite] , [I-D.shirasaki-nat444] and [RFC6146]
.
Because TCP or UDP port number length is 2 octets length,for one of
external public IPv4 addresses there are 65535 TCP or UDP ports at
most can be used to establish sessions from internal addresses to
external by NAT device. in consideration of IANA defined port ranges:
"Well Known Ports" is 0-1023, "Registered" is 1024-49151, and
"Dynamic and/or Private" is 49152-65535 ,it recommends that NAT
devices prefer to use the dynamic range first , then Dynamic and/or
Private range .In fact ,one publice IPv4 address' available NAT
translation sessions are less than 64511 for TCP or UDP, this number
seems enough in the past but inadequate when IPv4 address pool
starvation. New session fails to establish on NAT device if 2 octets
port range reached. IPv6 transitional technologies such as DS-
lite,NAT444 and NAT64 that relied on NAT will be affected if IPv4
public address pool ran out . For example , each internal host
behind NAT device requires 400 tcp or udp sessions to access
internet,(it's reasonable because of P2P applications,multi tab web
client , RSS etc.) one of external public ipv4 address can support
only 322 internal hosts at most. ICMP is out of the scope of this
specification temporary.
This document specifies TCP/UDP port extension model which focuses on
extending extra 2 octets tcp/udp port number to IP option named EPORT
without changes of existing TCP/UDP header and 20 octets fixed IPv4
header . EPORT allows a public IP on NAT device to be assigned 4
octets sessions for internal hosts.Thus one of external public ipv4
address can support 21102270 internal hosts at most with same session
requirement for each host described upon.
1.1. Requirements Language
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 RFC 2119 [RFC2119].
Sun Expires November 2, 2012 [Page 3]
Internet-Draft Expand NAT TCP/UDP Ports May 2012
2. Terminology
The technology described in this document is known as the TCP/UDP
port extension (EPORT) model to enhance Network Address Translation
(NAT)capability. The abbreviation EPORT will be used along this
text.
This document specifies TCP/UDP port extension model which focuses on
extending extra 2 octets tcp/udp port number to IP option named
EPORT.
UDP is defined in [RFC0768].
TCP is defined in [RFC0793].
IP option related terminology is defined in [RFC0791].
NAT related terminology is defined in [RFC4787].
In this document, the term "NAT" refers to "Network Address/Port
Translator (NAPT)" that multiple internal hosts share a single public
IP address simultaneously. When an internal host opens an outgoing
TCP or UDP session through a NAPT, the NAPT assigns the session a
public IP ddress and port number, so subsequent response packets from
the external host can be received by the NAT device, translated, and
forwarded to the internal host based on the address port mapping
table it maintainces .
Term "session" is defined in [RFC2663].
The process of IP option by protocol stack is defined in [RFC1122]
Term "Shared Public address" and "external public ipv4 address" has
same signification in this ducoment that means NAT translation
involved public ip address .
3. Deployment
3.1. EPORT IP option defination
This document defines a new IP option named EPORT option(Extended
TCP/UDP PORT). When NAT device's availabe public IP address,public
port number pairs are used up(It means that NAT device cannot
translate TCP/UDP sessions any more and its capability is full),EPORT
option is inserted by the NAT device into TCP/UDP packets' IP header
to expand existing TCP/UDP port numbers.
EPORT option includes an option-type octet, an option-length octet,
Sun Expires November 2, 2012 [Page 4]
Internet-Draft Expand NAT TCP/UDP Ports May 2012
and the 2 octets option-data according as Case 2 format defined in
[RFC0791] and exhibit below :
3.1.1. Figure 1. EPORT IP option
0 7 15 31
+--------+--------+--------+--------+
|10100001|00000100| EPORT ID |
+--------+--------+--------+--------+
Type=161 Length=4
Figure 1
option-type 1 octets :
1 bit copied flag: 1,this option MUST be copied into all fragments on
fragmentation.
2 bits option class: 01 drawed out from reserved IP option Classes.
5 bits option number:00001 defined as EPORT id.
LENGTH option 8bit:00000100,the EPORT option's total length is 4
octetes.
option-data 16bit: EPORT ID is 2 octets length. EPORT id is
assembled with traditional TCP/UDP port number (as defined in
[RFC0793],[RFC0768]) to identify a unique TCP/UDP session by NAT
device and external public hosts.Loading EPORT ID breaks the 2 octets
port preserving limitation of traditional TCP/UDP port number and
offers sufficient outbound TCP/UDP sessions translated by NAT device.
EPORT ID MUST conjunct with public IP address, public port number
pairs to identify a unique TCP/UDP session.
3.2. Elements description and behaviors
The involved elements of NAT TCP/UDP ports expanding are internal
hosts,NAT device,internet intermedia router and external host.
Internal hosts are assigned the private IP addresses mainly through
DHCPv4 by enterprise or ISP's DHCP server or BRAS. Internal hosts
can open multiple TCP/UDP sessions simultaneously through the NAT
device to access internet service such as WEB,MAIL etc. The NAT
device has one or more shared public addresses to establishes NAT
sessions to translate the private IP address,private port number pair
to a public IP address, public port number pair , and vice versa for
Sun Expires November 2, 2012 [Page 5]
Internet-Draft Expand NAT TCP/UDP Ports May 2012
the duration of the session as defined in [RFC4787]. If NAT device's
availabe public IP address,public port number pairs (64511 pairs for
1 shared public IP address at most as described upon )are occupied
entirely, subsequent sessions initiated by internal hosts will be
refused or preempting sessions in process. In this documents ,NAT
device tags the EPORT IP option with public port number ,public IP
address to translate and forward traffic correctly. Internet
intermedia router is a universal internet router with public
interface IP addresses which takes charge of packet lookup and
transmission to next hop.External host is any internet host with
public IP address .(A internet web server for simplicity)
This section uses the following diagram for reference:
Sun Expires November 2, 2012 [Page 6]
Internet-Draft Expand NAT TCP/UDP Ports May 2012
3.2.1. Figure 2. NAT with EPORT option
|
Internal | External(IPv4 internet)
|
IP:tcp/udp port | IP:tcp/udp port
src:10.1.0.1:6000 | src:218.80.254.1:65535
dst:202.100.0.1:80 | dst:202.100.0.1:80
-----------------------|-------------------------------------->
Before Shared Public address's port number runs out
<----------------------|---------------------------------------
src:202.100.0.1:80 | src:202.100.0.1:80
dst:10.1.0.1:6000 | dst:218.80.254.1:65535
|
|
|
+-------+ |
|Host A +---+ +----+----+
+-------+ | | |
Private +-----+ | +--------+
address | NAT | | inter | +---------+
10.1.0.1 | Device +-------+ media +------------+ Server C|
+-----+ | | router | +---------+
+-------+ | | | +--------+ Public
|Host B +---+ +----+----+ Public address
+-------+ | Shared address 202.100.0.1
Private | Public
address | address
10.100.0.1 | 218.80.254.1
IP:tcp/udp port | IP:EPORT:tcp/udp port
src:10.100.0.1:500 | src:218.80.254.1:100:65535
dst:202.100.0.1:80 | dst:202.100.0.1:80
------------------------|------------------------------------->
EPORT launched after Shared Public address's port number runs out
<-----------------------|--------------------------------------
IP:tcp/udp port | src:202.100.0.1:80
src:202.100.0.1:80 | dst:218.80.254.1:100:65535
dst:10.100.0.1:500 | IP:EPORT:tcp/udp port
|
Port Assignment with EPORT option supported
Figure 2
Sun Expires November 2, 2012 [Page 7]
Internet-Draft Expand NAT TCP/UDP Ports May 2012
3.2.2. Internal host
Internal host is assigned with private IP address. Internal host
MUST implement EPORT option,(The options may appear or not in
datagrams. They must be implemented by all IP modules . (from
[RFC0791] ) in spite of unnecessary in this document.When internal
host receive a IPv4 packet with EPORT option ,it MAY silently ignore
EPORT option part. Internal hosts MUST NOT insert EPORT option into
any packet it sends. Internal hosts act as private hosts described
in [RFC2663].
In Figure 2,Host A and Host B are internal hosts , in order to
exhibit more points, Host A and Host B visit the same server C's HTTP
service at this scenario(As Figure 2 upon).
3.2.3. NAT device
NAT device recieves the tcp/udp packets from internal hosts then:
Case 1. If NAT device' shared Public address' port numbers have not
run out,it MUST translate Private IP address,private port number
pairs to shared public IP address,public port number pairs at
normally( as [RFC2663] describes).The NAT device SHOULD NOT insert
EPORT option into the IP packet it translated.
Case 2. If NAT device' shared Public address' port numbers have run
out,it MUST insert EPORT option between IPv4 basic header and TCP/UDP
header into packets for subsequent sessions.Therefor NAT device
translates subsequent sessions expanding to 4 octet which EPORT ID
cumulated with 2 octets inherent public port number. No matter NAT
device' shared Public address' port numbers have run out or not,it
MUST maintaince a mapping table with 6 elements below ,then translate
and forward packets to the proper next hop:
Sun Expires November 2, 2012 [Page 8]
Internet-Draft Expand NAT TCP/UDP Ports May 2012
+------------------------------------+
| uplayer protocol |
+------------------------------------+
| src IP:src port before translation|
+------------------------------------+
| dst IP:dst port before translation|
+------------------------------------+
| src IP:src port after translation |
+------------------------------------+
| EPORT ID after translation |
+------------------------------------+
| dst IP:dst port after translation |
+------------------------------------+
mapping table elements
Figure 3
The EPORT ID after translation block is newly added ,it is padded all
zero in Case 1 and actual number in Case 2. The EPORT MAY be
assigned in order from low to high bits or by other algorithms which
is out of the scope of this document.
When returning packets include EPORT option,NAT device MUST lookup
mapping table with 6 elements described upon to decide the unique
session and forward it to the proper internal receiver.If no match
entry found, NAT device SHOULD drop the returning packet .
Before the NAT device forwards returning packet to the proper
internal receiver ,it SHOULD check packet's EPORT option ,if exists,
the NAT device SHOULD wippe off the EPORT option from packet.
It's NAT device's responsibility to insert EPORT for incoming
packets,maintain the NAT mapping table ,wipe off returning packet's
EPORT option and forward packet.
In Figure 2, Host A opened a session to Server C, the NAT device
translates its src IP:src port from src:10.1.0.1:6000 to src:
218.80.254.1:65535,it implies that all of Shared Public address' port
number ran out and no subsequent sessions will be translated by NAT
device without EPORT option.
At this time Host B also opened a session to Server C at the same dst
port,the NAT device translates src IP:src port from src:10.100.0.1:
500 to src:218.80.254.1:100:65535(IP:EPORT:src port) and forwards to
intermedia router.
After NAT device received the returning packet from Server C to Host
B with EPORT option,it lookups the NAT mapping table then wippes off
Sun Expires November 2, 2012 [Page 9]
Internet-Draft Expand NAT TCP/UDP Ports May 2012
the EPORT option , translates packet's dst IP:EPORT:dst port from
dst:218.80.254.1:100:65535 to dst:10.100.0.1:500 then forwards to
Host B.
3.2.4. Internet intermedia router
Internet intermedia router also MUST support EPORT option but SHOULD
NOT change the EPORT option without justified reason.(Hierarchical
NAT for example )
Internet intermedia router MUST forward the IPv4 packets with EPORT
option.
3.2.5. External host
External host MUST implement the EPORT option.
The interface between the IP layer and the transport layer MUST
provide full access to all the mechanisms of the IP layer, including
option. The transport layer MUST either have mechanisms to set these
interface parameters, or provide a path to pass them through from an
application, or both. (From [RFC1122]) This document follows the
criterion upon , EPORT option MUST be passed throuth TCP/UDP between
IP header and applications.
External host MUST indentify the EPORT option ,the packet with
different EPORT ID will be identified from heterogeneous sessions and
treated differently by applications even these packets have same TCP/
UDP port number.
External host MUST be allowed to respond to requests from same src
IP,src port but with different EPORT ID.
External host MUST hold the EPORT option and replicate it to the
returning packets of corresponding session same as it has ever been
received .
EPORT Option is not a end to end parameter ,it is assembled by NAT
device at the begining, passes through the intermedia routers ,
identified ,held and returned by external hosts , stripped off by NAT
device at last.
In Figure 2, Server C treats packets from Host A(src:218.80.254.1:
65535,dst:202.100.0.1:80 pair)and from Host B(src:218.80.254.1:100:
65535 ,dst:202.100.0.1:80 pair) as different sessions and hold EPORT
ID 100 for the session from Host B.
When responds to Host B ,Server C copy the EPORT option back into
Sun Expires November 2, 2012 [Page 10]
Internet-Draft Expand NAT TCP/UDP Ports May 2012
packet header(EPORT ID is 100),because NAT device need EPORT ID to
lookup mapping table and translate packet back to internal host B.
4. Best practice of EPORT
There are two fashions to approach EPORT expansion of NAT,the first
is natural arrangement and another is proactive arrangement.
4.1. Natural arrangement
When natural arrangement fashion is selected,the NAT device invokes
EPORT ID to expand outgoing TCP/UDP sessions on demand. The NAT
device assembles the mapping table with EPORT ID and TCP/UDP ports at
real time . This way provides best utilization of EPORT ID and
introduces more pressures on NAT device' overhead because of dynamic
allocation and maintenance of EPORT ID for every enlarged TCP/UDP
sessions. Under this way one public IPv4 address with EPORT will
fulfil Class A private address space as defined in [RFC1918] if each
internal host behind NAT device requires a reasonable TCP or UDP
sessions.
4.2. Proactive arrangement
Another way is proactive arrangement of EPORT ID. It's a trade off
between NAT device complexity and EPORT ID utilization. An ISP or
enterprise could bind each EPORT ID exclusively to one of(or mass of)
internal host behind NAT. On NAT device The layout of EPORT ID is
set statically in advance . The specific internal host's outgoing
TCP/UDP session will be marked by preassigned EPORT ID. Notice that
under this way the internal hosts is more vulnerable and traceable
from internet because statically arranged EPORT ID is following
translated packets.On the contrary, internal zombie computers or
malicious machines can be easily orientated and separated through
EPORT ID.
5. Acknowledgements
The author would like to acknowledge many helpful discussions with
Gj.Huang.
6. IANA Considerations
This draft request IANA to allocate a reserved IP option from IP
OPTION NUMBERS. The suggested Option Type value is 161 in this
document but can be assigned by IANA from IP Option class 0 or 2 .
Sun Expires November 2, 2012 [Page 11]
Internet-Draft Expand NAT TCP/UDP Ports May 2012
7. Security Considerations
Security issues of NAT have been documented at [RFC2663] and
[RFC2993]. In this document the EPORT option is inserted by NAT
device into IPv4 header and transmited through internet to external
host. If Man-in-the-middle intercepts the packets ,it can forge
EPORT ID. When the NAT device receives the packet with EPORT option
forged,it MUST drop the packet whose EPORT ID don't match the mapping
table it has established.
8. References
8.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
8.2. Informative References
[I-D.gundavelli-softwire-gateway-init-ds-lite]
Brockners, F., Gundavelli, S., Speicher, S., and D. Ward,
"Gateway Initiated Dual-Stack Lite Deployment",
draft-gundavelli-softwire-gateway-init-ds-lite-03 (work in
progress), March 2010.
[I-D.shirasaki-nat444]
Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work
Sun Expires November 2, 2012 [Page 12]
Internet-Draft Expand NAT TCP/UDP Ports May 2012
in progress), January 2011.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
Author's Address
Jianping Sun (editor)
China Telecom
No.1835,Sourth Pudong Road
Shanghai, Pudong
P.R.China
Phone: +86 021 5875 1214
Email: sunjp@sttri.com.cn
Sun Expires November 2, 2012 [Page 13]
