> From: Jeffrey Altman <jaltman(_at_)columbia(_dot_)edu>
> 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.....
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".
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...
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.
> 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.
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.
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.
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