Re: End to end NAT

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 mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf 
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf