* 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