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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf