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.
Bluntly, this isn't about whether you, or anyone else at IETF use 6to4. 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. 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? 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.
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.
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. 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.
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?
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
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.
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.
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?
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.
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.
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.
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.
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.
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. The
consumer electronics space is WOEFULLY behind by comparison. That's not "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.
Wes George
________________________________
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the sender
immediately and permanently delete the original and any copy of this E-mail and
any printout.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf