On Jun 7, 2011, at 5:27 PM, George, Wesley wrote:
From: Keith Moore [mailto:moore(_at_)network-heretics(_dot_)com]
Sent: Tuesday, June 07, 2011 11:21 AM
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
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf