One document matched: draft-ietf-v6ops-6to4-to-historic-10.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'>
<!ENTITY rfc6146 PUBLIC '' 
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6146.xml'>
<!ENTITY rfc6732 PUBLIC '' 
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6732.xml'>
<!ENTITY rfc3484 PUBLIC '' 
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml'>


]>

<rfc category="bcp" ipr="trust200902" docName="draft-ietf-v6ops-6to4-to-historic-10.txt" obsoletes="3068, 6732">
<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="2015" />
<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 when used in
  its anycast mode, the mechanism is unsuitable for widespread deployment and
  use in the Internet. This document therefore requests that RFC 3068, "An Anycast
  Prefix for 6to4 Relay Routers", be made obsolete and moved to historic
  status. It also obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It
  recommends that future products should not support 6to4 anycast and that
  existing deployments should be reviewed. This complements the guidelines
  in RFC 6343.</t>
</abstract>
</front>

<middle>


<!--  SECTION 1:  Introduction                  -->


<section title="Introduction">
  <t>The original form of the 6to4 transition mechanism <xref target="RFC3056"/>
  relies on unicast addressing. However, 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 and RFC 6732 be moved
  to Historic status as defined in section 4.2.4 of 
  <xref target="RFC2026"/>. It complements 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. The advice to disable 6to4
  by default has been widely adopted in recent operating systems, and the
  failure modes have been widely hidden from users by many browsers
  adopting the "Happy Eyeballs" approach <xref target="RFC6555"/>.
  </t>
  
  <t>Nevertheless, a substantial amount of 6to4 traffic is still observed
  by IPv6 content providers.
  The remaining successful users of anycast 6to4 are likely to be on hosts
  using the obsolete policy table <xref target="RFC3484"/>, which prefers 6to4
  above IPv4, and running without Happy Eyeballs. Furthermore, they must have
  a route to an operational anycast relay and they must be accessing an IPv6
  host that has a route to an operational return relay.</t>
  
  <t>However, experience shows that operational failures caused by anycast 6to4
  have continued, despite the advice in RFC 6343 being available.</t>


<section title="Related Work">
  <t>IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) <xref
  target="RFC5969"/> explicitly builds on the 6to4 mechanism,
  using a service provider prefix instead of 2002::/16. However, the deployment model is 
  based on service provider support, such that 6rd avoids the problems
  observed with anycast 6to4.</t>
  
  <t>The framework for 6to4 Provider Managed Tunnels <xref target="RFC6732"/> is
  intended to help a service provider manage 6to4 anycast tunnels.
  This framework only exists because of the problems observed with anycast 6to4.</t>

</section>
</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>
  
  <t>The word "deprecate" and its derivatives are used only in their generic sense of
  "criticize or express disapproval" and do not have any specific normative meaning.
  A deprecated function might exist in the Internet for many years to allow backwards
  compatibility.</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 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. </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>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.
   However, this anycast mechanism has a number of operational issues and problems,
   which are described in detail in Section 3 of <xref target="RFC6343"/>.
   This document is intended to deprecate the anycast mechanism.</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 whether the anycast relay
  can be discontinued as traffic diminishes. Internet service providers that do not
  operate an anycast relay but do provide their customers with a route to 192.88.99.1
  SHOULD verify that it does in fact lead to an operational anycast relay,
  as discussed in Section 4.2.1 of <xref target="RFC6343"/>.
  Furthermore, Internet service providers and other network providers MUST NOT
  originate a route to 192.88.99.1, unless they actively operate and monitor an anycast
  6to4 relay service as detailed in Section 4.2.1 of <xref target="RFC6343"/>. </t>
  
  <t>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 responding to the IPv6 prefix 2002::/16
  SHOULD review the information in <xref target="RFC6343"/>
  and the present document, and then consider carefully whether the return relay
  can be discontinued as traffic diminishes. To avoid confusion, note that nothing
  in the design of 6to4 assumes or requires that return packets are handled by the same
  relay as outbound packets. As discussed in Section 4.5 of 
  RFC 6343, content providers might choose to continue operating a return 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,
  including those operating a NAT64 service <xref target="RFC6146"/>,
  are advised that their own customers need a route to such a relay 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.
  
  However, 6to4 Provider Managed Tunnels <xref target="RFC6732"/> will no longer be necessary,
  so they are also deprecated by this document.</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,
  Mark Andrews,
  Dmitry Anipko, Jack Bates, Cameron Byrne, Ben Campbell,
  Lorenzo Colitti,
  Gert Doering, David Farmer,
  Nick Hilliard,
  Philip Homburg,
  Ray Hunter, Joel Jaeggli, Victor Kuarsingh, 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;
  &rfc6146;
</references>

<!--  SECTION 8.2:  Informative References		-->

<references title="Informative References">
  
  &rfc3964;
  &rfc5969;
  &rfc6343;
  &rfc6169;
  &rfc6324;
  &rfc6555;
  &rfc6732;
  &rfc3484;
  
  <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>