Network Working Group                                         M. Boutier
Internet-Draft                                             J. Chroboczek
Updates: 6126bis (if approved)         IRIF, University of Paris-Diderot
(if approved)                                            August 11, 2017
Intended status: Standards Track                         August 21, 2017
Expires: February 12, 22, 2018

                    Source-Specific Routing in Babel
                  draft-ietf-babel-source-specific-00
                  draft-ietf-babel-source-specific-01

Abstract

   Source-specific routing is an extension to traditional next-hop
   routing where packets are forwarded according to both their
   destination and their source address.  This document describes an the
   source-specific routing extension to the Standard Track's Babel
   routing protocol to
   support source-specific routing. defined in [BABEL].  It is incompatible with the
   Experimental Track's Babel [RFC6126].

   Source-specific routing is also known as Source Address Dependent
   Routing, SAD Routing, SADR, Destination/Source Routing or Source/
   Destination Routing.

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 12, 22, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  TODOs . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3   2
   2.  Introduction and background . . . . . . . . . . . . . . . . .  3   2
   3.  Data Structures . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  The Source Table  . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  The Route Table . . . . . . . . . . . . . . . . . . . . .  3   4
     3.3.  The Table of Pending Seqno Requests . . . . . . . . . . . . . .   4
   4.  Data Forwarding . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Protocol Operation  . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Source-specific messages  . . . . . . . . . . . . . . . . .  5   6
     5.2.  Route Acquisition . . . . . . . . . . . . . . . . . . . .  5   6
     5.3.  Wildcard retractions (update) . . . . . . . . . . . . . .   6
     5.4.  Wildcard requests . . . . . . . . . . . . . . . . . . . .   6
   6.  Compatibility with the base protocol  . . . . . . . . . . . . .  8   7
     6.1.  Loop-avoidance  . . . . . . . . . . . . . . . . . . . . . .  8   7
     6.2.  Starvation and Blackholes . . . . . . . . . . . . . . . .  9   8
   7.  Protocol Encoding . . . . . . . . . . . . . . . . . . . . . .  9   8
     7.1.  Source Prefix sub-TLV . . . . . . . . . . . . . . . . . .  9   8
     7.2.  Source-specific Update  . . . . . . . . . . . . . . . . . . 10   9
     7.3.  Source-specific (Route) Request . . . . . . . . . . . . . 10   9
     7.4.  Source-Specific Seqno Request . . . . . . . . . . . . . . 10   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10   9
   9.  Security considerations . . . . . . . . . . . . . . . . . . . 11   9
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 11  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 11  10
     10.2.  Informative References . . . . . . . . . . . . . . . . . . 11  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 11  10

1.  TODOs

   o  Source Prefix sub-TLV type: TBD

   o  check references (Section) for BABEL in 6126bis
   o  define wildcard Requests behaviour

2.  Introduction and background

   Source-specific

   The Babel routing (also known protocol as Source Address Dependant
   Routing, SAD Routing or SADR) defined is an extension to traditional next-hop [BABEL] is a distance vector
   routing where packets are routed according protocol for next-hop routing.  In next-hop routing, each
   node maintains a forwarding table which maps prefixes to both their next-hops.
   The forwarding decision is a per-packet operation which depends on
   the destination address of the packets and their source address.  This document describes on the source-
   specific routing extension to entries of the Babel routing protocol as defined
   in 6126bis [BABEL].

   Background information
   forwarding table.  When a packet is about source-specific routing to be routed, its
   destination address is provided in
   [SS-ROUTING].

3.  Data Structures

   This extension adds some data compared to the data structures maintained by a
   Babel node.

3.1.  The Source Table

   Every Babel node maintains a source table, as described in [BABEL],
   Section 3.2.5.  A source-specific Babel node extends this table with prefixes of the following field:

   o routing table:
   the source entry with the most specific prefix (sprefix, splen) specifying containing the source destination
   address of packets to which this entry applies.

   If a source table entry has a zero length source prefix (splen equals
   to 0), then the entry packet is a non-source-specific entry, choosen, and is treated
   just like a source table entry defined by the original Babel
   protocol.

   With this extension packet is forwarded to the route entry contains a source which itself
   contains a source prefix.  These are two very different concepts, and
   should not be confused.

3.2.  The Route Table

   Every Babel node maintains
   associated next-hop.  Next-hop routing is a route table, as described simple, well understood
   paradigm that works satisfactorily in [BABEL],
   Section 3.2.6.  With this extension, this table a large number of cases.

   Source-specific routing is indexed by a modest extension of next-hop routing
   where the
   5-tuple (prefix, plen, source prefix, source plen, router-id)
   obtained from forwarding decision additionnaly depends on the associated source table entry.

   If
   address of the packets.  The forwarding tables are extended to map
   pairs of prefixes (destination, source) to a next-hop.  When multiple
   entries are candidate to route table entry has a zero length source prefix, then packet, the
   entry one with the most
   specific destination prefix is a non-source-specific entry, choosen, and is treated just like a
   route table entry defined by the original Babel protocol.

3.3.  The Table of Pending Requests

   Every Babel node maintains a table of pending requests, as described in [BABEL], Section 3.2.7.  A source-specific Babel node extends this
   table with case of equality the following entry:

   o
   one with the source prefix being requested.

4.  Data Forwarding most specific source.  In next-hop source-specific routing, if two
   packets with the same destination but different sources may be
   forwarded among different paths.

   The main application of source-specific routing table entries overlap, then one
   is necessarily more specific than is, at the other; time of
   this writing, multihoming with Provider Agregatable (PA) addresses.
   In such configuration, each Internet Service Provider (ISP) provides
   to the "longest network a PA prefix
   rule" specifies that the most specific applicable routing table entry
   is chosen.

   With source-specific routing, there might no longer be a most
   specific applicable prefix: two routing table entries might match and a
   given packet without one necessarily being more specific than the
   other.  Consider default route for example the following fragment this prefix while
   performing ingress filtering ([BCP84]).  Each host has one address
   per ISP, and sends packets with one of a these addresses as source
   address.  Source-specific routing
   table:

      (2001:DB8:0:1::/64, ::/0, A)
      (::/0, 2001:DB8:0:2::/64, B)

   This specifies ensures that all packets with destination in 2001:DB8:0:1::/64 are to be routed through A, while packets with a
   towards the provider of their source in 2001:DB8:
   0:2::/64 address, such that they are to be routed through B. A packet with source 2001:DB8:0:
   2::42 not
   filtered out.  More details and destination 2001:DB8:0:1::57 matches both rules, although
   neither is more specific than use cases can be found in
   [SS-ROUTING],[IETF-SSR].

   This document describes the other.  A choice is necessary, and
   unless source-specific routing extension for the choice being made
   Babel routing protocol [BABEL].  This involves changes to data
   structures and protocol messages.  The data structures receive an
   additionnal source prefix which is part of the same on all routers in index, similarly to
   (and with) the destination prefix.  The Update, Route Request and
   Seqno Request are the three messages which carry a routing
   domain, persistent routing loops may occur.  More informations (destination)
   prefix: they are
   available in [SS-ROUTING] Section IV.C.

   A Babel implementation MUST choose routing table entries by using extended with a source prefix.

3.  Data Structures

   Some of the
   so-called destination-first ordering, where data structures of a routing table entry R1
   is preferred to Babel node contains a routing table entry R2 when either R1's destination
   prefix is more specific than R2's, or the destination prefixes are
   equal and R1's partly indexed by a destination prefix.  This extension
   adds a source prefix is more specific to these structures and indexes.

3.1.  The Source Table

   Every Babel node maintains a source table, as described in [BABEL],
   Section 3.2.5.  A source-specific Babel node extends this table with
   the following field.  With this extension, the source table is
   indexed by triples of the form (prefix, source prefix, router-id).

   o  the source prefix specifying the source address of packets to
      which this entry applies.

   If a source table entry has a zero length source prefix, then the
   entry is a non-source-specific entry, and is treated just like a
   source table entry defined by the original Babel protocol.

   With this extension, the route entry contains a source which itself
   contains a source prefix.  These are two very different concepts, and
   should not be confused.

3.2.  The Route Table

   Every Babel node maintains a route table, as described in [BABEL],
   Section 3.2.6.  With this extension, the route table is indexed by
   triples of the form (prefix, source prefix, neighbour) obtained from
   the associated source table entry.

   If a route table entry has a zero length source prefix, then the
   entry is a non-source-specific entry, and is treated just like a
   route table entry defined by the original Babel protocol.

3.3.  The Table of Pending Seqno Requests

   Every Babel node maintains a table of pending seqno requests, as
   described in [BABEL], Section 3.2.7.  A source-specific Babel node
   extends this table with the following entry.  With this extension,
   the table of pending seqno requests is indexed by triples of the form
   (prefix, source prefix, router-id).

   o  the source prefix being requested.

4.  Data Forwarding

   In next-hop routing, if two routing table entries overlap, then one
   is necessarily more specific than the other; the "longest prefix
   rule" specifies that the most specific applicable routing table entry
   is chosen.

   With source-specific routing, there might no longer be a most
   specific applicable entry: two routing table entries might match a
   given packet without one necessarily being more specific than the
   other.  Consider for example the following routing table:

             destination                source    next-hop
       2001:DB8:0:1::/64                  ::/0           A
                    ::/0     2001:DB8:0:2::/64           B

   This specifies that all packets with destination in 2001:DB8:0:1::/64
   are to be routed through A, while all packets with source in
   2001:DB8:0:2::/64 are to be routed through B.  A packet with source
   2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both rules,
   although neither is more specific than the other.  A choice is
   necessary, and unless the choice being made is the same on all
   routers in a routing domain, persistent routing loops may occur.
   More informations are available in [SS-ROUTING] Section IV.C.

   A Babel implementation MUST choose routing table entries by using the
   so-called destination-first ordering, where a routing table entry R1
   is preferred to a routing table entry R2 when either R1's destination
   prefix is more specific than R2's, or the destination prefixes are
   equal and R1's source prefix is more specific than R2's.  (In more
   formal terms, routing table entries are compared using the
   lexicographic product of the destination prefix ordering by the
   source prefix ordering.)

   In practice, this means that a source-specific Babel implementation
   must take care that any lower layer that performs packet forwarding
   obey this semantics.  In particular:

   o  If the lower layers implement the destination-first ordering, then
      the Babel implementation MAY use them directly;

   o  If the lower layers can hold source-specific routes, but not with
      the right semantics, then the Babel implementation MUST
      disambiguate the routing table by using a suitable disambiguation
      algorithm (see [SS-ROUTING] Section V.B for such an algorithm);

   o  If the lower layers cannot hold source-specific routes, then a
      Babel implementation MUST silently ignore (drop) any source-
      specific routes.

5.  Protocol Operation

   This extension does not fundamentally change the operation of the
   Babel protocol.  We only describe the fundamental differences between
   the original protocol and the this extension in this section.  The other
   mechanisms described in [BABEL] (Section 3) are extended to pairs of
   (destination, source) prefixes instead of just (destination)
   prefixes.

5.1.  Source-specific messages

   Three messages are used to communicate informations on routes: carry a destination prefix: Updates, Route Requests
   and Seqno Requests.  With this extension,
   these  These messages carry an additionnal are extended to carry, in
   addition, a source prefix if (and only if) the corresponding route is
   source-specific.  More formally, an Update, a Route Request and a
   Seqno Request MUST carry a source prefix if they concern a source-specific source-
   specific route (non-zero length source prefix) and MUST NOT carry a
   source prefix otherwise (zero length source prefix).  A message which
   carries a source prefix is said to be source-specific.

5.2.  Route Acquisition

   When a non-source-specific Babel node receives a source-specific
   update, it silently ignores it.

   TODO{On receipt of  When a source-specific Babel node
   receives a non-source-specific update, it MUST treat this update (id, prefix, source
   prefix, seqno, metric), as a
   zero length source-specific update.

   When a source-specific Babel node receives a source-specific update
   (prefix, source prefix, router-id, seqno, metric) from a neighbour
   neigh, it behaves as described in [BABEL] Section 3.5.4 (Section 3.5.4) though
   indexing entries by (neigh,
   id, prefix, source prefix).} When a source-specific Babel node
   receives a non-source-specific update, it MUST treat this update as
   carrying a zero length (prefix, source prefix. prefix, neigh).

5.3.  Wildcard retractions (update)

   The original protocol defines a wildcard update with AE equals to 0
   as being a wildcard retraction.  A node receiving a wildcard
   retraction on an interface must consider that the sending node
   retracts all the routes it advertised on this interface.

   Wildcard retractions are used when a node is about to leave the
   network.  Thus, this extension does not define source-specific
   wildcard retraction, but extends wildcard retraction to apply also to
   source-specific routes.  More formally, a wildcard update MUST NOT
   carry a source prefix, and a source-specific Babel node receiving a
   (legacy) wildcard update MUST retracts all routes it learns from this
   node (including source-specific ones).

5.4.  Wildcard requests

   TODO: behaviour to be defined.

5.4.1.  Proposal 1

   The original Babel protocol states that when a node receives a
   wildcard route request, it SHOULD send a full routing table dump.
   This extension does not change this statement: a source-specific node
   SHOULD send a full routing table dump when receiving a wildcard
   request.

   Source-specific wildcard requests does not exist: a wildcard request
   SHOULD NOT carry a source prefix.

5.4.2.  Proposal 2

   We assume that a mandatory sub-TLV has a corresponding non-mandatory
   sub-TLV.  This proposal is like Proposal 3 but instead of having
   multiple wildcard request TLVs, one for each kind of route
   understood, we use one wildcard request with sub-TLVs corresponding
   to the extension.  To have a full routing table dump, a node sends a
   wildcard requests with a non-mandatory Source sub-TLV.

   A source-specific node SHOULD always attach a non-mandatory Source
   sub-TLV to its wildcard requests.

   This proposal has been rejected because it implies to share the space
   of non-mandatory and mandatory sub-TLVs.

5.4.3.  Proposal 3 (mentionned by Juliusz)

   The Babel protocol provides the ability to request a full routing
   table dump by sending a "wildcard request", a route request with the
   AE field set to 0.  As the original protocol has no source-specific
   routes, such a request may only concern non-source-specific routes.
   This extension does not modify the semantics of wildcard requests in
   that sense: a wildcard request prompts the receiver wildcard retraction to apply also to send its non-
   source-specific routes only, and routes.  More formally, a Babel node SHOULD wildcard update MUST NOT send any
   source-specific updates in reply to
   carry a wildcard request.

   To obtain source prefix, and a dump of the source-specific routes, Babel node receiving a source-specific
   (legacy) wildcard request update MUST be used.  A retracts all routes it learns from this
   node (including source-specific wildcard request is
   a wildcard request carrying a zero length source prefix.

   When ones).

5.4.  Wildcard requests

   The original Babel protocol states that when a node receives a source-specific
   wildcard route request, it SHOULD send a dump of its routes which are source-specific "only".  It
   SHOULD NOT send any non-source-specific routes in reply to a source-
   specific wildcard request.  It SHOULD NOT send any source-specific
   routes which are under the effect of a future extension.  Such
   extension should detail how to handle the possible combinations.

   In consequence, a node requiring a full routing table dump must send
   both a non-source-specific wildcard request and a source-specific
   wildcard request.

5.4.4.  Proposal 4 (mentionned by Juliusz)

   Wildcard requests are deprecated.  Either deprecate it in 6126bis, or
   say the following.

   A node receiving a wildcard request SHOULD ignore it.

   This proposal has been rejected because wildcard requests speeds up
   the convergence of the network on boot.  This is considered
   important.

5.4.5.  Proposal 5 (mentionned by David)

   By default, a vanilla wildcard request triggers a dump of all non-
   specific routes.  We define a new non-mandatory sub-TLV on Route
   Requests called "Requested Route Types" that contains an array of all
   the types of routes this request is requesting.

   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 = TBD   |    Length     |  RR Type 1    |  RR Type 2...

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   We also create a registry of Requested Route (RR) types, for example:

      0 = Regular
      1 = Source-Specific
      2 = TOS-specific
      etc.

   A dump.
   This extension does not change this statement: a source-specific node
   SHOULD send a full routing table dump when receiving a Requested Route Types sub-TLV in wildcard
   request.

   Source-specific wildcard requests does not exist: a wildcard request SHOULD sends back
   MUST NOT carry a dump source prefix, and a source prefix associated with a
   wildcard update SHOULD be ignored.

   One of all its routes corresponding the motivation behalf this design choice is that wildcard
   requests are defined with AE equals to 0.  They naturally apply to AE
   1, AE 2 and AE 3 defined in [BABEL], but also to any other AE which
   may be defined in the requested types future.  New AEs, new TLVs or to a combination new sub-TLVs are
   extension mechanisms.  Thus, the semantics of these types. a wildcard request is
   clearly to also asks for routes coming from extensions.

6.  Compatibility with the base protocol

   The protocol extension defined in this document is, to a great
   extent, interoperable with the base protocol defined in [BABEL] (and
   all its known extensions).  More precisely, if non-source-specific
   routers and source-specific routers are mixed in a single routing
   domain, Babel's loop-avoidance properties are preserved, and, in
   particular, no persistent routing loops will occur.

   However, this extension is not compatible with the Experimental
   Track's Babel Routing Protocol (RFC 6126). [RFC6126].  It requires the mandatory
   sub-TLV introduced in [BABEL].  Consequently, this extension MUST NOT
   be used with routers implementing RFC 6126, otherwise persistent
   routing loops may occur.

6.1.  Loop-avoidance

   The extension defined in this protocol uses a new Mandatory sub-TLV
   to carry the source prefix information.  As discussed in Section 4.4
   of [BABEL], this encoding ensures that non-source-specific routers
   will silently ignore the whole TLV, which is necessary to avoid
   persistent routing loops in hybrid networks.

   Consider two nodes A and B, with A source-specific announcing a route
   to (D, S).  Suppose that B (non source-specific) merely ignores the
   source prefix information when it receives the update rather than
   ignoring the sub- whole TLV, and reannounces the route as D.  This
   reannouncement reaches A, which treats it as (D, ::/0).  Packets
   destined to D but not sourced in S will be forwarded by A to B, and
   by B to A, causing a persistent routing loop:

       (D,S)                 (D)
        <--                 <--
     ------ A ----------------- B
              -->
             (D,::/0)

6.2.  Starvation and Blackholes

   In general, discarding source-specific routes by non-source-specific
   routers will cause route starvation.  Intuitively, unless there are
   enough non-source-specific routes in the network, non-source-specific
   routers will suffer starvation, and discard packets for destinations
   that are only announced by source-specific routers.

   A simple yet sufficient condition for avoiding starvation is to build
   a connected source-specific backbone that includes all of the edge
   routers, and announce a (non-source-specific) default route towards
   the backbone.

7.  Protocol Encoding

   This extension defines a new sub-TLV used to carry a source prefix by
   the three following existing messages: Update, Route Request and
   Seqno Request.

7.1.  Source Prefix sub-TLV

   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
   |Type = TBD   | TBD[128]|    Length     |  Source Plen  | Source Prefix...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Fields:

   Type      Set to TBD TBD[128] to indicate a Source Prefix sub-TLV.

   Length    The length of the body, exclusive of the Type and Length
             fields.

   Source Plen  The length of the advertised source prefix.  This MUST
             NOT be 0.

   Source Prefix  The source prefix being advertised.  This field's size
             is (Source Plen)/8 rounded upwards.

   The Source Prefix field's source prefix encoding (AE) is the same as the Prefix's.  It is
   defined by the AE field of the corresponding TLV.

   Note that this sub-TLV is a Mandatory sub-TLV.  The whole TLV MUST be
   ignored if that TLV sub-TLV is not recognized as described in Section 4.4. recognized.  Otherwise, routing loops
   may occur. occur (see Section 6.1).

7.2.  Source-specific Update

   The source-specific Update is an Update TLV with a Source Prefix sub-
   TLV.  It advertises or retracts source-specific routes in the same
   manner than routes with non-source-specific Updates (see [BABEL]).
   This TLV  A
   wildcard retraction (Update with AE equals to 0) MUST NOT be attached to wildcard updates. carry a
   Source Prefix sub-TLV.

   Contrary to the destination prefix, this extension does not compress
   the source prefix attached to Updates.  The destination prefix uses
   compression as defined in [BABEL] for Updates with Mandatory
   extensions.  However, as defined in
   [BABEL] (Section 4.5), the compression is allowed for the destination
   prefix of source-specific routes.  Legacy implementation will
   correctly update their parser state, state while ignoring the whole TLV
   afterwards.

7.3.  Source-specific (Route) Request

   TODO:

   A source-specific Route Request is a Route Request TLV with a Source
   Prefix sub-TLV.  It prompts the receiver to send an update for a
   given pair of destination and source prefixes.  It MUST
   NOT be used to request a full routing table dump.  The Source Prefix
   sub-TLV of a  A wildcard source-specific Route request
   (Route Request (Request with AE equals to 0 and 0) MUST NOT carry a Source Prefix sub-TLV) MIGHT be ignored: a receiver
   MIGHT reply by a full routing table dump.
   sub-TLV.

7.4.  Source-Specific Seqno Request

   A source-specific Seqno Request is a Seqno Request TLV with a Source
   Prefix sub-TLV.  It is just like a Seqno Request for a
   source-specific source-
   specific route.  It uses the same mechanisms described in [BABEL].

8.  IANA Considerations

   IANA is instructed requested to allocate TBD, a Babel sub-TLV type from the
   range reserved for mandatory sub-TLVs [value 128 suggested], and to
   add the following entry to the "Babel mandatory sub-TLV Types"
   registry:

                +------+---------------+-----------------+

              +----------+---------------+-----------------+
              | Type     | Name          | Reference       |
                +------+---------------+-----------------+
              +----------+---------------+-----------------+
              | TBD TBD[128] | Source Prefix | (this document) |
                +------+---------------+-----------------+
              +----------+---------------+-----------------+

9.  Security considerations

   The extension defined in this document adds a new sub-TLV to three
   TLVs already present in the original Babel protocol.  It does not by
   itself change the security properties of the protocol.

10.  References

10.1.  Normative References

   [BABEL]    Chroboczek, J., "The Babel Routing Protocol", Internet
              Draft draft-ietf-babel-rfc6126bis-02, May 2017.

   [BCP84]    Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.

   [IETF-SSR]
              Lamparter, D. and A. Smirnov, "Destination/Source
              Routing", Internet Draft draft-ietf-rtgwg-dst-src-routing,
              May 2017.

   [RFC6126]  Chroboczek, J., "The Babel Routing Protocol
              (Experimental)", RFC 6126, February 2011.

10.2.  Informative References

   [SS-ROUTING]
              Boutier, M. and J. Chroboczek, "Source-Specific Routing",
              August 2014.

              In Proc.  IFIP Networking 2015.  A slightly earlier
              version is available online from
              http://arxiv.org/pdf/1403.0445. http://arxiv.org/
              pdf/1403.0445.

Authors' Addresses

   Matthieu Boutier
   IRIF, University of Paris-Diderot
   Case 7014
   75205 Paris Cedex 13, 13
   France

   Email: boutier@irif.fr

   Juliusz Chroboczek
   IRIF, University of Paris-Diderot
   Case 7014
   75205 Paris Cedex 13, 13
   France

   Email: jch@irif.fr