RE: IP network address assignments/allocations information?

[Matt Holdrege <matt at ascend.com>]

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