On Jul 18, 2011, at 3:36 AM, Roger Jørgensen wrote:
It must be re-iterated that the vast majority of problems associated with 6to4 appear to be caused by operators, not by 6to4 itself. 6to4 does have some real problems, and some of us are looking for ways to fix them. But that's no excuse for operators to deliberately make things worse.
Part of the problem seems to be that operators want a quick solution that is under their control, when it appears that no such solution can exist. - Changes to the default address selection rules, already implemented or being implemented, should help significantly, but it will take some time for hosts to get updated to reflect those changes. (Asking Microsoft, Apple, and Linux vendors to include those changes in incremental updates - if they haven't already done so - might help speed that process along.) - The changes in -advisory will help somewhat, but it will take time for operators and vendors to learn about them and implement them, and the effect will be gradual. - The changes in -experimental will also help somewhat, if those changes are published in some form, but the effect will also be gradual. - Improvements to the 6to4 protocol (especially where relay routers are concerned) might help, but again will require updates to hosts and/or routers. (it's conceivable that fixes could be implemented in hosts that don't require the routers to be upgrade in order for those changes to be helpful) - As I said yesterday, there are ways that content providers can use IPv6 to distribute content to their customers over HTTP, as well as monitor the percentage of their users that are IPv6 capable, though they're a tad trickier than simply adding AAAA records to the DNS and turning on v6 in their servers. All of the above can help. However, - Yelling "6to4 is Evil" as loudly as possible, e.g. declaring it Historic and publishing -historic, - Filtering protocol 41 packets, - Blocking 2002::/16 traffic or routing advertisements, or - Blocking 192.88.99.0/24 traffic or routing advertisements, will all make the situation worse for users, operators, and content providers. Keith |
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf