draft-ietf-rtgwg-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="yes" ?>
<!-- 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/sections... 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-llsyang-rtgwg-dst-src-routing-00"
     ipr="trust200902">
  <front>
    <title abbrev="Destination/Source Routing">
      Destination/Source Routing</title>

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

    <author fullname="Anton Smirnov" initials="A." surname="Smirnov">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>De Kleetlaan 6a</street>
          <city>Diegem</city>
          <region/>
          <code>1831</code>
          <country>Belgium</country>
        </postal>
        <email>as@cisco.com</email>
      </address>
    </author>
    <author fullname="Jen Linkova" initials="J." surname="Linkova">
      <organization>Google</organization>
      <address>
        <postal>
          <street>1 Darling Island Rd</street>
          <city>Pyrmont NSW</city>
          <region/>
          <code>2009</code>
          <country>Australia</country>
        </postal>
        <email>furry@google.com</email>
      </address>
    </author>  
  <author fullname="Shu Yang" initials="S." surname="Yang">
      <organization>Shenzhen University</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region/>
          <code></code>
          <country>China</country>
        </postal>
        <email>yang.shu@szu.edu.cn</email>
      </address>
    </author>  
    <date/>
    <area>Routing</area>
    <workgroup>rtgwg</workgroup>
    <abstract>
      <t>This note specifies using packets' source addresses in route lookups
        as additional qualifier to be used in hop-by-hop routing decisions.
        This applies to <xref target="RFC2460">IPv6</xref> in general with
        specific considerations for routing protocol left for separate
        documents.  There is nothing precluding similar operation in IPv4, but
        this is not in scope of this document.
      </t>
      <t>Note that destination/source routing, source/destination routing,
        SADR, source-specific routing, source-sensitive routing, S/D routing
        and D/S routing are all used synonymously.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Both <xref target="RFC0791">IPv4</xref> and
        <xref target="RFC2460">IPv6</xref> architectures specify that
        determination of the outgoing next-hop for packet forwarding is based
        solely on the destination address contained in the packet header. There
        exists class of network design problems which require packet forwarding
        to consider more than just the destination IP address (see <xref
          target="usecases"/> for examples).</t>
      <t>
        At present these problems are routinely resolved by configuring special
        forwarding based on a local policy on routers. The policy enforces
        packet forwarding decision outcome based not only on the destination
        address but also on other fields in the packet's IP header, most
        notably the source address. Such policy-based routing is conceptually
        similar to static routes in that it is highly static in nature and must
        be closely governed via the management plane (most frequently - via
        managing configuration by an operator). Thus policy-based routing
        configuration and maintenance is costly and error-prone.</t>

      <t>Rapid expansion of IPv6 to networks were static configuration
        is not acceptable due to both its static nature and necessity
        of frequent intervention by a skilled operator requires change
        in the paradigm of forwarding IP packets based only on their
        destination address.</t>

      <t>This document describes architecture of destination-source
        routing. It includes both forwarding plane and control plane
        considerations and requirements.  Specific considerations for
        particular dynamic routing protocols are outside of the scope of
        this note and will be covered in separate documents, for example
        handling of a noncontiguous sub-topology in a link-state protocol.</t>

      <t>General concepts covered by this document are equally
        applicable to both IPv4 and IPv6. Considering the implementation
        complexity of backward compatibility of destination-source routing
        with traditional destination-only routing, IPv4 is left outside the
        scope of this document.</t>
      <!-- todo: revisit -->

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

    <section title="Use cases" anchor="usecases">
      <section title="Multihomed networks with provider assigned prefixes"
          anchor="multihome">
        <t>There are good reasons for networks to be multihomed - benefits of
          doing this may include redundandy, better performance or faster
          access to important resources (for example, video or cloud services)
          local to ISPs.</t>
        <t>However, in a range from smaller home networks to
          even larger enterprises, it is likely that each service provider
          will assign some address space (from their PA allocation) to the
          network.</t>


        <?rfc needLines="16"?>
        <figure title="Example of multihomed small network">
          <artwork align="center">
                         _____                ,,-------.
                       _(     )_            ,'          ``.
    ___    +----+    _(         )_        ,'               `.
   /   \---| R1 |---(_   ISP 1   _)------/                   \
  /     \  +----+     (_       _)       /                     \
 / Small \              (_____)        (                       )
(         )                            (     The Internet      )
(         )              _____         (                       )
 \  net  /             _(     )_        \                     /
  \     /  +----+    _(         )_       \                   /
   \___/---| R2 |---(_   ISP 2   _)-------`.               ,'
           +----+     (_       _)           `.           ,'
                        (_____)               ``-------''
        </artwork>
      </figure>

      <t>In this situation, providers are expected to perform ingress
        filtering according to <xref target="RFC2827">BCP 38</xref>.
        Ths means only packets with a source address from the prefix that
        the provider assigned will be accepted.  In addition, the assigned
        prefix can usually not be expected to remain the same.</t>

      <t>Conventionally, NAT or policy routing would be used to produce
        correct behaviour.  These are not desirable solutions:   NAT66
        breaks end-to-end connectivity (and may restrict concurrent use of
        parallel paths.)  Policy routing requires a sufficiently skilled
        operator to manually manage these policies.</t>

      <t>By assigning addresses from multiple prefixes each to end host
        (as a policy routing solution could do), the choice of uplink is
        left to host, including the option to choose multiple at once.
        Destination-source routing provides the neccessary behaviour for
        routers (e.g. R1 and R2 in above example) to forward packets to
        the appropriate exit.  It does so without requiring the manual
        configuration maintenance that policy routing would entail.</t>

      <t>For a general introduction and aspects of interfacing routers to
        hosts, refer to <xref target="RFC8043"/>.</t>
      </section>

      <section title="Degree of traffic engineering">
        <t>Consider enterprise consisting of a headquarter (HQ) and
          branch offices. A branch office is connected to the
          enterprise HQ network via 2 links. For performance or
          security reasons it is desired to route corporate traffic
          via one link and Internet traffic via another link. In
          direction branch -> HQ the problem is easily solvable by
          having the default route pointing to the Internet link and
          HQ routes pointing to another link. But destination routing
          does not provide an easy way to achieve traffic separation
          in direction HQ -> branch because destination is the same
          (branch network).</t>

        <t>Source-destination routing provides an easy way to sort
          traffic going to the branch based on its source address.</t>
      </section>

      <section title="Distributed filtering based on source address">
        <t>A network has untrusted zone and secure one (and both zones
          comprise many links and routers). Computers from the secure
          zone need to be able to communicate with some selected hosts
          in the untrusted zone. The secure zone is protected by a
          firewall. The firewall is configured to check that packets
          arriving from the untrusted zone have destination address in
          the range of secure zone and source address of trusted
          hosts in the untrusted zone. This works but leaves the
          firewall open to DDOS attack from outside.</t>

        <t>If routers in the untrusted zone are configured with
          destination-source routing (and, possibly, unicast RPF
          check) and receive via dynamic routing protocol routes
          &lt;destination: secure zone; source: trusted host in the
          untrusted zone&gt; then DDOS attack is dropped by routers on
          the edge of destination-source routing area. DDOS attack
          does not even reach the firewall whose resources are freed
          to deal with Deep Packet Inspection. On the other hand,
          security policy is managed in a single point - on a router
          injecting relevant destination-source routes into the
          dynamic routing protocol.</t>
      </section>

      <section title="Walled-garden Enterprise services">
        <t>Apart from transfering from multihomed personal networks to
          multihomed PA enterprise setups without any changes,
          destination-source routing can also be used to correctly
          route services that assign their own prefixes to customers using
          the particular service.  This is distinct from internet
          connectivity only in that it does not provide a default route.
          Applying destination-source routing, the entire routing domain
          is aware of the specific constraints of the routes involved.</t>
        <t>Additionally, if the walled-garden's destination prefix is
          advertised as blackhole route, this ensures that communication
          with the service will only be routed using the specific D/S route,
          never leaking onto unintended paths like a default route.</t>
        <t>This is very similar to firewall/filtering functionality, except
          the feature is distributed onto routers.</t>
      </section>

      <section title="Information Source for Neighbor Management">
        <t>Having information on source address restrictions for routes
          distributed, routers can rely on this additional information to
          improve their behaviour towards hosts connected to them.  This
          specifically includes IPv6 Router Advertisements, which is described
          in <xref target="RFC8028"/> and <xref
            target="I-D.linkova-v6ops-conditional-ras"/>.</t>
      </section>
    </section>

    <section title="Principle of operation">
      <section title="Frame of reference">
        <t>The principles described here are define on a functional level what
          the semantics of routing information exchanged between systems is.
          It is neither a prescription in how to efficiently implement these
          semantics, nor does it preclude an implementation from providing
          other administrator-friendly views of the same routing
          information.</t>

        <t>More specifically, forwarding plane implementations are expected to
          internally diverge from the lookup algorithm described below.  The
          router as a whole MUST ultimately behave as if the steps below were
          followed.  An internal variation providing improved performance,
          as well as a variation matching existing implementations with
          reversed order are described in <xref target="nobacktrack"/>
          and <xref target="altlookup"/>, respectively.</t>
      </section>

      <section title="Route information and equality">
      <t>The mechanism in this document is such that a source prefix is added
        to all route entries.  This document assumes all entries have a source
        prefix, with ::/0 as default value for entries installed without a
        specified source prefix.  This need not be implemented in this
        particular way, however the system MUST behave exactly as if it were.
        In particular, a difference in behaviour between routes with a source
        prefix of ::/0 and routes without source prefix MUST NOT be visible.
      </t>
      <t>For uniqueness considerations, the source prefix factors MUST be
        taken into account for comparisons.  Two routes with identical
        information except the source prefix MAY exist and MUST be installed
        and matched.</t>
      </section>

      <section title="Lookup ordering and disambiguation" anchor="deflookup">
        <t>When a router is making packet forwarding decision, that
          is consulting its routing table in order to determine next-hop to
          forward the packet to, it will use information from packet's header
          to look up best matching route from the routing table. This section
          describes lookup into the destination-source routing table.</t>

        <t>For longest-match lookups, the source prefix is matched after the
          destination prefix.  This is to say, first the longest matching
          destination prefix is found, then the table is searched for the route
          with the longest source prefix match, while only considering routes
          with exactly the destination prefix previously found.  If and only if
          no such route exists (because none of the source prefixes match), the
          lookup moves to the next less specific destination prefix.</t>
        <t>A router MUST continue to a less specific destination prefix if no
          route matches on the source prefix.  It MUST NOT terminate lookup
          on such an event.</t>
        <t>Using A &lt; B to mean "A is more specific than B", this is
          represented as:</t>
        <figure><artwork><![CDATA[
A < B :=    Adst <  Bdst
        || (Adst == Bdst && Asrc < Bsrc)
]]>
</artwork>
        </figure>
      </section>

      <section title="Ordering Rationale">
        <t>Ordering of searching for address match is important and
          reversing it would lead to semantically different
          behavior. This standard requires most specific match on
          destination address to be found before looking for match on
          source address.</t>

        <t>Choosing destination to be evaluated first caters to the assumption
          that local networks should have full, contiguous connectivity to each
          other.  This implies that those specific local routes always match
          first based on destination, and use a zero ("all sources") source
          prefix.</t>

        <t>If the source prefix were to be matched first, this would result in
          a less specific (e.g. default) route with a source prefix to match
          before those local routes.  In other terms, this would essentially
          divide local connectivity into zones based on source prefix, which
          is not the intention of this document.</t>

        <t>Hence, this document describes destination-first match search.</t>
      </section>
    </section>

    <section title="Routing protocol considerations">
      <t>As with the destination-only routing, destination-source
        routes will typically be disseminated throughout the network
        by dynamic routing protocols. It is expected that multiple
        dynamic routing protocols will be adapted to the needs of
        destination-source routing architecture. Specification of
        dynamic routing protocols is outside of scope of this
        document. This section lists requirements and considerations
        for the dynamic destination-source routing protocols.</t>

      <section title="Source information">
        <t>Dynamic routing protocols will need to be able to propagate
          source range information together with destination prefix
          and other accompanying routing information. Source range
          information may be propagated with all destination prefixes
          or only some of them. Destination prefixes advertised
          without associated source range MUST be treated as having
          default source range ::/0.</t>

        <t>Dynamic routing protocols MUST be able to propagate
          multiple routes whose destination prefix is the same but
          associated source ranges are different. Such unique pairs of
          destination and source MUST be treated as different
          destination-source routes.</t>

        <t>There is no limitation on how source range information is
          propagated and associated with destination
          prefixes. Individual protocols may choose to propagate
          source range together with a destination prefix in the form
          of prefix, in the form of index to list of known source
          ranges or in any other form allowing receiver to reconstruct
          pair of destination prefix and associated source range.</t>
      </section>

      <section title="Loop-freeness considerations" anchor="loopfree">
        <t>It is expected that some existing dynamic routing protocols
          will be enhanced to propagate destination-source routing
          information. In this case the protocol may be configured to
          operate in a network where some, but not all, routers
          support destination-source routing and others are still
          using destination-only routing. Even if all routers within a
          network are capable of destination-source routing, it is
          very likely that on edges of the network they will have to
          forward packets to routers doing destination-only
          routing.</t>

        <t>Since a router implementing destination-source routing can
          have additional, more granular routes than one that doesn't
          implement it, persistent loops can form between these
          systems.</t>

        <t>Thus specifications of destination-source routing protocols
          (either newly defined protocols or enhancements to already
          existing one) MUST take provisions to guarantee loop-free
          operations.</t>

        <t>There are 3 possible approaches to avoid looping condition:</t>

        <t><list style="numbers">
            <t>Guarantee that next-hop gateway of a destination-source
              route supports destination-source routing, for example
              calculate an alternate topology including only routers
              that support destination-source routing architecture</t>

            <t>If next-hop gateway is not aware of destination-source
              routing then a destination-source path can lead to it
              only if next-hop router is 'closer' to the destination
              in terms of protocol's routing metric; important
              particular case of the rule is if destination-only
              routing is pointing to the same next-hop gateway</t>

            <t>Discard the packet (i.e. treat destination-source route
              as unreachable)</t>
        </list></t>

        <t>In many practical cases routing information on the edges of
          destination-source routing domain will be provided by an
          operator via configuration. Dynamic routing protocol will
          only disseminate this trusted external routing information.
          For example, returning to the use case of multihomed Home
          network (<xref target="multihome"/>), both routers R1 and R2
          will have default static routes pointing to ISPs.</t>

        <t>Above considerations require a knowledge of the next-hop
          router's capabilities. For routing protocols based on
          hop-by-hop flooding (<xref target="RFC2080">RIP</xref>,
          <xref target="RFC4271">BGP</xref>), knowing the peer's
          capabilities is sufficient. Information about if peer supports
          destination-source routing can either be negotiated
          explicitly or simply be deduced from the fact that systems
          would propagate destination-source routing information only
          if they understand it. Protocols building a link-state
          database (<xref target="RFC5340">OSPFv3</xref>, <xref
          target="RFC5308">IS-IS</xref>) have the additional
          opportunity to calculate alternate paths based on knowledge
          of the entire domain but cannot assume that routers
          understand destination-source routing information only
          because they participated in its flooding. Such protocols
          MUST explicitly advertise support for the destination-source
          routing.</t>
      </section>

      <section title="Recursive routing">
        <t>Dynamic routing protocols may propagate routing information
          in a recursive way. Examples of such recursion is forwarding
	  address in <xref target="RFC5340">OSPFv3</xref>
	  AS-External-LSAs and NEXT_HOP attribute in <xref
	  target="RFC4271">BGP</xref> NLRI.</t>

        <t>Dynamic routing protocol supporting recursive routes
          MUST specify how this recursive routing information is
          interpreted in the context of destination-source routing as
          part of standardizing destination-source routing extensions
          for the protocol. <xref target="recurs"/> lists several
          possible strategies protocols can choose from.</t>
      </section>
    </section>

    <section title="Applicability To Specific Situations">
      <t>This section discusses how destination-source routing is used
        together with some common networking techniques dependent on
        routes in the routing table.</t>

      <section title="Recursive Route Lookups" anchor="recurs">
        <t>Recursive routes provide indirect path information where
          instead of supplying the next-hop directly they specify that next-hop
          information must be taken from another route in the same routing
          table. It is said that one route 'recurses' via another route which
          is 'resolving' recursion. Recursive routes may either be carried by
          dynamic routing protocols or provided via configuration as recursive
          static routes.</t>

        <t>Recursive destination-source routes have additional
          complication in how source address range should be
          considered while finding destination-source route to resolve
          recusion.</t>

        <t>There are several possible approaches:</t>
        <t><list style="numbers">
          <t>Ignore destination-source routes, resolve recursion only
            via destination-only routes (i.e. routes with source range
            ::/0)</t>

          <t>Require that both the recursive and resolving routes have
            the same source range associated with them; this
            requirement may be too restrictive to be useful in many
            cases</t>

          <t>Require that source range associated with recursive route
            is a subset of source range associated with route
            resolving recursion (i.e. source range of the resolving
            route is less specific superset of recursive route's
            source range)</t>

          <t>Create multiple instances of the route whose nexthop is
            being resolved with different source prefixes; this
            option is further elaborated in <xref
            target="multiroute"/></t>
        </list></t>

        <t>When recursive routing information is propagated in a
          dynamic routing protocol, it is up to the protocol
          specification to select and standardize appropriate scheme
          of recusrsive resolution.</t>

        <t>Recursive resolution of configured static routes is local
          to router where recursive static routes were configured,
          thus behavior is implementation's choice. Implementations
          SHOULD provide option (3) from the above list as their
          default method of recursive static route resolution. This is
          both to guarantee that destination-only recursive static
          routes do not change their behavior when router's software
          is upgraded to support destination-source routing and at the
          same time make destination-source recursive routes
          useful.</t>

        <section title="Recursive route expansion" anchor="multiroute">
        <t>When doing recursive nexthop resolution, the route that is being
          resolved is installed in potentially multiple copies, inheriting all
          possible more-specific routes that match the nexthop as
          destination.  The algorithm to do this is:</t>
        <t><list style="numbers">
            <t>form the set of attributes for lookup by using the (unresolved,
              recursive) nexthop as destination (with full host prefix length,
              i.e. /128), copy all other attributes from the original route</t>
            <t>find all routes that overlap with this set of attributes
              (including both more-specific and less-specific routes)</t>
            <t>order the result from most to less specific</t>
            <t>for each route, install a route using the original route's
              destination and the "logical and" overlap of each extra match
              attribute with same attribute from the set.  Copy nexthop data
              from the route under iteration.  Then, reduce the set of extra
              attributes by what was covered by the route just installed
              ("logical AND NOT").</t>
        </list></t>
        <figure><preamble>Example recursive route resolution</preamble>
          <artwork>
route to be resolved:
2001:db8:1234::/48, source 2001:db8:3456::/48,
                    recursive nexthop via 2001:db8:abcd::1

routes considered for recursive nexthop:
::/0,                                              via fe80::1
2001:db8:abcd::/48,                                via fe80::2
2001:db8:abcd::/48,   source 2001:db8:3456:3::/64, via fe80::3
2001:db8:abcd::1/128, source 2001:db8:3456:4::/64, via fe80::4

recursive resolution result:
2001:db8:1234::/48,   source 2001:db8:3456::/48,   via fe80::2
2001:db8:1234::/48,   source 2001:db8:3456:3::/64, via fe80::3
2001:db8:1234::/48,   source 2001:db8:3456:4::/64, via fe80::4
</artwork>
        </figure>
        </section>
      </section>
      <section title="Unicast Reverse Path Filtering">
        <t>Unicast reverse path filtering MUST use dst-src routes analog to its
          usage of destination-only routes.  However, the system MAY match
          either only incoming source against routes' destinations, or it MAY
          match source and destination against routes' destination and
          source.  It MUST NOT ignore dst-src routes on uRPF checks.</t>
      </section>
      <section title="Multicast Reverse Path Forwarding">
        <t>Multicast Reverse Path Lookups are used to find paths towards the
          (known) sender of multicast packets.  Since the destination of these
          packets is the multicast group, it cannot be matched against the
          source part of a dst-src route.  Therefore, dst-src routes MUST be
          ignored for Multicast RPF lookups.</t>
      </section>
      <section title="Testing for Connectivity Availability">
        <t>There are situations where systems' behaviour depends on the fact
          whether "connectivity" is available in a broad sense.  These systems
          may have previously tested for the existence of a default route
          in the routing table.</t>
        <t>Since the default route may now be qualified with a source prefix,
          this test can fail.  If no additional information is available to
          qualify this test, systems SHOULD test for the existence of any
          default route instead, e.g. include routes with default destination
          but non-default source prefix.</t>
        <t>However, if the test can be associated with a source address or
          source prefix, this data SHOULD be used in looking up a default
          route.  Depending on the application, it MAY also be useful to -
          possibly additionally - consider "connectivity" to be available if
          any route exists where the route's source prefix covers the prefix
          or address under consideration, allowing arbitrary destination
          prefixes.</t>
        <t>Note though that this approach to routing SHOULD NOT be used to
          infer a list of source prefixes in an enumerative manner, or even to
          guess domain information.  Specifically, if an operator uses more
          specific source prefixes to refine their routing, the inferred
          information will provide bogus extraneous output.  This is distinct
          from the connectivity tests mentioned above in that those actually
          inquire the routing system, unlike domain information or enumeration,
          which is higher-layer application information.</t>
      </section>
    </section>

    <section title="Interoperability" anchor="interop">
      <t>As pointed out in <xref target="loopfree"/> traffic may
        permanently loop between routers forwarding packets based only
        on their destination IP address and routers using both source
        and destination addresses for forwarding decision.</t>

      <t>In networks where the same dynamic routing protocol is being
        used to propagate routing information between both types of
        systems the protocol may address some or all traffic looping
        problems. Recommendations to protocol designers are discussed
        in <xref target="loopfree"/>.</t>

      <t>When routing information is coming from outside of the
        routing protocol (for example, being provided by operator in
        the form of static routes or network protocols not aware of
        destination-source routing paradigm) it may not be possible
        for the router to ascertain loop-free properties of such
        routing information. In these cases consistent (and loop-free)
        packet forwarding is woven into network topology and must be
        taken into consideration at design time.</t>

      <t>It is possible to design network with mixed deployment of
        routers supporting and not supporting destination-source
        routing. Thus gradual enablement of destination-source routing
        in existing networks is also possible but has to be carefully
        planned and evaluated for each network design
        individually.</t>

      <t>Generally, destination-source routing will not cause traffic
        loops when disjoint 'islands' of destination-source routing do
        not exchange destination-source routing information. One
        particular case of this rule is a network which contains
        single contiguous 'island' of routers aware of
        destination-source routing. Example SOHO network from <xref
        target="multihome"/> which demonstrates this design
        approach:</t>

      <?rfc needLines="19"?>
        <figure title="Example of multihomed small network with
		       partial deployment of destination-source
		       routing">
          <artwork align="center">
                 ______             ___             ,,------.
                /      \          _(   )_         ,'         ``.
    ___        /      +----+    _(       )_     ,'              `.
   /   \      /       | R1 |---(_  ISP 1  _)---/                  \
  /     \----/        +----+     (_     _)    /                    \
 /  Dst  \  /   Source-    \       (___)     (                      )
(  only   )(  destination   )                (     The Internet     )
( routing )(     aware      )       ___      (                      )
 \ area  /  \   routing    /      _(   )_     \                    /
  \     /----\   area +----+    _(       )_    \                  /
   \___/      \       | R2 |---(_  ISP 2  _)----`.              ,'
               \      +----+     (_     _)        `.          ,'
                \______/           (___)            ``------''

|----------------------------|
        SOHO network
        </artwork>
      </figure>

      <section title="Interoperability in Distance-Vector Protocols" anchor="distvector">
        <t>Distance-Vector routing protocols (BGP, RIPng, BABEL), operating on
          a hop-by-hop basis, can address interoperability and migration
          concerns on that level.  With routing information being flooded in
          the reverse direction of traffic being forwarded using that
          information, a hop that floods is the same hop that forwards.</t>
        <t>This makes dealing with destination/source-unaware routers easy
          if destination/source routes are made to be ignored by such unaware
          routers, and flooding of such routes is inhibited.</t>
        <t>If D/S routes are discarded by non-D/S routers, D/S routers will
          not receive non-working routes and can select from other available
          working D/S routes.</t>
        <t>Note that for this to work, non-D/S routers MUST NOT flood D/S
          routing information.  This can be achieved in 2 ways:
          <list style="numbers">
            <t>Using some preexisting encoding to signal non-D/S routers to not
              flood these particular routes</t>
            <t>Ignoring flooded D/S information on D/S routers by having them
              detect that they received it from a non-D/S router (e.g. using
              some capability signalling to identify non-D/S routers.)  This
              handling likely needs to be performed on a level of same-link
              neighborships.</t>
          </list>
        </t>
        <t>Also note that the considerations in this section only apply if data
          path and flooding path are congruent.</t>
      </section>
      <section title="Interoperability in Link-State Protocols" anchor="linkstate">
        <t>For Link-State routing protocols (OSPF, IS-IS), there is no relation
          between route flooding and forwarding.  Instead, forwarding decisions
          are based on shortest-path calculation on top of the received
          topology information.</t>
        <t>For a D/S router to avoid loops, there are again two choices
          available:
          <list style="numbers">
            <t>Detect that forwarding for a D/S route transits over a non-D/S
              router and convert the route into a blackhole route to replace
              looping with blackholing.  This obviously impacts
              connectivity.</t>
            <t>Perform separate SPF calculations using only the subset of
              D/S-capable routers; thus D/S routers can forward D/S-routed
              packets as long as they stay in contiguous islands.</t>
          </list>
        </t>
        <t>The latter approach is facilitated by Multi-Topology extensions to
          the respective protocols.  These extensions provide a way to both
          isolate D/S routing information and perform the separate SPF
          calculation.  Note that it is not neccessary to use multiple
          topologies for distinct source prefixes;  only a single additional
          topology encompassing all D/S-capable routers is sufficient.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no requests to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Systems operating under the principles of this document can have
        routes that are more specific than the previously most specific, i.e.
        host routes.  This can be a security concern if an operator was relying
        on the impossibility of hijacking such a route.</t>

      <!-- from draft-baker-ipv6-dst-src-routing -->
      <t>While destination-source routing could be used as part of a security
        solution, it is not really intended for the purpose. The approach
        limits routing, in the sense that it routes traffic to an appropriate
        egress, or gives a way to prevent communication between systems not
        included in a destination-source route, and in that sense could be
        considered similar to an access list that is managed by and scales with
        routing.</t>
    </section>

    <section anchor="Privacy" title="Privacy Considerations">
      <t>If a host's addresses are known, injecting a dst-src route allows
        isolation of traffic from that host, which may compromise privacy.
        However, this requires access to the routing system.  As with similar
        problems with the destination only, defending against it is left to
        general mechanisms protecting the routing infrastructure.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The base underlying this document was first outlaid by Ole Troan and
        Lorenzo Colitti in <xref target="I-D.troan-homenet-sadr"/> for
        application in the homenet area.  Significant contributions to
        source-specific routing as a whole came from Juliusz Chroboczek and
        Matthieu Boutier.  Matthieu has also provided a huge amount of review
        and editing input on this document.</t>
      <t>This document itself is largely the result of discussions with Fred
        Baker and derives from <xref
          target="I-D.baker-ipv6-isis-dst-src-routing"/>.</t>
      <t>Thanks to Chris Bowers, Acee Lindem and Tony Przygienda for their
        input and review.</t>
      <t>The Linux kernel is providing an implementation of the behaviour
        described here since even before the document was started.</t>
    </section>

    <section anchor="log" title="Change Log">
      <t><list style="hanging">
          <t hangText="March 2019 [-07]:"><list>
              <t>no changes</t>
            </list></t>
          <t hangText="October 2017 [-06]:"><list>
              <t>clarify described operation is not an implementation guide</t>
              <t>editorial cleanups</t>
            </list></t>
          <t hangText="July 2017 [-05]:"><list>
              <t>clarify connectivity tests</t>
              <t>extend use cases</t>
              <t>editorial cleanups</t>
            </list></t>
          <t hangText="May 2017 [-04]:">no changes</t>
          <t hangText="November 2016 [-03]:"><list>
              <t>added DV/LS protocol considerations</t>
              <t>note backtracking workaround/caveat</t>
            </list></t>
          <t hangText="November 2015 [-02]:"><list>
            <t>added section on destination-source routing use cases</t>
            <t>added section on alternative lookup algorithm</t>
            <t>added section on requirement for dynamic routing
              protocols dessiminating destination-source informaton</t>
            </list></t>
          <t hangText="October 2015 [-00]:">
            renamed to draft-ietf-rtgwg-dst-src-routing-00, no content changes
            from draft-lamparter-rtgwg-dst-src-routing-01.</t>
          <t hangText="April 2015 [-01]:">merged routing-extra-qualifiers
            draft, new ordering rationale section</t>
          <t hangText="October 2014 [-00]:">Initial Version</t>
        </list></t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.2460"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.0791"?>
      <?rfc include="reference.RFC.2080"?>
      <?rfc include="reference.RFC.2827"?>
      <?rfc include="reference.RFC.4271"?>
      <?rfc include="reference.RFC.5308"?>
      <?rfc include="reference.RFC.5340"?>
      <?rfc include="reference.RFC.8028"?>
      <?rfc include="reference.RFC.8043"?>
      <?rfc include="reference.I-D.troan-homenet-sadr"?>
      <?rfc include="reference.I-D.baker-ipv6-isis-dst-src-routing"?>
      <?rfc include="reference.I-D.linkova-v6ops-conditional-ras"?>
      <reference anchor="hal-00947234v1" target="https://hal-univ-diderot.archives-ouvertes.fr/hal-00947234v1">
        <front>
          <title>Source-sensitive routing</title>
          <author fullname="Matthieu Boutier" initials="M." surname="Boutier"/>
          <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
          <date year="2014"/>
        </front>
        <seriesInfo name="hal" value="00947234v1" />
      </reference>
    </references>

    <section title="Implementation Options">
      <section title="Pre-expanded 2-step lookup without backtracking"
          anchor="nobacktrack">
        <t>The backtracking behavior (specified in <xref target="deflookup"/>
          as "A router MUST continue to a less specific destination prefix")
          has been shown to potentially cause a significant loss of forwarding
          performance since forwarding a single packet may require a large
          number of table lookups.  (The degenerate case is 129 destination
          lookups in decreasing prefix length, each followed by a failing
          longest-match on the source prefix.)</t>
        <t>To avoid this, implementations can install synthetic routes to
          achieve the same lookup result.  This works as follows, to be
          evaluated for each unique destination prefix:</t>
        <?rfc needLines="13"?>
        <t><list style="numbers">
            <t>If there is a route (D, S=::/0), end processing for D.</t>

            <t>Iterate upwards one level (from D if first iteration, previous
              D' otherwise) to a less specific destination.  Call this D'.</t>

            <t>For all routes (D', S'), i.e. all source prefixes S' under that
              destiation prefix, install a copy (D, S') if and only if S'
              covers some source prefix that isn't covered yet.  (In terms of
              set theory, S' cut by all existing S under D is not empty.)
            </t>

            <t>Repeat at step 1.</t>
        </list></t>
        <t>The effect of this algorithm is that after performing a lookup on
          the destination prefix, looking up the source prefix directly yields
          the result that backtracking would give.  This eliminates
          backtracking and provides constant 2 lookup cost (after exactly one
          destination longest-match, the source longest-match will provide the
          final, correct result;  any no-match is a final no-match).</t>
      </section>

      <section title="Translation to Multi-FIB (Policy Routing) perspective"
          anchor="altlookup">
        <t>The lookup procedure described in this document requires
          destination-first lookup.  This is not a fit with most existing
          implementations of Policy Routing.  While Policy Routing has no
          formal specification, it generally permits choosing from multiple
          routing tables / FIBs based on, among other things, source address.
          Some implementations support using more than one FIB for a single
          lookup, but not all do.</t>
        <t>An implementation that can choose from multiple FIBs based on
          source address is capable of correct forwarding according to this
          document, provided that it supports enough FIBs.  One FIB will be
          used for each unique source prefix.</t>
        <t>For a complete description of the required translation algorithm,
          please refer to <xref target="hal-00947234v1"/>.  It roughly works
          as follows:
        </t>

        <t>After destination-source routing information has been
          collected, one FIB table is created for each source range
          including the default range ::/0. Source-destination routes
          then replicated into each destination-only FIB table whose
          associated source address range is a subset of route's
          source range. Note that this rule means routes with default
          source range ::/0 are replicated into each FIB
	  table.</t>

        <t>In case when multiple routes with the same destination
          prefix are replicated into the same FIB table only route
          with the most specific source address range is
          installed.</t>

        <t>For example, if destination-source routing table contains
          these routes:</t>

	<texttable style="headers">
	  <ttcol>Destination prefix</ttcol>
	  <ttcol>Source range</ttcol>
	  <ttcol>Next Hop</ttcol>

	  <c>::/0,</c>
	  <c>::/0,</c>
	  <c>NH1</c>

	  <c>2001:101:1234::/48,</c>
	  <c>2001:db8:3456:8000::/56,</c>
	  <c>NH2</c>

	  <c>2001:101:5678::/48,</c>
	  <c>2001:db8:3456:8000::/56,</c>
	  <c>NH3</c>

	  <c></c>
	  <c>::/0,</c>
	  <c>NH4</c>

	  <c>2001:101:abcd::/48,</c>
	  <c>2001:db8:3456::/48,</c>
	  <c>NH5</c>
	</texttable>

        <t>then 3 FIB tables will be created associated with source
          ranges ::/0, 2001:db8:3456::/48 and
          2001:db8:3456:8000::/56. In this example range
          2001:db8:3456:8000::/56 is a subset of less specific range
          2001:db8:3456::/48. Such inclusion makes a somewhat
          artificial example but was intentionally selected to
          demonstrate hierarchy of route replication.</t>

        <t>And content of these FIB tables will be:</t>

        <t>FIB 1 (source range ::/0):</t>
	<texttable style="headers">
	  <ttcol>Destination prefix</ttcol>
	  <ttcol>Next Hop</ttcol>

	  <c>::/0,</c>
	  <c>NH1</c>

	  <c>2001:101:5678::/48,</c>
	  <c>NH4</c>
	</texttable>

        <t>FIB 2 (source range 2001:db8:3456::/48):</t>
	<texttable style="headers">
	  <ttcol>Destination prefix</ttcol>
	  <ttcol>Next Hop</ttcol>

	  <c>::/0,</c>
	  <c>NH1</c>

	  <c>2001:101:5678::/48,</c>
	  <c>NH4</c>

	  <c>2001:101:abcd::/48,</c>
	  <c>NH5</c>
	</texttable>

        <t>FIB 3 (source range 2001:db8:3456:8000::/56):</t>
	<texttable style="headers">
	  <ttcol>Destination prefix</ttcol>
	  <ttcol>Next Hop</ttcol>

	  <c>::/0,</c>
	  <c>NH1</c>

	  <c>2001:101:1234::/48,</c>
	  <c>NH2</c>

	  <c>2001:101:5678::/48,</c>
	  <c>NH3</c>

	  <c>2001:101:abcd::/48,</c>
	  <c>NH5</c>
	</texttable>

        <t>During packet forwarding, lookup first matches source
          address against the list of address ranges associated with
          FIB tables to select a FIB table with the most specific
          source address range and then does destination-only lookup
          in the selected FIB table.</t>
      </section>
    </section>
  </back>
</rfc>