I strongly object to the proposed reclassification of these documents as
Historic.
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.)
(It could be argued that reclassification of RFC 3068 (by itself) to Historic
is appropriate, but that would require a separate document and last call.)
In addition, this document is misleading and perhaps even vituperative. For
instance:
"There would appear to be no evidence of any substantial deployment of the
variant of 6to4 described in [RFC3056]."
This statement is blatantly false. 6to4 is supported by every major desktop and
server platfrom that is shipping today, and has been supported for several
years.
"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.
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.
The fact that some firewalls block protocol 41 traffic causes problems for many
tunneling solutions, not just 6to4; yet this document appears to recommend some
tunneling solutions while trashing 6to4.
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.
This document appears to make the mistake of assuming that the purpose of
applications using IPv6 is to interoperate with the existing Internet. I have
maintained for many years that it is new applications, or existing applications
that can't tolerate widespread deployment of IPv4 NAT, that will drive use of
IPv6. I therefore believe that it is inappropriate to judge 6to4 merely by
how well it works in scenarios where it is being used to talk to applications
that work well over IPv4 NAT such as HTTP. The Internet is much more diverse
than that, and will become even more diverse as IPv6 enjoys wider deployment.
It is also premature to remove references to 6to4 from RFC 5156bis, for IANA to
mark the prefix and DNS zones as deprecated. This will only cause confusion
and difficulty for legitimate continued uses of 6to4.
Keith
On Jun 6, 2011, at 12:23 PM, The IESG wrote:
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to
Historic status'
<draft-ietf-v6ops-6to4-to-historic-04.txt> as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2011-06-20. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
Experience with the "Connection of IPv6 Domains via IPv4 Clouds
(6to4)" IPv6 transitioning mechanism has shown that the mechanism is
unsuitable for widespread deployment and use in the Internet. This
document requests that RFC3056 and the companion document "An Anycast
Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf