On Jun 7, 2011, at 10:39 AM, George, Wesley wrote:
At the risk of rehashing discussion from WGLC...
Ole has addressed some of your points, I'll address a few others below inline.
From: v6ops-bounces(_at_)ietf(_dot_)org
[mailto:v6ops-bounces(_at_)ietf(_dot_)org] On Behalf Of Keith Moore
Sent: Monday, June 06, 2011 1:22 PM
To: ietf(_at_)ietf(_dot_)org
Cc: v6ops(_at_)ietf(_dot_)org; IETF-Announce
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
6to4 still has many valid use cases, and there is not a suitable replacement
for it that has been deployed. Until there is a suitable replacement, or
until there is widespread ISP support for native IPv6, reclassification of
this document to Historic is premature. (6rd is not a suitable replacement
for 6to4, as it is intended for very different use cases than 6to4.)
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"?
The best current use cases for 6to4 that I'm aware of are:
- 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.
- 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.
- 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.
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.
"The IETF sees no evolutionary future for the mechanism and it is not
recommended to include this mechanism in new implementations."
6to4 never was intended to have an "evolutionary future". It was always
intended as a near-term solution to allow consenting hosts and networks to
interchange IPv6 traffic without prior support from the IPv4 networks that
carry the traffic. It is premature to recommend that 6to4 be removed from
implementations. We do not know how long it will take ISPs to universally
deploy IPv6. Until they do, there will be a need for individuals and
enterprises using IPv6-based applications to be able to exchange IPv6 traffic
with hosts that only have IPv4 connectivity.
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.
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.
6to4 is as reliable as IPv4 is, if it isn't asked to cross a relay router. And
there are valid reasons to use 6to4 even where IPv4 connectivity already exists.
Even in cases where 6to4 traffic must cross a relay router, sometimes it's the
best solution available.
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.
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.
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
The recommendations to treat 6to4 as a service of last resort will do harm to
users and applications using it. A better recommendation is for hosts to
disable 6to4 by default.
WEG> this seems to be to be splitting hairs. Please explain the distinction
you're making here. Disable by default means never use. Use as last resort
means use when no better IP connectivity is available.
I was interpreting "treat 6to4 as a service of last resort" as affecting the
address and interface selection algorithm. If 6to4 is enabled on a host or
network, there are reasons to use 6to4 in preference to some other kinds of
connectivity. The question of whether to enable 6to4 should be separate from
the question of "if 6to4 is enabled, what priority should it have in address
selection?"
Keith
p.s. I'd support the writing of an applicability statement for 6to4 that
recommends a narrowing of its applicability to specific use cases, and I'm even
willing to help write it. But moving it to Historic is going too far, and it
sends the wrong message. We need for 6to4 in our toolbox to enable
enterprises and applications developers to be able to write and (tentatively,
carefully) deploy applications that use IPv6. We can't afford to wait until
all ISPs support native v6 for people to start writing applications that use
it.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf