Re: Another look at 6to4 (and other IPv6 transition issues)

[Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>]

On Jul 17, 2011, at 12:59 AM, Doug Barton wrote:

But, while some people have argued that 6to4 has caused so much

damage by being misconfigured that it should, presumably as

punishment or to create a public example, be eliminated entirely

as an option

My perspective, which I've described at length many times now, is not
that 6to4 needs to be punished, but that the widespread deployment of
IPv6 is being harmed as a result of the negative user experience that it
creates for the majority of its users (particularly the unintentional
ones) and therefore the network as a whole is better off if it goes away.

It doesn't follow.

Nor would declaring 6to4 Historic (or any other label) have that effect.   It could easily make things worse for both users and content providers, by giving people the mistaken impression that "remedial" actions like filtering protocol 41 or advertisements for 6to4 relay routers are good ideas.   

The fixes for unintentional users of 6to4 are already in the pipeline.  Everybody agrees that the default address selection preferences should be changed to prefer native IPv4 over 6to4, and host platforms (including FreeBSD I assume) have already changed these preferences or are in the process of doing so.    Most platforms have ways of pushing urgent updates to their users, and IMO this change in the address selection preference list should qualify for such updates.   (As for the users who don't make use of that feature and/or turn automatic updating off, declaring 6to4 Historic would not make them more likely to use such updates.)

To summarize my main points once again (since you seem determined to
reopen the debate on 6to4's utility):

1. There is next to zero IPv6-only content at this time.
2. Therefore the number of people who actually *need* IPv6 is so close
to zero as to not be a factor.

#2 does not follow from #1, for various reasons.   One reason is that the Internet is highly diverse, and people use it for many other things than to download "content" from "content providers".

3. Of the tiny number of people that actually do need IPv6, there are
plenty of other tunnel options.

...which are often worse than 6to4, for some meaning of "worse" (more overhead, longer delay, greater likelihood of path congestion, single point of failure, reduced probability of getting a connection established).

4. By the time that there *is* IPv6-only content the market will have
sorted out access for the average user.

The market hasn't sorted out IPv6 access in the past 15+ years, mostly because of the lack of any new v6-only applications or usage scenarios that would drive IPv6 deployment.   Under current conditions, there is zero incentive to produce IPv6-only content because would block 99.99% of the potential market for said content.   HTTP and SMTP will be the last protocols to migrate to IPv6, not the first ones.   Prior to widespread deployment of IPv6 access, any use of HTTP-over-IPv6 to serve content to the public, or SMTP-over-IPv6 to exchange mail between arbitrary administrative mail domains, is either a proof-of-concept or a publicity stunt.  

So the idea of waiting until there is IPv6-only content to drive the market to provide IPv6 access for the average user, is a nonstarter.

Thus, 6to4 hurts way more than it helps at this point.

It doesn't follow even if one accepts the premise of #4 (which is not a reasonable premise).

And again, nobody disputes that unintentional use of 6to4 is harmful.  But that fix is already in the pipeline, via much more effective means than any label that could be put on 6to4.

Furthermore you have the huge problem that neither end of the 6to4
equation has *any* motivation to fix it. The ISP side can simply block
tunnels (or even simpler, ignore the problem). The content side can
simply not deploy AAAA records.

Blocking tunnels makes the situation worse both for users (who will experience even more connection failures) and for operators (who will experience even more support calls).   We need to get that message out as loudly and as clearly as possible.

As for content providers, there are lots of ways for them to provide content over HTTP-over-IPv6 without exposing that content to 6to4 users, or (better) without exposing that content to users with poor IPv6 connections.   

One way is this: make the initial connection - the advertised URL - use a domain name which only has A records.  This is safe to do because for the foreseeable future, everybody will have some kind of IPv4 HTTP access.   Have the initial connection provide referrals to the "real" content using one of two different domain names, based on whether the source address is within 2002::/16: ipv4.example.com only returns A records, ipv6.example.com returns both AAAA and A records.  A lot of content is using referrals for various reasons anyway, so it might be possible to do this without any additional overhead.  Offhand this seems a lot more reliable than playing games with DNS.

Another, perhaps better, way:   Again, have the advertised URL use a domain name that only has A records.   Have the main page set a cookie, the value of which is based on a timestamp.   Also have the initial page load a one-pixel image via a URL with a domain that only has IPv6 addresses.  This image sets its own cookie, also based on a timestamp.   If the server gets a request with the v4 cookie's timestamp much earlier than the v6 cookie's timestamp, or if the v6 cookie is missing, make all links and referrals use only A records.  If the v4 and v6 cookies are both present and have similar timestamps, the links and referrals can have AAAA records.

Of course both of the above depend on using different URL domains depending on whether the content provider wants to provide v4-only or dual-stack service to the client.  The content provider might prefer to use the same domain in both cases and play games with DNS based on the requester address.  (which causes a different set of issues).  

But at least with the web, it seems like enough tools are there to let content providers serve content via v6 when it works well, and minimize use of v6 for those users for whom it doesn't work well, as well as to keep track of how often v6 is working for their users.  Admittedly, it's a bit more work than just adding AAAA records to existing DNS names and enabling v6 on the servers.    

I do think that the -advice document is a good thing, and for those that
care I think it's great that the IETF is going to help them out. But all
statements of the form "all we need to do to fix 6to4 is X" are
non-starters because the people with the ability to actually fix it are
not going to.

Speculation.    

How can we expect people to have "fixed" 6to4 without their being clear recommendations for how to do that?   Arguably, a lot of the problems that we're seeing with 6to4 are the results of poorly chosen "fixes" (like protocol 41 filtering) that actually exacerbate the problem.

(For that matter, how do you know that people aren't slowly discovering how to "fix" 6to4, and doing it?   I assure you, 6to4 works better now than it did 10 years ago.  It's reasonable to believe that the measures in -advisory will also help the situation.)

-- for FreeBSD users, the exact effect of your removing the code --

To be clear, I didn't say that we *will* remove it, only that making it
historic gives us that opportunity at some point down the road *if* that
becomes appropriate.

The FreeBSD developers can do whatever they like with their code.   They don't need for IETF to declare it anything.  If they want to remove 6to4 support, they can do so and deal with the criticism and/or praise from their users.   

Hopefully, "at some point down the road", presumably when native IPv6 is widely available, it will make sense to declare 6to4 Historic, and we'll all celebrate when that happens.  

If the thing is still useful, even in limited circumstances and

used correctly, then the IETF should not provide you with

"cover" to remove the code because it is not in the best

interest of the community for you to remove the code.   Might

both your removing the code and moving 6to4 to Historic in the

future be appropriate?  Sure.  I also look forward to the day

when we can move IPv4 to Historic (just as the various

specifications that make up NCP should have been moved years ago

if we paid attention to that sort of housekeeping).

So the debate is on the timing. I (and others) think that the time is
now. My opinion is that there is also a pretty strong community
consensus that the time is now, modulo a very vocal group of people who
do not. But fortunately I'm not the one who has to make the decision
about what there is and is not consensus for. :)

From my perspective, the "very vocal group of people" is in v6ops, which is heavily biased toward the operator's viewpoint, and against the user's and application developer's viewpoint.  They haven't even tried to get community consensus on this.

But I don't recall seeing the sort of venom

that is directed toward 6to4 being focused on them.  Perhaps

there weren't enough complaints or you have solid data that 6to4

has caused even more damage.

Once again repeating myself ... I have no venom towards 6to4. This isn't
a personal attack. And yes, various people and organizations that have
vested interests in seeing IPv6 deployed have posted the data about why
6to4 causes way more problems than it solves, and I believe them.

They've posted data about why unintentional use of 6to4 causes more problems than it solves.  And that's being fixed.

Keith

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf