RE: solution to NAT and multihoming

["Bernard Aboba" <aboba at internaut.com>]

Wow. After dozens of emails, finally a list of implementable
work items that could improve the situation ;)

I particularly like the IPv6 over UDP idea, after having
encountered several NATs that can't handle anything other than
TCP and UDP. Though you've got to be aware of the NAT state timeout
issues. 

To this list, I'd like to add something along the lines
of a "NAT requirements" document, specifying the expected behavior
of a properly behaving NAT. I think this is useful because in
addition to the things that NAT must break due to their
fundamental nature, there are lots of other things that they
break just because they're badly implemented. It would be great
to have an RFC to point to and say "your NAT is violating
RFC X -- fix it!" 

I'd also like to have a NAT MIB that could do things like
plumb state for incoming flows, so that there would be a uniform
way to enable incoming traffic. But there is more than one
way to skin that particular cat. 



====================================================================
Keith Moore spake thusly:

"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."