One document matched: draft-ietf-v6ops-6to4-to-historic-08.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="no" ?>
<?rfc tocompact="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc1918 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml'>
<!ENTITY rfc2026 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml'>
<!ENTITY rfc5226 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
<!ENTITY rfc3056 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml'>
<!ENTITY rfc3068 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3068.xml'>
<!ENTITY rfc3964 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3964.xml'>
<!ENTITY rfc6890 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6890.xml'>
<!ENTITY rfc5158 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5158.xml'>
<!ENTITY rfc5969 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5969.xml'>
<!ENTITY rfc6724 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6724.xml'>
<!ENTITY rfc6343 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6343.xml'>
<!ENTITY rfc6169 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6169.xml'>
<!ENTITY rfc6324 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6324.xml'>
<!ENTITY rfc6555 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6555.xml'>
]>
<rfc category="bcp" ipr="trust200902" docName="draft-ietf-v6ops-6to4-to-historic-08.txt" obsoletes="3068" updates="6343">
<front>
<title abbrev="Deprecating 6to4 Anycast">
Deprecating Anycast Prefix for 6to4 Relay Routers
</title>
<author initials="O" surname="Troan" fullname="Ole Troan">
<organization abbrev="">Cisco</organization>
<address>
<postal>
<street></street>
<city>Oslo</city>
<region></region>
<code></code>
<country>Norway</country>
</postal>
<email>ot@cisco.com</email>
</address>
</author>
<author fullname="Brian Carpenter" initials="B. E." role="editor"
surname="Carpenter">
<organization abbrev="Univ. of Auckland"></organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>University of Auckland</street>
<street>PB 92019</street>
<city>Auckland</city>
<region></region>
<code>1142</code>
<country>New Zealand</country>
</postal>
<email>brian.e.carpenter@gmail.com</email>
</address>
</author>
<date year="2014" />
<area>Ops</area>
<workgroup>v6ops WG</workgroup>
<!-- SECTION 0: Abstract -->
<abstract>
<t>Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)"
IPv6 transition mechanism defined in RFC 3056 has shown that the mechanism
is unsuitable for widespread deployment and use in the Internet, especially
in its anycast mode. This document requests that RFC 3068, "An Anycast
Prefix for 6to4 Relay Routers", be made obsolete and moved to historic
status. It also recommends that future products should not support 6to4
anycast and that existing deployments should be reviewed. Thus it updates
the guidelines in RFC 6343.</t>
</abstract>
</front>
<middle>
<!-- SECTION 1: Introduction -->
<section title="Introduction">
<t>There would appear to be no evidence of any substantial
deployment of the variant of 6to4 described in <xref
target="RFC3056"/>. Its extension specified in "An Anycast
Prefix for 6to4 Relay Routers" <xref target="RFC3068"/> has
been shown to have severe practical problems when used in the
Internet. This document requests that RFC 3068 be moved
to Historic status as defined in section 4.2.4 of
<xref target="RFC2026"/>. It also updates the deployment guidelines
in <xref target="RFC6343"/>.</t>
<t>6to4 was designed to help transition the Internet from IPv4 to
IPv6. It has been a good mechanism for experimenting with IPv6, but
because of the high failure rates seen with anycast 6to4 <xref
target="HUSTON"/>, end users may end up disabling IPv6 on
hosts as a result, and some content providers have been reluctant to
make content available over IPv6.</t>
<t><xref target="RFC6343"/> analyses the
known operational issues in detail and describes a set of suggestions to
improve 6to4 reliability, given the widespread presence of hosts and
customer premises equipment that support it. However, experience
shows that operational failures have continued despite
this advice being available. Fortunately the advice to disable 6to4
by default has been widely adopted in recent operating systems, and the
failure modes have been largely hidden from users by many browsers
adopting the "happy eyeballs" approach <xref target="RFC6555"/>.
Nevertheless, operational problems caused by 6to4 still occur. </t>
<t>IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) <xref
target="RFC5969"/> utilizes the same encapsulation and base
mechanism as 6to4, and could be viewed as a superset of 6to4 (6to4
could be achieved by setting the 6rd prefix to 2002::/16). However,
the deployment model is such that 6rd can avoid the problems
described here. In this sense, 6rd can be viewed as superseding 6to4
as described in section 4.2.4 of <xref target="RFC2026"/></t>
<t>Given that native IPv6 support and reliable transition mechanisms such as 6rd
are now becoming common, the IETF sees no evolutionary future for the 6to4 mechanism. </t>
</section>
<!-- SECTION 2: REQUIREMENTS LANGUAGE -->
<section anchor="conventions" title="Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119
<xref target="RFC2119"/>.</t>
</section> <!-- conventions -->
<!-- SECTION 3: 6to4 analysis -->
<section anchor="proc-rules" title="6to4 operational problems">
<t>6to4 is a mechanism designed to allow isolated IPv6 islands to
reach each other using IPv6 over IPv4 automatic tunneling. To reach
the native IPv6 Internet the mechanism uses relay routers both in
the forward and reverse direction. The mechanism is supported in
many IPv6 implementations. With the increased deployment of IPv6,
the mechanism has been shown to have a number of fundamental
shortcomings.</t>
<t>6to4 depends on relays both in the forward and reverse direction
to enable connectivity with the native IPv6 Internet. A 6to4 node
will send IPv4 encapsulated IPv6 traffic to a 6to4 relay, that is
connected both to the 6to4 cloud and to native IPv6. In the reverse
direction a 2002::/16 route is injected into the native IPv6 routing
domain to attract traffic from native IPv6 nodes to a 6to4 relay
router. It is expected that traffic will use different relays in the
forward and reverse direction. RFC 3068 adds an extension that allows
the use of a well known IPv4 anycast address to reach the nearest
6to4 relay in the forward direction.</t>
<t>One model of 6to4 deployment, described in section 5.2 of
RFC 3056, suggests that a 6to4 router should have a set of managed
connections (via BGP connections) to a set of 6to4 relay
routers. While this makes the forward path more controlled, it does
not guarantee a functional reverse path. In any case this model has
the same operational burden as manually configured tunnels and has
seen no deployment in the public Internet.</t>
<t>List of some of the known issues with 6to4:</t>
<t><list style="symbols">
<t>Use of relays. 6to4 depends on an unknown third party to
operate the relays between the 6to4 cloud and the native IPv6
Internet.</t>
<t>The placement of the relay can lead to increased latency, and
in the case the relay is overloaded, packet loss.</t>
<t>There is generally no customer relationship between the
end-user and the relay operator, or even a way for the end-user to
know who the relay operator is, so no support is possible.</t>
<t>A 6to4 relay for the reverse path and an anycast 6to4 relay
used for the forward path, are openly accessible, limited
only by the scope of routing. 6to4 relays can be used to anonymize
traffic and inject attacks into IPv6 that are very difficult to
trace.</t>
<t>6to4 may silently discard traffic in the case where protocol
(41) is blocked in intermediate firewalls. Even if a firewall sent
an ICMP message unreachable back, an IPv4 ICMP message rarely
contains enough of the original IPv6 packet so that it can be
relayed back to the IPv6 sender. That makes this problem hard to
detect and react upon by the sender of the packet.</t>
<t>As 6to4 tunnels across the Internet, the IPv4 addresses used
must be globally reachable. RFC 3056 states that a private address
<xref target="RFC1918"/> MUST NOT be used. 6to4 will not
work in networks that employ other addresses with limited
topological span. In particular it will predictably fail in the case of
double network address translation (NAT444). </t>
</list></t>
<t>For further analysis, see <xref target="RFC6343"/>. </t>
<t>Peer-to-peer usage of the 6to4 mechanism, not depending on the anycast
mechanism, might exist in the Internet, largely unknown to operators. This
is harmless to third parties and the current document is not intended to
prevent such traffic continuing. </t>
</section>
<section title="Deprecation">
<t>This document formally deprecates the anycast 6to4 transition mechanism
defined in <xref target="RFC3068"/> and the associated anycast
IPv4 address 192.88.99.1. It is NOT RECOMMENDED to include this mechanism in new
implementations. It is no longer considered to be a useful service of last resort. </t>
<t>The prefix 192.88.99.0/24 MUST NOT be reassigned
for other use except by a future IETF standards action.</t>
<t>The basic unicast 6to4 mechanism defined in <xref target="RFC3056"/>
and the associated 6to4 IPv6 prefix 2002::/16 are not deprecated.
The default address selection rules specified in <xref target="RFC6724"/>
are not modified. However, if included in implementations, unicast
6to4 MUST be disabled by default. </t>
<t>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. </t>
<t>Current operators of an anycast 6to4 relay with the IPv4 address 192.88.99.1
SHOULD review the information in <xref target="RFC6343"/>
and the present document, and then consider carefully when the anycast relay
can be discontinued as traffic diminishes. Internet service providers
SHOULD filter out routes to 192.88.99.1. However, networks SHOULD NOT filter out
packets whose source address is 192.88.99.1, because this is normal 6to4
traffic from a 6to4 return relay somewhere in the Internet.
</t>
<t>Operators of a 6to4 return relay announcing the IPv6 prefix 2002::/16
SHOULD review the information in <xref target="RFC6343"/>
and the present document, and then consider carefully when the return relay
can be discontinued as traffic diminishes. As discussed in Section 4.5 of
RFC 6343, content providers might choose to continue operating such a relay
for the benefit of their own residual 6to4 clients. Internet service providers
SHOULD announce the IPv6 prefix 2002::/16 to their own customers if and only if it leads to a correctly
operating return relay as described in RFC 6343. IPv6-only service providers
are advised that their own customers need such a relay to be available in case
a residual 6to4 user served by a different service provider attempts to communicate with them.</t>
<t>The guidelines in Section 4 of <xref target="RFC6343"/> remain valid for
those who choose to continue operating Anycast 6to4 despite its
deprecation.</t>
<!-- <t>The references to 6to4 should be removed as soon as practical
from the revision of the Special-Use IPv6 Addresses <xref
target="RFC6890"/>.</t> -->
<t>Incidental references to 6to4 should be reviewed and possibly removed from other IETF
documents if and when they are updated. These documents include
RFC3162, RFC3178, RFC3790, RFC4191, RFC4213, RFC4389, RFC4779,
RFC4852, RFC4891, RFC4903, RFC5157, RFC5245, RFC5375, RFC5971,
RFC6071 and RFC6890.</t>
</section>
<!-- SECTION 4: IANA Considerations -->
<section title="IANA Considerations">
<t>
The document creating the IANA IPv4 Special-Purpose Address Registry
<xref target="RFC6890"/> included the 6to4 relay anycast prefix
(192.88.99.0/24) as Table 10. Instead, IANA is requested to mark the
192.88.99.0/24 prefix originally defined by <xref target="RFC3068"/>
as "Deprecated (6to4 Relay Anycast)", pointing to the present document.
Redelegation of this prefix for any usage requires justification
via an IETF Standards Action <xref target="RFC5226"/>.</t>
</section>
<!-- SECTION 5: Security Considerations -->
<section title="Security Considerations">
<t>There are no new security considerations pertaining to this
document. General security issues with tunnels are listed in <xref
target="RFC6169"/> and more
specifically to 6to4 in <xref target="RFC3964"/> and <xref
target="RFC6324"/>.</t>
</section>
<!-- SECTION 6: Acknowledgements -->
<section title="Acknowledgements">
<t>The authors would like to acknowledge Tore Anderson, Dmitry
Anipko, Jack Bates, Cameron Byrne, Ben Campbell, Gert Doering, David Farmer,
Ray Hunter, Joel Jaeggli, Kurt Erik Lindqvist, Jason Livingood, Keith
Moore, Tom Petch, Daniel Roesen, Mark Townsley and James Woodyatt
for their contributions and discussions on this topic.</t>
<t>Special thanks go to Fred Baker, Geoff Huston,
and Wes George for their significant contributions.</t>
<t>Many thanks to Gunter Van de Velde for documenting the harm
caused by non-managed tunnels and stimulating the creation of this
document.</t>
</section>
</middle>
<back>
<!-- SECTION 8.1: Normative References -->
<references title="Normative References">
&rfc2119;
&rfc2026;
&rfc3056;
&rfc3068;
&rfc6890;
&rfc5226;
&rfc6724;
</references>
<!-- SECTION 8.2: Informative References -->
<references title="Informative References">
&rfc1918;
&rfc3964;
<!-- &rfc5158; -->
&rfc5969;
&rfc6343;
&rfc6169;
&rfc6324;
&rfc6555;
<reference anchor="HUSTON" target="http://www.potaroo.net/ispcol/2010-12/6to4fail.html">
<front>
<title>Flailing IPv6</title>
<author fullname="Geoff Huston" surname="Huston">
<organization></organization>
</author>
<date month="December" year="2010" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:12:20 |