John Day wrote:

> Cmon, surely you can come up with a better counterargument than that!  ;-))
> I certainly could.  If it is architecturally acceptable for those protocols
> to rewrite the address field at every hop, why shouldn't it be for IP?  How
> does it differ?  Basically a NAT is doing what an ATM switch does. How does
> an MPLS tag differ?

Here is the difference between NAT and the other things you mention.
The only changes to the IP header and encapsulated data should be the
TTL and fragmentation information.  Granted ATM chops the packet into
small cells, but when its put back together the packet looks the same.  This
cannot be said of NAT.

>               But it would be a big step to solving the problem.  However,
> there are so many special cases now of people doing strange things with IP
> addresses that they shouldn't be doing that there may not be anyway out of
> the problem.

Ok, here is where the rubber meets the road.  What is "the problem"?
My guess is that you think the protocols/applications are broke, or
architecturally unsound.  I think the problem is that NAT became
"necessary".

> I am well aware of the issues, but I did want to push back on people who
> see no problem with applications exchanging IP-addresses.

Is there a constraint/expectation that these applications/protocols run on
something other than IP?  Is it a requirement that when (if) the switch
is made to IPv6, that all IPv4 applications will work over IPv6, and even
better yet work across an IPv4/IPv6 "converter"?

While these would all be nice things to have, are they design
requirements?  Is the goal to have a stackable streams-like system
where I can slide in/out or replace "modules" letting me (in theory)
run any application using any transport over any physical medium?

It's a nice idea, but certainly brings with it lots of complexity.
My personal opinion is that the IETF's goals essentially boil down
to "IP on everything".  Unfortunately, this means if IP changes,
everything much change with it.  Just as IP's predecessor is gone,
so would vanish old versions of IP.

This of course has its own problems, but I think identifies (at
least for some) the current mindset.  If the IETF has to identify
and specify the entire behavior from user interface to bit order
on the wire, their charter needs to be expanded.

Tony

Reply via email to