One document matched: draft-troan-v6ops-6to4-update-00.txt

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]