Dear All;
Attached is a draft internet draft on end to end NAT.
As is discussed in draft-iab-ipv6-nat-00.txt:
If the
translation is reversible, and the translation is indeed reversed
by the time it reaches the other end of communication, then end-
to-end transparency can be provided. However if the two
translators involved are owned by different organizations, then
solutions are harder to incrementally deploy due to the incentive
and coordination issues involved.
NAT can be end to end and an ISP and its customer do have the
incentive to coordinate two translators: an ISP's NAT gateway
and a costomer's end.
Have a happy april fools day.
Masataka Ohta
.
INTERNET DRAFT M. Ohta
draft-ohta-e2e-nat-00.txt
Tokyo Institute of Technology
April 2009
End to End NAT
Status of this Memo
This memo is a draft Internet Draft. Redistribution of this memo is
unlimited.
Abstract
By making NAT visible to ends and let the ends help NAT gateways, NAT
can be correct, complete, and fully transparent at the transport
layer and above.
1. Introduction
NAT (Network Address Translation) is a technique to suppress address
space consumption by sharing an IP address by multiple hosts at
different times or, more practically, at the same time with different
port numbers.
According to the end to end argument [SALTZER],
The function in question can completely and correctly be
implemented only with the knowledge and help of the application
standing at the end points of the communication system. Therefore,
providing that questioned function as a feature of the
communication system itself is not possible. (Sometimes an
incomplete version of the function provided by the communication
system may be useful as a performance enhancement.)
NAT can completely and correctly be implemented only with the
knowledge and help of ends.
However, legacy NAT was designed to be transparent to ends that the
ends can not help NAT gateways. As a result, legacy NAT is incomplete
and incorrect in various ways.
E2ENAT (End to end NAT) is a NAT, configuration of which is visible
to ends so that the ends can, with their knowledge, help NAT gateways
by reversing address translation at the ends and maintain state of
NAT gateways, which makes NAT operations complete and correct.
2. Operation of End to End NAT
M. Ohta Expires on October 1, 2009 [Page 1]
INTERNET DRAFT End to End NAT April 2009
Dependeing on how port numbers are shared, there are static and
dynamic E2ENAT or combinations of them. With static E2ENAT, an end is
assigned port numbers statically, which is necessary for a server
with a stable IP address and a port number. With dynamic E2ENAT, ends
dynamically share port numbers, which is useful if a small number of
port numbers are shared by many ends, which could be the case with
nested E2ENAT.
With E2ENAT, an end and a NAT gateway share knowledge of NAT
configuration: a private IP address, a public IP addresses and public
port numbers assigned to the end. DHCP and PPP options may be useful
to give the ends NAT configuration information. A private IP address
and a UDP port number of a NAT gateway for dynamic NAT control may
also be given.
As for incoming packets, a NAT gateway translates a public unicast
destination address of the packets to private destination addresses
based on the destination port number assigned to ends, without
modifying transport information such as port numbers and checksums.
An end translates private destination addresses of incoming packets
to public destination addresses, unless the source addresses of the
packets are not within address ranged used by a private network,
which restores correctness of transport checksum. Multicast
addresses should be shared unmodified between a public and a private
networks.
As for outgoing packets, after transport processing including
checksum calculation, an end translates a public source address of
outgoing unicast packets to a private address of the end. A NAT
gateway translates private source addresses of the outgoing packets
to a public source address (if the gateway manages multiple public
addresses, the one corresponding to the private source address),
unless destination address of the packets are private address of the
NAT gateway, regardless of whether the source port number actually
belongs to an end of the private address. Validity of the source port
is expected to be, if necessary, verified end to end with a three way
handshake, just as validity of source addresses are verified. Source
addresses of multicast packets should be public ones.
Packets generated by an end to a public IP address of the end will be
looped back to other ends by a NAT gateway, unless the destination
port numbers belong to the end, in which case, the packets should be
looped back locally within the end.
Local communication within a private network is performed using
private addresses.
Ends are responsible for maintenance of dynamic NAT state on a NAT
M. Ohta Expires on October 1, 2009 [Page 2]
INTERNET DRAFT End to End NAT April 2009
gateway and periodically refresh assignments as long as the transport
connections on the ends are alive. So, the NAT gateway does not have
to guess the validity of port assignment, even if there is no data
flowing through the connection.
A private network may have multiple NAT gateways sharing a public
address. Ends are responsible for coordination of dynamic state
among the NAT gateways.
To ease management, a port number assigned to an end may be valid for
all the protocols of the end.
A NAT gateway may manage more than one public IP addresses but does
not have to be large scale.
For ends without E2ENAT capability, E2ENAT gateway may also support
legacy NAT.
3. Port Number Considerations
3.1 Well Known Port Numbers
Considering that multiple ends behind NAT gateways can not share a
well known port number of a transport layer protocol, we must abandon
a notion of well known port numbers.
Or, for some application, with which information to demultiplex ends
is available at the application layer, an application layer relay may
operate at a well known port of the application to redirect requests
to non-standard ports of the ends. The relay may be collocated on a
NAT gateway or the NAT gateway may merely redirect requests to an
external server shared by multiple NAT gateways.
Fortunately enough, if a client can, through some mechanism, know IP
address of a server of some service, the same mechanism may be used
by the client to know a port number of the service, which is the case
with URLs or manual configuration. To ease remembering port numbers
of URLs or for manual configuration, small port numbers are better.
For fairness, each end behind a NAT gateway should be assigned almost
equal number of small port numbers.
A problem is that port numbers of SMTP and DNS are hardcoded as MX
and NS records and can not be changed.
Again, fortunately enough, SMTP and DNS are applications with
demultiplexing capability at the application layer that application
layer relaying should be performed at well known ports. To suppress
birthday attacks, DNS relays should well randomize message IDs and
M. Ohta Expires on October 1, 2009 [Page 3]
INTERNET DRAFT End to End NAT April 2009
support source port randomization. For NAT gateway operators to
confirm that an end has an authority for a domain of SMTP or DNS, the
operator can generate a random hostname as a cookie and request an
administrator of the end put the cookie in MX or referral NS of the
domain.
Other protocols such as HTTP may also be relayed at well known ports.
3.2 What are Destination Port Numbers?
Though E2ENAT is almost fully transparent to upper layers, it is
still NAT.
So, it is required that packets to ends sharing an IP address must,
somehow, be demultiplexed by a NAT gateway. However, as the
demultiplexing information is located in payload part of IP packets,
it depends on a protocol above IP. The issue is briefly discussed in
[RFC2205] as an RSVP session identification issue.
It should be noted that a NAT gateway and all the ends behind it must
agree on how the demultiplexing information is extracted that strong
standardization is necessary here. Thus, it must be assumed that the
protocol is identified by IANA assigned value in protocol field of IP
headers, ignoring a possibility of private agreement on the value.
For most, if not all, true transport protocols (such as TCP, UDP,
DCCP, SCTP, UDPLite), demultiplexing depends on destination port
numbers located at the third and the forth bytes of transport
headers.
The same location may be usable for some protocols. For example, ESP
packets may be demultiplexed based on the lower 16 bit of SPI.
Some other protocols may use different location, for which E2ENAT may
provide special care. For example, AH packets may be demultiplexed
based on the lower 16 bit of SPI, located at a location different
from that of ESP. Identifier field of ICMP Echo may be used for
demultiplexing.
There are protocols with no demultiplexing information, for which
NAT, including but not limited to E2ENAT, is not applicable, of
course.
Except for this subsection, the demultiplexing information is assumed
to be 16 bit long and is called (destination) port (number).
4. Information on NAT configuration
M. Ohta Expires on October 1, 2009 [Page 4]
INTERNET DRAFT End to End NAT April 2009
The following is a summary of information on NAT configuration an end
should know.
Private IP address of the end
Public IP address of the end
Public port numbers statically assigned to the end
Private IP address and port number of NAT gateway(s) for dynamic
NAT
Methods to extract destination port numbers for special protocols
(such as AH)
Applications with application relays
Port numbers to be used between application relay and application
on the end
Information may be standardized and hard coded, manually configured
or automatically configured through some protocol such as DHCP or
PPP, as long as it is consistent with that of a NAT gateway.
M. Ohta Expires on October 1, 2009 [Page 5]
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf