On 2/13/2012 7:09 PM, Brian E Carpenter wrote:
On 2012-02-14 13:42, Dave CROCKER wrote:
On 2/13/2012 4:38 PM, 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.
So, an initial requirement that simply said "we need a larger address space"
became "we need a larger address space, a new routing architecture, and a slew
of other new mechanisms".
For an exercise like creating IPv6, this is called second system syndrome.[1]
If often accounts for massive delays. 15 years qualifies.
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.
In theory, there is no difference between theory and practice...
By saying 'benchmarking' you appear to be referring to something like
transformation time. But notice that I gave a list that had nothing to do with
cpu or i/o performance.
I fear that anyone who thinks that developing and operating a slightly enhanced
router, such as I described, is the same as an application gateway probably does
not understand the relative complexities or OA&M demands of either very well.
d/
[1][http://en.wikipedia.org/wiki/Second-system_effect
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf