On killing IPv6 transition mechanisms
Brian E Carpenter
brian.e.carpenter at gmail.com
Fri Mar 19 02:28:47 CET 2010
The link for Nathan Ward's work:
On 2010-03-19 11:58, Tore Anderson wrote:
> * Brian E Carpenter
>> I believe this was intentional, since the philosophy was 'prefer IPv6
>> connectivity if it exists'. I also agree that reversing this in
>> the policy table would be very reasonable; 3484 only provides a
>> *default* policy table.
> I should probably have said "shortcoming" instead of "bug". However,
> the RFC does special-case 6to4 and makes 6to4-to-!6to4 connectivity less
> preferred than IPv4-to-IPv4. If the point was to prefer IPv6
> unconditionally, they would not have had to mention the 6to4 prefix at all.
> But they did, and I cannot imagine any other reason that they recognized
> that 6to4-based connectivity would be inherently less reliable than the
> IPv4 connectivity that 6to4 was tunneled on top of. So I don't quite
> understand why they didn't make 6to4-to-6to4 less preferred than
> IPv4-to-IPv4 too. I don't think 6to4-to-6to4 is used for much
> production traffic though, so it's not really a problem.
>> You mean, I assume, that it turns out that there is no 6to4 relay
>> in the outbound or return path? That is (IMHO) the problem
>> with RFC 3068. The assumption of RFC 3056 was that the placement
>> of 6to4 relays would be a managed process, for savvy early-adopter
>> sites. The addition of the anycast relay model in RFC 3068 broke that
>> assumption and brought about unmanaged deployment.
> Yes, that there is no 6to4 relay in the outbound path (I can easily make
> sure there's return relays for 2002::/16 within my own network so that
> part isn't easily handled), or that proto-41 traffic is filtered, or
> that the relay doesn't work, or is very far away latency-wise, and so on
> and so on.
> Broken 6to4/Teredo connectivity is the single largest cause for web
> sites to appear unreachable/down for regular eyeballs after introducing
> AAAA records. It's responsible for almost all of it, I cannot really
> point out any other single cause of significance, of the 0.094% of total
> brokenness I measured in February, 0.090 percentage points is due to
> Had it not been for 6to4 I doubt I would have had an problems convincing
> my customers to dualstack their content. But now they're understandably
> concerned about losing visitors and thus revenue. Probably most content
> providers wants everyone else to go first and take the pain, so that the
> problematic users hopefully will be mostly fixed by the time they add
> IPv6 capability themselves.
>> Nathan Ward has suggested a way to fix this (and the equivalent
>> problem with Vista/Teredo) but it does need sites or ISPs to install
>> a box to catch the anycasts.
> Do you have a pointer to his suggested solution?
> Best regards,
More information about the ipv6-ops