On Jun 8, 2011, at 3:28 PM, George, Wesley wrote:
From: Keith Moore [mailto:moore(_at_)network-heretics(_dot_)com]
Sent: Tuesday, June 07, 2011 6:48 PM
To: George, Wesley
Cc: ietf(_at_)ietf(_dot_)org; v6ops(_at_)ietf(_dot_)org
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt>
(Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to
Historic status) to Informational RFC
KM>I've been using 6to4 on a regular, often daily, basis since the late
1990s. 6to4 has allowed me to develop IPv6 applications and test them on
real networks, and deploy them in limited circumstances. 6to4 has also
allowed me to remotely access computers on my SOHO networks, using any
application protocol that I chose to do so, with out-of-the-box hardware and
software, without any application-specific proxies, and generally without any
application-specific configuration. None of these scenarios required a relay
router. All of them were, and continue to be, useful.
KM> Yes, I've experienced on many occasions that using 6to4 to access
dual-stack web servers doesn't always work so well. Sometimes it picks a
suboptimal path because the relay router isn't convenient. Sometimes the v6
path doesn't work at all and the application has to time out and retry using
v4. But this never really bothered me much, because my purpose in using
6to4 wasn't to try to access services that I could get to via IPv4 anyway.
And neither, I suggest, is that a reasonable metric for evaluating 6to4 or
any other IPv6 transition mechanism. The metric for evaluating an IPv6
transition mechanism should be based on its effectiveness in accessing
services that are IPv6 only.
WEG> Again, are you or are you not using a relay router? You keep going back
and forth.
No, I don't keep going back and forth. I am able to use 6to4 usefully without
a relay router. But I do have the anycast address configured as the relay
router, and I find that useful also.
Bluntly, this isn’t about whether you, or anyone else at IETF use 6to4.
Nor, bluntly, is it about a few big content providers or whomever else you want
to label as important. The internet is a hugely diverse place, and you don't
get to dismiss the concerns of people whom you want to label as red herrings.
Again, 40-something percent of the IPv6 traffic that is observed on the net
today uses 6to4. That's about as much as Teredo, it's a hell of a lot more
than native v6. As long as 6to4 is one of the major ways that people get IPv6
connectivity (and it clearly is), it's premature to declare 6to4 historic.
We are the longest of the long tail; the smallest percentage, the exception
to the rule, not the exception that proves the rule. We’re network geeks;
we’re willing to deal with dodgy connectivity or otherwise fiddly methods of
doing things to test them and to prove a point. This discussion cannot be
about whether the protocol should be preserved because some marginal
percentage of folks in IETF use 6to4 successfully.
40-something percent of the traffic is not marginal. The marginal use is,
currently, of native IPv6.
I am not disagreeing that for some value of “work” 6to4 works to reach
IPv6-only things. What I am saying is that the very things you illustrate
here make it only acceptable for testing, and not for any sort of real
substitute for IPv6 connectivity. What user is going to accept +100ms in
latency due to suboptimal relay choice, or waiting multiple seconds for IPv6
to time out because 6to4 didn’t work in that particular network setup?
100ms extra latency as compared to what? Nonexistent v6 service when they need
to use v6? Using v6 for services for which v4 will do just fine? And in
which use cases does that 100ms extra latency apply? None in the ones I'm
seeing today, on IPv6 day.
You are the one who keeps citing red herrings as evidence that 6to4 should be
deprecated. You want to take the least compelling use cases for IPv6, and when
6to4 performs suboptimally for some of those cases, use that as an excuse to
sabotage it.
I think that the evidence says that 6to4 is actually *ineffective* by the
evaluation you suggest – a good portion of the time it either utterly fails
or provides such degraded service that it may as well not work.
The evidence is that people are using it. You're trying to subject it to test
cases that are largely meaningless - because in those cases IPv6 (of any kind)
provides no marginal value in the near term.
KM> - Enterprises have applications that need to be able to communicate with
large numbers of hosts spread over a diverse area. IPv6 is clearly the way
that they want to go, but it's not widely available at present. 6to4
provides them with a means of routing traffic to their hosts in the interim
until widespread support for IPv6 exists.
WEG> So do IPv6IP or GRE tunnels. Been using one at home for 3+ years now.
And honestly, if this type of application is going to be enterprise-class, it
needs to be in conjunction with ISP deployment of IPv6, not in spite of it.
Almost all usage of IPv6 today is in spite of ISPs. For that matter, a great
many successful IPv4 applications today are deployed in spite of ISPs. Again,
ISPs in general have let us down, and 6to4 and Teredo are carrying ~90% of IPv6
traffic. ISPs are not in a good position to demand that 6to4 be deprecated.
KM> What you're saying is that applications developers shouldn't bother with
actually trying to use IPv6 until the ISPs get their act together and deploy
it. Well guess what? The ISPs have let us down. We've been waiting for 15
years for the ISPs to roll out IPv6, and for most of those 15 years they were
all telling us that there were no applications for it. Now the ISPs are
scrambling to get IPv6 into their networks, and they want to sabotage the
IPv6 mechanisms that we have in place even before they are actually offering
product.
WEG> Yes, yes, shame on the big, bad ISPs and their lack of deployment. Trust
me, I’m as annoyed with the ISPs I’ve worked for and been a customer of that
it is taking so long to get IPv6 out there too.
But…6to4 sabotaged itself. This draft is acknowledging reality that it really
didn’t work the way we’d hoped.
I have no problem with acknowledging the shortcomings of 6to4 and especially of
the use of anycast addresses for relay routers. There are valuable lessons to
be learned there. But face it, a lot of stuff that's widely deployed on the
Internet and useful doesn't work as well as we hoped. We generally don't try
to sabotage things that are useful to people.
There is no active malevolence here on the part of the ISPs. In fact many of
them (us?) have deployed or will be deploying 6to4 relays to improve the
customer experience until native service is available, and are supporting the
recommendations to make 6to4 suck less in draft-carpenter.
That's excellent news. But the current proposal on the table to deprecate 6to4
is premature, confusing, and harmful to real users.
KM>Widespread IPv6 support for native IPv6 would be when native IPv6 is
available everywhere that IPv4 access is available, from at least one
provider, with quality (connectivity, reliability, support) approximately as
good as IPv4, and at a reasonable price. In other words, you can't expect
applications to rely on native IPv6 until it's reliably available everywhere
that they need to use it.
WEG> So Widespread IPv6 has to have reliability and support equivalent to
IPv4, yet you're saying that you can expect applications to rely on 6to4 in
the meantime despite evidence that it's unreliable, and the virtual guarantee
that it won't be supported by the upstream ISP?
KM>There's no such virtual guarantee.
WEG>I should probably have clarified that by “support” I don’t mean “will
pass protocol 41 IPv4 packets.” I mean “can call and yell at someone when it
breaks.” Make more sense now?
So let's narrow the focus on relay routers that advertise anycast addresses.
I think it's clear that they're the major part of the problem with 6to4.
Maybe there is a way to filter out the advertisements for the ones that
blackhole traffic; maybe all such advertisements for those prefixes should be
filtered and 6to4 users should have to explicitly configure relay routers.
But whatever the fix, this is a fairly narrow problem and it warrants narrow
corrective action.
WEG> I am simply saying that I do not for a second believe that those same
applications that are so important to that user community are at the same
time unimportant enough that they're the sacrificial lamb that has to go
IPv6-only when the majority of that user community, no matter how small,
doesn't have native IPv6 access yet.
KM>You have absolutely no idea which applications will be important to the
user community tomorrow. Who knows what will be the next netflix, twitter,
facebook, youtube, ... ? The Internet is successful not because it supports
some small number of apps that operators think are a good idea; it's
successful because it (at least as originally architected) can support a wide
range of apps without operators having to bless them.
WEG> One of the few places I’m in agreement with you. However, it’s not a
justification for 6to4. It’s a justification for ubiquitous IPv6.
It's not one versus the other. 6to4 is helping to promote ubiquitous IPv6.
It’s not about whether the operators “bless” an application or not. If those
up-and-coming applications are saddled with the performance hit that 6to4
represents, they are unlikely to be successful. In other words, 6to4 will not
move the needle on innovative IPv6-only applications, so they’re tied to the
native IPv6 rollout schedule. Sad, but true.
There are many applications that can't be widely successful because of NATs, or
lack of addresses. IPv6 (and 6to4) offer those applications a chance to be
successful. 6to4 does not inherently represent a performance hit. In some
cases, it provides connectivity to other IPv6 hosts (whether 6to4 or native)
where no other connectivity was as easily available (and without having to
explicitly set up tunnels that also cause performance hits.) Some
connectivity to IPv6 is generally better than none. Again, if you try to
compare v6 performance to v4 performance, it will be a long time until there
are no cases where the v6 performance comes up short. Those comparisons are
meaningless, because the reason to move to 6to4 isn't to get better performance
than v6 for applications that already work fine with v4. It's to enable new
kinds of apps that don't work well in a v4 network full of NATs, and to enable
new users and new kinds of devices to be able to fully participate in the
Internet.
WEG>This is the essence of the IPv6 content vs access chicken/egg problem,
and 6to4 absolutely will not break the impasse. 6to4 breakage is the most
common thing that content providers cite as reasons why they don't just go
dual-stack. Why would an enterprise application be any different?
KM> It doesn't really matter much whether "content-providers" (as in web site
providers) go "dual stack" now. Sure, they need to be gearing up for it,
making sure that they understand it, making sure that their networks support
it. (Or maybe they'll just install v6-to-v4 proxies at their borders so that
they can keep providing good customer service in the face of LSN-induced
brain damage on the public v4 network.) But assuming their applications
work through LSN, they're going to keep supporting v4 for a long time anyway,
because that's the established base of interoperability for their products
and services. Existing "content providers" are not going to drive adoption
of IPv6. They're going to follow it. Web and email will be the last
applications to migrate. New content might appear on v6, and that might
drive adoption. But to the extent that it drives adoption, it probably won't
be from the currently established players that already have plenty of v4
addresses and infrastructure. It will be from new things that take advantage
of the niches created by IPv6 that didn't exist before.
WEG> This is a variant of the old “IPv6 Killer App” discussion. We’re still
waiting for one, largely because people are afraid of excluding some
non-trivial percentage of the populace from being able to use their new, cool
thing because it’s IPv6-only, and they don’t think it will so compelling as
to be a justification for people to find a workaround or clamor for IPv6
support.
Though I have no doubt that some such apps will eventually appear, the case for
IPv6 doesn't have to be a single killer app that's visible to everybody. The
Internet isn't only valuable because of killer apps. B2b communication (e.g.
EDI), for instance, isn't any single kind of killer app that people generally
recognize. But it's extremely valuable to society, and it's tremendously
impaired by NATs and widespread use of private IPv4 address space.
IMO, IPv4 exhaustion and CGN is the closest thing we have to a Killer App for
IPv6. If 6to4 somehow provides an incentive for folks to generate IPv6-only
applications, and for ordinary users to start using 6to4 to connect to IPv6,
I’m wondering why it hasn’t accomplished that goal in the last 10 years?What
would be different all of the sudden?
Killer apps are in the eyes of the beholders. Early adopters of IPv6 are using
it in myriad ways that are quite useful to them. If they can find uses for
v6, so can new users, and makers of new products. It's not necessary for
there to be a single killer app that requires v6 that everyone knows about, for
IPv6 to be widely useful.
KM> 6to4 is as reliable as IPv4 is, if it isn't asked to cross a relay router.
WEG> perhaps (with the exception of MTU issues that plague any tunneled
protocol), but you continue to not provide any examples of this being used
anywhere, in the face of significant evidence that 6to4 is horribly
unreliable *with* a relay. So this gets filed in the same place as my 100%
secure file server which happens to be unplugged from power and network and
encased in 10ft of concrete. Theoretically perfect, but otherwise practically
useless.
KM>What is "anywhere" to you? You seem to have a content-centric view of the
Internet. I do not. Meanwhile, you persist in saying that something that
I've used regularly for more than 10 years, to do useful work, isn't being
used anywhere.
WEG> No, I’m trying to follow the same distinction you’ve drawn between 6to4
with relays and without and understand how that’s being used, since
apparently 6to4 without relays is a lot less problematic and you’ve had such
success with it. What I’ve read is multiple people trying to explain to you
that non-anycast 6to4 (3056) is not being used, and you continuing to insist
that it’s heavily used by providing examples of 3068.
Sorry, that's a complete mischaracterization of everything I have said.
KM> I keep seeing figures that 6to4 comprises 40-some-odd percent of IPv6
traffic, while native IPv6 is around 10 percent. By your logic, native v6
should be deprecated because it doesn't work reliably and it's not being used
anywhere.
WEG> While my general view is that 40% of less than 1% of Internet traffic
amounts to a statistical anomaly, citation, please? Assuming that the source
of your statistic is able to distinguish between types of protocol 41
traffic, that 40% is almost definitely traffic that is using a relay, BTW.
You are as capable of using google as I am. And the sources I found didn't
break the 6to4 traffic down between 6to4-to-6to4 vs. 6to4-to-native (that would
definitely have been useful), but your BTW is pure speculation. My speculation
would be the opposite, but that's just based on my personal experience with
6to4.
(actually it would be nice for such stats to get a full breakdown of the
different cases: native to native, native to 6to4, native to Teredo, 6to4 to
Teredo, 6to4 to 6to4, Teredo to Teredo)
KM> The disease is the current IPv4 network with NATs and LSNs and a paucity
of address space. 6to4 is like a drug that can let some valuable v6
applications grow (even if a bit stunted) and survive until there's once
again a network that will support them. Sure, there are some side effects
and contraindications. But it's useful when used with awareness of its
limitations. You're arguing that it should be discouraged because it causes
some problems. Indeed it does. But LSN also causes problems, and is a
bigger dead-end than 6to4, and it's full steam ahead with that. At least
6to4 is designed to ease transition to a saner world, which is a lot more
than I can say for LSN.
WEG> LSN is a necessary evil brought on by the lack of ubiquitous IPv6
support, which has many causes. I don’t like it either. The thing you are
failing to realize is that IETF saying that 6to4 use is a bad idea in no way
stops consenting adults from using it in spite of the side effects and
contraindications, but it does put a much finer point on those
contraindications.
People who are using 6to4 now might need for new implementations of hardware
and operating systems to support it. This draft explicitly discourages that.
On a broader level, people have a hard time grasping what it means to
'deprecate' something or to declare it Historic even if the document goes into
a fair amount of detail about it. They tend to get the high-order bit and to
misinterpret that.
KM> I have no doubt that many of those "major content providers" are correct
when they don't see 6to4 as an acceptable substitute for them. But the
Internet doesn't exist just to support "major content providers". So stop
trying to sabotage something that works well enough for other users.
WEG> Not trying to imply that it does. I’m saying that your definition of
“works well enough” and the average user’s are widely different, making 6to4
a no-op for the average user. The content providers’ position on end users
trying to use 6to4 to reach their content is an example of that point.
The average user of what? Of IPv6 apps? I don't think content providers know
squat about the average users of IPv6 apps. And anything that compares 6to4
performance to IPv4 performance is a red herring, at least as applied to an
argument about whether 6to4 or not is justified.
WEG> Why are we having a World IPv6 Day? In part to shake loose the broken
6to4 users that may not even know that 6to4 is enabled/broken so that content
providers can be more confident that they can dual-stack their websites
without risk of significant user impact due to breakage.
KM> I'm looking forward to World IPv6 Day, and what will be learned from it.
But again, how well 6to4 works with "major content providers" is irrelevant.
WEG> I might argue that this is because 6to4 is largely irrelevant and will
become increasingly more so as major ISPs roll out IPv6 in the next 12-18
months. This is about removing barriers to deployment and use of IPv6 for the
increasing population of Native IPv6 users, not trying to buff the turd for a
tiny (but unfortunately very vocal) minority.
I'll be happy to abandon use of 6to4 when I can get native (and non-NATted)
IPv6 access anywhere I live, anywhere I work, and anywhere I travel. If that
happens in the next 12-18 months I'll be ecstatic. But I'm not holding my
breath. In 12-18 months I'll be lucky if I can get native v6 access in one of
those cases. For the others, I'll continue to need some kind of tunneling
solution, and 6to4 is often the one that works best. Deprecating 6to4 is
imposing a barrier to deployment, not removing one.
WEG>Finally, we're having problems with equipment that doesn't support IPv6
at all. 6to4 is not high on the priority list to implement compared with a
functional IPv6 stack, meaning that on new gear, it likely won't get
implemented until it's no longer necessary.
KM> Gear that doesn't support IPv6 by now is pretty odd gear. But I'm not
going to tell you not to use it. I'm just saying, if you want odd gear to
work for you in your own specific use cases, don't try to sabotage other odd
things that work for other people in their specific use cases.
WEG> No. As have multiple others, you assume that I am talking about the
usual suspects in core routing and enterprise-class networking and servers.
Where did you get that idea?
The consumer electronics space is WOEFULLY behind by comparison. That’s not
“odd” gear.
If I were to apply your criteria about what justifies use of 6to4 to such
devices, they would be odd gear.
And this isn’t about me (for some value of me) wanting that gear to work for
some corner case application. This is about me having to support millions of
customers who want that gear to work because they don’t want to buy
replacements for something that they see as working just fine today. See also
CGN = necessary evil.
Yes, it's an important problem. Good luck trying to solve it while you're
sabotaging things that work for other people.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf