Tony Hain wrote: >>On the other hand, with NAT, which can be end to end transparent, >>IPv4 capable servers can be reached by IPv4 only clients, optionaly >>with end to end transparency. > Nat is not end to end 'transparent' no matter how you define it, I did think so. So, I tried to prove so directly from the end to end argument of Saltzer, Reed and Clark only to find out that NAT can be end to end transparent. See draft-ohta-e2e-nat-00.txt. NAT is end to end transparent, if a NAT GW translates destination address (and IP checksum, but not port nor transport checksum) of incoming packets and end hosts translate the address back to the original. The packet is now identical to the original packet in the public Internet and integrity of transport checksum is restored. After the reverse translation, the NAT is equivalent to port-wise routing (an end host is identified and located not only by an address but also by a port number) and is obviously end to end transparent. Like port-wise routing, end hosts must restrict port numbers they use to those assigned to them, of course (in_pcb.c (and more if you want to use SCTP) needs to be modified). > and will > break all the stuff you claim works when it is operated by a third party. The stuff works, unless the stuff requires fixed port numbers not assigned to end hosts, which is no different from port-wise routing. For example, end to end NAT is implemented and ftp active mode with PORT commands is working with it. > Nat in the core will be nothing like nat at the edge, They are same, as long as end to end NAT is used and end hosts are informed of NAT configuration information (shared public addresses and port number range of the end hosts etc.). > the CGN mess Fully agreed. Masataka Ohta _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf