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