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. 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf