> From: Keith Moore <[EMAIL PROTECTED]>
>> 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.....
> nobody is saying that it isn't raining.
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.
>> 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.
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. 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'.
> 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.
> 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.
>> 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.
Noel
