|
From: Keith Moore [mailto:moore@xxxxxxxxxxxxxxxxxxxx]
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. 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. 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?
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. 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf