Subject: Re: draft-ietf-nat-protocol-complications-02.txt

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 20 Apr 2000 15:58:39 -0400

> From: Jeffrey Altman <[email-masked]>

    > I am not a IPv6 proponent other than

Well, I'm not exactly a big fan of NAT boxes either. Disgusting kludges.

However, I've generally found that it's not really very useful to go around
saying "it's not really raining, it's not really raining" while I'm walking
in a thunderstorm.....
                              
NAT's are with us, like them or not, and the sooner we accept it, and try to
start working to fix things up to work with them, the better...

(E.g. fixing IPSEC to work through them, to use one example mentioned here -
although some people would no doubt point to things like SSL, which already
work through NAT boxes, and ask why we need IPSEC anyway - but I'm *not* going
to get into that! :-)

    > the extended address space that everyone needs without breaking the end
    > to end model of IP.

Well, I think we can regain the "end-end model", even with NAT boxes, if we
accept that those 32-bit things are irrevocably destined to become just
forwarding tags with only local scope.

There's a need, and a place, for things with only local scope - e.g. the
network layer header in front of the internet header, the hop count in the
internet header, etc, etc. The IPv4 address will have to be added to that list
- and for things which need an end-end name, we'll have to migrate to using
something else.

This still leaves us with the architectural problem of having mapping state
in the border boxes (another impingement on the fatesharing principle - i.e.
that all state relevant to an end-end connection be kept only at the ends),
but that can be looked at. It's not like there's *no* state in the network,
without which the connection won't work - routing table entries may seem like
they're handed down on stone tablets, but they are critical state too.

Then there's how it's installed (wiretapping DNS - eccch, another disgusting
kludge); definitely need to do something better there.

But it will have to be an incremental approach back to goodness, I fear...

	Noel

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Apr 2000 19:17:21 -0400

> saying "it's not really raining, it's not really raining" while I'm walking

nobody is saying that it isn't raining.
(though personally I'd say NATs are more like baseball-sized hail than rain)

people are saying (to continue the analogy) that if people are getting wet 
and cold and ill because they're standing out in the rain, maybe they 
should go somewhere else instead of continuing to stand there and saying 
"man was meant to be rained on".

> start working to fix things up to work with them, the better...

some of us are trying to fix the NATs.  but ultimately the only way to 
"fix" NATs is to coerce them into being routers that deal with 
larger end-to-end addresses.

> forwarding tags with only local scope.

we might regain the "end to end model" from doing this but we would 
still prevent a lot of applications from working well.  if the only
applications we ever wanted to care about were email and the web this 
might be good enough.  but from where I sit it looks like Internet usage
is becoming more and more diverse. so a model that assumes that everything
is connection-oriented and can therefore afford connection setup overhead, 
or that all networked apps are client-server or provider-consumer, or that 
all apps need a central point of control, doesn't look very attractive to me.

an Internet that doesn't support distributed apps efficiently is at
least as crippled as one that doesn't support multicast. 

> - and for things which need an end-end name, we'll have to migrate to using

from the point of view of a developer of distributed apps, that's a 
pretty naive statement.  and I have yet to see someone who recommends 
that approach demonstrate how to recover the functionality that you lose 
by doing so.    instead, the argument tends to be of the form
"your use of IP addresses as endpoint IDs is already screwed by NATs, so 
we might as well usurp them for use as local forwarding tags".

and except for the dubious benefit of NAT compatibility, I haven't been
able to figure out why it's so important to have yet another form of 
local forwarding tag in addition to link-layer addresses, MPLS tags, 
PPP header compression, IP-in-IP tunneling, and probably one or two
other ways that we have for forwarding IP packets within a local scope.

> But it will have to be an incremental approach back to goodness, I fear...

if you mean an approach that can be deployed incrementally, I agree.
but strict hill-climbing strategies tend not to produce very good solutions,
and the top of the NAT hill is a long way from goodness.

Keith