On Wed, 31 Mar 2010, Jason Livingood wrote:
:: Igor - How do you define broken? And what technical issues do you believe
:: underlie this condition?
This is actually very subjective, and I suspect would differ from provider
to provider, so, these are *my* own shot at this definition, not my
employer's..
"Broken" = any time a user has a worse experience in the presense of ipv6
(AAAA) then over ipv4 (A) in any "measurable" way.
Measurable ways:
1) connectivity: ie user can't connect to the site if the site has
ipv6, compared to a site that only has ipv4 (this one is very simple)
2) latency: A page takes noticebly longer to load in the presense of ipv6,
compared to an ipv4-only site. So, to measure this, take the total page
load time of ipv4, and compare it to the load times of ipv6.
So, what is "noticebly longer"? (this is a lot more subjective)
a) studies have shown that users easily notice (and are
impacted by) extra latency of 100-200ms... see
http://en.oreilly.com/velocity2009/public/schedule/detail/8523
b) for those users that connect over low-bandwidth or far away
links, let's set another upper bound of 10% performance penalty
(so, basically, extra latecy of 100ms is the cut-of for total
page render of 1s, and 500ms is the cut-off for total page render
of 5s)
We can debate if those cut-offs are right, or if 2x of those is where the
line should be drawn, but we'd still be in the same order of magnitude, so
let's just stick to that entire range, with the cut-off being somewhere in
a 10 to 20% or 100-200ms penalty (whichever is higher).
This means that the default retry/fallback to ipv4 time-outs of most
browsers are completely inadequate, and any user that believes to have
working ipv6 connectivity, but doesn't actually have it, or who's ipv6
connectivity is worse then ipv4 connectivity will be "broken" by AAAA's
being added for content.
As to what can break, here is what I've seen or heard about:
1) home gateways announcing RA's into the LAN w/o working external ipv6
connectivity of any type
2) home gateways that when configured for IPv4 VPN, will try to send IPv6
packets over it
3) Personal firewall apps that will block tcp/udp ipv6
4) IPv4-only vpn clients that turn-off split-tunneling, thereby breaking
ipv6
5) Users who have configured proxies in their browser which are not
ipv6-capable (either manually or via PAC for vpn/whatnot reasons)
The above breaks ipv6 completely, and causes users into a 21 - 186 sec
time-outs... I've also seen 6to4/Teredo injecting really bad latency into
the path that is *way* outside of what we'd concider to be acceptable, and
would concider that to be "broken" as well..
Does this help?
-igor
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
