idnits 2.17.1 draft-troan-v6ops-6to4-update-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3068], [RFC3056]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC3056, but the abstract doesn't seem to directly say this. It does mention RFC3056 though, so this could be OK. -- The draft header indicates that this document updates RFC3068, but the abstract doesn't seem to directly say this. It does mention RFC3068 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3056, updated by this document, for RFC5378 checks: 1999-01-25) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 10, 2011) is 4642 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3068 (Obsoleted by RFC 7526) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops WG O. Troan 3 Internet-Draft Cisco 4 Updates: 3056, 3068 K. Moore 5 (if approved) Network Heretics 6 Intended status: Standards Track J. Woodyatt 7 Expires: February 11, 2012 Apple Inc. 8 August 10, 2011 10 Connection of IPv6 Domains via IPv4 Clouds (6to4) as Last Resort 11 draft-troan-v6ops-6to4-update-00.txt 13 Abstract 15 Experience with the mechanism described in "An Anycast Prefix for 16 6to4 Relay Routers" [RFC3068] has shown that the mechanism is not a 17 reliable means for communicating with resources in the public IPv6 18 Internet. This limits the applicability of the "6to4" mechanism 19 described in [RFC3056]. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 11, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 Experience with the mechanism described in [RFC3068] has shown that 56 the mechanism is not a reliable means for permitting hosts using 6to4 57 addresses (2002::/16) to communicate with resources in the public 58 IPv6 Internet. 60 The particular problems are described in section 3 of 61 [I-D.ietf-v6ops-6to4-advisory]. 63 This limits the applicability of the "6to4" mechanism described in 64 [RFC3056]. Without a reliable mechanism of communication between the 65 6to4 realm and the native IPv6 realm, 6to4 should be considered 66 primarily as a mechanism to communicate between hosts that are both 67 using 6to4 addresses. Use of 6to4 addresses in general and [RFC3068] 68 in particular should be considered a "last resort" means of 69 communicating with resources in the public IPv6 Internet. 71 2. Conventions 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [RFC2119]. 77 3. 6to4 as a mechanism of last resort 79 While usage of 6to4 will decrease as native IPv6 is deployed, this 80 will take time. In order to ensure that hosts supporting both 6to4 81 and IPv4 prefer more reliable connectivity mechanisms where 82 available, this document recommends making 6to4 a service of last 83 resort. 85 Implementations capable of acting as 6to4 routers MUST NOT enable 86 6to4 without explicit user configuration. In particular, enabling 87 IPv6 forwarding on a device, MUST NOT automatically enable 6to4. 89 When performing address selection, connections between an IPv4 source 90 and destination address SHOULD be preferred to connections either 91 between a 6to4 source address and a native v6 destination address, or 92 between a native v6 source address and a 6to4 destination address. 94 4. IANA Considerations 96 This document makes no recommendation to IANA. 98 5. Security Considerations 100 There are no new security considerations pertaining to this document. 101 General security issues with tunnels are listed in 102 [I-D.ietf-v6ops-tunnel-security-concerns] and more specifically to 103 6to4 in [RFC3964] and [I-D.ietf-v6ops-tunnel-loops]. 105 6. Acknowledgements 107 The authors would like to acknowledge Fred Baker, Ron Bonica, Stewart 108 Bryant, Geoff Huston, Brian Carpenter, Lorenzo Colitti, Pete Resnick, 109 and Erik Kline for their significant contributions. 111 Many thanks to Gunter Van de Velde for documenting the harm caused by 112 non-managed tunnels and to stimulate the creation of this document. 114 7. References 116 7.1. Normative References 118 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 119 Requirement Levels", BCP 14, RFC 2119, March 1997. 121 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 122 via IPv4 Clouds", RFC 3056, February 2001. 124 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 125 RFC 3068, June 2001. 127 7.2. Informative References 129 [I-D.ietf-v6ops-6to4-advisory] 130 Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 131 draft-ietf-v6ops-6to4-advisory-02 (work in progress), 132 June 2011. 134 [I-D.ietf-v6ops-tunnel-loops] 135 Nakibly, G. and F. Templin, "Routing Loop Attack using 136 IPv6 Automatic Tunnels: Problem Statement and Proposed 137 Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in 138 progress), May 2011. 140 [I-D.ietf-v6ops-tunnel-security-concerns] 141 Krishnan, S., Thaler, D., and J. Hoagland, "Security 142 Concerns With IP Tunneling", 143 draft-ietf-v6ops-tunnel-security-concerns-04 (work in 144 progress), October 2010. 146 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 147 6to4", RFC 3964, December 2004. 149 Authors' Addresses 151 Ole Troan 152 Cisco 153 Oslo, 154 Norway 156 Email: ot@cisco.com 158 Keith Moore 159 Network Heretics 161 Email: moore@network-heretics.com 163 James Woodyatt 164 Apple Inc. 165 1 Infinite Loop 166 Cupertino, CA 95014 167 US 169 Email: jhw@apple.com