Re: Yahoo and IPv6

[Tore Anderson <tore.anderson () redpill-linpro com>]

* Tony Hain

> So take the relays out of the path by putting up a 6to4 router and a
> 2002:: prefix address on the content servers. Longest match will
> cause 6to4 connected systems to prefer that prefix while native
> connected systems will prefer the current prefix. The resulting IPv4
> path will be exactly what it is today door-to-door. Forcing traffic
> through a third party by holding to a purity principle for dns, and
> then complaining about the results is not exactly the most productive
> thing one could do.

If you add a 6to4 AAAA record to your domain name, you'll attract 6to4
traffic from a lot of systems that would earlier have used IPv4. This is
because 6to4<->6to4 is preferred above IPv4<->IPv4 in RFC 3484 (which in
turn is preferred aboue 6to4<->NativeV6).

This in turn results in a net decrease of reliability, as 6to4 is
extremely unreliable, even in the situation where the relays are known
to work correctly - the failure rate in this case has been indepentently
verified by Emile Aben of the RIPE NCC
(https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really) and
Geoff Huston of APNIC
(http://www.potaroo.net/ispcol/2010-12/6to4fail.html) to be in the 15%
ballpark.

Also, I actually tried it myself, by «triple-stacking» (adding a 6to4
AAAA) the dual-stack measurement point in my own brokenness experiment
(http://fud.no/ipv6). Overall brokenness increased about ten-fold, from
around 0.03% to 0.3%, so the change was reverted the next day.

In conclusion, publishing 6to4 AAAA records is a terrible idea if
you're concerned about reliability.

> The argument is that enterprise firewalls are blocking it, but that
> makes no sense because many/most enterprises are in 1918 space so 
> 6to4 will not be attempted to begin with, and for those that have
> public space internally the oft-cited systems that are domain members
> will have 6to4 off by default. To get them to turn it on would
> require the IT staff to explicitly enable it for the end systems but
> then turn around and block it at the firewall ... Not exactly a
> likely scenario.

Perhaps most enterprises are in 1918 space, but I don't the reasoning
why an enterprise that are not using 1918 space would be more likely to
use Active Directory than those that are using 1918 space. I would have
thought that the use of AD is completely orthogonal the use of 1918 space?

In any case, there's no shortage of 6to4 implementations in the wild that
will happily enable 6to4 from 1918 addresses even though it cannot
possibly work.

> The most likely source of public space for non-domain joined systems
> would be universities,

My data shows that university networks are overrepresented with broken
end-users, yes.

> but no one that is complaining about protocol 41 filtering has shown
> that the source addresses are coming from those easily identifiable
> places.

http://www.fud.no/ipv6/snapshot-20101221/gnuplot/nouninett-t10-historic.png

The red line is the overall internet brokenness I measured. The green
line is the overall brokenness for the internet *except* UNINETT, the
Norwegian University and Research Network, which filters proto-41. So
that particular network with some tens of thousands of end users are
responsible for around one-third of all failed dual-stack connection
attempts, in a country that has around five million citizens.

The sharp drop at the end is when they finally deployed native IPv6 at
certain proto-41-filtered problem spots in their network, by the way.

> That leaves the case of networks that use public addresses
> internally, but nat those at the border. This would confuse the
> client into thinking 6to4 should be viable, only to have protocol 41
> blocked by the nat. These networks do exist,

End users in such networks are likely to increase sharply in numbers,
thanks to IPv4 depletion and the inevitable deployment of CGNs using
bogon or unrouted public addresses.

> The 6rd hack is nothing more than 6to4 in a different prefix to get
> around the one-liner that should be ignored in the original RFC that
> said to only publish the /16 into IPv6 bgp. I can already hear the
> screams about routing table, but there is no difference between the
> impact of a 6rd specific announcement and a deaggregate of 2002::

Only in the case that the 2002::/16-deaggregating ISP only has *one*
IPv4 PA allocation, and that the 6RD using ISP you're comparing it to
gets a *separate* IPv6 PA allocation dedicated to 6RD end users,
something which I don't believe will be granted in the RIPE region at
least.

The only well-known deployment of 6RD (Free.fr / AS12322) currently
originate 18 IPv4 prefixes and a single IPv6 prefix. With your solution
they would need to originate 18 deaggregates of 2002::/16 instead, in
addition to their single IPv6 PA allocation for native deployments.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27