ietf
[Top] [All Lists]

Re: solution to NAT and multihoming

2001-01-26 13:20:01
Kevin,

I don't disagree with most of your assertions, except perhaps one or two.
Here's the gap in a nutshell:

The fact that NATs are widely deployed means that several quite useful
applications are having great difficulty being deployed.  You may not
think you want to participate in the great global address space, but
you might not realize what you're missing as the result of the inability 
to do so.  The market has very limited foresight, which means that it
can run into dead ends.  The potential market for applications in an
IPv6 Internet is far greater than that for a NATted IPv4 Internet,
but that doesn't mean that market forces alone will bring about adoption
of IPv6.

And now the question(s) of the day:

What is the solution that can be deployed today or in the next 6 months
that will replace the function of NATs in the IPv4 Internet? What about
in the next year? 2 years?

you can't replace NATs in the v4 Internet.
you can however provide new functionality that will allow deployment
of applications that won't work in a NATted v4 Internet.

- 6to4 lets you tunnel v6 over the existing v4 internet 

- a IPv6 over UDP tunneling scheme would let you transmit IPv6 over
  your NATted v4 private network until it got upgraded to transmit
  v6 natively

- extensions to PPP and/or DHCP to request blocks of addresses 
  (rather than just a single address) would allow implementation
  of the "plug a network anywhere into the network" feature 
  of NATs without actually resorting to address translation

- renumbering still needs a considerable amount of work.  perhaps
  we need extensions to routing protocols to advertise upcoming
  renumbering events  (new prefixes become valid in XXXX seconds;
  old prefixes become invalid in YYYY seconds, with some reasonable
  time between the two), with similar extensions to DHCP and to the
  APIs used by applications.

this could all be deployable in 2 years, but the last bit would be 
tight.  the rest could be done much sooner.

Keith