Brian E Carpenter wrote: > >Dave CROCKER wrote: >> >> Brian E Carpenter wrote: >>> >>> There were very specific reasons why this was not done. >> >> Is there a useful citation that covers this strategic decision? > >You may recall that at the time, we were very concerned about the >pre-CIDR growth rate in BGP and there was, iirc, a generalised >aversion to anything that would import the entire IPv4 BGP4 table >into IPv6. I don't recall without a lot of archive grepping whether >this was explicit in the IPng decision or whether it came a bit later. With the result that you have two independent routing tables describing the entire internet instead of just one. I do not see a size benefit, only the possibility for seperate code so that during development of IPv6, the old IPv4 code that carries the larger part of the Internet traffic is subject to less changes and therefore less new bugs. > > > > > Given that that decision was an essential part of what caused a roughly > > 15 year delay, it would be helpful to have it documented. > > > > > >> And it doesn't > >> change the fact that an old-IP-only host cannot talk to a new-IP-only > >> host > >> without a translator. It is that fact that causes our difficulties today. > > > > The translator needed today is a complete gateway between two entirely > > incompatible protocols. The one that I'm describing would have been a > > trivial re-formatter. > > > > The development, deployment and interoperability differences between > > these is massive. > > Honestly, having had an MSc student who benchmarked translation vs > application proxying vs native, I don't think so. The mechanics of > packet translation are trivial. The hard part is exactly the same as > with NAT44, caused by the shortage of IPv4 addresses and all the state > that goes with sharing the pool of transport ports for a single address. the difference in connection setup seems to huge, that folks came up with the happy eyeballs proposal -- at an enormous cost of change for apps that aren't multi-threaded or async multi-connect yet, and extra load for the network and Server OS. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf