Re: End to end NAT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear profesionals,

You may be just proposing a social security hole, I think.?An idea of End-to-end is too primitive like monkey world. I recommend an idea of family-to-family. At first, a nation should be considered as a set of home, right? In other words, as you may know, according to the theorem of Social Contract by Jean-Jacques Rousseau, fundamental unit of a nation is a set of an idea of family. Specifications of any information system must be based upon such kinds of fundamental insight of civilization, even if it is related to military usage, I think. There is no need to say, the solution of where the legs of table are located under the board of table could be an element of a patent, similar to this, the resolution where authorities for controlling, modifying, observing and distributing information should be located could be a kind of invention about social science. Without considering such point of view, any specification could be a kind of delusion or fantasy, I think. Considering the differences between Traditional Newspaper and Internet News, deliverer of newspaper know who are reading this according to "family register" or "KOSEKI", on the other hand, deliverer of internet news know nothing about readers. That's the fundamental question to solve, I think. We should remember the faces of our local politicians and what their saying, I think.

Abraham TaddyHatty
taddyhatty at acm dot org


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

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]