idnits 2.17.1 draft-troan-v6ops-6to4-to-historic-01.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 draft header indicates that this document obsoletes RFC3056, but the abstract doesn't seem to directly say this. It does mention RFC3056 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 -- The document date (March 10, 2011) is 4796 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) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-03) exists of draft-carpenter-v6ops-6to4-teredo-advisory-02 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-tunnel-loops-04 == Outdated reference: A later version (-07) exists of draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops WG O. Troan 3 Internet-Draft G. Van de Velde 4 Obsoletes: 3056 (if approved) Cisco 5 Intended status: Standards Track March 10, 2011 6 Expires: September 11, 2011 8 Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to 9 Historic status 10 draft-troan-v6ops-6to4-to-historic-01.txt 12 Abstract 14 Experience with the "Connection of IPv6 Domains via IPv4 Clouds 15 (6to4)" IPv6 transitioning mechanism has shown that the mechanism is 16 unsuitable for widespread deployment and use in the Internet. This 17 document requests that RFC3056 and the companion document "An Anycast 18 Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 11, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Introduction 54 The IPv6 transitioning mechanism "Connection of IPv6 Domains via IPv4 55 Clouds (6to4) described in [RFC3056] and the extension in "An Anycast 56 Prefix for 6to4 Relay Routers" RFC3068 [RFC3068] have been shown to 57 have severe practical problems being used in the Internet. This 58 document requests that RFC3056 and RFC3068 be moved to Historic 59 status as defined in section 4.2.4 [RFC2026]. 61 See also the document Non-Managed IPv6 Tunnels considered Harmful 62 [I-D.vandevelde-v6ops-harmful-tunnels] for details. 64 [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] are proposing a 65 mechanism using IPv6 NAT to solve the 6to4 reverse path problem. 67 [I-D.carpenter-v6ops-6to4-teredo-advisory] are proposing a set of 68 suggestions to improve 6to4 reliability. 70 Declaring the mechanism historic is not expected to have immediate 71 product implications. The IETF sees no evolutionary future for the 72 mechanism and it is not recommended to include this mechanism in new 73 implementations. 75 2. Conventions 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [RFC2119]. 81 3. 6to4 operational problems 83 6to4 is a mechanism designed to allow isolated IPv6 islands to reach 84 each other using IPv6 over IPv4 automatic tunneling. To reach the 85 native IPv6 Internet the mechanism uses relay routers both in the 86 forward and reverse direction. The mechanism is supported in many 87 IPv6 implementations. With the increased deployment of IPv6, the 88 mechanism has been shown to have a number of fundamental 89 shortcomings. 91 6to4 depends on relays both in the forward and reverse direction to 92 enable connectivity with the native IPv6 Internet. A 6to4 node will 93 send IPv4 encapsulated IPv6 traffic to a 6to4 relay, that is 94 connected both to the 6to4 cloud and to native IPv6. In the reverse 95 direction a 2002::/16 route is injected into the native IPv6 routing 96 domain to attract traffic from native IPv6 nodes to a 6to4 relay 97 router. It is expected that traffic will use different relays in the 98 forward and reverse direction. RFC3068 adds an extension that allows 99 the use of a well known IPv4 anycast address to reach the nearest 100 6to4 relay in the forward direction. 102 One model of 6to4 deployment as described in section 5.2, RFC3056, 103 suggests that a 6to4 router should have a set of managed connections 104 (read BGP peers) to a set of 6to4 relay routers. While this makes 105 the forward path more controlled, it does not help the reverse path. 106 In any case this model has the same operational burden has manually 107 configured tunnels and has seen no deployment in the public Internet. 109 6to4 issues: 110 o Use of relays. 6to4 depends on the charity of an unknown third- 111 party to operate the relays between the 6to4 cloud and the native 112 IPv6 Internet. With the use of mechanism specified in [RFC3068] 113 in both directions, without it only in the reverse direction (from 114 native to 6to4) [RFC3056]. 115 o The placement of the relay can lead to increased latency, and in 116 the case the relay is overloaded packet loss. 117 o There is generally no customer relationship or even a way for the 118 end-user to know who the relay operator is, so no support is 119 possible. 120 o In case of the reverse path 6to4 relay and the anycast forward 121 6to4 relay, these have to be open for any address. Only limited 122 by the scope of the routing advertisement. 6to4 relays can be used 123 to anonymize traffic and inject attacks into IPv6 that are very 124 difficult to trace. 125 o 6to4 has no specified mechanism to handle the case where the 126 protocol (41) is blocked in intermediate firewalls. It can not be 127 expected that path MTU discovery across the Internet works 128 reliably; ICMP messages may be blocked and in any case an IPv4 129 ICMP message rarely has enough of the original packet in it to be 130 useful to proxy back to the IPv6 sender. 131 o As 6to4 tunnels across the Internet, the IPv4 addresses used must 132 be globally reachable. RFC3056 states that a private address 133 [RFC1918] MUST NOT be used. 6to4 will not work in networks that 134 employ addresses with limited topological span. 136 4. Recommendations for 6to4 Relay Operators 138 See [I-D.carpenter-v6ops-6to4-teredo-advisory]. 140 5. Recommendations for implementors 142 If the implementation continues to support 6to4, then the 6to4 143 functionality MUST NOT be enabled by default. 145 If the implementation continues to support 6to4, then the Source 146 Address Selection algorithm [RFC3484] MUST use a 6to4 address as a 147 last resort. I.e. only use it the node has no other means of IPv6 148 connectivity and the destination is IPv6 only. 150 6. IANA Considerations 152 This specification does not require any IANA actions. 154 7. Security Considerations 156 There are no new security considerations pertaining to this document. 157 General security issues with tunnels are listed in 158 [I-D.ietf-v6ops-tunnel-security-concerns] and more specifically to 159 6to4 in [I-D.ietf-v6ops-tunnel-loops] and 160 [I-D.vandevelde-v6ops-harmful-tunnels]. 162 8. Acknowledgements 164 The authors would like to acknowledge Fred Baker, Jack Bates, Cameron 165 Byrne, Brian Carpenter, Gert Doering, Joel Jaeggli, Jason Livingood, 166 Keith Moore, Daniel Roesen and Mark Townsley, for their contributions 167 and discussions on this topic. 169 9. References 171 9.1. Normative References 173 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 174 E. Lear, "Address Allocation for Private Internets", 175 BCP 5, RFC 1918, February 1996. 177 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 178 3", BCP 9, RFC 2026, October 1996. 180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 181 Requirement Levels", BCP 14, RFC 2119, March 1997. 183 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 184 via IPv4 Clouds", RFC 3056, February 2001. 186 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 187 RFC 3068, June 2001. 189 [RFC3484] Draves, R., "Default Address Selection for Internet 190 Protocol version 6 (IPv6)", RFC 3484, February 2003. 192 9.2. Informative References 194 [I-D.carpenter-v6ops-6to4-teredo-advisory] 195 Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 196 draft-carpenter-v6ops-6to4-teredo-advisory-02 (work in 197 progress), February 2011. 199 [I-D.ietf-v6ops-tunnel-loops] 200 Nakibly, G. and F. Templin, "Routing Loop Attack using 201 IPv6 Automatic Tunnels: Problem Statement and Proposed 202 Mitigations", draft-ietf-v6ops-tunnel-loops-04 (work in 203 progress), March 2011. 205 [I-D.ietf-v6ops-tunnel-security-concerns] 206 Krishnan, S., Thaler, D., and J. Hoagland, "Security 207 Concerns With IP Tunneling", 208 draft-ietf-v6ops-tunnel-security-concerns-04 (work in 209 progress), October 2010. 211 [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] 212 Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider 213 Managed Tunnels", 214 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-01 215 (work in progress), February 2011. 217 [I-D.vandevelde-v6ops-harmful-tunnels] 218 Velde, G., Troan, O., and T. Chown, "Non-Managed IPv6 219 Tunnels considered Harmful", 220 draft-vandevelde-v6ops-harmful-tunnels-01 (work in 221 progress), August 2010. 223 Authors' Addresses 225 Ole Troan 226 Cisco 227 Oslo, 228 Norway 230 Email: ot@cisco.com 232 Gunter Van de Velde 233 Cisco 234 De Kleetlaan 6a 235 Diegem 1831 236 Belgium 238 Phone: +32 2704 5473 239 Email: gvandeve@cisco.com