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

[Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>]

On Jun 8, 2011, at 3:28 PM, George, Wesley wrote:

 

From: Keith Moore [mailto:moore@xxxxxxxxxxxxxxxxxxxx] 
Sent: Tuesday, June 07, 2011 6:48 PM
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

 

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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf