One document matched: draft-kohno-ipv6-prefixlen-p2p-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3627 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3627.xml">
<!ENTITY rfc4291 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY rfc4443 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY rfc3756 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3756.xml">
<!ENTITY rfc5375 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5375.xml">
<!ENTITY rfc4861 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
]>
<rfc category="std" docName="draft-kohno-ipv6-prefixlen-p2p-01.txt"
     ipr="trust200902" obsoletes="3627" updates="4291,5375">
  <?rfc toc="yes" ?>

  <?rfc compact="yes"?>

  <?rfc subcompact="no"?>

  <?rfc symrefs="yes"?>

  <?rfc sortrefs="yes" ?>


  <front>
    <title abbrev="IPv6 prefixlen p2p">Using 127-bit IPv6 Prefixes on Inter-Router Links</title>

    <author fullname="Miya Kohno" initials="M" surname="Kohno">
      <organization>Juniper Networks, Keio University</organization>

      <address>
        <postal>
          <street>Shinjuku Park Tower, 3-7-1 Nishishinjuku</street>

          <city>Shinjuku-ku</city>

          <region>Tokyo</region>

          <code>163-1035</code>

          <country>Japan</country>
        </postal>

        <email>mkohno@juniper.net</email>
      </address>
    </author>

    <author fullname="Becca Nitzan" initials="B" surname="Nitzan">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>1194 North Marhilda Avenue</street>

          <city>Sunnyvale</city>

          <region>CA</region>

          <code>94089</code>

          <country>USA</country>
        </postal>

        <email>nitzan@juniper.net</email>
      </address>
    </author>

    <author fullname="Randy Bush" initials="R" surname="Bush">
      <organization>Internet Initiative Japan</organization>

      <address>
        <postal>
          <street>5147 Crystal Springs</street>

          <city>Bainbridge Island</city>

          <region>WA</region>

          <code>98110</code>

          <country>USA</country>
        </postal>

        <email>randy@psg.com</email>
      </address>
    </author>

    <author fullname="Yoshinobu Matsuzaki" initials="Y" surname="Matsuzaki">
      <organization>Internet Initiative Japan</organization>

      <address>
        <postal>
          <street>Jinbocho Mitsui Building,</street>

          <city>1-105 Kanda Jinbo-cho</city>

          <region>Tokyo</region>

          <code>101-0051</code>

          <country>Japan</country>
        </postal>

        <email>maz@iij.ad.jp</email>
      </address>
    </author>
    
     <author fullname="Lorenzo Colitti" initials="L" surname="Colitti">
      <organization>Google</organization>

      <address>
        <postal>
          <street>1600 Amphitheatre Parkway,</street>

          <city>Mountain View</city>

          <region>CA</region>

          <code>94043</code>

          <country>USA</country>
        </postal>

        <email>lorenzo@google.com</email>
      </address>
    </author>


    <date month="March" year="2010" />

    <area>O</area>

    <workgroup>v6man</workgroup>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <keyword>IPv6</keyword>

    <abstract>
      <t>In many environments it is useful, for security and other reasons,
      to use 127-bit IPv6 prefixes on inter-router links. This document outlines
      some of these reasons and proposes that 127-bit IPv6 prefix lengths be
      allowed on these links.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Conventions" title=" Conventions Used In This Document">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </section>

    <section anchor="Introduction" title="Introduction">
      <t><xref target="RFC4291">RFC 4291</xref> specifies that interface IDs
      for all unicast address, except those that start with the binary value
      000, are required to be 64 bits long and to be constructed in
      Modified EUI-64 format. In addition, it defines the Subnet-Router anycast
      address, which is intended to be used for applications where a node needs
      to communicate with any one of the set of routers on a link.</t>

      <t>Some operators have been using 127-bit prefixes, but this
      has been discouraged due to conflicts with Subnet-Router anycast
      <xref target="RFC3627"/>.
      However, using 64-bit prefixes creates security issues which are
      particularly problematic on inter-router links, and there are other valid
      reasons to use prefixes longer than 64 bits, in particular /127
      (see <xref target="Rationale" />).
      </t>
      
      <t>This document provides rationale for using 127-bit prefix lengths,
      reevaluates the reasons why doing so was considered harmful, and proposes that
      /127 prefixes may be used on inter-router links if certain conditions are met.</t>
    </section>

    <section anchor="Scope" title="Scope Of This Memo">
      <t>This document is applicable to cases where operators assign specific
      addresses on inter-router links and do not rely on link-local
      addresses. Many operators assign specific addresses for purposes of
      network monitoring, reverse DNS resolution for traceroute and other
      management tools, EBGP peering sessions, and so on.</t>

      <t>For the purposes of this document, an inter-router link is a link to
      which only routers and no hosts are attached. Thus, links between a router
      and a host, or links to which both routers and hosts are attached, are out of
      scope of this document.</t>
    </section>

    <section anchor="Problems"
             title="Problems identified with 127-bit prefix lengths in the past">
      <t><xref target="RFC3627" /> discourages the use of 127-bit prefix lengths
      due to conflicts with the Subnet-Router anycast
      addresses. However, the RFC also states that the utility of Subnet-Router
      Anycast for point-to-point links is questionable.</t>
      
      <t><xref target="RFC5375" /> also says the usage of 127-bit prefix lengths
      is not valid and should be strongly discouraged, but the stated reason for
      doing this is to be in compliance with <xref target="RFC3627" />.</t>

      <t>Given that Subnet-Router
      Anycast is not currently widely implemented, an alternative solution to
      this problem could have been to recommend that Subnet-Router
      Anycast be disabled on prefixes that are 127 bits long.</t>
    </section>

    <section anchor="Rationale" title="Reasons for using longer prefixes">
      <t>There are various reasons for network operators to use IPv6 prefix
      length greater than 64, particularly 127, for inter-router links.</t>
      
      <section anchor="Pingpong" title="Ping-pong issue">

      <t>As described in <xref target="PINGPONG"/>, a forwarding loop may
      occur on a point-to-point link with a prefix length shorter than
      127. This does not affect interfaces that perform Neighbor
      Discovery, but some point-to-point links, such as SONET, do not use Neighbor Discovery.
      As a consequence, configuring any prefix length other than 127 bits on
      these links creates an attack vector in the network.</t>

      <t>The latest ICMPv6 specification <xref target="RFC4443" /> provides
      a solution to this issue by specifying that a router receiving a packet
      on a point-to-point link sent to an address on the link itself
      must not forward the packet back onto the same link, instead generating
      an ICMPv6 Destination Unreachable (Code 3) message. However, checking all
      traffic for this condition is likely to affect performance, as it
      doubles the number of routing lookups required to forward every packet.</t>
      </section>

      <section anchor="Neighbor Cache" title="Neighbor Cache Exhaustion issue">
      <t>As described in Section 4.3.2 of <xref target="RFC3756"/>, the use of a
      64-bit prefix length on an inter-router link that uses 
      Neighbor Discovery (e.g., Ethernet) potentially allows for denial-of-service 
      attacks on the routers on the link.</t>
        
      <t>Consider an Ethernet link between two routers A and B to which a /64 
      subnet has been assigned. A packet sent to any address on the /64 (except the 
      addresses of A and B) will cause the router attempting to forward it to create 
      an new cache entry in state INCOMPLETE, send a Neighbor Solicitation message to 
      be sent on the link, start a retransmit timer, and so on <xref target="RFC4861" />.</t>
        
      <t>By sending a continuous stream of packets to a large number of the 2^64 - 
      3 addresses on the link that are not assigned to the routers (one for each
      router and one for Subnet-Router Anycast), an attacker can 
      cause the routers to create a large number of neighbor cache entries and send a 
      large number of Neighbor Solicitation packets which will never receive replies, 
      possibly consuming a disproportionate amount of memory and processing resources. 
      Sending the packets to one of the 2^24 addresses on the link that have the same 
      Solicited-Node multicast address as of one of the routers also causes the other 
      router to spend disproportionate amounts of processing time discarding useless
      Neighbor Solicitation messages.</t>
        
      <t>Careful implementation and rate-limiting can limit the impact of such an attack, 
      but are unlikely to neutralize it completely. Rate-limiting neighbor solicitation 
      messages will reduce CPU usage, and following the garbage-collection recommendations 
      in <xref target="RFC4861" /> will maintain reachability, but if the link is down and
      neighbor cache entries have expired while the attack is ongoing, legitimate traffic
      (for example, BGP sessions) over the link might never be re-established because the
      routers cannot resolve each others' IPv6 addresses to MAC addresses.</t>
        
      <t>This attack is not specific to point-to-point links, but is particularly harmful 
      in the case of point-to-point backbone links, which may carry large amounts of traffic 
      to many destinations over long distances.</t>
      </section>
      
      <section anchor="Others" title="Other reasons">
      <list style="numbers">
        <t>With the use of 127-bit or other long prefix lengths, interface IDs
        are simpler and easier to remember (e.g., the Interface ID is 0 or
        1).</t>

        <t>Using 64-bit prefixes for inter-router links leaves a large number of unused addresses
        that an attacker with physical access to a link could use to insert a node onto the link
        without having to compromise the routing protocols used on the link. If 127-bit prefix lengths
        are in use, this is not possible.</t>

        <t>Though address space conservation considerations are less important for IPv6
        than they are in IPv4, it may still be desirable to use the smallest possible prefix
        to number links (and thus use, for example, /127 for point-to-point links). For example,
        a large end-site that is assigned a /48 of IPv6 space may not want to reserve a full /64
        for every point-to-point link to avoid renumbering in the future.</t>
      </list>
     </section>
      
    </section>


    <section anchor="Recommendations" title="Recommendations">
    <t>In light of the above reasons, this document proposes that inter-router links
    MAY be assigned 127-bit prefix lengths. If such a prefix is assigned to a link,
    Subnet-Router Anycast MUST be disabled for the prefix.</t>
    </section>

    <section anchor="Security Considerations" title="Security Considerations">
      <t>This draft addresses, among other things, various security issues.</t>
    </section>

    <section anchor="IANAConsiderations" title="IANA Considerations">
      <t>None.</t>
    </section>

    <section anchor="Contributors" title="Contributors">
      <t>Chris Morrow, morrowc@google.com</t>

      <t>Pekka Savola, pekkas@netcore.fi</t>
      
      <t>Remi Despres, remi.despres@free.fr</t>
    </section>

    <section anchor="Acknowledgments" title="Acknowledgments">
      <t>We'd like to thank Ron Bonica, Pramod Srinivasan, Olivier Vautrin,
      Tomoya Yoshida and Warren Kumari for their helpful inputs.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &rfc2119;

      &rfc4291;

      &rfc4443;

      &rfc4861;
    </references>

    <references title="Informative References">
      &rfc3627;
      
      &rfc3756;

      &rfc5375;
      
      <reference anchor="PINGPONG"
                 target="http://tools.ietf.org/html/draft-ietf-ipngwg-p2p-pingpong-00">
        <front>
          <title>Avoiding ping-pong packets on point-to-point links</title>

          <author fullname="Junichiro Itojun Hagino" initials="H"
                  surname="Hagino">
            <organization />
          </author>

          <author fullname="Tatsuya Jimmei" initials="T" surname="Jimmei">
            <organization />
          </author>
        </front>
      </reference>
    </references>
  </back>
</rfc>