| 1 |
On Fri, Nov 19, 2010 at 09:25:18AM +0000, Neil Bothwick wrote |
| 2 |
|
| 3 |
> But harmless. The severe delays you noticed were the result of a |
| 4 |
> broken modem/router failing to recognise that IPv6 was not available |
| 5 |
> and trying to use it anyway. The usual fix for such a problem is a |
| 6 |
> firmware update. |
| 7 |
|
| 8 |
It's more complex than that. How is the IPV6-enabled browser or media |
| 9 |
player supposed to know that my modem doesn't support IPV6 and neither |
| 10 |
does my ISP and neither do umpteen hops between me and the site I'm |
| 11 |
trying to connect to? See http://www.ipjforum.org/?p=378 |
| 12 |
|
| 13 |
> The technology in web browsers and operating systems involves doing |
| 14 |
> Domain Name System (DNS) queries for AAAA and A resource records and |
| 15 |
> then attempting to connect to the resulting IPv6 and IPv4 addresses |
| 16 |
> sequentially. If the IPv6 path is broken (or slow), this connection |
| 17 |
> can take a long time before it falls back to trying IPv4. This process |
| 18 |
> is especially painful on typical websites that retrieve objects |
| 19 |
> from different hosts-each failure incurs a delay. The combination of |
| 20 |
> operating system and web browser results in delays from 20 seconds to |
| 21 |
> several minutes if the IPv6 path is broken[2]. The typical message |
| 22 |
> flow of a TCP client is shown in Figure 1. Clearly, this delay is |
| 23 |
> unacceptable to users. Users avoid this delay by disabling IPv6[3] |
| 24 |
> or avoiding IPv6-enabled websites. |
| 25 |
|
| 26 |
The decision to enable IPV6 by default was a mistake. The only |
| 27 |
beneficial side effect was that it taught me not to do robo-updates |
| 28 |
any more <G>. |
| 29 |
|
| 30 |
-- |
| 31 |
Walter Dnes <waltdnes@××××××××.org> |
Archives