ietf
[Top] [All Lists]

Re: Backwards compatibility myth [Re: Last Call:

2012-02-13 21:29:54
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>