ietf
[Top] [All Lists]

Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

2011-07-05 10:08:25
On Sun, Jul 3, 2011 at 5:05 AM, Noel Chiappa 
<jnc(_at_)mercury(_dot_)lcs(_dot_)mit(_dot_)edu>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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf