One document matched: draft-behringer-lla-only-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3209 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC4193 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY RFC4443 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC5837 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5837.xml">
<!ENTITY RFC6192 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6192.xml">
<!ENTITY I-D.ietf-grow-private-ip-sp-cores PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-grow-private-ip-sp-cores.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<rfc category="info" docName="draft-behringer-lla-only-01" ipr="trust200902"
     submissionType="independent" xml:lang="en">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="lla-only-core">Using Only Link-Local Addressing Inside an
    IPv6 Network</title>

    <author fullname="Michael Behringer" initials="M" surname="Behringer">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>400 Avenue Roumanille, Bat 3</street>

          <city>Biot</city>

          <region/>

          <code>06410</code>

          <country>France</country>
        </postal>

        <email>mbehring@cisco.com</email>
      </address>
    </author>

    <author fullname="Eric Vyncke" initials="E" surname="Vyncke">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>De Kleetlaan, 6A</street>

          <city>Diegem</city>

          <region/>

          <code>1831</code>

          <country>Belgium</country>
        </postal>

        <email>evyncke@cisco.com</email>
      </address>
    </author>

    <date day="16" month="July" year="2012"/>

    <!-- Meta-data Declarations -->

    <area>ops</area>

    <workgroup/>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>IPv6 security routing</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document proposes to use only IPv6 link-local addresses on
      infrastructure links between routers, wherever possible. It discusses
      the advantages and disadvantages of this approach to aide the decision
      process for a given network,</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction" toc="default">
      <t>An infrastructure link between a set of routers typically does not
      require global or even <xref target="RFC4193">unique local
      addressing</xref>. Using link-local addressing on such links has a
      number of advantages, for example that routing tables do not need to
      carry link addressing, and can therefore be significantly smaller. This
      helps to decrease failover times in certain routing convergence events.
      An interface of a router is also not reachable beyond the link
      boundaries, therefore reducing the attack horizon.</t>

      <t>We propose to configure neither globally routable IPv6 addresses nor
      unique local addresses on infrastructure links of routers, wherever
      possible. We recommend to use exclusively link-local addresses on such
      links.</t>

      <t>This document discusses the advantages and caveats of this
      approach.</t>

      <section title="Requirements Language">
        <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"/> when they appear in ALL CAPS. These words may also
        appear in this document in lower case as plain English words, absent
        their normative meanings.</t>
      </section>
    </section>

    <section anchor="using"
             title="Using Link-Local Address on Infrastructure Links"
             toc="default">
      <t>This document proposes to use only link-local addresses (LLA) on all
      router interfaces on infrastructure links. Routers typically do not need
      to be reached from from users of the network, nor from outside the
      network. For an network operator there may be reasons to send packets to
      an infrastructure link for certain monitoring tasks; we suggest that
      many of those tasks could also be handled differently, not requiring
      routable address space on infrastructure links.</t>

      <section anchor="approach" title="The Suggested Approach" toc="default">
        <t>Neither global IPv6 addresses nor unique local addresses are
        configured on infrastructure links. In the absence of specific global
        or unique local address definitions, the default behavior of routers
        is to use link-local addresses. These link-local addresses MAY be
        hard-coded to prevent the change of EUI-64 addresses when changing of
        MAC address (such as after changing a network interface card).</t>

        <t><xref target="RFC4443">ICMPv6</xref> error messages
        (packet-too-big...) are required for routers, therefore a loopback
        interface MUST be configured with a global scope IPv6 address. This
        global scope IPv6 address MUST be used as the source IPv6 address for
        all generated ICMPv6 messages.</t>

        <t>The effect on specific traffic types is as follows:<list
            style="symbols">
            <t>Control plane protocols, such as BGP, ISIS, OSPFv3, RIPng, PIM
            work by default or can be configured to work with link-local
            addresses.</t>

            <t>Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo
            request ... can be addressed to loopback addresses of routers with
            a global scope address. Router management can also be done over
            out-of-band channels.</t>

            <t>ICMP error message can also be sourced from the global scope
            loopback address.</t>

            <t>Data plane traffic is forwarded independently of the link
            address type.</t>

            <t>Neighbor discovery (neighbor solicitation and neighbor
            advertisement) is done by using link-local unicast and multicast
            addresses, therefore neighbor discovery is not affected.</t>
          </list>We therefore conclude that it is possible to construct a
        working network in this way.</t>
      </section>

      <section anchor="advantages" title="Advantages" toc="default">
        <t>Smaller routing tables: Since the routing protocol only needs to
        carry one loopback address per router, it is smaller than in the
        traditional approach where every infrastructure link addresses are
        carried in the routing protocol. This reduces memory consumption, and
        increases the convergence speed in some routing failover cases. Note:
        smaller routing tables can also be achieved by putting interfaces in
        passive mode for the IGP.</t>

        <t>Reduced attack surface: Every globally routable address on a router
        constitutes a potential attack point: a remote attacker can send
        traffic to that address, for example a TCP SYN flood, or he can intent
        SSH brute force password attacks. If a network only uses loopback
        addresses for the routers, only those loopback addresses need to be
        protected from outside the network. This significantly eases
        protection measures, such as infrastructure access control lists. See
        also <xref target="I-D.ietf-grow-private-ip-sp-cores"/> for further
        discussion on this topic.</t>

        <t>Lower configuration complexity: LLAs require no specific
        configuration, thereby lowering the complexity and size of router
        configurations. This also reduces the likelihood of configuration
        mistakes.</t>

        <t>Simpler DNS: Less address space in use also means less DNS mappings
        to maintain.</t>
      </section>

      <section anchor="caveats" title="Caveats and Possible Workarounds"
               toc="default">
        <t>Interface ping: If an interface doesn't have a globally routable
        address, it can only be pinged from a node on the same link. Therefore
        it is not possible to ping a specific link interface remotely. A
        possible workaround is to ping the loopback address of a router
        instead. In most cases today it is not possible to see which link the
        packet was received on; however, <xref target="RFC5837">RFC5837</xref>
        suggests to include the interface identifier of the interface a packet
        was received on in the ICMP response; it must be noted that there are
        little implemented of this extension. With this approach it would be
        possible to ping a router on the loopback address, yet see which
        interface the packet was received on. To check liveliness of a
        specific interface it may be necessary to use other methods, for
        example to connect to the router via SSH and to check locally.</t>

        <t>Traceroute: Similar to the ping case, a reply to a traceroute
        packet would come from a loopback address with a global address. Today
        this does not display the specific interface the packets came in on.
        Also here, <xref target="RFC5837">RFC5837</xref> provides a
        solution.</t>

        <t>Hardware dependency: LLAs are usually EUI-64 based, hence, they
        change when the MAC address is changed. This could pose problem in a
        case where the routing neighbor must be configured explicitly (e.g.
        BGP) and a line card needs to be physically replaced hence changing
        the EUI-64 LLA and breaking the routing neighborship. But, LLAs can be
        statically configured such as fe80::1 and fe80::2 which can be used to
        configure any required static routing neighborship.</t>

        <t>NMS toolkits: If there is any NMS tool that makes use of interface
        IP address of a router to carry out any of NMS functions, then it
        would no longer work, if the interface is missing globally routable
        address. A possible workaround for such tools is to use the globally
        routable lopback address of the router instead.</t>

        <t>MPLS and RSVP-TE <xref target="RFC3209"/> allows establishing MPLS
        LSP on a path that is explicitly identified by a strict sequence of IP
        prefixes or addresses (each pertaining to an interface or a router on
        the path). This is commonly used for FRR. However, if an interface
        uses only a link-local address, then such LSPs can not be established.
        A possible workaround is to use loose sequence of IP prefixes or
        addresses (each pertaining to a router) to identify an explicit path
        along with shared-risk-link-group (to not use a set of common
        interfaces).</t>
      </section>

      <section title="Summary" toc="default">
        <t>Using link-local addressing only on infrastructure links has a
        number of advantages, such as a smaller routing table size and a
        reduced attack surface. It also simplifies router configurations.
        However, the way certain network management tasks are carried out has
        to be adapted to provide the same level of detail, for example
        interface identifiers in traceroute.</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>Using LLAs only on infrastructure links reduces the attack surface of
      a router: Loopback addresses with globally routed addresses are still
      reachable and must be secured, but infrastructure links can only be
      attacked from the local link. This simplifies security of control and
      management planes. The proposal does not impact the security of the data
      plane. This proposal does not address <xref target="RFC6192">control
      plane</xref> attacks generated by data plane packets (such as hop-limit
      expiration).</t>

      <t>As in the traditional approach, also this approach relies on the
      assumption that all routers can be trusted due to physical and
      operational security.</t>
    </section>

    <section title="IANA Considerations">
      <t>There are no IANA considerations or implications that arise from this
      document.</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors would like to thank Salman Asadullah, Janos Mohacsi and
      Wes George for their useful comments about this work.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      &RFC2119;
    </references>

    <references title="Informative References">
      &RFC3209;

      &RFC4193;

      &RFC4443;

      &RFC5837;

      &RFC6192;

      &I-D.ietf-grow-private-ip-sp-cores;
    </references>
  </back>
</rfc>