Subject: Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

From: "J. Noel Chiappa" <[email-masked]>
Date: Mon, 23 Jun 2003 08:27:23 -0400

> From: Michael Thomas <[email-masked]>

    > we're being driven as a community to do both with the ensuing insanity
    > of two broken models being forced to cohabitate, all the while neither
    > meeting the actual requirements.

Time to hit the "reset" button on our current direction, I would say.

    > So just saying that NAT is here get used to it is, architecturally, not
    > helpful. .. more importantly the net is becoming more and more
    > incomprehensible because of it, both intellectually as well as
    > operationally.
    > ..
    > saying "get used to it" is a weird position because it discounts the
    > problems of the status quo and doesn't really express any vision for
    > what the architecture *ought* to be

Look, in my comments about NAT, I'm *not* saying "just get used to the
current level of poor design", we're stuck. What I am saying is that it's
time to stop acting like NAT is this awful icky thing that we refuse to touch
in any way because it's so bad, and that if we stick our heads in the sand
hard enough it will go away. It won't.

Here, again, is the nub of what we have to deal with:

    >> The notion of a system with a single, globally unique namespace at the
    >> lowest level is a really nice one, one we had for a while - and *one
    >> we think we can reclaim*. I now think we've been deluding ourselves;
    >> that past .. is gone for good.

How would I move forward from there, constructively, to try and produce a
less broken architecture/system?

The very first thing I would so would be to actually write a "NAT spec" (or
perhaps a small number of them, for different flavours that are useful in
different ways).

There are many different flavors of NAT, and so it's hard to make an
application "work with NAT" when you don't know exactly what the NAT box is
going to do. E.g. the recent point about most NAT boxes being port mappers,
not address mappers - I don't know about that, actually, and none of the NAT
boxes I've seen come with specs that say *exactly* what they do.

For another example:

    > Voice is one trend and it pretty fundamentally challenges one of the
    > base assumptions of NAT: private-client/public-server. But instead of
    > realizing that NAT is architecturally incapable of dealing with private
    > servers

That's true of the current crop of NAT boxes, but the first NAT boxes (both
Paul Tsuchuchiya's and Van Jacobsen's) did indeed handle incoming connections
(albeit in a really ugly way, by intercepting incoming DNS requests and
modifying the responses, and setting up external->internal mappings based on
that.) The little boxes people running home networks use don't do that.

We first need to really get a definitive handle on what these things are
doing.

The next step would be to add a "NAT considerations" section to all protocol
specifications, just like the "Security considerations" we have now.
Protocols can be designed to be less NAT-hostile - e.g. no giving addresses
to third parties as a way to contact someone, etc.

NAT boxes are here, and are very widespread, and will be for a long time to
come, and it's doing the users (not to mention the IETF) a tremdous
disservice to roll out protocols that won't work with NAT boxes.

Finally, there are some hard technical issues involved with NAT we need to
think about.

We can, if we feel its needed, define a new namespace which is used for
long-term identification of entities, and deploy that on an
application-by-application basis for new applications.

(I've thought about how to modify existing transport protocols on an
upwardly-compatible basis to use such a global namespace for entities, and it
can be done [I have a complete draft spec for TCP]. However, I don't think
that's very useful - too many old installations will remain. I think the same
logic applies to old applications. So only new applications, I think.)

The big problem is incoming connections - how do you set up the mappings they
will need? Wiretapping DNS is ugly, but it doesn't require changing anything
(for existing applications). On the other hand, if you only want to support
incoming connections for new applications, you can define them to include
some sort of MidCom-like setup.

    > We want an architecture that meets all of the requirements, not a
    > hodgepodge of half solutions which fall over in the first stiff breeze.

Nothing positive can happen as long as we keep acting as NAT i) is too
disgusting to seriously try and deal with, and ii) will go away if we stick
our heads in the sand hard enough

	Noel

---

From: Jonathan Hogg <[email-masked]>
Date: Mon, 23 Jun 2003 17:52:36 +0100

> some sort of MidCom-like setup.

Aren't Microsoft already "standardizing" this with their Universal Plug and
Play (UPnP) architecture?

I'm a little fuzzy on the details, but I believe the concept is that
applications that understand this can communicate with the router (the NAPT
box in the case of SoHo networks) and request ports to be opened externally
and forwarded back to the host. I think Microsoft's NetMeeting conferencing
program supports this already and there are a few ADSL modem/routers that
implement it.

I agree that NAPT is here for a long time and it would be better to work
towards controlling it.

Jonathan

-- 
Jonathan Hogg
Director, Technology

Seventh Wave Systems Ltd.
4-14 Tabernacle Street
London EC2A 4LU
Telephone: +44 20 7074 0423

<http://www.seventh-wave-systems.com/>

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Jun 2003 13:28:00 -0400

>     >> The notion of a system with a single, globally unique namespace
>     >at the> lowest level is a really nice one, one we had for a while
>     >- and *one> we think we can reclaim*. I now think we've been
>     >deluding ourselves;> that past .. is gone for good.
> 
> How would I move forward from there, constructively, to try and
> produce a less broken architecture/system?

the only way I can see to do so is to provide tools to ease migration to
a less broken system.  I don't see any way to make the NAT technique
significantly less broken (and I have tried) that takes less effort than
supporting IPv6 alongside NAT.   basically you end up trying to create a
new network with a new address space on top of a NATted network,
instead of alongside it. and to do this you have to upgrade the NAT
boxes, and the hosts, and the apps that can't deal with status quo NAT -
at which point you're imposing about the same deployment barrier as IPv6
imposes.  IPv6 is both cleaner and ahead of the curve.

> application "work with NAT" when you don't know exactly what the NAT
> box is going to do.

indeed, this is a problem - and NATs are also a moving target.  but it's
almost as difficult to "work with NAT" even when you do know exactly
what the NAT box is going to do.  

also, the argument is often made that NATs are "here to stay" precisely
because they are already so widely deployed.  if one accepts that,
doesn't it follow that broken NATs with their inconsistent behavior are
"here to stay" also, for the same reasons?  and if we assume we can
upgrade the NATs anyway, why not make them support something cleaner
than IPv4+NAT+MIDCOM-style application hooks?

> The next step would be to add a "NAT considerations" section to all
> protocol specifications, just like the "Security considerations" we
> have now. Protocols can be designed to be less NAT-hostile - e.g. no
> giving addresses to third parties as a way to contact someone, etc.

many protocols cannot be designed to be less NAT hostile without
imposing significant overhead both in bandwidth and in extra
infrastructure, and degrading performance and reliability.  if we want
to set up proxies for each protocol outside of every NAT we can make
those protocols work. IPv6 is a lot simpler and more robust.

> disgusting to seriously try and deal with, and ii) will go away if we
> stick our heads in the sand hard enough

nothing positive can happen as long as we keep acting as if NAT is
here to stay and that it's going to be forced on all future apps.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Mon, 23 Jun 2003 15:24:22 -0400

> Play (UPnP) architecture?

That's just midcom, which the IETF is standardizing.  We
started before they did but Microsoft got there first and
worst (there's even midcom language in their documents).  So
that's something that was started in the IETF and
expropriated.  Note that it still handles incoming
connections pretty badly.
  
There are other IETF efforts, as well, which I think are
more sound, but may take some time to become fully ramped
up.

Melinda

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Jun 2003 15:38:26 -0400

> I agree that NAPT is here for a long time and it would be better to
> work towards controlling it.

in other words, we should keep beating our heads against the wall trying
to solve insurmountable problems.  

trying to make NATs work is the modern task of Sisyphus.