Subject: Re: solution to NAT and multihoming

From: Kevin Farley <[email-masked]>
Date: Fri, 26 Jan 2001 10:06:25 -0800 (PST)

Keith, Ed, others...

I have been following this entire line of discussion with some
amusement and some frustration. I would like to share a couple of
humble thoughts on this subject from my own perspective.

- yes, NAT in general restricts the applications and/or protocols that
can be accessed by users behind the NAT.

- yes, having NAT devices deployed will impede development of new
protocols and applications that rely on embedding IP addresses.

- yes, NAT can be cumbersome in its sustained management as sys admins
must punch holes through their various NAT devices to allow a
particular application/protocol through.

- yes, NAT does violate the global addressibility of Internet hosts.

- yes, we could eliminate NAT by giving everyone a globally unique IP
address.

- no, not everyone wants to run every conceivable application/protocol
to their client machines, they are happy with the subset they chose.

- no, protocol developers cannot go off developing new protocols that
do not consider implications with NAT deployment.

- no, not all NAT implementations prevent the use of punch-throughs
allowing unique or custom protocols to still work.

- no, not everyone wants to participate in the great global address
space of the Internet, they just want to access Internet-connected
devices.

- no, as a mere mortal user, I cannot always obtain real IP addresses
as the ISPs claim they must justify IP address assignment and hold them
close to their vest pocket.

Considering my own company and the plethora of IP-addressed devices,
and yes we sit behind NAT and yes I can do nearly all applications and
protocols as one can who is not behind a NAT, many of these devices are
lab tools that only need connectivity back to an engineer's desk or a
shared printer. I don't really need access to a JTAG emulator pod from
across the ocean, it just doesn't make sense for my purposes.

Given the argument that NAT restricts the available applications and/or
protocols, a potential buyer of the device must then choose the one
that meets his or her requirements. Since the more restrictive devices
will most likely be purchased less and less, and the "better" devices
will prevail, will it not be expected that the NAT implementations will
improve over time in a manner similar to a farmer improving his crops
year after year by only planting the hardiest varieties?

So when it comes to buying NAT devices, "buyer beware" should be the
mantra of the day.

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?

Respectfully,

Kevin Farley

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. 
http://auctions.yahoo.com/

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 26 Jan 2001 19:26:26 +0000 (GMT)

> to their client machines, they are happy with the subset they chose.

you have an interesting spin on 'choice'. How can you choose something
before you've tried it? Before it's been written?

> space of the Internet, they just want to access Internet-connected

That is tantamount to saying 'We don't need clean air! We don't even
want to know what clean air is! We just need to be able to breathe!'.

I'm tempted to equate the walled-garden restrictions imposed by NAT
with the walled-garden restrictions imposed for copy-protection:
http://cryptome.org/jg-wwwcp.htm

either way, consumers are disadvantaged.

> that meets his or her requirements.

or the requirements of his users. Note the disconnect of needs and
interests there.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 Jan 2001 15:14:16 -0500

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.

> 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

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 26 Jan 2001 13:12:34 -0800

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.

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