One document matched: draft-ietf-rtgwg-dst-src-routing-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="yes" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents, but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="4"?>
<!-- Sets the number of levels of sections/sections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc rfcprocack="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-ietf-rtgwg-dst-src-routing-02"
ipr="trust200902">
<front>
<title abbrev="Destination/Source Routing">
Destination/Source Routing</title>
<author fullname="David Lamparter" initials="D." surname="Lamparter">
<organization>NetDEF</organization>
<address>
<postal>
<street></street>
<city>Leipzig</city>
<code>04103</code>
<region></region>
<country>Germany</country>
</postal>
<email>david@opensourcerouting.org</email>
</address>
</author>
<author fullname="Anton Smirnov" initials="A." surname="Smirnov">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>De Kleetlaan 6a</street>
<city>Diegem</city>
<region/>
<code>1831</code>
<country>Belgium</country>
</postal>
<email>as@cisco.com</email>
</address>
</author>
<date year="2016"/>
<area>Routing</area>
<workgroup>rtgwg</workgroup>
<abstract>
<t>This note specifies using packets' source addresses in route lookups
as additional qualifier to be used in route lookup. This applies to
<xref target="RFC2460">IPv6</xref> in general with specific
considerations for routing protocol left for separate documents.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Both <xref target="RFC0791">IPv4</xref> and
<xref target="RFC2460">IPv6</xref> architectures specify that
determination of the outgoing interface and next-hop gateway
for packet forwarding is based solely on the destination
address contained in the packet header. There exists class of
network design problems which require packet forwarding to
consider more than just the destination IP address (see <xref
target="usecases"/> for examples). At present these problems
are routinely resolved by configuring on routers special
forwarding based on a local policy. The policy enforces packet
forwarding decision outcome based not only on the destination
address but also on other fields in the packet's IP header,
most notably the source address. Such policy-based routing is
conceptually similar to static routes in that it is highly
static in nature and must be closely governed via the
management plane (most frequently - via managing configuration
by an operator). Thus policy-based routing configuration and
maintenance is costly and error-prone.</t>
<t>Rapid expansion of IPv6 to networks were static configuration
is not acceptable due to both its static nature and necessity
of frequent intervention by a skilled operator requires change
in the paradigm of forwarding IP packets based only on their
destination address.</t>
<t>This document describes architecture of source-destination
routing. This includes description of making a packet
forwarding decision and requirements to dynamic routing
protocols which will disseminate source-destination routing
information. Specific considerations for particular dynamic
routing protocols are outside of the scope of this note and
will be covered in separate documents.</t>
<t>General concepts covered by this document are equally
applicable to both IPv4 and IPv6. Considering limited backward
compatibility of the source-destination routing with the
traditional destination-only routing, it appears likely that
at this stage of IPv4 deployment change of routing paradigm in
existing networks is not feasible (see <xref
target="interop"/> for discussion of backwards
compatibility). So examples in this document will be given
using IPv6 addresses.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
</section>
<section title="Use cases" anchor="usecases">
<section title="Dual-connected home / SOHO network" anchor="homenet">
<t>Small networks - such as SOHO or the home networks
(homenet) - may be multihomed (i.e. dual-connected) to two
different Internet Service Providers (ISPs). Benefits of
doing this may include resiliency or faster access to
important resources (for example, video or cloud services)
local to ISPs.</t>
<figure title="Example of multihomed small network">
<artwork align="center">
_____ ,,-------.
_( )_ ,' ``.
___ +----+ _( )_ ,' `.
/ \---| R1 |---(_ ISP 1 _)------/ \
/ \ +----+ (_ _) / \
/ Small \ (_____) ( )
( ) ( The Internet )
( ) _____ ( )
\ net / _( )_ \ /
\ / +----+ _( )_ \ /
\___/---| R2 |---(_ ISP 2 _)-------`. ,'
+----+ (_ _) `. ,'
(_____) ``-------''
</artwork>
</figure>
<t>Each ISP will allocate to the network IP address (or small
range of IP addresses) to use as source address for Internet
communications.</t>
<t>Since connectivity providers generally secure their ingress along
the lines of <xref target="RFC2827">BCP 38</xref>,
small multihomed networks have a need to ensure their traffic
leaves their network with a correct combination of source address and
exit taken. This applies to networks of a particular pattern where
the provider's default (dynamic) address provisioning methods are used
and no fixed IP space is allocated, e.g. home networks, small business
users and mobile ad-hoc setups.</t>
<t>While IPv4 networks would conventionally use NAT or policy routing to
produce correct behaviour, this not desirable to carry over to IPv6.
Instead, assigning addresses from multiple prefixes in parallel shifts
the choice of uplink to the host. However, now for finding the proper
exit the source address of packets must be taken into account.</t>
<t>Source-destination routing, when enabled on routers in the
multihomed small network (including routers R1 and R2), solves
the problem by driving packets originated by internal hosts to
the correct Internet exit point considering IP source address
assigned to the packet by originating host.</t>
<t>For a general introduction and aspects of interfacing routers to
hosts, refer to <xref target="I-D.sarikaya-6man-sadr-overview"/>.</t>
</section>
<section title="Degree of traffic engineering">
<t>Consider enterprise consisting of a headquarter (HQ) and
branch offices. A branch office is connected to the
enterprise HQ network via 2 links. For performance or
security reasons it is desired to route corporate traffic
via one link and Internet traffic via another link. In
direction branch -> HQ the problem is easily solvable by
having the default route pointing to the Internet link and
HQ routes pointing to another link. But destination routing
does not provide an easy way to achieve traffic separation
in direction HQ -> branch because destination is the same
(branch network).</t>
<t>Source-destination routing provides an easy way to sort
traffic going to the branch based on its source address.</t>
</section>
<section title="Distributed filtering based on source address">
<t>A network has untrusted zone and secure one (and both zones
comprise many links and routers). Computers from the secure
zone need to be able to communicate with some selected hosts
in the untrusted zone. The secure zone is protected by a
firewall. The firewall is configured to check that packets
arriving from the untrusted zone have destination address in
the range of secure zone and source address of trusted
hosts in the untrusted zone. This works but leaves the
firewall open to DDOS attack from outside.</t>
<t>If routers in the untrusted zone are configured with
source-destination routing (and, possibly, unicast RPF
check) and receive via dynamic routing protocol routes
<destination: secure zone; source: trusted host in the
untrusted zone> then DDOS attack is dropped by routers on
the edge of source-destination routing area. DDOS attack
does not even reach the firewall whose resources are freed
to deal with Deep Packet Inspection. On the other hand,
security policy is managed in a single point - on a router
injecting relevant source-destination routes into the
dynamic routing protocol.</t>
</section>
</section>
<section title="Principle of operation">
<t>The mechanism in this document is such that a source prefix is added
to all route entries. This document assumes all entries have a source
prefix, with ::/0 as default value for entries installed without a
specified source prefix. This need not be implemented in this
particular way, however the system MUST behave exactly as if it were.
In particular, a difference in behaviour between routes with a source
prefix of ::/0 and routes without source prefix MUST NOT be visible.
</t>
<t>For uniqueness considerations, the source prefix factors MUST be
taken into account for comparisons. Two routes with identical
information except the source prefix MAY exist and MUST be installed
and matched.</t>
<section title="Lookup ordering and disambiguation" anchor="deflookup">
<t>When a router is making packet forwarding decision, that
is consulting its routing table in order to determine
outgoing interface and next-hop to forward the packet to, it
will use information from packet's header to look up best
matching route from the routing table. This section
describes lookup into the source-destination routing
table.</t>
<t>For longest-match lookups, the source prefix is matched after the
destination prefix. This is to say, first the longest matching
destination prefix is found, then the table is searched for the route
with the longest source prefix match, while only considering routes
with exactly the destination prefix previously found. If and only if
no such route exists (because none of the source prefixes match), the
lookup moves to the next less specific destination prefix.</t>
<t>A router MUST continue to a less specific destination prefix if no
route matches on the source prefix. It MUST NOT terminate lookup
on such an event.</t>
<t>Using A < B to mean "A is more specific than B", this is
represented as:</t>
<figure><artwork><![CDATA[
A < B := Adst < Bdst
|| (Adst == Bdst && Asrc < Bsrc)
]]>
</artwork>
</figure>
<t>Implementations MAY implement lookup algorithm differently
from step-by-step description given above but if they do so
then outcome of the algorithm MUST be exactly the same as if
above steps were used. One example of equivalent lookup
algorithm is given in <xref target="altlookup"/>.</t>
</section>
<section title="Ordering Rationale">
<t>Ordering of searching for address match is important and
reversing it would lead to semantically different
behavior. This standard requires most specific match on
destination address to be found before looking for match on
source address.</t>
<t>Choosing destination to be evaluated first caters to the assumption
that local networks should have full, contiguous connectivity to each
other. This implies that those specific local routes always match
first based on destination, and use a zero ("all sources") source
prefix.</t>
<t>If the source prefix were to be matched first, this would result in
a less specific (e.g. default) route with a source prefix to match
before those local routes. In other terms, this would essentially
divide local connectivity into zones based on source prefix, which
is not the intention of this document.</t>
<t>Hence, this document describes destination-first match search.</t>
</section>
<section title="Multi-FIB lookup" anchor="altlookup">
<t>Routing table lookup algorithm described in <xref
target="deflookup"/> is iterative and looks for destination
match first. This section outlines alternative
implementation of the lookup algorithm which produces the
same outcome but does match on the source address
first. Algorithm in this section is given for illustration
purposes only.</t>
<t>Lookup algorithm described in this section is not iterative
at the expense of maintaining multiple lookup tables. Such
tradeoff may be desirable for implementation on routers
where packet forwarding is assisted by specialized ASICs.</t>
<t>The crux of the algorithm is in creating multiple
destination-only tables for forwarding lookups (FIB tables)
with each table being associated with unique range of source
addresses.</t>
<t>After source-destination routing information has been
collected, one FIB table is created for each source range
including the default range ::/0. Source-destination routes
then replicated into each destination-only FIB table whose
associated source address range is a subset of route's
source range. Note that this rule means routes with default
source range ::/0 are replicated into each FIB
table.</t>
<t>In case when multiple routes with the same destination
prefix are replicated into the same FIB table only route
with the most specific source address range is
installed.</t>
<t>For example, if source-destination routing table contains
these routes:</t>
<texttable style="headers">
<ttcol>Destination prefix</ttcol>
<ttcol>Source range</ttcol>
<ttcol>Next Hop</ttcol>
<c>::/0,</c>
<c>::/0,</c>
<c>NH1</c>
<c>2001:101:1234::/48,</c>
<c>2001:db8:3456:8000::/56,</c>
<c>NH2</c>
<c>2001:101:5678::/48,</c>
<c>2001:db8:3456:8000::/56,</c>
<c>NH3</c>
<c></c>
<c>::/0,</c>
<c>NH4</c>
<c>2001:101:abcd::/48,</c>
<c>2001:db8:3456::/48,</c>
<c>NH5</c>
</texttable>
<t>then 3 FIB tables will be created associated with source
ranges ::/0, 2001:db8:3456::/48 and
2001:db8:3456:8000::/56. In this example range
2001:db8:3456:8000::/56 is a subset of less specific range
2001:db8:3456::/48. Such inclusion makes a somewhat
artificial example but was intentionally selected to
demonstrate hierarchy of route replication.</t>
<t>And content of these FIB tables will be:</t>
<t>FIB 1 (source range ::/0):</t>
<texttable style="headers">
<ttcol>Destination prefix</ttcol>
<ttcol>Next Hop</ttcol>
<c>::/0,</c>
<c>NH1</c>
<c>2001:101:5678::/48,</c>
<c>NH4</c>
</texttable>
<t>FIB 2 (source range 2001:db8:3456::/48):</t>
<texttable style="headers">
<ttcol>Destination prefix</ttcol>
<ttcol>Next Hop</ttcol>
<c>::/0,</c>
<c>NH1</c>
<c>2001:101:5678::/48,</c>
<c>NH4</c>
<c>2001:101:abcd::/48,</c>
<c>NH5</c>
</texttable>
<t>FIB 3 (source range 2001:db8:3456:8000::/56):</t>
<texttable style="headers">
<ttcol>Destination prefix</ttcol>
<ttcol>Next Hop</ttcol>
<c>::/0,</c>
<c>NH1</c>
<c>2001:101:1234::/48,</c>
<c>NH2</c>
<c>2001:101:5678::/48,</c>
<c>NH3</c>
<c>2001:101:abcd::/48,</c>
<c>NH5</c>
</texttable>
<t>During packet forwarding, lookup first matches source
address against the list of address ranges associated with
FIB tables to select a FIB table with the most specific
source address range and then does destination-only lookup
in the selected FIB table.</t>
</section>
</section>
<section title="Requirements to the dynamic routing protocols
providing source-destination routing information">
<t>As with the destination-only routing, source-destination
routes will typically be disseminated throughout the network
by dynamic routing protocols. It is expected that multiple
dynamic routing protocols will be adapted to the needs of
source-destination routing architecture. Specification of
dynamic routing protocols is outside of scope of this
document. This section lists requirements and considerations
for the dynamic source-destination routing protocols.</t>
<section title="Source information">
<t>Dynamic routing protocols will need to be able to propagate
source range information together with destination prefix
and other accompanying routing information. Source range
information may be propagated with all destination prefixes
or only some of them. Destination prefixes advertised
without associated source range MUST be treated as having
default source range ::/0.</t>
<t>Dynamic routing protocols MUST be able to propagate
multiple routes whose destination prefix is the same but
associated source ranges are different. Such unique pairs of
source and destination MUST be treated as different
source-destination routes.</t>
<t>There is no limitation on how source range information is
propagated and associated with destination
prefixes. Individual protocols may choose to propagate
source range together with a destination prefix in the form
of prefix, in the form of index to list of known source
ranges or in any other form allowing receiver to reconstruct
pair of destination prefix and associated source range.</t>
</section>
<section title="Loop-freeness considerations" anchor="loopfree">
<t>It is expected that some existing dynamic routing protocols
will be enhanced to propagate source-destination routing
information. In this case the protocol may be configured to
operate in a network where some, but not all, routers
support source-destination routing and others are still
using destination-only routing. Even if all routers within a
network are capable of source-destination routing, it is
very likely that on edges of the network they will have to
forward packets to routers doing destination-only
routing.</t>
<t>Since a router implementing source-destination routing can
have additional, more granular routes than one that doesn't
implement it, persistent loops can form between these
systems.</t>
<t>Thus specifications of source-destination routing protocols
(either newly defined protocols or enhancements to already
existing one) MUST take provisions to guarantee loop-free
operations.</t>
<t>There are 3 possible approaches to avoid looping condition:</t>
<t><list style="numbers">
<t>Guarantee that next-hop gateway of a source-destination
route supports source-destination routing, for example
calculate an alternate topology including only routers
that support source-destination routing architecture</t>
<t>If next-hop gateway is not aware of source-destination
routing then a source-destination path can lead to it
only if next-hop router is 'closer' to the destination
in terms of protocol's routing metric; important
particular case of the rule is if destination-only
routing is pointing to the same next-hop gateway</t>
<t>Discard the packet (i.e. treat source-destination route
as unreachable)</t>
</list></t>
<t>In many practical cases routing information on the edges of
source-destination routing domain will be provided by an
operator via configuration. Dynamic routing protocol will
only disseminate this trusted external routing information.
For example, returning to the use case of multihomed Home
network (<xref target="homenet"/>), both routers R1 and R2
will have default static routes pointing to ISPs.</t>
<t>Above considerations require a knowledge of the next-hop
router's capabilities. For routing protocols based on
hop-by-hop flooding (<xref target="RFC2080">RIP</xref>,
<xref target="RFC4271">BGP</xref>), knowing the peer's
capabilities is sufficient. Information about if peer supports
source-destination routing can either be negotiated
explicitly or simply be deduced from the fact that systems
would propagate source-destination routing information only
if they understand it. Protocols building a link-state
database (<xref target="RFC5340">OSPFv3</xref>, <xref
target="RFC5308">IS-IS</xref>) have the additional
opportunity to calculate alternate paths based on knowledge
of the entire domain but cannot assume that routers
understand source-destination routing information only
because they participated in its flooding. Such protocols
MUST explicitly advertise support for the source-destination
routing.</t>
</section>
<section title="Recursive routing">
<t>Dynamic routing protocols may propagate routing information
in a recursive way. Examples of such recursion is forwarding
address in <xref target="RFC5340">OSPFv3</xref>
AS-External-LSAs and NEXT_HOP attribute in <xref
target="RFC4271">BGP</xref> NLRI.</t>
<t>Dynamic routing protocol supporting recursive routes
MUST specify how this recursive routing information is
interpreted in the context of source-destination routing as
part of standardizing source-destination routing extensions
for the protocol. <xref target="recurs"/> lists several
possible strategies protocols can choose from.</t>
</section>
</section>
<section title="Applicability To Specific Situations">
<t>This section discusses how source-destination routing is used
together with some common networking techniques dependent on
routes in the routing table.</t>
<section title="Recursive Route Lookups" anchor="recurs">
<t>Recursive routes provide indirect path information where
instead of supplying outgoing interface and next-hop gateway
directly they specify that next-hop information must be
taken from another route in the same routing table. It is
said that one route 'recurses' via another route which is
'resolving' recursion. Recursive routes may either be
carried by dynamic routing protocols or provided via
configuration as recursive static routes.</t>
<t>Recursive source-destination routes have additional
complication in how source address range should be
considered while finding source-destination route to resolve
recusion.</t>
<t>There are several possible approaches:</t>
<t><list style="numbers">
<t>Ignore source-destination routes, resolve recursion only
via destination-only routes (i.e. routes with source range
::/0)</t>
<t>Require that both the recursive and resolving routes have
the same source range associated with them; this
requirement may be too restrictive to be useful in many
cases</t>
<t>Require that source range associated with recursive route
is a subset of source range associated with route
resolving recursion (i.e. source range of the resolving
route is less specific superset of recursive route's
source range)</t>
<t>Create multiple instances of the route whose nexthop is
being resolved with different source prefixes; this
option is further elaborated in <xref
target="multiroute"/></t>
</list></t>
<t>When recursive routing information is propagated in a
dynamic routing protocol, it is up to the protocol
specification to select and standardize appropriate scheme
of recusrsive resolution.</t>
<t>Recursive resolution of configured static routes is local
to router where recursive static routes were configured,
thus behavior is implementation's choice. Implementations
SHOULD provide option (3) from the above list as their
default method of recursive static route resolution. This is
both to guarantee that destination-only recursive static
routes do not change their behavior when router's software
is upgraded to support source-destination routing and at the
same time make source-destination recursive routes
useful.</t>
<section title="Recursive route expansion" anchor="multiroute">
<t>When doing recursive nexthop resolution, the route that is being
resolved is installed in potentially multiple copies, inheriting all
possible more-specific routes that match the nexthop as
destination. The algorithm to do this is:</t>
<t><list style="numbers">
<t>form the set of attributes for lookup by using the (unresolved,
recursive) nexthop as destination (with full host prefix length,
i.e. /128), copy all other attributes from the original route</t>
<t>find all routes that overlap with this set of attributes
(including both more-specific and less-specific routes)</t>
<t>order the result from most to less specific</t>
<t>for each route, install a route using the original route's
destination and the "logical and" overlap of each extra match
attribute with same attribute from the set. Copy nexthop data
from the route under iteration. Then, reduce the set of extra
attributes by what was covered by the route just installed
("logical AND NOT").</t>
</list></t>
<figure><preamble>Example recursive route resolution</preamble>
<artwork>
route to be resolved:
2001:db8:1234::/48, source 2001:db8:3456::/48,
recursive nexthop via 2001:db8:abcd::1
routes considered for recursive nexthop:
::/0, via fe80::1
2001:db8:abcd::/48, via fe80::2
2001:db8:abcd::/48, source 2001:db8:3456:3::/64, via fe80::3
2001:db8:abcd::1/128, source 2001:db8:3456:4::/64, via fe80::4
recursive resolution result:
2001:db8:1234::/48, source 2001:db8:3456::/48, via fe80::2
2001:db8:1234::/48, source 2001:db8:3456:3::/64, via fe80::3
2001:db8:1234::/48, source 2001:db8:3456:4::/64, via fe80::4
</artwork>
</figure>
</section>
</section>
<section title="Unicast Reverse Path Filtering">
<t>Unicast reverse path filtering MUST use dst-src routes analog to its
usage of destination-only routes. However, the system MAY match
either only incoming source against routes' destinations, or it MAY
match source and destination against routes' destination and
source. It MUST NOT ignore dst-src routes on uRPF checks.</t>
</section>
<section title="Multicast Reverse Path Forwarding">
<t>Multicast Reverse Path Lookups are used to find paths towards the
(known) sender of multicast packets. Since the destination of these
packets is the multicast group, it cannot be matched against the
source part of a dst-src route. Therefore, dst-src routes MUST be
ignored for Multicast RPF lookups.</t>
</section>
</section>
<section title="Interoperability" anchor="interop">
<t>As pointed out in <xref target="loopfree"/> traffic may
permanently loop between routers forwarding packets based only
on their destination IP address and routers using both source
and destination addresses for forwarding decision.</t>
<t>In networks where the same dynamic routing protocol is being
used to propagate routing information between both types of
systems the protocol may address some or all traffic looping
problems. Recommendations to protocol designers are discussed
in <xref target="loopfree"/>.</t>
<t>When routing information is coming from outside of the
routing protocol (for example, being provided by operator in
the form of static routes or network protocols not aware of
source-destination routing paradigm) it may not be possible
for the router to ascertain loop-free properties of such
routing information. In these cases consistent (and loop-free)
packet forwarding is woven into network topology and must be
taken into consideration at design time.</t>
<t>It is possible to design network with mixed deployment of
routers supporting and not supporting source-destination
routing. Thus gradual enablement of source-destination routing
in existing networks is also possible but has to be carefully
planned and evaluated for each network design
individually.</t>
<t>Generally, source-destination routing will not cause traffic
loops when disjoint 'islands' of source-destination routing do
not exchange source-destination routing information. One
particular case of this rule is a network which contains
single contiguous 'island' of routers aware of
source-destination routing. Example SOHO network from <xref
target="homenet"/> which demonstrates this design
approach:</t>
<figure title="Example of multihomed small network with
partial deployment of source-destination
routing">
<artwork align="center">
______ ___ ,,------.
/ \ _( )_ ,' ``.
___ / +----+ _( )_ ,' `.
/ \ / | R1 |---(_ ISP 1 _)---/ \
/ \----/ +----+ (_ _) / \
/ Dst \ / Source- \ (___) ( )
( only )( destination ) ( The Internet )
( routing )( aware ) ___ ( )
\ area / \ routing / _( )_ \ /
\ /----\ area +----+ _( )_ \ /
\___/ \ | R2 |---(_ ISP 2 _)----`. ,'
\ +----+ (_ _) `. ,'
\______/ (___) ``------''
|----------------------------|
SOHO network
</artwork>
</figure>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no requests to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Systems operating under the principles of this document can have
routes that are more specific than the previously most specific, i.e.
host routes. This can be a security concern if an operator was relying
on the impossibility of hijacking such a route.</t>
<!-- from draft-baker-ipv6-dst-src-routing -->
<t>While source/destination routing could be used as part of a security
solution, it is not really intended for the purpose. The approach
limits routing, in the sense that it routes traffic to an appropriate
egress, or gives a way to prevent communication between systems not
included in a source/destination route, and in that sense could be
considered similar to an access list that is managed by and scales with
routing.</t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>If a host's addresses are known, injecting a dst-src route allows
isolation of traffic from that host, which may compromise privacy.
However, this requires access to the routing system. As with similar
problems with the destination only, defending against it is left to
general mechanisms protecting the routing infrastructure.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The base underlying this document was first outlaid by Ole Troan and
Lorenzo Colitti in <xref target="I-D.troan-homenet-sadr"/> for application in the
homenet area.</t>
<t>This document is largely the result of discussions with Fred Baker and
derives from <xref target="I-D.baker-ipv6-isis-dst-src-routing"/>.</t>
</section>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="November 2015 [-01]:"><list>
<t>added section on source-destination routing use cases</t>
<t>added section on alternative lookup algorithm</t>
<t>added section on requirement for dynamic routing
protocols dessiminating source-destination informaton</t>
</list></t>
<t hangText="October 2015 [-00]:">
renamed to draft-ietf-rtgwg-dst-src-routing-00, no content changes
from draft-lamparter-rtgwg-dst-src-routing-01.</t>
<t hangText="April 2015 [-01]:">merged routing-extra-qualifiers
draft, new ordering rationale section</t>
<t hangText="October 2014 [-00]:">Initial Version</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0791"?>
<?rfc include="reference.RFC.2080"?>
<?rfc include="reference.RFC.2827"?>
<?rfc include="reference.RFC.4271"?>
<?rfc include="reference.RFC.5308"?>
<?rfc include="reference.RFC.5340"?>
<?rfc include="reference.I-D.sarikaya-6man-sadr-overview"?>
<?rfc include="reference.I-D.troan-homenet-sadr"?>
<?rfc include="reference.I-D.baker-ipv6-isis-dst-src-routing"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:41:56 |