v6ops WG O. Troan Internet-Draft Cisco Updates: 3056, 3068 K. Moore (if approved) Network Heretics Intended status: Standards Track J. Woodyatt Expires: February 11, 2012 Apple Inc. August 10, 2011 Connection of IPv6 Domains via IPv4 Clouds (6to4) as Last Resort draft-troan-v6ops-6to4-update-00.txt Abstract Experience with the mechanism described in "An Anycast Prefix for 6to4 Relay Routers" [RFC3068] has shown that the mechanism is not a reliable means for communicating with resources in the public IPv6 Internet. This limits the applicability of the "6to4" mechanism described in [RFC3056]. 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 February 11, 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 Troan, et al. Expires February 11, 2012 [Page 1]
Internet-Draft 6to4 as last resort August 2011 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction Experience with the mechanism described in [RFC3068] has shown that the mechanism is not a reliable means for permitting hosts using 6to4 addresses (2002::/16) to communicate with resources in the public IPv6 Internet. The particular problems are described in section 3 of [I-D.ietf-v6ops-6to4-advisory]. This limits the applicability of the "6to4" mechanism described in [RFC3056]. Without a reliable mechanism of communication between the 6to4 realm and the native IPv6 realm, 6to4 should be considered primarily as a mechanism to communicate between hosts that are both using 6to4 addresses. Use of 6to4 addresses in general and [RFC3068] in particular should be considered a "last resort" means of communicating with resources in the public IPv6 Internet. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. 6to4 as a mechanism of last resort While usage of 6to4 will decrease as native IPv6 is deployed, this will take time. In order to ensure that hosts supporting both 6to4 and IPv4 prefer more reliable connectivity mechanisms where available, this document recommends making 6to4 a service of last resort. Implementations capable of acting as 6to4 routers MUST NOT enable 6to4 without explicit user configuration. In particular, enabling IPv6 forwarding on a device, MUST NOT automatically enable 6to4. When performing address selection, connections between an IPv4 source and destination address SHOULD be preferred to connections either between a 6to4 source address and a native v6 destination address, or between a native v6 source address and a 6to4 destination address. Troan, et al. Expires February 11, 2012 [Page 2]
Internet-Draft 6to4 as last resort August 2011 4. IANA Considerations This document makes no recommendation to IANA. 5. Security Considerations There are no new security considerations pertaining to this document. General security issues with tunnels are listed in [I-D.ietf-v6ops-tunnel-security-concerns] and more specifically to 6to4 in [RFC3964] and [I-D.ietf-v6ops-tunnel-loops]. 6. Acknowledgements The authors would like to acknowledge Fred Baker, Ron Bonica, Stewart Bryant, Geoff Huston, Brian Carpenter, Lorenzo Colitti, Pete Resnick, and Erik Kline for their significant contributions. Many thanks to Gunter Van de Velde for documenting the harm caused by non-managed tunnels and to stimulate the creation of this document. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. 7.2. Informative References [I-D.ietf-v6ops-6to4-advisory] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", draft-ietf-v6ops-6to4-advisory-02 (work in progress), June 2011. [I-D.ietf-v6ops-tunnel-loops] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in progress), May 2011. Troan, et al. Expires February 11, 2012 [Page 3]
Internet-Draft 6to4 as last resort August 2011 [I-D.ietf-v6ops-tunnel-security-concerns] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns With IP Tunneling", draft-ietf-v6ops-tunnel-security-concerns-04 (work in progress), October 2010. [RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004. Authors' Addresses Ole Troan Cisco Oslo, Norway Email: ot@cisco.com Keith Moore Network Heretics Email: moore@network-heretics.com James Woodyatt Apple Inc. 1 Infinite Loop Cupertino, CA 95014 US Email: jhw@apple.com Troan, et al. Expires February 11, 2012 [Page 4]