Nothing to say here that Keith hasn't already said in so many fine words. In summary:
+-1. Heck, no, -1000. I especially dislike the registry changes; those are deeply, *deeply* irresponsible. On 6 Jun 2011, at 18:22, Keith Moore wrote: > 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@ietf.org mailing lists by 2011-06-20. Exceptionally, comments may be >> sent to i...@ietf.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 mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
