Bottom line, NAT or changing destination addresses on the fly breaks the
end-to-end nature of Internetworking. This is true not only for IP, for for
other protocols as well. Some may recall older DECNET IV networks that
exceeded the maximim ~65K nodes. We had to come up with a scheme to make
that work and it was ugly.
Even though we are not in the same situation as DECNET IV (we still have a
lot of addresses available), we are (for other reasons already discussed)
stuck with this NAT situation for the foreseeable future. It does
absolutely no good to complain about the state of the world. It is what it
is and all the complaining by the IETF won't change it.
It would do a lot of good to find a way to dig ourselves out of this
situation. The Internet isn't going to stop growing and there will be
future applications that require or desire a heck of a lot of public IP
addresses. Other future applications may compromise some useful feature to
be "NAT Friendly". This is not a good thing.
So we need to find a way to bridge ourselves to a new addressing
architecture. IPv6 is one such architecture, but getting there is very,
very difficult. So we need some alternative solutions in the meantime. And
we need to continue to reassess how we might transition to such an
architecture. The Internet will not stop changing so we need to be fluid in
our transition schemes.
The IETF, IAB and IRTF are struggling with this and there is no neat short
term fix. The NAT WG and the NGTRANS WG are a couple of places (I'm sure
there are others) where folks are trying to help things along and we would
appreciate your support.
P.S. Let me take this public moment to ask (beg!) for review of
draft-ietf-nat-protocol-complications-01.txt which I'm editing. If
you know of any particular protocol that has difficulty with basic
Network Address Translation, please send me the info in the format
of the above draft.
- Matt Holdrege - NAT WG co-chair
