> Look, I have on my disk a file from June, 1992 (yes, that's not a typo -
> *1992*) called "Problems with NAT".
>
> However, as a close personal friend of the patron saint of Lost Causes (see
> all the scars on my forehead? :-), let me tell you that I have (painfully :-)
> learned to recognize a lost cause when I see one, and trying to put the NAT
> geni back in the bottle definitely counts.
>
> It's raining NAT's. Deal with it.
understood. it's just that part of my strategy for dealing with the
NAT problem is to try to counteract the "NATs are wonderful and don't
really cause any signifcant problems that can't be fixed with ALGs"
propaganda that's being generated from some corners. NATs are a big
problem for the Internet and we can't really solve it until folks realize
that there's a problem.
and just because I'm arguing against the above kinds of statements doesn't
mean that I think we can convince folks to just discard their NATs. I do
however think that folks may be willing to upgrade and/or replace their
NATs once something better exists that allows them to run applications that
they can't run with current NATs. and I don't know of any way to
improve things that doesn't require replacing/upgrading NATs in some sense.
another part of my strategy is to counteract the "we need to move away
from using addresses as endpoint IDs" argument, which I might restate
as "we don't really need endpoint IDs which allow network addresses
to be algorithmically derived from them". because in my experience
endpoint IDs that are not resolvable into network addresses aren't
very useful, and endpoint IDs that require a distributed database lookup
to translate them into network addresses are slow, inefficient, expensive,
and error prone.
I do understand that there are scaling difficulties at the routing layer
associated with having network addresses be derivable from endpoint IDs,
(e.g. having them be both stable and globally scoped) even though I
don't think I could accurately describe those problems.
> >> 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.
>
> > we might regain the "end to end model" from doing this but we would
> > still prevent a lot of applications from working well. ... so a model
> > that assumes that everything is connection-oriented and can therefore
> > afford connection setup overhead ... doesn't look very attractive to me.
>
> I'm not trying to deny there are real problems with the NAT world (and you've
> pointed out at least very serious one - I wasn't sure of what you meant by
> the others).
>
> In fact, I 'embrace' NAT only in order to build things that enable us to
> throw away NAT - ASAP!
>
> And it won't be easy - but there is *no* forward path for growing the
> Internet which is easy. Whatever we do, it's going to be painful.
agreed.
> But I don't think a forklift upgrade is workable in today's Internet. We have
> to find an path consisting of many incremental steps.
I guess I think that forklift upgrades might be possible, but those
have to be incremental as well - and the folks who pay for the upgrades
have to see some benefit from doing so.
> E.g. we have to build a
> new end-end namespace, and modify applications one by one to use it. (That
> still won't fix some of the problems you allude to, but's it's a necessary
> preliminary step.) Then, with that as a fixed reference, we can more easily
> deploy new location 'names'.
I agree that applications will need to adapt to a new end to end namespace,
because a 32 bit space isn't enough for the long term even if the bits
had no significance at all for network topoligy. (you still would need
to have hierarchical delegation of the namespace and the associated
inefficiences, just so that assignment would scale)
> > and I have yet to see someone who recommends that approach demonstrate
> > how to recover the functionality that you lose by doing so.
>
> Well, the goal is to throw away NATs eventually (like 10 years down the road,
> at the pace the gigantic beast called the Internet moves now). But we can't
> get there unless we embrace NAT's in the short term.
this is not clear to me. I understand that folks are going to use NATs
when NATs meet their immediate needs and when getting non NATted addresses
is too painful. but there is an increasing demand for devices and
applications that do not work well with NAT.
> > 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
>
> Simple; I don't think anyone working with NAT's has any interest in another
> form of local forwarding tag! People don't give a rat's anterior about
> another local forwarding tag. They treat them that way because they have to,
> not because they need/want a local forwarding tag.
okay, so you're not arguing that the architecture inherently needs more local
forwarding tags, but simply that this is the environment that NATs give us,
and if we can find a solution that works within that environment, we're
better off. I guess I don't see a way to actually solve applications'
problems that doesn't either require some changes to the NAT (whether by a
forklift or a rom upgrade), or requires that the NATted IP network be
treated as a link layer and that the "real" traffic be tunneled over it.
(which is equivalent in difficulty to a forklift upgrade and more complex)
and if we're going to need to change the NATs anyway I'd just as soon
change them in such a way that we're back to having endpoint IDs
from which network addresses can be algorithmically derived.
>
> >> 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.
>
> Good, something we concur on - although I suspect my "incremental" is perhaps
> a lot more incremental than you realize.
>
> > the top of the NAT hill is a long way from goodness.
>
> Absolutely. Which is why it's important to throw NAT's away as soon as we
> can.
sure. see we do agree on some things!
Keith
