From: Keith Moore [mailto:moore@xxxxxxxxxxxxxxxxxxxx] Sent: Tuesday, June 07, 2011 11:21 AM To: George, Wesley Cc: ietf@xxxxxxxx; v6ops@xxxxxxxx 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 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. That doesn't require IPv6 connectivity to the outside world. 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. 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. 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> - 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. 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? 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." 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... 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. 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> 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> 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. 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... 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. 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. 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> 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. 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. 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