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

From: [email-masked] (Noel Chiappa)
Date: Sat, 2 Jul 2011 23:05:48 -0400 (EDT)

> From: Cameron Byrne <[email-masked]>

    > It is a shame that work that directly removes barriers to REAL ipv6
    > deployment gets shouted down

So, perhaps you can explain something to me, since nobody else has been
able to.

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?

Are you thinking that people will see this knob called '6to4' and turn it
on, and cause support issues? This seems unlikely to me - e.g. they don't
seem to commonly turn off DHCP on their NAT boxes (a switch most NAT boxes
seem to provide).

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.)

In short, I just cannot fathom what concrete benefit the _additional_ step
of marking the protocol 'historic' provides, _over and above_ just issuing
the 'do not enable 6to4 automatically because it has problems' document.

Can you point to such a benefit?

	Noel

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 02:14:46 -0400

On Jul 3, 2011, at 1:23 AM, Lorenzo Colitti wrote:

> 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.

No, but they do want their applications to work well.  That's constantly getting more difficult in IPv4.   The workarounds for NATs and other forms of brain damage in the network keep changing, and each application requires not only its own code but also its own infrastructure to deal with that brain damage.     So a solution that allows applications to use IPv6 whether or not all of the networks between the peers support native v6, is very badly needed.  We can't wait for ISPs to give everybody IPv6 before applications start using it.

And I agree that most users don't know what IPv6 is, at the moment.  But if they learn that it will help their apps work better, they'll want it. 

(I also remember when most people didn't know what the Internet was.  And then, almost in an instant, everybody knew, and a cartoon in the New Yorker magazine about the internet and a dog was something everybody could understand.  Users will understand IPv6 also, soon enough.)

Keith

p.s. I often wear a t-shirt that says "there's no place like ::1".  Non-computer people ask me what it means, and in response, I tell them it's the address of their own machine in IPv6.   So far, nobody has asked me what IPv6 means.   Everyone who has asked me about the shirt has heard of IPv6 and understood at some level that it's the next version of the Internet.  If anything, there seems to be a disconnect between what "ordinary users" know about IPv6 and what their ISPs are telling them - because for the most part, the ISPs seem to keep publicly pretending that it doesn't exist.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 3 Jul 2011 07:23:03 +0200

> 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).

> 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.