On killing IPv6 transition mechanisms

[Brian E Carpenter]

The link for Nathan Ward's work:

http://www.braintrust.co.nz/tui/

Regards
   Brian Carpenter

On 2010-03-19 11:58, Tore Anderson wrote:
> Hi,
> 
> * 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
> 6to4/Teredo....
> 
> 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,