Subject: RE: Stupid NAT tricks and how to stop them.

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 28 Mar 2006 08:00:37 -0800

> From: Kurt Erik Lindqvist [mailto:[email-masked]] 

> > NAT is a dead end.  If the Internet does not develop a way 
> to obsolete 
> > NAT, the Internet will die.  It will gradually be replaced 
> by networks 
> > that are more-or-less IP based but which only run a small number of 
> > applications, poorly, and expensively.
> 
> 
> ...or you will see an overlay network build on top of 
> NAT+IPv4 that abstracts the shortcomings away - aka what the 
> peer to peer networks are doing. End-to-end addressing...

Precisely. Just what is this fetish about keeping the IP address the same as
the packet travels?

If there is a way for the host to determine that it is behind a NAT and to
request external registration of necessary ports the whole process can be
made completely transparent to the hosts at each end.
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 28 Mar 2006 18:23:38 +0200

> Precisely. Just what is this fetish about keeping the IP address the same as

It certainly doesn't have to be. As long as there is one global
identifier which is the same on the other side. A double NAT (thus
making sure the packet is 100% identical on the sending and receiving
side) with a signalling protocol in between is the solution for this.
And there is something already being worked on which does that: shim6.

> made completely transparent to the hosts at each end.

You are thinking of UPNP (See http://www.upnp.org or read for instance
http://www.microsoft.com/windowsxp/using/setup/expert/crawford_02july22.mspx). Which is already support by Windows for some time and many "NAT boxes" (ohno I should say 'router' or 'firewall' according to them) vendors also nicely implement it. But it is a kludge and a heavy one as all the applications using it also have to support it and it is not always available and there are not too many applications supporting it, let alone protocols. Next to that, when the well known port on the outside IP is taken it won't work. Just like when there are multiple levels of NAT, or there are no rights to control the UPNP process at all.

IPv6 thus gives the advantage over UPNP that:
 - it is clear and simple to all the applications who they are
   talking to based on the source/destination IPv6 address
 - same ideas as IPv4 and no kludges
 - firewalling can remain the normal firewalling
 - multiple tools can use the wellknown ports as there are multiple IP's
 - etc...

Other thing you might want to look at is Teredo (RFC4380), which
basically implements an p2p overlay network on top of IPv4, but using
IPv6 for addressing. (Funny eh that both Teredo and UPNP come out of the
MS stables, guess what these guys wanted to solve...)

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Mar 2006 14:33:25 -0500

> Precisely. Just what is this fetish about keeping the IP address the same as

it's called good engineering.  eliminating needless complexity.

> made completely transparent to the hosts at each end.

sounds nice, but the actual situation is more complicated:

apps behind a NAT need to have a way to have the NAT allocate
an address/port pair for incoming traffic, set up mappings to a
local address/port pair that is used by the app, and retain that
mapping for as long as the app is listening to the local address/port
pair.

apps behind a NAT also need to be able to ask the NAT about external
address/port bindings for traffic that they originate.

in either case, the external address/port pair needs to work equally
well from inside or outside the NAT.

the whole arrangement needs to work with nested NATs

there needs to be a reliable way for apps to automatically discover the
NAT and whether it supports the extensions.

a big wrinkle is when private networks are interconnected via
NATs - there's no "external" addresses that can be used there.

another big wrinkle is apps that use well-known ports, and the
potential for conflicts.  that alone prevents your suggestion from
making the whole process "completely transparent".

Keith

---

From: Austin Schutz <[email-masked]>
Date: Tue, 28 Mar 2006 12:11:52 -0800

> it's called good engineering.  eliminating needless complexity.

	..and NAT isn't good engineering. But it may be good enough.

> the whole arrangement needs to work with nested NATs

	This would qualify as a NAT enhancement. This is available now
via manual methods on the devices I've used. This might benefit from 
automation.

> NATs - there's no "external" addresses that can be used there.
	Currently (as I understand it) the solution involves static
natting both sides. Again, this could probably benefit from automation. No
question that this adds complexity. Multihoming becomes much more difficult,
for example.

> making the whole process "completely transparent".

	This goes back to the earlier tcpmux discussion.
	But using httpd as an example, one could use split horizon dns and
set up the nat (really a bastion in this example) as a proxy server. Good
engineering? Doubtful. Good enough? Probably. I would be very surprised
if there weren't many real life examples of this in practice.

	Austin

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Mar 2006 15:52:07 -0500

> question that this adds complexity. Multihoming becomes much more difficult,

that's one example.  there are many others.

> engineering? Doubtful. Good enough? Probably.

when you say good enough, you have to consider who is asking the
question and whether they really know enough to be answering it.

it's not good enough for the application developer who has to cope with
the lack of a good way to do referrals across addressing domain
boundaries, the lack of any naming for addressing domains, and the
inability of apps to tell which interfaces are in which addressing
domains.

the typical user, on the other hand, might _think_ that the solution is
good enough because he doesn't ever see the apps that he doesn't get to
run.

> I would be very surprised

there are.  but this is an example of why existing practice is not an
indicator of goodness.

the only workarounds for NATs that make any sense are those which
effectively allow apps to operate in a non-NATted world, and which,
in the long term, render NATs superfluous.

Keith

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 30 Mar 2006 13:58:44 +0200

> Precisely. Just what is this fetish about keeping the IP address  

I will have to get better at making irony clearer....I most certainly  
hope we are not heading down the route I suggest above. I am _afraid_  
we are though.

- kurtis -