Network Working Group K. Moore Internet-Draft Network Heretics Intended status: Informational July 5, 2011 Expires: January 6, 2012 Reclassification of 6to4 as an Experimental Protocol draft-moore-6to4-experimental-00 Abstract This memo explains why the 6to4 specifications are being reclassified as Experimental protocols. It also makes recommendations for limiting the scope of continued use of 6to4 for those wishing to use it. These recommendations are being made in light of decreasing applicability of 6to4 and of operational problems associated with its use. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 6, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Moore Expires January 6, 2012 [Page 1] Internet-Draft 6to4 to Experimental July 2011 described in the Simplified BSD License. Moore Expires January 6, 2012 [Page 2] Internet-Draft 6to4 to Experimental July 2011 1. NOTE IN DRAFT This document was written to accompany a proposal, submitted to IESG, to reclassify the 6to4 RFCs as Experimental. While IETF procedures do not require an RFC to be published when reclassifying an existing RFC, this has often been done in the past in order to provide a visible explanation for the reasons for the reclassification and/or to provide increased visibility for the reclassification. While the reclassification of 6to4 is a standards action, the intended status of this document is Informational, or perhaps BCP. (Recommendations to discourage accidental use of 6to4 are presumed to have more weight if classified as BCP, and it's the author's understanding that some members of the community wish to have IETF produce weighty recommendations to that effect.) The decision to reclassify 6to4 as Experimental, and the decision to approve this document for publication, should be treated as separate decisions by the IETF, since endorsement of the decision to reclassify should not automatically be taken as an endorsement of this document. However it makes no sense to publish this document if the standards action is not approved. The author's intention in writing this document is to provide a noncontroversial public justification for removing 6to4 from the standards track, while still leaving open the possibility for experience with 6to4 to inform the design of a better general-purpose means of allowing IPv6 to be accessed from IPv4 networks. This document is not a work item of any IETF working group. Comments on this draft should be sent to the author. Moore Expires January 6, 2012 [Page 3] Internet-Draft 6to4 to Experimental July 2011 2. Introduction This memo explains why the 6to4 specifications ([RFC3056], [RFC3068]) are being reclassified as Experimental protocols. 6to4 was intended to be a general-purpose means by which small networks or individual hosts with only IPv4 access could exchange IPv6 traffic with each other, and with hosts on the public IPv6 Internet. However, 6to4 relies on direct access to the public Internet, using public address space, for two reasons: (1) it derives an IPv6 prefix from the public IPv4 address; and (2) it uses IP protocol 41, which is not compatible with most NATs. The already common and increasing use of NAT following the introduction of 6to4 has always meant that 6to4 had less applicability than was hoped for, but until now most uses of those NATs have been in enterprise networks which could implement 6to4 at their borders if they chose. The recent exhaustion of IPv4 address space means that Internet service providers must increasingly impose NAT between their customers and the public Internet, or at least, that public IPv4 addresses will become harder to come by and more expensive. The already-narrow applicability of 6to4 can thus be expected to narrow considerably in the near future. Worse, the widespread use of RFC 1918 [RFC1918] address blocks in private networks means that ISPs often cannot assign such addresses to their customers without conflicting with their customers' existing use of those addresses. Many 6to4 implementations do not enable 6to4 for any interface that has an RFC 1918 address, but such implementations have no way of knowing if they were assigned an address from public IPv4 space, that is not actually routed to from the public Internet. All attempts to use 6to4 in such circumstances will fail silently. Several operational problems have been associated with 6to4, which have caused an increased support burden for Internet service providers, network operators, and other support personnel. In practice, 6to4 has not been sufficiently reliable to be a general- purpose means of providing IPv6 service to hosts with only IPv4 connectivity; and performance sometimes been significantly worse than IPv4, particularly when exchanging traffic between "native" IPv6 and 6to4 addresses. Content providers have also complained about host implementations that choose 6to4 addresses over native IPv4 addresses, per the recommendations in [RFC3484], resulting in worse reliability and/or diminished performance. A more detailed discussion of these problems, along with recommendations for addressing some of them, is in [draft-ietf-v6ops-6to4-advisory]. (Note that there is work in progress to update the address selection Moore Expires January 6, 2012 [Page 4] Internet-Draft 6to4 to Experimental July 2011 recommendations [draft-ietf-6man-rfc3484-revise], and some implementations already prefer native IPv4 over 6to4.) It appears possible to improve the reliability of 6to4 somewhat, for the benefit of hosts and networks for which it remains useful. However, the narrowing applicability of 6to4 implies that there is clearly a point of diminishing returns. Due to the nature of routing between 6to4 and native IPv6, there is often little that a service provider can do to improve its customer's 6to4 service. Internet service providers with IPv6 implementations underway, are understandably more interested in investing in efforts to deploy native IPv6, than in supporting an unreliable transition mechanism with inherently narrowing applicability. For these reasons, it is clear that 6to4 no longer meets the requirements of the Proposed Standard classification as defined in RFC 2026. Nor does it appear to be possible to remedy these problems without changes that would make the result incompatible with existing 6to4 implementations. The Experimental classification is appropriate for a limited-use protocol that provides the opportunity for research or development. Moore Expires January 6, 2012 [Page 5] Internet-Draft 6to4 to Experimental July 2011 3. Recommendations For Continued Use Of 6to4 o It is strongly recommended that all host and router implementations which support 6to4, disable it by default, and require explicit action to enable it o New host and router implementations may implement support for 6to4, but vendors should take into account the decreasing applicability of 6to4 along with support issues, and make decisions accordingly. o For a host implementing "host 6to4", or a router implementing 6to4 for the purpose of providing v6 service to an IPv4-only enterprise network: The host or router must have direct access to the public IPv4 internet, using public IPv4 address space that is exclusively delegated to and routed to that host or router, with the ability to exchange unfiltered IPv4 packets with protocol 41 with other host or routers on the public IPv4 Internet. o For a relay router routing 6to4 traffic between the public IPv6 Internet and the public IPv4 Internet: The router must not be configured to advertise connectivity to either 2002::/16 or 192.88.99.0/24 without: A. being able to route all traffic with destinations within 2002::/16 or native IPv6 (respectively) consistent with that advertisement, to all hosts affected by the route advertisement (subject to normal filtering of bogus packets); B. being adequately provisioned to handle all of the reasonably expected traffic generated by the hosts affected by that route advertisement; C. being monitored to ensure continued reachability to the entirety of the advertised network(s) (modulo occasional distant network outages); and D. immediately ceasing such advertisement when such connectivity is interrupted, until such time as it is restored. o Any host using both 6to4 addresses and native IPv4, regardless of whether it supports 6to4 directly, should prefer IPv4 over 6to4 destination addresses when both are advertised for the same destination, unless the application explicitly selects the 6to4 destination, or the application explicitly selects IPv6 and 6to4 is the best IPv6 address available for that destination. Moore Expires January 6, 2012 [Page 6] Internet-Draft 6to4 to Experimental July 2011 o Any host with both a 6to4 address and a native, public IPv6 address, regardless of whether it supports 6to4 directly, should prefer native IPv6 destination addresses over 6to4 destination addresses. o Techniques similar to those described in [draft-ietf-v6ops-happy-eyeballs] may be appropriate for some applications (including applications other than HTTP) when presented with the ability to send traffic over multiple network interfaces, including cases when one or more of those interfaces is assigned a 6to4 address. This will minimize the delay in recovery or fault detection when an attempt to use a 6to4 address fails. o Any critical application (e.g. enterprise application) deployment using 6to4 should use explicitly provisioned relay routers to provide any required connectivity between 6to4 addresses and native IPv6 addresses. o It is also recommended that host and router implementations make clear to their users, in a method appropriate to the implementation (e.g. user interface, documentation, notices to customers), that 6to4 is only applicable and likely to work well under fairly narrow conditions, such as those described above. Moore Expires January 6, 2012 [Page 7] Internet-Draft 6to4 to Experimental July 2011 4. 6to4 as an Experiment It is believed that experience with the use of 6to4 can provide useful insight into the design and operation of new network protocols, including potentially: o better mechanisms to allow hosts on IPv4 networks to exchange traffic with the public IPv6 Internet; o a better understanding of the limitations and hazards associated with using anycast addresses to advertise services in the public Internet, particularly when those services are provided by multiple parties; o sudden, widespread deployment and use of new types of services in the public Internet, when those services have significantly different communications patterns than existing services, and especially when those services are used without users and network administrators being explicitly made aware of their use and the consequences thereof, o design of network services in such a way that error conditions are detectable and/or correctable by those who are most affected by such errors, and who presumably have the most incentive to fix them. Measurement of existing and future use of 6to4 with the intent of gaining a greater understanding of any result of such use, is encouraged. Moore Expires January 6, 2012 [Page 8] Internet-Draft 6to4 to Experimental July 2011 5. Security Considerations It appears that this memo introduces no new security vulnerabilities. Moore Expires January 6, 2012 [Page 9] Internet-Draft 6to4 to Experimental July 2011 6. References [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. Moore Expires January 6, 2012 [Page 10] Internet-Draft 6to4 to Experimental July 2011 Author's Address Keith Moore Network Heretics Email: moore@network-heretics.com Moore Expires January 6, 2012 [Page 11]