ietf
[Top] [All Lists]

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

2011-06-07 10:31:43
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 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.

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.

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 would think if you 
insist that 6to4 must stick around you'd prefer it to be enabled. I understand 
that there are different values of "better" but if 6to4 works, this means that 
the host is not behind a NAT, and therefore by most definitions, its IPv4 
connectivity would be better than 6to4. If it's behind an IPv4 NAT, and 
therefore IPv6 connectivity would be better (especially if there are one or 
more applications that work via IPv6 but not via IPv4 + NAT) then 6to4 won't 
work in lieu of IPv6 connectivity anyway.

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

<Prev in Thread] Current Thread [Next in Thread>