rfc9079xml2.original.xml   rfc9079.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<rfc category="std" docName="draft-ietf-babel-source-specific-08" ipr="trust2009
02">
<front>
<title>Source-Specific Routing in Babel</title>
<author fullname="Matthieu Boutier" initials="M." surname="Boutier">
<organization>IRIF, University of Paris</organization>
<address>
<postal>
<street>Case 7014</street>
<city>75205 Paris Cedex 13</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<email>boutier@irif.fr</email>
</address>
</author>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
<organization>IRIF, University of Paris</organization>
<address>
<postal>
<street>Case 7014</street>
<city>75205 Paris Cedex 13</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<email>jch@irif.fr</email>
</address>
</author>
<date day="21" month="April" year="2021"/>
<abstract> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<t>Source-specific routing (also known as Source-Address Dependent
Routing, SADR) 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 extension for source-specific routing
to the Babel routing protocol.</t>
</abstract>
</front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-babel-source -specific-08" number="9079" ipr="trust200902" obsoletes="" updates="" submission Type="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocD epth="2" symRefs="true" sortRefs="true" version="3">
<middle> <front>
<title abbrev="Source-Specific Routing in Babel">Source-Specific Routing in
the Babel Routing Protocol</title>
<seriesInfo name="RFC" value="9079"/>
<author fullname="Matthieu Boutier" initials="M." surname="Boutier">
<organization>IRIF, University of Paris</organization>
<address>
<postal>
<street>Case 7014</street>
<city>Paris Cedex 13</city>
<region/>
<code>75205</code>
<country>France</country>
</postal>
<email>boutier@irif.fr</email>
</address>
</author>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
<organization>IRIF, University of Paris</organization>
<address>
<postal>
<street>Case 7014</street>
<city>Paris Cedex 13</city>
<region/>
<code>75205</code>
<country>France</country>
</postal>
<email>jch@irif.fr</email>
</address>
</author>
<date month="August" year="2021"/>
<section title="Introduction and background"> <keyword>SADR</keyword>
<keyword>source address-dependent routing</keyword>
<keyword>source address</keyword>
<keyword>multihoming</keyword>
<keyword>multihoming with multiple addresses</keyword>
<keyword>multiple addresses</keyword>
<keyword>source address selection</keyword>
<keyword>multiple routes</keyword>
<keyword>multipath</keyword>
<keyword>disjoint routes</keyword>
<keyword>route diversity</keyword>
<t>The Babel routing protocol <xref target="RFC8966"/> is a distance vector <abstract>
<t>Source-specific routing, also known as Source Address Dependent
Routing (SADR), is an extension to traditional next-hop routing where
packets are forwarded according to both their destination address and their sour
ce
address. This document describes an extension for source-specific routing
to the Babel routing protocol.</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction and Background</name>
<t>The Babel routing protocol <xref target="RFC8966" format="default"/> is
a distance vector
routing protocol for next-hop routing. In next-hop routing, each node routing protocol for next-hop routing. In next-hop routing, each node
maintains a forwarding table which maps destination prefixes to next hops. maintains a forwarding table that maps destination prefixes to next hops.
The forwarding decision is a per-packet operation which depends on the The forwarding decision is a per-packet operation that depends on the
destination address of the packets and on the entries of the forwarding destination address of the packets and on the entries of the forwarding
table. When a packet is about to be routed, its destination address is table. When a packet is about to be routed, its destination address is
compared to the prefixes of the routing table: the entry with the most compared to the prefixes of the routing table: the entry with the most
specific prefix containing the destination address of the packet is specific prefix containing the destination address of the packet is
chosen, and the packet is forwarded to the associated next-hop. Next-hop chosen, and the packet is forwarded to the associated next hop. Next-hop
routing is a simple, well understood paradigm that works satisfactorily in routing is a simple, well-understood paradigm that works satisfactorily in
a large number of cases.</t> a large number of cases.</t>
<t>The use of next-hop routing limits the flexibility of the routing
<t>The use of next-hop routing limits the flexibility of the routing
system in two ways. First, since the routing decision is local to each system in two ways. First, since the routing decision is local to each
router, a router A can only select a route ABC...Z if its neighbouring router, a router A can only select a route ABC...Z if its neighbouring
router B has selected the route BC...Z. Second, the only criterion used router B has selected the route BC...Z. Second, the only criterion used
by a router to choose a route is the destination address: two packets with by a router to choose a route is the destination address: two packets with
the same destination follow the same route. Yet, there are other data in the same destination follow the same route. Yet, there are other data in
the IP header that could conceivably be used to guide the routing decision the IP header that could conceivably be used to guide the routing decision
&mdash; the ToS octet and, of course, the source address.</t> -- the Type of Service (ToS) octet and, of course, the source address.</t>
<t>Source-specific routing <xref target="SS-ROUTING" format="default"/>, o
<t>Source-specific routing <xref target="SS-ROUTING"/>, or Source Address r Source Address
Dependent Routing (SADR), is a modest extension to next-hop routing where Dependent Routing (SADR), is a modest extension to next-hop routing where
the forwarding decision depends not only on the destination address but the forwarding decision depends not only on the destination address but
also on the source address of the packet being routed, which makes it also on the source address of the packet being routed, which makes it
possible for two packets with the same destination but different source possible for two packets with the same destination but different source
addresses to be routed following different paths.</t> addresses to be routed following different paths.</t>
<t>This document describes a source-specific routing extension for the
<t>This document describes a source-specific routing extension for the Babel routing protocol <xref target="RFC8966" format="default"/>. This involves
Babel routing protocol <xref target="RFC8966"/>. This involves minor minor
changes to the data structures, which must include a source prefix in changes to the data structures, which must include a source prefix in
addition to the destination prefix already present, and some changes to addition to the destination prefix already present, and some changes to
the Update, Route Request and Seqno Request TLVs, which are extended with the Update, Route Request, and Seqno Request TLVs, which are extended with
a source prefix. The source prefix is encoded using a mandatory sub-TLV a source prefix. The source prefix is encoded using a mandatory sub-TLV
(<xref target="RFC8966"/> Section 4.4).</t> (<xref target="RFC8966" sectionFormat="comma" section="4.4"/>).</t>
<section numbered="true" toc="default">
<section title="Application to multihoming"> <name>Application to Multihoming</name>
<t>Multihoming is the practice of connecting a single network to two or
<t>Multihoming is the practice of connecting a single network to two or
more transit networks. The main application of source-specific routing is more transit networks. The main application of source-specific routing is
a form of multihoming known as "multihoming with multiple addresses".</t> a form of multihoming known as "multihoming with multiple addresses".</t>
<t>Classical multihoming consists of assigning a provider-independent
<t>Classical multihoming consists in assigning a provider-independent
range of addresses to the multihomed network and announcing it to all range of addresses to the multihomed network and announcing it to all
transit providers. While classical multihoming works well for large transit providers. While classical multihoming works well for large
networks, the cost of obtaining a provider-independent address range and networks, the cost of obtaining a provider-independent address range and
announcing it globally in the Internet is prohibitive for small networks. announcing it globally in the Internet is prohibitive for small networks.
Unfortunately, it is not possible to implement classical multihoming with Unfortunately, it is not possible to implement classical multihoming with
ordinary provider-dependent addresses: in a network connected to two ordinary provider-dependent addresses: in a network connected to two
providers A and B, a packet with a source address allocated by A needs to providers A and B, a packet with a source address allocated by A needs to
be routed through the edge router connected to A. If it is routed through be routed through the edge router connected to A. If it is routed through
the edge router connected to B, it will most likely be filtered (dropped), the edge router connected to B, it will most likely be filtered (dropped),
in accordance with <xref target="BCP84"/>.</t> in accordance with <xref target="BCP84" format="default"/>.</t>
<t>In multihoming with multiple addresses, every host in the multihomed
<t>In multihoming with multiple addresses, every host in the multihomed
network is assigned multiple addresses, one for each transit provider. network is assigned multiple addresses, one for each transit provider.
Additional mechanisms are needed in order (i) to choose, for each packet, Additional mechanisms are needed in order (i) to choose, for each packet,
a source address that is associated with a provider that is currently up, a source address that is associated with a provider that is currently up,
and (ii) to route each packet towards the router connected to the provider and (ii) to route each packet towards the router connected to the provider
associated with its source address. One might argue that multihoming with associated with its source address. One might argue that multihoming with
multiple addresses splits the difficult problem of multihoming into two multiple addresses splits the difficult problem of multihoming into two
simpler sub-problems.</t> simpler sub-problems.</t>
<t>The issue of choosing a suitable source address is a decision local to <t>The issue of choosing a suitable source address is a decision local t
the sending host, and an area of active research. The simplest solution o
the sending host and is an area of active research. The simplest solution
is to use a traditional transport-layer protocol, such as TCP, and to is to use a traditional transport-layer protocol, such as TCP, and to
probe all available source addresses at connection time, analogously to probe all available source addresses at connection time, analogously to
what is already done with destination addresses, either sequentially what is already done with destination addresses, either sequentially
<xref target="RFC3484"/> or in parallel <xref target="RFC8305"/>. Since <xref target="RFC6724" format="default"/> or in parallel <xref target="RFC8305" format="default"/>. Since
the transport-layer protocol is not aware of the multiple available the transport-layer protocol is not aware of the multiple available
addresses, flows are interrupted when the selected provider goes down addresses, flows are interrupted when the selected provider goes down
(from the point of view of the user, all TCP connections are dropped when (from the point of view of the user, all TCP connections are dropped when
the network environment changes). A better user experience can be the network environment changes). A better user experience can be
provided by making available all of the potential source and destination provided by making all of the potential source and destination
addresses to higher layer protocols, either at the transport layer <xref addresses available to higher-layer protocols, either at the transport layer <xr
target="RFC8684"/> <xref target="RFC4960"/>, or at the applicaton layer ef target="RFC8684" format="default"/> <xref target="RFC4960" format="default"/>
<xref target="RFC8445"/>.</t> or at the application layer
<xref target="RFC8445" format="default"/>.</t>
<t>Source-specific routing solves the problem of routing a packet to the <t>Source-specific routing solves the problem of routing a packet to the
edge router indicated by its source address. Every edge router announces edge router indicated by its source address. Every edge router announces into t
into the routing domain a default route specific to the prefix associated he routing domain a default route specific to the prefix associated
with the provider it is connected to. This route is propagated all the with the provider it is connected to. This route is propagated all the
way to the routers on the access link, which are therefore able to route way to the routers on the access link, which are therefore able to route
every packet to the correct router. Hosts simply send packets to their every packet to the correct router. Hosts simply send packets to their
default router &mdash; no host changes are necessary at the network layer.</t> default router -- no host changes are necessary at the network layer.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Other Applications</name>
<section title="Other applications"> <t>In addition to multihoming with multiple addresses, we are aware of t
wo applications of source-specific routing. Tunnels and VPNs are packet
<t>In addition to multihoming with multiple addresses, we are aware of two
applications of source-specific routing. Tunnels and VPNs are packet
encapsulation techniques that are commonly used in the Internet to encapsulation techniques that are commonly used in the Internet to
establish a network-layer topology that is different from the physical establish a network-layer topology that is different from the physical
topology. In some deployments, the default route points at the tunnel; topology. In some deployments, the default route points at the tunnel;
this causes the network stack to attempt to send encapsulated packets this causes the network stack to attempt to send encapsulated packets
through the tunnel, which causes it to break. Various solutions to this through the tunnel, which causes it to break. Various solutions to this
problem are possible, the most common of which is to point a host route at problem are possible, the most common of which is to point a host route at
the tunnel endpoint.</t> the tunnel endpoint.</t>
<t>When source-specific routing is available, it becomes possible to
<t>When source-specific routing is available, it becomes possible to
announce through the tunnel a default route that is specific to the prefix announce through the tunnel a default route that is specific to the prefix
served by the tunnel. Since the encapsulated packets have a source served by the tunnel. Since the encapsulated packets have a source
address that is not within that prefix, they are not routed through the address that is not within that prefix, they are not routed through the
tunnel.</t> tunnel.</t>
<t>The third application of source-specific routing is controlled anycas
<t>The third application of source-specific routing is controlled anycast. t.
Anycast is a technique in which a single destination address is used to Anycast is a technique in which a single destination address is used to
represent multiple network endpoints, collectively called an "anycast represent multiple network endpoints, collectively called an "anycast
group". A packet destined to the anycast group is routed to an arbitrary group". A packet destined to the anycast group is routed to an arbitrary
member of the group, typically the one that is nearest according to the member of the group, typically the one that is nearest according to the
routing protocol.</t> routing protocol.</t>
<t>In many applications of anycast, such as DNS root servers, the
<t>In many applications of anycast, such as DNS root servers, the
nondeterminism of anycast is acceptable; some applications, however, nondeterminism of anycast is acceptable; some applications, however,
require finer control. For example, in some Content Distribution Networks require finer control. For example, in some Content Distribution Networks
(CDNs) every endpoint is expected to handle a well-defined subset of the (CDNs), every endpoint is expected to handle a well-defined subset of the
client population. With source-specific routing, it is possible for each client population. With source-specific routing, it is possible for each
member of the anycast group to announce a route specific to its client member of the anycast group to announce a route specific to its client
population, a technique that is both simpler and more robust than manually population, a technique that is both simpler and more robust than manually
tweaking the routing protocol's metric ("prepending" in BGP).</t> tweaking the routing protocol's metric ("prepending" in BGP).</t>
</section>
</section> <section anchor="specificity" numbered="true" toc="default">
<name>Specificity of Prefix Pairs</name>
<section title="Specificity of prefix pairs" anchor="specificity"> <t>In ordinary next-hop routing, when multiple routing table entries mat
ch
<t>In ordinary next-hop routing, when multiple routing table entries match
the destination of a packet, the "longest prefix rule" mandates that the the destination of a packet, the "longest prefix rule" mandates that the
most specific one applies. The reason why this rule makes sense is that most specific entry applies. The reason why this rule makes sense is that
the set of prefixes has the following "tree property": the set of prefixes has the following "tree property":
<list style="empty"> </t>
<t>for any prefixes P and P', either P and P' are disjoint, or one is more <ul empty="true">
specific than the other.</t>
</list></t>
<t>It would be a natural proposition to order pairs of prefixes pointwise: <li>
For any prefixes P and P', either P and P' are disjoint, or one is more
specific than the other.
</li>
</ul>
<t>It would be a natural proposition to order pairs of prefixes pointwis
e:
to define that (D,S) is more specific than (D',S') when D is more specific to define that (D,S) is more specific than (D',S') when D is more specific
than D and S is more specific than S'. Unfortunately, the set of pairs of than D and S is more specific than S'. Unfortunately, the set of pairs of
prefixes with the pointwise ordering doesn't satisfy the tree property. prefixes with the pointwise ordering doesn't satisfy the tree property.
Indeed, consider the following two pairs: Indeed, consider the following two pairs:
<list style="empty"> </t>
<t>(2001:db8:0:1::/64, ::/0) and (::/0, 2001:db8:0:2::/64)</t> <t indent="3">(2001:db8:0:1::/64, ::/0) and (::/0, 2001:db8:0:2::/64)</t
</list></t> >
<t>These two pairs are not disjoint (a packet with destination
<t>These two pairs are not disjoint (a packet with destination
2001:db8:0:1::1 and source 2001:db8:0:2::1 is matched by both), but 2001:db8:0:1::1 and source 2001:db8:0:2::1 is matched by both), but
neither is more specific than the other. The effect is that there is no neither is more specific than the other. The effect is that there is no
natural unambiguous way to interpret a routing table such as the natural, unambiguous way to interpret a routing table such as the
following:</t> following:</t>
<figure><artwork><![CDATA[ <artwork name="" type=""><![CDATA[
destination source next-hop destination source next-hop
2001:db8:0:1::/64 ::/0 A 2001:db8:0:1::/64 ::/0 A
::/0 2001:db8:0:2::/64 B ::/0 2001:db8:0:2::/64 B
]]></artwork></figure> ]]></artwork>
<t>A more refined ordering over pairs of prefixes is required in order to <t>A finer ordering of pairs of prefixes is required in order to
avoid all ambiguities. There are two natural choices: the avoid all ambiguities. There are two natural choices: destination-first orderin
destination-first ordering, where (D,S) is more specific than (D',S') g, where (D,S) is more specific than (D',S')
when when
<list style="symbols"> </t>
<t>D is strictly more specific than D'; or</t> <ul spacing="normal">
<t>D&nbsp;=&nbsp;D' and S is more specific than S',</t> <li>D is strictly more specific than D', or</li>
</list> <li>D&nbsp;=&nbsp;D', and S is more specific than S'</li>
and, symmetrically, the source-first ordering, in which sources are </ul>
<t>
and, symmetrically, source-first ordering, in which sources are
compared first and destinations second.</t> compared first and destinations second.</t>
<t>Expedient as it would be to leave the choice to the implementation,
<t>Expedient as it would be to leave the choice to the implementation,
this is not possible: all routers in a routing domain must use the same this is not possible: all routers in a routing domain must use the same
ordering, lest persistent routing loops occur. Indeed, consider the ordering lest persistent routing loops occur. Indeed, consider the
following topology:</t> following topology:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
A --- B --- C --- D A --- B --- C --- D
]]></artwork></figure> ]]></artwork>
<t>Suppose that A announces a route for (::/0, 2001:db8:0:2::/64), while
<t>Suppose that A announces a route for (::/0, 2001:db8:0:2::/64), while
D announces a route for (2001:db8:0:1::/64, ::/0). Suppose further that D announces a route for (2001:db8:0:1::/64, ::/0). Suppose further that
B uses the destination-first ordering, while C uses the source-first B uses destination-first ordering while C uses source-first
ordering. Then a packet that matches both routes, say, with destination ordering. Then a packet that matches both routes, say, with destination
2001:db8:0:1::1 and source 2001:db8:0:2::1, would be sent by B towards 2001:db8:0:1::1 and source 2001:db8:0:2::1, would be sent by B towards
D and by C towards A, and would therefore loop indefinitely between B and D and by C towards A and would therefore loop indefinitely between B and
C.</t> C.</t>
<t>This document mandates (<xref target="forwarding" format="default"/>)
<t>This document mandates (<xref target="forwarding"/>) that all routers that all routers
use the destination-first ordering, which is generally believed to be more use destination-first ordering, which is generally believed to be more
useful than the source-first ordering. Consider the following topology, useful than source-first ordering. Consider the following topology,
where A is an edge router connected to the Internet and B is an internal where A is an edge router connected to the Internet and B is an internal
router connected to an access network N:</t> router connected to an access network N:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
(::/0, S) (D, ::/0) (::/0, S) (D, ::/0)
Internet --- A --- B --- N Internet --- A --- B --- N
]]></artwork></figure> ]]></artwork>
<t>A announces a source-specific default route with source
<t>A announces a source-specific default route with source S (::/0,&nbsp;S), while B announces a nonspecific route to prefix D.
S (::/0,&nbsp;S), while B announces a non-specific route to prefix D. Consider what happens to a packet with a destination in D and a source in
Consider what happens to a packet with a desination in D and a source in S. With destination-first ordering, the packet is routed towards the
S. With the destination-first ordering, the packet is routed towards the
network N, which is the only way it can possibly reach its destination. network N, which is the only way it can possibly reach its destination.
With the source-first ordering, on the other hand, the packet is sent With source-first ordering, on the other hand, the packet is sent
towards the Internet, with no hope to ever reach its destination in N.</t> towards the Internet, with no hope of ever reaching its destination in N.</t>
</section>
</section> </section>
<section numbered="true" toc="default">
</section> <name>Specification of Requirements</name>
<t>
<section title="Specification of Requirements"> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and be interpreted as
only when, they appear in all capitals, as shown here.</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</section> </t>
</section>
<section title="Data Structures"> <section numbered="true" toc="default">
<name>Data Structures</name>
<t>A number of the conceptual data structures described in Section 3.2 of <t>A number of the conceptual data structures described in <xref target="R
<xref target="RFC8966"/> contain a destination prefix. This specification FC8966" sectionFormat="of" section="3.2"/> contain a destination prefix. This s
pecification
extends these data structures with a source prefix. Data from the extends these data structures with a source prefix. Data from the
original protocol, which do not specify a source prefix, are stored with original protocol, which do not specify a source prefix, are stored with
a zero length source prefix, which matches exactly the same set of packets a zero-length source prefix, which matches the exact same set of packets
as the original, non-source-specific data.</t> as the original, non-source-specific data.</t>
<section numbered="true" toc="default">
<section title="The Source Table"> <name>The Source Table</name>
<t>Every Babel node maintains a source table, as described in <xref targ
<t>Every Babel node maintains a source table, as described in <xref et="RFC8966" sectionFormat="comma" section="3.2.5"/>. A source-specific Babel n
target="RFC8966"/> Section&nbsp;3.2.5. A source-specific Babel node ode
extends this table with the following field: extends this table with the following field:
<list style="symbols"> </t>
<t>The source prefix (sprefix,&nbsp;splen) specifying the source address of <ul spacing="normal">
packets to which this entry applies.</t> <li>The source prefix (sprefix,&nbsp;splen) specifying the source addr
</list></t> ess of
packets to which this entry applies.</li>
<t>The source table is now indexed by 5-tuples of the form (prefix, plen, </ul>
<t>The source table is now indexed by 5-tuples of the form (prefix, plen
,
sprefix, splen, router-id).</t> sprefix, splen, router-id).</t>
<t>Note that the route entry contains a source (see Sections <xref targe
<t>Note that the route entry contains a source (see sections 2 and 3.2.5 t="RFC8966" section="2" sectionFormat="bare"/> and <xref target="RFC8966" sectio
of <xref target="RFC8966"/>) which itself contains both destination and nFormat="bare" section="3.2.5" />
source prefixes. These are two different concepts, and must not be of <xref target="RFC8966" format="default"/>) that itself contains both destinat
ion and
source prefixes. These are two different concepts and must not be
confused.</t> confused.</t>
</section>
<section numbered="true" toc="default">
<name>The Route Table</name>
</section> <t>Every Babel node maintains a route table, as described in <xref targe
t="RFC8966" sectionFormat="comma" section="3.2.6"/>. Each route table entry con
<section title="The Route Table"> tains,
<t>Every Babel node maintains a route table, as described in <xref
target="RFC8966"/> Section&nbsp;3.2.6. Each route table entry contains,
among other data, a source, which this specification extends with a source among other data, a source, which this specification extends with a source
prefix as described above. The route table is now indexed by 5-tuples of prefix as described above. The route table is now indexed by 5-tuples of
the form (prefix, plen, sprefix, splen, neighbour), where the first four the form (prefix, plen, sprefix, splen, neighbour), where the first four
components are obtained from the source.</t> components are obtained from the source.</t>
</section>
</section> <section numbered="true" toc="default">
<name>The Table of Pending Seqno Requests</name>
<section title="The Table of Pending Seqno Requests"> <t>Every Babel node maintains a table of pending seqno requests, as
described in <xref target="RFC8966" sectionFormat="comma" section="3.2.7"/>. A
<t>Every Babel node maintains a table of pending seqno requests, as
described in <xref target="RFC8966"/>, Section&nbsp;3.2.7. A
source-specific Babel node extends this table with the following entry:</t> source-specific Babel node extends this table with the following entry:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The source prefix (sprefix,&nbsp;splen) being requested.</li>
<t>The source prefix (sprefix,&nbsp;splen) being requested.</t> </ul>
</list></t> <t>The table of pending seqno requests is now indexed by 5-tuples of the
<t>The table of pending seqno requests is now indexed by 5-tuples of the
form (prefix, plen, sprefix, splen, router-id).</t> form (prefix, plen, sprefix, splen, router-id).</t>
</section>
</section> </section>
<section anchor="forwarding" numbered="true" toc="default">
</section> <name>Data Forwarding</name>
<t>As noted in <xref target="specificity" format="default"/>, source-speci
<section title="Data Forwarding" anchor="forwarding"> fic tables
<t>As noted in <xref target="specificity"/> above, source-specific tables
can, in general, be ambiguous, and all routers in a routing domain must can, in general, be ambiguous, and all routers in a routing domain must
use the same algorithm for choosing applicable routes. An implementation use the same algorithm for choosing applicable routes. An implementation
of the extension described in this document MUST choose routing table of the extension described in this document <bcp14>MUST</bcp14> choose routing t
entries by using the destination-first ordering, where a routing table able
entry R1 is preferred to a routing table entry R2 when either R1's entries by using destination-first ordering, where routing table
destination prefix is more specific than R2's, or the destination prefixes entry R1 is preferred to 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.</t> are equal and R1's source prefix is more specific than R2's.</t>
<t>In practice, this means that a source-specific Babel implementation
<t>In practice, this means that a source-specific Babel implementation
must take care that any lower layer that performs packet forwarding obey must take care that any lower layer that performs packet forwarding obey
this semantics. More precisely:</t> these semantics. More precisely:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>if the lower layers implement the destination-first ordering, then the <li>if the lower layers implement destination-first ordering, then the
Babel implementation SHOULD use them directly;</t> Babel implementation <bcp14>SHOULD</bcp14> use them directly;</li>
<t>if the lower layers can hold source-specific routes, but not with the <li>if the lower layers can hold source-specific routes but not with the
right semantics, then the Babel implementation MUST either silently ignore right semantics, then the Babel implementation <bcp14>MUST</bcp14> either silent
any source-specific routes, or disambiguate the routing table by using ly ignore
any source-specific routes or disambiguate the routing table by using
a suitable disambiguation algorithm (see Section V.B of a suitable disambiguation algorithm (see Section V.B of
<xref target="SS-ROUTING"/> for such an algorithm);</t> <xref target="SS-ROUTING" format="default"/> for such an algorithm);</li>
<t>if the lower layers cannot hold source-specific routes, then a Babel <li>if the lower layers cannot hold source-specific routes, then a Babel
implementation MUST silently ignore any source-specific routes.</t> implementation <bcp14>MUST</bcp14> silently ignore any source-specific routes.</
</list></t> li>
</ul>
</section> </section>
<section numbered="true" toc="default">
<section title="Protocol Operation"> <name>Protocol Operation</name>
<t>This extension does not fundamentally change the operation of the Babel
<t>This extension does not fundamentally change the operation of the Babel
protocol, and we therefore only describe differences between the original protocol, and we therefore only describe differences between the original
protocol and the extended protocol.</t> protocol and the extended protocol.</t>
<t>In the original protocol, three TLVs carry a destination prefix: <t>In the original protocol, three TLVs carry a destination prefix:
Updates, Route Requests and Seqno Requests. This specification extends Update, Route Request, and Seqno Request TLVs. This specification extends
these messages so that they may carry a Source Prefix sub-TLV, as these messages so that they may carry a Source Prefix sub-TLV, as
described in <xref target="protocol-encoding"/> below. The sub-TLV is described in <xref target="protocol-encoding" format="default"/>. The sub-TLV i
marked as mandatory, so that an unextended implementation will silently s
ignore the whole enclosing TLV. A node obeying this specification MUST marked as mandatory so that an unextended implementation will silently
NOT send a TLV with a zero-length source prefix: instead, it sends a TLV ignore the whole enclosing TLV. A node obeying this specification <bcp14>MUST
NOT</bcp14> send a TLV with a zero-length source prefix; instead, it sends a TLV
with no Source Prefix sub-TLV. Conversely, an extended implementation with no Source Prefix sub-TLV. Conversely, an extended implementation
MUST interpret an unextended TLV as carrying a source prefix of zero <bcp14>MUST</bcp14> interpret an unextended TLV as carrying a source prefix of z ero
length. Taken together, these properties ensure interoperability between length. Taken together, these properties ensure interoperability between
the original and extended protocols (see <xref target="compatibility"/> the original and extended protocols (see <xref target="compatibility" format="de
below).</t> fault"/>).</t>
<section numbered="true" toc="default">
<section title="Protocol Messages"> <name>Protocol Messages</name>
<t>This extension allows three TLVs of the original Babel protocol to
<t>This extension allows three TLVs of the original Babel protocol to
carry a source prefix: Update TLVs, Route Request TLVs, and Seqno Request carry a source prefix: Update TLVs, Route Request TLVs, and Seqno Request
TLVs.</t> TLVs.</t>
<t>In order to advertise a route with a non-zero length source prefix,
<t>In order to advertise a route with a non-zero length source prefix, a node sends a source-specific update, i.e., an update with a Source
a node sends a source-specific Update, i.e., an Update with a Source Prefix sub-TLV. When a node receives a source-specific update (prefix,
Prefix sub-TLV. When a node receives a source-specific Update (prefix,
source prefix, router-id, seqno, metric) from a neighbour neigh, it source prefix, router-id, seqno, metric) from a neighbour neigh, it
behaves as described in <xref target="RFC8966"/> Section&nbsp;3.5.3, behaves as described in <xref target="RFC8966" sectionFormat="comma" section="3. 5.3"/>,
except that the entry under consideration is indexed by (prefix, plen, except that the entry under consideration is indexed by (prefix, plen,
sprefix, splen, neigh) rather than just (prefix, plen, neigh).</t> sprefix, splen, neigh) rather than just (prefix, plen, neigh).</t>
<t>Similarly, when a node needs to send a request of either kind that
<t>Similarly, when a node needs to send a Request of either kind that
applies to a route with a non-zero length source prefix, it sends applies to a route with a non-zero length source prefix, it sends
a source-specific Request, i.e., a Request with a Source Prefix sub-TLV. a source-specific request, i.e., a request with a Source Prefix sub-TLV.
When a node receives a source-specific Request, it behaves as described in When a node receives a source-specific request, it behaves as described in
Section 3.8 of <xref target="RFC8966"/>, except that the request applies to <xref target="RFC8966" sectionFormat="of" section="3.8"/>, except that the reque
the Route Table entry carrying the source prefix indicated by the st applies to
the route table entry carrying the source prefix indicated by the
Source Prefix sub-TLV.</t> Source Prefix sub-TLV.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Wildcard Messages</name>
<section title="Wildcard Messages"> <t>In the original protocol, the address encoding (AE) value 0 is used f
or
<t>In the original protocol, the Address Encoding (AE) value 0 is used for wildcard messages: messages that apply to all routes of any address
wildcard messages: messages that apply to all routes, of any address
family and with any destination prefix. Wildcard messages are allowed in family and with any destination prefix. Wildcard messages are allowed in
two places in the protocol: wildcard retractions are used to retract all two places in the protocol: wildcard retractions are used to retract all
of the routes previously advertised by a node on a given interface, and of the routes previously advertised by a node on a given interface, and
wildcard Route Requests are used to request a full dump of the Route Table wildcard route requests are used to request a full dump of the route table
from a given node. Wildcard messages are intended to apply to all routes, from a given node. Wildcard messages are intended to apply to all routes,
including routes decorated with additional data and AE values to be including routes decorated with additional data and AE values to be
defined by future extensions, and hence this specification extends defined by future extensions; hence, this specification extends
wildcard operations to apply to all routes, whatever the value of the wildcard operations to apply to all routes, whatever the value of the
source prefix.</t> source prefix.</t>
<t>More precisely, a node receiving an update with the AE field set to
<t>More precisely, a node receiving an Update with the AE field set to 0 and the Metric field set to infinity (a wildcard retraction) <bcp14>MUST</bcp1
0 and the Metric field set to infinity (a wildcard retraction) MUST apply 4> apply
the route acquisition procedure described in Section 3.5.3 of <xref the route acquisition procedure described in <xref target="RFC8966" sectionForma
target="RFC8966"/> to all of the routes that it has learned from the sending t="of" section="3.5.3"/> to all of the routes that it has learned from the sendi
node, whatever the value of the source prefix. A node MUST NOT send ng
node, whatever the value of the source prefix. A node <bcp14>MUST NOT</bcp14> s
end
a wildcard retraction with an attached source prefix, and a node that a wildcard retraction with an attached source prefix, and a node that
receives a wildcard retraction with a source prefix MUST ignore the receives a wildcard retraction with a source prefix <bcp14>MUST</bcp14> ignore t he
retraction.</t> retraction.</t>
<t>Similarly, a node that receives a route request with the AE field set
<t>Similarly, a node that receives a route request with the AE field set to 0 (a wildcard route request) <bcp14>SHOULD</bcp14> send a full routing table
to 0 (a wildcard route request) SHOULD send a full routing table dump, dump,
including routes with a non-zero length source prefix. A node MUST NOT including routes with a non-zero length source prefix. A node <bcp14>MUST NOT</
bcp14>
send a wildcard request that carries a source prefix, and a node receiving send a wildcard request that carries a source prefix, and a node receiving
a wildcard request with a source prefix MUST ignore the request.</t> a wildcard request with a source prefix <bcp14>MUST</bcp14> ignore the request.<
/t>
</section> </section>
</section>
</section> <section anchor="compatibility" numbered="true" toc="default">
<name>Compatibility with the Base Protocol</name>
<section title="Compatibility with the base protocol" anchor="compatibility"> <t>The protocol extension defined in this document is, to a great extent,
interoperable with the base protocol defined in <xref target="RFC8966" format="d
<t>The protocol extension defined in this document is, to a great extent, efault"/>
interoperable with the base protocol defined in <xref target="RFC8966"/>
(and all previously standardised extensions). More precisely, if (and all previously standardised extensions). More precisely, if
non-source-specific routers and source-specific routers are mixed in non-source-specific routers and source-specific routers are mixed in
a single routing domain, Babel's loop-avoidance properties are preserved, a single routing domain, Babel's loop-avoidance properties are preserved,
and, in particular, no persistent routing loops will occur.</t> and, in particular, no persistent routing loops will occur.</t>
<t>However, this extension is encoded using mandatory sub-TLVs, introduced
<t>However, this extension is encoded using mandatory sub-TLVs, introduced in <xref target="RFC8966" format="default"/>, and therefore is not compatible wi
in <xref target="RFC8966"/>, and therefore is not compatible with the th the
older version of the Babel Routing Protocol <xref target="RFC6126"/> which older version of the Babel routing protocol <xref target="RFC6126" format="defau
does not support mandatory sub-TLVs. Consequently, this extension MUST lt"/>, which
NOT be used in a routing domain in which some routers implement RFC 6126, does not support mandatory sub-TLVs. Consequently, this extension <bcp14>MUST
otherwise persistent routing loops may occur.</t> NOT</bcp14> be used in a routing domain in which some routers implement <xref ta
rget="RFC6126"/>;
<section title="Starvation and Blackholes"> otherwise, persistent routing loops may occur.</t>
<section numbered="true" toc="default">
<t>In general, the discarding of source-specific routes by <name>Starvation and Blackholes</name>
<t>In general, the discarding of source-specific routes by
non-source-specific routers will cause route starvation. Intuitively, non-source-specific routers will cause route starvation. Intuitively,
unless there are enough non-source-specific routes in the network, unless there are enough non-source-specific routes in the network,
non-source-specific routers will suffer starvation, and discard packets non-source-specific routers will suffer starvation and discard packets
for destinations that are only announced by source-specific routers.</t> for destinations that are only announced by source-specific routers.</t>
<t>In the common case where all source-specific routes are originated at
<t>In the common case where all source-specific routes are originated at
one of a small set of edge routers, a simple yet sufficient condition for one of a small set of edge routers, a simple yet sufficient condition for
avoiding starvation is to build a connected source-specific backbone that avoiding starvation is to build a connected source-specific backbone that
includes all of the edge routers, and announce a non-source-specific includes all of the edge routers and announce a non-source-specific
default route towards the backbone.</t> default route towards the backbone.</t>
</section>
</section> </section>
<section anchor="protocol-encoding" numbered="true" toc="default">
</section> <name>Protocol Encoding</name>
<t>This extension defines a new sub-TLV used to carry a source prefix: the
<section title="Protocol Encoding" anchor="protocol-encoding"> Source Prefix sub-TLV. It can be used within an Update, Route Request,
or Seqno Request TLV to match a source-specific entry of the route
<t>This extension defines a new sub-TLV used to carry a source prefix: the table in conjunction with the destination prefix natively carried by
Source Prefix sub-TLV. It can be used within an Update, a Route Request
or a Seqno Request TLV to match a source-specific entry of the Route
Table, in conjunction with the destination prefix natively carried by
these TLVs.</t> these TLVs.</t>
<t>Since a source-specific routing entry is characterized by a single <t>Since a source-specific routing entry is characterised by a single
destination prefix and a single source prefix, a source-specific contains destination prefix and a single source prefix, a source-specific message contain
message exactly one Source Prefix sub-TLV. A node MUST NOT send more s
exactly one Source Prefix sub-TLV. A node <bcp14>MUST NOT</bcp14> send more
than one Source Prefix sub-TLV in a TLV, and a node receiving more than than one Source Prefix sub-TLV in a TLV, and a node receiving more than
one Source Prefix sub-TLV in a single TLV MUST ignore the TLV. It MAY one Source Prefix sub-TLV in a single TLV <bcp14>MUST</bcp14> ignore the TLV. I t <bcp14>MAY</bcp14>
ignore the whole packet.</t> ignore the whole packet.</t>
<section numbered="true" toc="default">
<section title="Source Prefix sub-TLV"> <name>Source Prefix Sub-TLV</name>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 = 128 | Length | Source Plen | Source Prefix... | Type = 128 | Length | Source Plen | Source Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork></figure> ]]></artwork>
<t>Fields:
<t>Fields:
<list style="hanging" hangIndent="10">
<t hangText="Type">Set to 128 to indicate a Source Prefix
sub-TLV.</t>
<t hangText="Length">The length of the body, in octets, exclusive of the
Type and Length fields.</t>
<t hangText="Source Plen">The length of the advertised source prefix, in
bits. This MUST NOT be 0.</t>
<t hangText="Source Prefix">The source prefix being advertised. This
field's size is (Source Plen)/8 octets rounded upwards.</t>
</list>
</t> </t>
<dl newline="false" spacing="normal" indent="15">
<t>The length of the body TLV is normally of size 1+(Source Plen)/8 <dt>Type</dt>
<dd>Set to 128 to indicate a Source Prefix
sub-TLV.</dd>
<dt>Length</dt>
<dd>The length of the body, in octets, exclusive of the
Type and Length fields.</dd>
<dt>Source Plen</dt>
<dd>The length of the advertised source prefix, in
bits. This <bcp14>MUST NOT</bcp14> be 0.</dd>
<dt>Source Prefix</dt>
<dd>The source prefix being advertised. This
field's size is (Source Plen)/8 octets rounded upwards.</dd>
</dl>
<t>The length of the body TLV is normally of size 1+(Source Plen)/8
rounded upwards. If the Length field indicates a length smaller than rounded upwards. If the Length field indicates a length smaller than
that, then the sub-TLV is corrupt, and the whole enclosing TLV must be that, then the sub-TLV is corrupt, and the whole enclosing TLV must be
ignored; if the Length field indicates a length that is larger, then the ignored; if the Length field indicates a length that is larger, then the
extra octets contained in the sub-TLV MUST be silently ignored.</t> extra octets contained in the sub-TLV <bcp14>MUST</bcp14> be silently ignored.</
t>
<t>The contents of the Source Prefix sub-TLV are interpreted according to <t>The contents of the Source Prefix sub-TLV are interpreted according t
o
the AE of the enclosing TLV. If a TLV with AE equal to 0 contains the AE of the enclosing TLV. If a TLV with AE equal to 0 contains
a Source Prefix sub-TLV, then the whole enclosing TLV MUST be ignored. If a Source Prefix sub-TLV, then the whole enclosing TLV <bcp14>MUST</bcp14> be ign
a TLV contains multiple Source Prefix sub-TLVs, then the whole TLV MUST be ored. If
a TLV contains multiple Source Prefix sub-TLVs, then the whole TLV <bcp14>MUST</
bcp14> be
ignored.</t> ignored.</t>
<t>Note that this sub-TLV is a mandatory sub-TLV. Therefore, as describ
<t>Note that this sub-TLV is a mandatory sub-TLV. Therefore, as described ed
in Section 4.4 of <xref target="RFC8966"/>, the whole TLV MUST be ignored if in <xref target="RFC8966" sectionFormat="of" section="4.4"/>, the whole TLV <bcp
14>MUST</bcp14> be ignored if
that sub-TLV is not understood (or malformed).</t> that sub-TLV is not understood (or malformed).</t>
</section>
</section> <section numbered="true" toc="default">
<name>Source-Specific Update</name>
<section title="Source-specific Update"> <t>The source-specific update is an Update TLV with a Source Prefix
<t>The source-specific Update is an Update TLV with a Source Prefix
sub-TLV. It advertises or retracts source-specific routes in the same sub-TLV. It advertises or retracts source-specific routes in the same
manner as routes with non-source-specific Updates (see <xref manner as routes with non-source-specific updates (see <xref target="RFC8966" fo
target="RFC8966"/>). A wildcard retraction (Update with AE equal to 0) MUST rmat="default"/>). A wildcard retraction (update with AE equal to 0) <bcp14>MUS
NOT carry a Source Prefix sub-TLV.</t> T
NOT</bcp14> carry a Source Prefix sub-TLV.</t>
<t>Babel uses a stateful compression scheme to reduce the size taken by <t>Babel uses a stateful compression scheme to reduce the size taken by
destination prefixes in update TLVs (see Section 4.5 of <xref destination prefixes in Update TLVs (see <xref target="RFC8966" sectionFormat="o
target="RFC8966"/>). The source prefix defined by this extension is not f" section="4.5"/>). The source prefix defined by this extension is not
compressed. On the other hand, compression is allowed for the destination compressed. On the other hand, compression is allowed for the destination
prefixes carried by source-specific updates. As described in Section 4.5 prefixes carried by source-specific updates. As described in <xref target="RFC8
of <xref target="RFC8966"/>, unextended implementations will correctly 966" sectionFormat="of" section="4.5"/>, unextended implementations will correct
ly
update their parser state while otherwise ignoring the whole TLV.</t> update their parser state while otherwise ignoring the whole TLV.</t>
</section>
</section> <section anchor="ss-request" numbered="true" toc="default">
<name>Source-Specific Route Request</name>
<section title="Source-specific Route Request" anchor="ss-request"> <t>A source-specific route request is a Route Request TLV with a Source
<t>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 Prefix sub-TLV. It prompts the receiver to send an update for a given
pair of destination and source prefixes, as described in Section 3.8.1.1 pair of destination and source prefixes, as described in <xref target="RFC8966"
of <xref target="RFC8966"/>. A wildcard request (Route Request with AE sectionFormat="of" section="3.8.1.1"/>. A wildcard request (route request with
equals to 0) MUST NOT carry a Source Prefix sub-TLV; if a wildcard request AE
with a Source Prefix sub-TLV is received, then the request MUST be equal to 0) <bcp14>MUST NOT</bcp14> carry a Source Prefix sub-TLV; if a wildcard
request
with a Source Prefix sub-TLV is received, then the request <bcp14>MUST</bcp14> b
e
ignored.</t> ignored.</t>
</section>
<section numbered="true" toc="default">
</section> <name>Source-Specific Seqno Request</name>
<t>A source-specific seqno request is a Seqno Request TLV with a Source
<section title="Source-Specific Seqno Request"> Prefix sub-TLV. It requests that the receiving node perform the procedure
described in <xref target="RFC8966" sectionFormat="of" section="3.8.1.2"/> but a
<t>A source-specific Seqno Request is a Seqno Request TLV with a Source pplied to
Prefix sub-TLV. It requests the receiving node to perform the procedure a pair consisting of a destination and source prefix.</t>
described in Section 3.8.1.2 of <xref target="RFC8966"/>, but applied to </section>
a pair of a destination and source prefix.</t> </section>
<section numbered="true" toc="default">
</section> <name>IANA Considerations</name>
<t>IANA has allocated sub-TLV number 128 for the Source Prefix sub-TLV in
</section> the "Babel Sub-TLV Types" registry.</t>
</section>
<section title="IANA Considerations"> <section numbered="true" toc="default">
<name>Security Considerations</name>
<t>IANA has allocated sub-TLV number 128 for the Source Prefix sub-TLV in <t>The extension defined in this document adds a new sub-TLV to three
the Babel sub-TLV types registry.</t> sub-TLVs already present in the original Babel protocol and does not
</section>
<section title="Security considerations">
<t>The extension defined in this document adds a new sub-TLV to three
sub-TLVs already present in the original Babel protocol, and does not
change the security properties of the protocol itself. However, the change the security properties of the protocol itself. However, the
additional flexibility provided by source-specific routing might additional flexibility provided by source-specific routing might
invalidate the assumptions made by some network administrators, which invalidate the assumptions made by some network administrators, which
could conceivably lead to security issues.</t> could conceivably lead to security issues.</t>
<t>For example, a network administrator might be tempted to abuse route
<t>For example, a network administrator might be tempted to abuse route filtering (<xref target="RFC8966" sectionFormat="of" section="C"/>) as a securit
filtering (Appendix C of <xref target="RFC8966"/>) as a security mechanism. y mechanism.
Unless the filtering rules are designed to take source-specific routing Unless the filtering rules are designed to take source-specific routing
into account, they might be bypassed by a source-specific route, which into account, they might be bypassed by a source-specific route, which
might cause traffic to reach a portion of a network that was thought to be might cause traffic to reach a portion of a network that was thought to be
protected. A network administrator might also assume that no route protected. A network administrator might also assume that no route
is more specific than a host route, and use a host route in order to is more specific than a host route and use a host route in order to
direct traffic for a given destination through a security device (e.g., direct traffic for a given destination through a security device (e.g.,
a firewall); source-specific routing invalidates this assumption, and in a firewall); source-specific routing invalidates this assumption, and, in
some topologies announcing a source-specific route might conceivably be some topologies, announcing a source-specific route might conceivably be
used to bypass the security device.</t> used to bypass the security device.</t>
</section>
</middle>
<back>
</section> <references>
<name>References</name>
<section title="Acknowledgments"> <references>
<name>Normative References</name>
<t>The authors are indebted to Donald Eastlake, Joel Halpern, and Toke <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Hoiland-Jorgensen for their help with this document.</t> FC.2119.xml"/>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119"><front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="BCP84"><front>
<title>Ingress Filtering for Multihomed Networks</title>
<author fullname="Fred Baker" initials="F." surname="Baker"/>
<author fullname="Pekka Savola" initials="P." surname="Savola"/>
<date month="March" year="2004"/>
</front>
<seriesInfo name="BCP" value="84"/>
<seriesInfo name="RFC" value="3704"/>
</reference>
<reference anchor="RFC8966" target="https://www.rfc-editor.org/info/rfc8966">
<front>
<title>The Babel Routing Protocol</title>
<author initials="J." surname="Chroboczek" fullname="J. Chroboczek"/>
<author initials="D." surname="Schinazi" fullname="D. Schinazi"/>
<date year="2021" month="January"/>
</front>
<seriesInfo name="RFC" value="8966"/>
<seriesInfo name="DOI" value="10.17487/RFC8966"/>
</reference>
<reference anchor="RFC8174"><front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials="B." surname="Leiba" fullname="B. Leiba"/>
<date year="2017" month="May"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC6126" target="https://www.rfc-editor.org/info/rfc6126">
<front>
<title>The Babel Routing Protocol</title>
<author initials="J." surname="Chroboczek" fullname="J. Chroboczek"/>
<date year="2011" month="April"/>
</front>
<seriesInfo name="RFC" value="6126"/>
<seriesInfo name="DOI" value="10.17487/RFC6126"/>
</reference>
<reference anchor="SS-ROUTING" target="http://arxiv.org/pdf/1403.0445">
<front>
<title>Source-Specific Routing</title>
<author initials="M." surname="Boutier" fullname="Matthieu Boutier"/>
<author initials="J." surname="Chroboczek" fullname="Juliusz Chroboczek"/>
<date year="2014" month="August"/>
</front>
<annotation>In Proc. IFIP Networking 2015.</annotation>
</reference>
<reference anchor="RFC3484" target="https://www.rfc-editor.org/info/rfc3484">
<front>
<title>Default Address Selection for Internet Protocol version 6 (IPv6)</title>
<author initials="R." surname="Draves" fullname="R. Draves"/>
<date year="2003" month="February"/>
</front>
<seriesInfo name="RFC" value="3484"/>
<seriesInfo name="DOI" value="10.17487/RFC3484"/>
</reference>
<reference anchor="RFC8305" target="https://www.rfc-editor.org/info/rfc8305">
<front>
<title>Happy Eyeballs Version 2: Better Connectivity Using Concurrency</title>
<author initials="D." surname="Schinazi" fullname="D. Schinazi"/>
<author initials="T." surname="Pauly" fullname="T. Pauly"/>
<date year="2017" month="December"/>
</front>
<seriesInfo name="RFC" value="8305"/>
<seriesInfo name="DOI" value="10.17487/RFC8305"/>
</reference>
<reference anchor="RFC8684" target="https://www.rfc-editor.org/info/rfc8684">
<front>
<title>TCP Extensions for Multipath Operation with Multiple Addresses</title>
<author initials="A." surname="Ford" fullname="A. Ford">
<organization/>
</author>
<author initials="C." surname="Raiciu" fullname="C. Raiciu"/>
<author initials="M." surname="Handley" fullname="M. Handley"/>
<author initials="O." surname="Bonaventure" fullname="O. Bonaventure"/>
<author initials="C." surname="Paasch" fullname="C. Paasch"/>
<date year="2020" month="March"/>
</front>
<seriesInfo name="RFC" value="8684"/>
<seriesInfo name="DOI" value="10.17487/RFC8684"/>
</reference>
<reference anchor="RFC4960" target="https://www.rfc-editor.org/info/rfc4960">
<front>
<title>Stream Control Transmission Protocol</title>
<author initials="R." surname="Stewart" fullname="R. Stewart" role="editor"/>
<date year="2007" month="September"/>
</front>
<seriesInfo name="RFC" value="4960"/>
<seriesInfo name="DOI" value="10.17487/RFC4960"/>
</reference>
<reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8445"> <referencegroup anchor="BCP84" target="https://www.rfc-editor.org/info/bcp84">
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>Interactive Connectivity Establishment (ICE): A Protocol for Network Addr FC.3704.xml"/>
ess Translator (NAT) Traversal</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials="A." surname="Keranen" fullname="A. Keranen"/> FC.8704.xml"/>
<author initials="C." surname="Holmberg" fullname="C. Holmberg"/> </referencegroup>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg"/>
<date year="2018" month="July"/>
</front>
<seriesInfo name="RFC" value="8445"/>
<seriesInfo name="DOI" value="10.17487/RFC8445"/>
</reference>
</references> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8966.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6126.xml"/>
</back> <reference anchor="SS-ROUTING" target="http://arxiv.org/pdf/1403.0445">
<front>
<title>Source-Specific Routing</title>
<author initials="M." surname="Boutier" fullname="Matthieu Boutier"/
>
<author initials="J." surname="Chroboczek" fullname="Juliusz Chroboc
zek"/>
<date year="2015" month="May"/>
</front>
<seriesInfo name="DOI" value="10.1109/IFIPNetworking.2015.7145305"/>
<refcontent>IFIP Networking Conference</refcontent>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6724.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8305.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8684.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4960.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8445.xml"/>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors are indebted to <contact fullname="Donald Eastlake"/>, <con
tact fullname="Joel Halpern"/>, and <contact fullname="Toke
Hoiland-Jorgensen"/> for their help with this document.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 100 change blocks. 
542 lines changed or deleted 455 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/