Keith, I'm loathe to go through this discussion again. let me just respond to some of the points you make, and then agree that we disagree. > 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. incorrect. there is no evidence that the _managed_ model of 6to4 described in rfc3056 has any deployment. that's the model where relay operators advertise what parts of the 6to4 space they are routing. with BGP neighborships between managed and participating relays. _deployment_ not _support_. > "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. it is the unmanaged aspect of 6to4 deployment that exhibits the most problems. a manually configured managed point to point tunnel may also be blocked in a firewall, but then the operator will have to sort that out. 6to4 has no operator. Teredo is similar in many aspects to 6to4, but there is little evidence that it causes the same problems. largely because it is the choice of last resort in implementations and it hasn't/can't be enabled by default in CPEs. > 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. 6to4 does not work through IPv4 NATs. > 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. the purpose of the text in the document is to ensure that the deprecated prefixes are not reused before 6to4 has been phased out. cheers, Ole _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf