On Jun 7, 2011, at 5:27 PM, George, Wesley wrote: From: Keith Moore [mailto:moore@xxxxxxxxxxxxxxxxxxxx] Sent: Tuesday, June 07, 2011 11:21 AM To: George, Wesley Cc: ietf@xxxxxxxx; v6ops@xxxxxxxxSubject: 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 WEG> Please substantiate these claims. What are the use cases, and why are there no other solutions for those specific use cases? What is considered "widespread ISP support for native IPV6"? KM>The best current use cases for 6to4 that I'm aware of are: KM>- Applications developers want to be forward thinking and develop IPv6 apps, but cannot get native IPv6 access. 6to4 allows them to develop those apps and test or use them in useful situations (i.e. outside of a lab) without having to configure a separate tunnel to every host involved. Note that 6to4 is useful in this way even if all of the addresses used are 6to4 addresses, and the traffic therefore does not cross any relays between 6to4 and native IPv6. WEG> Exactly my point. this is a valid use case, but 6to4 is by no means the only way to solve it. Application developers are welcome to set up an IPv6 network to test their apps against.
Why are you trying to make life harder for developers of IPv6 applications? There's no reason at all that an application developer should have to set up a special-purpose network just to test an IPv6 application. That doesn't require IPv6 connectivity to the outside world.
Realistic testing of applications needs to be done on real networks, or a least an approximation to real networks. Testing IPv6 using 6to4 over public IPv4 obviously isn't perfect, but it's a hell of a lot more realistic than setting up a lab network and confining one's testing to that.
If you have more than one of any modern computer on your LAN and you turn the right knobs, they can all talk to each other via IPv6 independent of any external IPv6 connectivity. You seem to want to draw this distinction between IPv6 between two hosts using 6to4 since that "works" and using 6to4 as a means to connect to the IPv6 Internet via relays, but then you conflate them by repeatedly complaining about lack of IPv6 service available from most ISPs and presenting 6to4 as a solution.
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.
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.
And sure, 6to4 is a sort of last resort for those services, except maybe for the other transition mechanisms that are worse: Teredo is often worse, configured tunnels are often worse, for all of the obvious reasons. If your ISP offers you native IPv6 access you should probably use that instead, even if internally they use 6rd or some other tunneling scheme. There's definitely benefit to having professional management and support (such as it is) for your IPv6 connectivity.
Yet, time and time again the argument gets made that 6to4 gets in the way of trying to access such services. 6to4 by itself is not the problem. The problem is address selection rules that favor v6 over v4. If the service is supported under v4, if it works fine through any NATs in the signal path, the application should probably use v4 to talk to that service. And if the service is v6-only, and 6to4 is the best way of getting there that's available, you might as well try to use it.
Further, I don't buy the "separate tunnel to every host..." thing. Tunneled IPv6 connectivity is widely available. All any developer needs to do if they can't get Native IPv6 and a tunneled application is deemed good enough for their testing purposes is connect both ends of their testing environment to their choice of tunnel broker, and through the magic of the internet, they're all connected to one another.
You seem to have this fixed idea of how applications should be tested and used, that is inconsistent with my experience. "Both" ends of their testing environment? What gives you the idea that there are only two ends? Distributed development projects are quite commonplace, and can involve hundreds or even thousands of people, each at different sites. Nor is there necessarily some sort of central network that everything connects to. Nor should there be. 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.
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.
KM> - Users (including enterprise users) who have small networks with IPv4 access (generally behind v4 NATs) can use 6to4 to allow them to remotely access individual hosts on those networks. This can be done either with a NAT that also acts as a v6 router and supports 6to4 as an external connection, or by configuring the NAT to pass protocol 41 to a IPv6 router for the network, internal to the v4 NAT.
WEG> Until CGN becomes common, in which case 6to4 doesn't work again. Also, that same NAT + v6 router combination could just as easily manage a static tunnel.
You're missing something. I can connect directly from my mobile laptop to a machine in my home network using 6to4. I didn't have to set up any static tunnel for either one. Sure, I could do that, I could get tunnels from HE or some other source and route through them. Why should I bother? Why do I want to make my IPv6 traffic take any longer a route than necessary? You've argued against 6to4 with relay routers because it's routing can be suboptimal, but the same is true of any other tunneling scheme. 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?
There's no such virtual guarantee. And you and I disagree about the definition of widespread. I do not think that widespread means "every small ISP in every corner of the world supports it ubiquitously and at every price point." I think it means "it's available for a majority (>50%) of Internet service customers."
We can disagree about the meaning of the word "widespread", but the practical fact is that you can't expect people to give up something that works for them until you can provide them something that works better for them. "Available to 50% of Internet service customers" is equivalent to a very small percent probability of native connectivity being able to replace 6to4 connectivity in a scenario where 6to4 is currently working. And the more hosts involved, the smaller that probability is. WEG> As was discussed in the WGLC for this document, enterprise applications will not realistically use 6to4 as a means to reach IPv6 for business critical applications. It's simply not reliable enough. It's also probably unlikely that those will go directly to IPv6-only vs using dual-stack to ease that transition. Individuals and Enterprises that use IPv6-only applications will need to make IPv6 service a non-negotiable requirement for their ISPs, networks, and devices rather than hoping that 6to4 works.
KM> With respect, the v6ops working group is not in a good position to judge whether enterprise applications will use 6to4. Operators rarely have a good understanding of what individual application users or developers need. They tend to focus mostly on the applications that generate the most traffic, or cause them particular amounts of trouble, or the ones that their biggest customers need. Problem is, those aren't the only applications that are important. Every application is important to its users, no matter how much or little traffic (or revenue) it generates.
WEG> I'm not going to touch the "operators don't know what they're talking about" part of your comment, except to note that it's a gross generalization that won't help your argument, and wonder how you are uniquely qualified to know better than the rest of us...
Seems to me it's the v6ops people who are making the gross generalizations. I'm mostly pointing out exceptions to those gross generalizations that have been made here and in v6ops.
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.
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. 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?
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. 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.
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. 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.
KM> And there are valid reasons to use 6to4 even where IPv4 connectivity already exists.
WEG> One would hope you wouldn't be trying to use 6to4 where IPv4 connectivity *doesn't* exist.
Right, but the point is that there are valid use cases for 6to4 even where you have IPv4 connectivity for part or even all of the network that you're using. KM>Even in cases where 6to4 traffic must cross a relay router, sometimes it's the best solution available.
WEG> Perhaps, but again, we're talking about such a small percentage of the time that the cure ends up being worse than the disease. I love orphans and lost causes as much as the next guy, but really...
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. KM>All of the criticisms in section 3 have to do with the use of relays to exchange traffic between 6to4 and native IPv6. In many cases the criticisms are overbroad. Not all uses of 6to4 involve relays. For some of those that do need to use relays, it is not necessarily the case that the relay is operated by an unknown third-party.
WEG> Again, please substantiate this with examples of implementations that are actively using non-relay 6to4. Also, the number of applications of 6to4 that can be guaranteed to avoid any unknown 3rd party relays is extremely limited due to the nature of anycast and 6to4's asymmetric routing. The protocol action requested in this draft in no way prevents one or more consenting networks from using 6to4 and continuing to run relays for their local traffic indefinitely - in fact, it even provides a reference to a document to show them how to make it work as well as possible. It is simply saying that it's not a good idea.
KM> Application implementations shouldn't care whether they're using relay 6to4, non-relay 6to4, or 6to4 at all. Application implementations should at most care that they're using IPv6 rather than IPv4, and for some applications even this is not appropriate.
Application deployments might well need to care how well their underlying networks work. Ideally, they shouldn't have to care, but that's the world we're currently living in.
WEG> First, you're hair-splitting between implementation and deployment. However you want to call it, I'm referring to "situations" where 6to4 is in use without relays and is performing reliably on a business-critical use to justify your assertion that we shouldn't toss out this part of 6to4 along with the anycast/relay part because it's still so useful.
You're attacking 6to4 on the basis of irrelevancies. As for business-critical, that's up to the business using it to determine whether it works well enough for their purposes. There are a lot of technically dubious practices used in business critical applications and networks. WEG> I agree that properly written applications are IP version-agnostic. There is only a question of whether they work through one or more layers of IPv4 NAT, or they don't. If they don't, then the solution is IPv6. If IPv6 isn't available, you have many major content providers saying that they absolutely don't see 6to4 as an acceptable substitute, meaning that your supposed application of 6to4 as a fix for this problem is so niche as to be harmful rather than helpful.
The notion that "properly written applications are IP version-agnostice" is naive and overbroad. IPv6 works differently enough from IPv4 that many applications cannot treat them the same. Simple client-server apps, perhaps, can ignore their differences, but that's just a corner case.
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. 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.
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. KM> The requested protocol action deprecates 6to4 and discourages its inclusion in future implementations. That's harmful to applications and users for whom native IPv6 isn't available - which is to say, pretty much everyone at the moment. When native IPv6 becomes widely available, it will then be appropriate to transition hosts and networks using 6to4 to native IPv6. But even then, there will probably still be a need for host implementations
WEG> Well, it'd be more harmful if there weren't alternatives.
There aren't any good ones. Teredo and configured tunnels are worse in many ways; though they each have their use cases. Also, assuming that the protocol is declared historical, we're now in a footrace between ISPs deploying IPv6 and equipment vendors removing support for 6to4 (or rolling out new products that don't support it in the first place). I think you're oversensationalizing both the impact of this draft and the lack of IPv6, given that nearly all major ISPs in the commercial space are currently offering or have a timeline to offer Native IPv6, and a large amount of the ISPs in the residential space have a timeline for deployment, many have already started trials.
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.
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.
Keith
|