On Sun, Jul 3, 2011 at 5:05 AM, Noel Chiappa <jnc@xxxxxxxxxxxxxxxxxxx> wrote:
I think there is pretty much complete consensus that i) 6to4 doesn't work
in several very common environments (behind a NAT, etc, etc), and that
therefore, ii) at the very least, it should be disabled by default (and
therefore only turned on by knowledgeable users who know they are not in
one of those situations).
Given and assuming a document that makes all that formal, _what else_ does
the _additional_ step of making 6to4 historic buy?
Compared to the alternative of publishing 6to4-historic now, it:
a) Delays the time of any statement made by the IETF on the question by at least a number of months, while vendors and home gateways are *still shipping* products that implement 6to4 and enable it by default. I have personally seen this in beta home gateway products with "new IPv6 firmware" that aren't even released yet.
b) Even assuming it were to gain consensus in any sort of reasonable timescale, it would provide a less clear statement, and thus be less of an incentive for implementors such as home gateway manufacturers to do the right thing and remove it. We have heard in the working group from real implementors like Apple, who have said that even 6to4-historic may not go far enough for them to justify actions such as removing support from their products. We have heard, also, that when implementors such as home gateway manufacturers are asked to remove 6to4 or disable it because it harms user experience, they say that they don't see why they should do work to remove a feature, in the absence of any guidance from the IETF.
Time is important, because over time, 6to4's reliability will get worse, not better, as ISPs do things like use bogon IPv4 space plus carrier-grade NAT for their users, because implementations will think they have public IPv4 addresses and thus turn on 6to4 (which will never work, because it's behind a NAT).
Or perhaps the concept is that nuking 6to4 will help force ISPs to deploy
native IPv6, since it removes one way for users to get IPv6 if their
provider doesn't supply it? If so, why not ditch Teredo, too? (Not to
mention that 'mandate it and they will come' hasn't worked to well so far.)
Normal users will not get IPv6 unless their ISP gives it to them. Period, end of story. I think it's clear by now that the vast majority of users don't know what IPv6 is, and that they do not ask for it. For a normal user, having 6to4 is more a liability than an asset. Normal users don't rely on 6to4 to give them IPv6 connectivity, because they don't use or need IPv6; everything they do today can be done with higher performance and higher reliability using IPv4 and NAT traversal. However, if they get it "for free" in the form of 6to4, then far from gaining a benefit (reliable IPv6 connectivity), they get something that only works 80% of the time, and 20% of the time breaks dual-stack websites.
By "users" I explicitly do not include the tiny percentage of users on this list who are technical enough to know that 6to4 exists and rely on it to get IPv6 connectivity. Compared to the overwhelming number of users who have no idea what IPv6 even is, they are so far away from the mainstream that they don't matter at all, and they are knowledgeable enough to deploy other solutions, such as managed tunnels, which in my experience are typically lower latency and higher reliability (pretty much everything is higher reliability than a 20% failure rate).
The only way you can incentivize ISPs to deploy IPv6 is to provide IPv6 content that they can use to justify the investment (for example, reduce the load on the NATs that they will be deploying). ISPs have been saying for years, and are still saying, that one of the reasons tha they are not deploying IPv6 because there is no point, since so little content is available over IPv6. Now we are hearing clearly from content providers that they *do not want* 6to4, because its 80% failure rate is a concern for them, and that in fact, its existence is one of the major barriers to lack of adoption on the part of content providers.
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf