draft-baker-ipv6-isis-dst-src-routing.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section, 
                                 otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a 
                                 string such as <29> printed in the blank line at the 
                                 beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.  
         Note the ToC may be omitted for very short documents, but idnits insists on a ToC 
         if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="4"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references. 
         Some like symbolic tags in the references (and citations) and others prefer 
         numbers. The RFC Editor always uses symbolic tags.
         The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc rfcprocack="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
                                 This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each 
         main section on a new page but does not omit the blank lines between list items. 
         If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-baker-ipv6-isis-dst-src-routing-08"
     ipr="trust200902">
  <front>
    <title abbrev="IS-IS Source/Destination Routing">IPv6 Source/Destination
    Routing using IS-IS</title>

    <author fullname="Fred Baker" initials="F.J." surname="Baker">
      <organization/>
      <address>
        <postal>
          <street/>
          <city>Santa Barbara</city>
          <code>93117</code>
          <region>California</region>
          <country>USA</country>
        </postal>
        <email>FredBaker.IETF@gmail.com</email>
      </address>
    </author>

    <author fullname="David Lamparter" initials="D." surname="Lamparter">
      <organization>NetDEF</organization>
      <address>
        <postal>
          <street/>
          <city>Leipzig</city>
          <code>04229</code>
          <region></region>
          <country>Germany</country>
        </postal>
        <email>david@opensourcerouting.org</email>
      </address>
    </author>

    <date/>
    <area>Internet Engineering Task Force</area>

    <workgroup/>

    <abstract>
      <t>This note describes the changes necessary for IS-IS to route IPv6
      traffic from a specified prefix to a specified prefix.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This specification defines how to exchange <xref
          target="I-D.ietf-rtgwg-dst-src-routing">destination/source
          routing</xref> information in <xref target="RFC5308">IS-IS for
          IPv6</xref> routing environments.  To this extent, a new sub-TLV for
        an <xref target="RFC2460">IPv6</xref> Source Prefix is added, and 
        <xref target="RFC5120">Multi Topology Routing</xref> is employed to
        address compatibility and isolation concerns.</t>

      <t>The router MUST implement the Destination/Source Routing mechanism
      described in <xref target="I-D.ietf-rtgwg-dst-src-routing"/>.
      This implies not simply routing "to a destination", but routing "to
      that destination AND from a specified source".
      The obvious application is egress routing, as required for a multihomed
      entity with a provider-allocated prefix from each of several upstream
      networks. Traffic within the network could be source/destination routed
      as well, or could be implicitly or explicitly routed from "any prefix",
      ::/0. Other use cases are described in <xref
      target="I-D.baker-rtgwg-src-dst-routing-use-cases"/>. If a FIB contains
      a route to a given destination from one or more prefixes not including
      ::/0, and a given packet destined there that has a source address that
      is in none of them, the packet in effect has no route, just as if the
      destination itself were not in the route table.</t>

      <?rfc needLines="5" ?>

      <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"/>.</t>
      </section>
    </section>

    <section anchor="routing" title="Theory of Routing">
      <t>Both IS-IS and OSPF perform their calculations by building a lattice
      of routers and links from the router performing the calculation to each
      router, and then use routes (sequences in the lattice) to get to
      destinations that those routes advertise connectivity to. Following the
      SPF algorithm, calculation starts by selecting a starting point
      (typically the router doing the calculation), and successively adding
      {link, router} pairs until one has calculated a route to every router in
      the network. As each router is added, including the original router,
      destinations that it is directly connected to are turned into routes in
      the route table: "to get to 2001:db8::/32, route traffic to {interface,
      list of next hop routers}". For immediate neighbors to the originating
      router, of course, there is no next hop router; traffic is handled
      locally.</t>

      <t>In this context, the route is qualified by a source prefix; It is
      installed into the FIB with the destination prefix, and the FIB applies
      the route if and only if the IPv6 source address also matches the
      advertised prefix. Of course, there may be multiple LSPs in the RIB with
      the same destination and differing source prefixes; these may also have
      the same or differing next hop lists. The intended forwarding action is
      to forward matching traffic to one of the next hop routers associated
      with this destination and source prefix, or to discard non-matching
      traffic as "destination unreachable".</t>

      <t>TLVs that lack a source prefix sub-TLV match any source address
      (i.e., the source prefix TLV defaults to ::/0), by definition.</t>

      <t>To ensure that routers without support for Destination/Source routing
        are excluded from path calculation for routes with a non-default source
        prefix, a separate MTID is used to carry Destination/Source routes.  A
        router MUST NOT participate in a topology with such an MTID unless it
        implements Destination/Source routing.</t>

      <t>There is a distinct Destination/Source Routing MTID for each of the
        underlying base MT topologies the information applies to.  The set of
        routes propagated towards the forwarding plane is the union of the
        information in the base topology and the D/S Routing MTID.  Incoming
        connectivity information with a default or non-present source prefix
        is advertised in the base topology, routes with non-default source
        prefix are advertised in the D/S Routing MTID.</t>

      <?rfc needLines="5" ?>

      <section title="Notation">
        <t>For the purposes of this document, a route from the prefix A to the
        prefix B (in other words, whose source prefix is A and whose
        destination prefix is B) is expressed as A-&gt;B. A packet with the
        source address A and the destination address B is similarly described
        as A-&gt;B.</t>
      </section>

      <?rfc needLines="5" ?>

      <section title="Dealing with ambiguity">
        <t>In any routing protocol, there is the possibility of ambiguity. For
        example, one router might advertise a fairly general prefix - a
        default route, a discard prefix (which consumes all traffic that is
        not directed to an instantiated subnet), or simply an aggregated
        prefix while another router advertises a more specific one. In
        source/destination routing, potentially ambiguous cases include cases
        in which the link state database contains two routes A-&gt;B' and
        A'-&gt;B, in which A' is a more specific prefix within the prefix A
        and B' is a more specific prefix within the prefix B. Traditionally,
        we have dealt with ambiguous destination routes using a "longest match
        first" rule. If the same datagram matches more than one destination
        prefix advertised within an area, we follow the route with the longest
        matching prefix.</t>

        <t>With source/destination routes, as noted in <xref
        target="I-D.baker-rtgwg-src-dst-routing-use-cases"/>, we follow a
        similar but slightly different rule; the FIB lookup MUST yield the
        route with the longest matching destination prefix that also matches
        the source prefix constraint. In the event of a tie on the destination
        prefix, it MUST also match the longest matching source prefix among
        those options.</t>

        <t>An example of the issue is this. Suppose we have two routes: <list
            style="numbers">
            <t>2001:db8:1::/48 -&gt; 2001:db8:3:3::/64</t>

            <t>2001:db8:2::/48 -&gt; 2001:db8:3::/48</t>
          </list></t>

        <t>and a packet <list style="empty">
            <t>2001:db8:2::1 -&gt; 2001:db8:3:3::1</t>
          </list></t>

        <t>If we require the algorithm to follow the longest destination match
        without regard to the source, the destination address matches
        2001:db8:3:3::/64 (the first route), and the source address doesn't
        match the constraint of the first route; we therefore have no route.
        The FIB algorithm, in this example, must therefore match the second
        route, even though it is not the longest destination match, because it
        also matches the source address.</t>
      </section>

      <?rfc needLines="5" ?>

      <section title="Multi-topology Routing">
        <t>As outlined in <xref target="routing"/>, this document specifies the
          use of separate topologies for <xref target="RFC5120">Multi Topology
            Routing</xref> to carry Destination/Source routing information.
          These topologies form pairs with a base topology each as follows:</t>
        <figure title="Destination/Source Routing MTIDs" anchor="mtids">
          <artwork align="left"><![CDATA[
base               base    D/S
designated usage   MTID    MTID
----------------------------------
default topology   0       TBD-MT0
IPv4 management    1       n/a
IPv6 default       2       TBD-MT2
IPv4 multicast     3       n/a
IPv6 multicast     4       n/a
IPv6 management    5       TBD-MT5
]]></artwork></figure>

        <t>The rationale for in-/excluding base MTIDs to provide a D/S MTID for
          is as follows:</t>
        <t><list style="hanging">
            <t hangText="MTID 0:">The base (non-MTR) topology in some
              installations carries all routing information, including IPv6
              reachabilities.  In such a setup, the topology with MTID TBD-MT0
              is used to carry associated D/S reachabilities.
            </t>
            <t hangText="MTIDs 1 and 3:">Topologies with MTID 1 and 3 carry
              exclusively IPv4 reachabilities.  Thus, no IPv6 D/S topology is
              created to associate with them.</t>
            <t hangText="MTID 2:">The topology with MTID 2 carries IPv6
              reachabilities in common M-ISIS setups.  (MTID 0 in such cases
              carries exclusively IPv4 reachability information.)  Associated
              IPv6 D/S reachabilities MUST be carried in MTID TBD-MT2.</t>
            <t hangText="MTID 4:">MTID 4, while carrying IPv6 connectivity
              information, is used for multicast RPF lookups.  Since
              Destination/Source routing is not compatible with multicast
              RPF lookups, no associated D/S MTID is defined for IS-IS.</t>
            <t hangText="MTID 5:">An alternate management/administration
              topology may carry its routing information in MTID 5.
              Destination/Source routing is applicable to this and MUST use
              MTID TBD-MT5 to carry associated reachability TLVs.</t>
        </list></t>

        <t>Note that the different topology ID is the sole and only mechanism
          of both capability detection and backwards compatibility.  D/S
          routing will operate correctly if D/S routing information is put in
          the same topology as non-D/S information, but adding an IS that does
          not support D/S routing will then -undetectably- lead to incorrect
          routing decisions, possibly including loops.</t>

        <t>Therefore, all routers participating in D/S routing MUST implement
          M-ISIS and participate in the appropriate D/S topology per the table
          above.  Conversely, routers not supporting D/S routing (or not
          configured to participate) MUST NOT participate in these topologies.
          Even installations that previously used only MTID 0 (i.e. no M-ISIS)
          would need to start using M-ISIS on all D/S routers.  This results
          in correct operation in the face of partial deployment of D/S
          routing.</t>

        <t>Note it is implied by the separate topology that there is a separate
          SPF calculation for that topology - using only the participants of
          that topology - and D/S routes use paths according to the result from
          that calculation.  This is an aspect of Multi-topology operation
          itself, not this document.</t>

        <t>Routers MUST NOT advertise non-D/S routing information using a
          D/S-Routing MTID.  This includes both reachability information
          with a source prefix TLV with value ::/0, as well as without a
          source prefix sub-TLV.  On receipt, routers MUST ignore any
          reachability information in a D/S-Routing MTID that does not have
          non-default source prefix information.</t>

        <t>To limit complexity, each IPv6 Reachability TLV in a D/S-Routing
          MTID MUST have exactly one Source Prefix sub-TLV.  Routers MUST NOT
          advertise TLVs with more than one Source Prefix sub-TLV, and MUST
          ignore any received TLV with more than one Source Prefix sub-TLV.</t>

        <t>Systems that use topology IDs different than the values reserved by
          IANA should apply the considerations from this section
          analogously.</t>
      </section>

      <section title="Migration and partial deployments">
        <t>The Multi-topology mechanism described in the previous section
          introduces a distinct, independently operating topology that covers
          D/S routers.  This easily allows partial and incremental deployments.
        </t>

        <t>Such deployments then contain one or more D/S "subdomains" of
          neighboring routers that have D/S routing capability.  Since shortest
          paths for D/S routes are calculated using a separate topology,
          traffic routed on D/S routes will be forwarded inside such a
          subdomain until it reaches the router originating the
          reachability.</t>

        <t>Routers unaware or not participating in D/S routing will in such a
          case forward traffic according to only non-D/S routes.  This can
          produce 2 distinct outcomes:
          <list style="numbers">
            <t>Traffic traverses a D/S router, where a more specific D/S route
              matches (and SPF in the D/S topology has found a valid path).
              It is then kept inside the D/S subdomain, reaching
              an originator of the D/S route.</t>
            <t>Traffic reaches a system originating a non-D/S route or is
              considered unroutable even without regard to D/S routes.</t>
          </list>
        </t>

        <t>Since the latter case provides no guarantee that there is no D/S
          route in the routing domain that could have matched, operators must
          pay careful attention to where non-D/S reachabilities are originated
          when more specific D/S routes are covered by them.</t>

        <t>A very simple configuration that guarantees correct operation is to
          ensure covering destination-only reachabilities for D/S routes are
          originated by D/S routers themselves, and only by them.  This results
          in traffic entering the D/S subdomain and D/S routes applying.</t>

        <t>Lastly, in partial deployments, disconnected D/S subdomains may
          exist.  Routers in such a subdomain cannot calculate a path for
          reachabilities in a subdomain they're not in.  In this case a router
          MAY discard packets matching a D/S reachability for which it was
          unable to calculate a valid path.  Alternatively, it MAY behave
          as if the D/S reachability didn't exist to begin with, i.e. routing
          the packet using the next less specific route (which could be D/S or
          non-D/S).  It MUST NOT keep stale SPF calculation results that have
          become invalid as result of the topology partition.</t>

        <t>This can be remediated by the operator adding connectivity between
          the subdomains, for example using some tunneling interface.  The new
          link is then used to form an IS-IS adjacency fusing the previously
          split subdomains.  The link will then be used to forward D/S traffic,
          possibly incurring some tunnel encapsulation overhead.  To the IS-IS
          implementation, this link is no different from other links.</t>
      </section>
    </section>

    <section anchor="new-tlvs"
             title="Protocol encoding for IPv6 Source Prefix information">
      <t>Destination/Source reachabilities are originated using TLV 237, using
        an additional sub-TLV to carry the source prefix as follows.</t>

      <t>As noted in <xref target="routing"/>, any IPv6 Reachability TLV that
        does not specify a source prefix is functionally identical to
        specifying ::/0 as the source prefix.  Such routes SHOULD NOT be
        originated into the D/S MTID, but rather into the base MTID.</t>

      <section anchor="IS-IS-source" title="Source Prefix sub-TLV">
        <?rfc needLines="10"?>
        <t>The following Sub-TLV is defined for TLV 237:</t>

        <figure title="Source Prefix Sub-TLV">
          <artwork align="center"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |    Length     |Prefix Length  |    Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>


        <t><list style="hanging">
            <t hangText="Source Prefix Type:">TBD-TLV (assigned by IANA)</t>

            <t hangText="TLV Length:">Length of the sub-TLV in octets</t>

            <t hangText="Prefix Length:">Length of the prefix in bits</t>

            <t hangText="Prefix:">(source prefix length+7)/8 octets of
            prefix</t>
        </list></t>
        <t>This Sub-TLV MUST occur exactly once in all reachability originated
          in any of the D/S topologies listed in <xref target="mtids"/>.  A
          reachability in these topologies with the Sub-TLV either missing or
          present more than once MUST be ignored in its entirety.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>IANA is requested to allocate Values from the "IS-IS Multi-Topology ID Values" registry as follows:</t>
      <t><list style="hanging">
          <t hangText="TBD-MT0:">IPv6 Dest/Source routing corresponding to topology 0</t>
          <t hangText="TBD-MT2:">Reserved for IPv6 Dest/Source routing corresponding to topology 2</t>
          <t hangText="TBD-MT5:">Reserved for IPv6 Dest/Source routing corresponding to topology 5</t>
      </list></t>
      <t>Additionally, IANA is requested to allocate an IS-IS codepoint from
        the "Sub-TLVs for TLVs 135, 235, 236, and 237" registry:</t>
      <t><list style="hanging">
          <t hangText="Type:">TBD-TLV</t>
          <t hangText="Description:">IPv6 SADR Source Prefix</t>
          <t hangText="Applicable to TLV 237:">Yes</t>
          <t hangText="Applicable to TLVs 135, 235, 236:">No</t>
      </list></t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The same injection and resource exhaustion attack scenarios as with
        all routing protocols apply.</t>
      <t>Security considerations from <xref
          target="I-D.ietf-rtgwg-dst-src-routing"/> are particularly
        relevant to this document, in particular the possibility to inject
        (more) specific routes to hijack traffic.</t>
    </section>

    <section anchor="Privacy" title="Privacy Considerations">
      <t>No privacy considerations apply to this document, as it only specifies
        routing control plane information.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Thanks to Les Ginsberg, Chris Hopps, Acee Lindem, Chris Bowers and
        Tony Przygienda for valuable feedback on this document.  (TODO:
        incomplete, and sort by name.)</t>
    </section>
  </middle>

  <back>
    <!-- references split to informative and normative -->

    <references title="Normative References">
      <reference anchor="IS-IS">
        <front>
          <!--   [IS-IS]    ISO/IEC 10589:2002, Second Edition, "", 2002. -->
          <title>Intermediate System to Intermediate System Intra-Domain
            Routing Exchange Protocol for use in Conjunction with the Protocol
            for Providing the Connectionless-mode Network Service (ISO
            8473)</title>
          <author>
            <organization>ISO/IEC</organization>
          </author>
          <date year="2002"/>
        </front>
        <seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
      </reference>

      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.2460" ?>

      <?rfc include="reference.RFC.5120" ?>

      <?rfc include="reference.RFC.5308" ?>

      <?rfc include="reference.I-D.ietf-rtgwg-dst-src-routing"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.baker-rtgwg-src-dst-routing-use-cases"?>
      <?rfc include="reference.I-D.baker-ipv6-isis-dst-flowlabel-routing"?>
    </references>

    <section title="Correctness considerations">
      <t>While Multi-Topology routing in general can be assumed to work
        correctly when used on its own, this may not apply to a scenario mixing
        route calculation results as suggested in this document.  However,
        this specific application is easily understandable as correct:</t>
      <t><list>
          <t>Systems that do not implement D/S routing will not participate in
            the D/S topology.  They will calculate SPF in the base topology.
            Packets routed by such system will either (a) cross only non-D/S
            routers and reach the last hop as intended, or (b) cross a D/S
            router at some point.</t>
          <t>For case (b), the D/S router may (b1) or may not (b2) have a more
            specific D/S route with a valid path.  In case (b2), packets will
            be routed based on the same decisions that a non-D/S system would
            apply, so they will reach their last hop without any
            differences.</t>
          <t>For case (b1), a break in forwarding behaviour happens for packets
            as they hit the first D/S-capable router, possibly after traversing
            some non-D/S systems.  That router will apply D/S routing - which,
            since the path calculation is performed in the D/S topology, means
            that the packet is from there on routed on a path that only
            contains D/S capable systems.  It will thus reach the D/S last hop
            as intended.</t>
          <t>Packets starting out on a D/S-capable router fall into cases (b1)
            or (b2) as if a non-D/S router routed them first.</t>
          <t>For both cases (b1) and (b2), a situation where a D/S router
            is aware (by flooding) of a more specific D/S route, but can't
            calculate a valid path (because the MT topology is not contiguous),
            this is for correctness concerns identical to the D/S route not
            existing to begin with.  Note below on the correctness of this.</t>
      </list></t>
      <t>The compatibility mechanics thus rest on 2 pillars:
        <list>
          <t>D/S routes will match as more specific if applicable</t>
          <t>Packets will transit into D/S routing but not out of it</t>
      </list></t>
      <t>Note that the latter assumption holds true even if D/S routers fall
        back to non-D/S paths if they cannot calculate a shortest path towards
        the advertising system (either because SPF reaches the maximum path
        metric, or because there are multiple discontiguous D/S subdomains).
        This is because if a router A receives a packet routed on a D/S path,
        this implies the previous router B was able to successfully calculate
        SPF, via A, and that A has a path towards the originating system with a
        lower path metric than B.  Conversely, if router A is unable to find
        a valid path, it is safe to assume router B was unable to do so either,
        and B forwarded the packet on a path calculated on non-D/S
        information.</t>
      <t>Lastly, in terms of application use cases, it is also worth pointing
        out that loops will always result if (for example on a boundary to
        an upstream) the prefix routed incoming to the IS-IS domain is not
        fully covered by routes.  Just as in non-D/S routing, this may cause
        a less specific (default) route to apply and loop packets back onto
        the same upstream.  With D/S routing, this can now also occur if the
        incoming prefix is not covered for all sources.  The solution remains
        the same:  making sure the entire prefix is covered (for all sources),
        usually with a discard route.  This is not an IS-IS consideration.</t>
    </section>

    <section anchor="log" title="Change Log">
      <t>(to be removed)</t>
      <t><list style="hanging">
          <t hangText="Initial Version:">February 2013</t>

          <t hangText="updated Version:">August 2013</t>

          <t hangText="Added MTR:">August 2014</t>

	  <t hangText="Split into 4 drafts:">October 2014</t>

	  <t hangText="Dropped 'Critical Sub-TLV' drafts">June 2015</t>

          <t hangText="MT clarifications">October 2015</t>
        </list></t>
    </section>
  </back>
</rfc>