On 28-Jun-2007, at 13:16, Randy Bush wrote:
Interoperability is achieved by having public facing servers reachable via IPv4 and IPv6.
that may be what it looks like from the view of an address allocator.
but if you actually have to deliver data from servers you need a path where data from/in both protocols is supported on every link of the chain that goes all the way to every bit of back end data in your system. and if one link in that chain is missing, <sound of glib idea imploding>.
I think this is one reason why the transition is hard: supporting dual stacks in clients when the demonstrated quality of the v6 network is noticably worse than the v4 network is a difficult business case to sell. When you depends on users being able to talk to you reliably, having them use a low-quality transport when a high-quality transport is also available has a direct impact on the bottom line, without even considering the capex/opex costs of supporting IPv6. The difference in performance/reliability might be relatively small to a single user, but to a company who is trying to service millions of clients every minute (and is earning revenue from each visit) the aggregate effect is surely much more significant. Providing access to (e.g.) web services over both IPv4 and IPv6 using (e.g.) a single URL hence reduces revenue when serving the non-zero (but small) set of dual-stack clients, and does not increase revenue from the set of IPv6-only clients in any practical sense since that set is (to all intents and purposes) empty. Providing separate URLs for services over IPv6 requires user education, which is arguably even more expensive. The way to avoid this scenario is presumably to improve the quality of the IPv6 network such that the risk of revenue loss from IPv6 support falls below an acceptable threshold. Which would be much easier to do if people were using it, and opening trouble tickets when things need to be fixed :-) Joe