![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.