ietf
[Top] [All Lists]

End to end NAT

2009-04-01 06:15:44
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>