draft-ietf-rtgwg-dst-src-routing-01.txt   draft-ietf-rtgwg-dst-src-routing-02.txt 
rtgwg D. Lamparter rtgwg D. Lamparter
Internet-Draft NetDEF Internet-Draft NetDEF
Intended status: Standards Track A. Smirnov Intended status: Standards Track A. Smirnov
Expires: September 10, 2016 Cisco Systems, Inc. Expires: November 3, 2016 Cisco Systems, Inc.
March 9, 2016 May 2, 2016
Destination/Source Routing Destination/Source Routing
draft-ietf-rtgwg-dst-src-routing-01 draft-ietf-rtgwg-dst-src-routing-02
Abstract Abstract
This note specifies using packets' source addresses in route lookups This note specifies using packets' source addresses in route lookups
as additional qualifier to be used in route lookup. This applies to as additional qualifier to be used in route lookup. This applies to
IPv6 [RFC2460] in general with specific considerations for routing IPv6 [RFC2460] in general with specific considerations for routing
protocol left for separate documents. protocol left for separate documents.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2016. This Internet-Draft will expire on November 3, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Principle of operation . . . . . . . . . . . . . . . . . . . 3 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Lookup ordering and disambiguation . . . . . . . . . . . 3 2.1. Dual-connected home / SOHO network . . . . . . . . . . . 3
2.2. Ordering Rationale . . . . . . . . . . . . . . . . . . . 3 2.2. Degree of traffic engineering . . . . . . . . . . . . . . 4
3. Applicability To Specific Situations . . . . . . . . . . . . 4 2.3. Distributed filtering based on source address . . . . . . 5
3.1. Recursive Route Lookups . . . . . . . . . . . . . . . . . 4 3. Principle of operation . . . . . . . . . . . . . . . . . . . 5
3.2. Unicast Reverse Path Filtering . . . . . . . . . . . . . 5 3.1. Lookup ordering and disambiguation . . . . . . . . . . . 6
3.3. Multicast Reverse Path Forwarding . . . . . . . . . . . . 5 3.2. Ordering Rationale . . . . . . . . . . . . . . . . . . . 6
4. Interoperability . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Multi-FIB lookup . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements to the dynamic routing protocols providing
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 source-destination routing information . . . . . . . . . . . 8
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 4.1. Source information . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Loop-freeness considerations . . . . . . . . . . . . . . 9
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Recursive routing . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Applicability To Specific Situations . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 5.1. Recursive Route Lookups . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 7 5.1.1. Recursive route expansion . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Unicast Reverse Path Filtering . . . . . . . . . . . . . 12
5.3. Multicast Reverse Path Forwarding . . . . . . . . . . . . 13
6. Interoperability . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Both IPv4 [RFC0791] and IPv6 [RFC2460] 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 Section 2 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.
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.
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.
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
Section 6 for discussion of backwards compatibility). So examples in
this document will be given using IPv6 addresses.
1.1. Requirements Language
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 [RFC2119].
2. Use cases
2.1. Dual-connected home / SOHO network
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.
_____ ,,-------.
_( )_ ,' ``.
___ +----+ _( )_ ,' `.
/ \---| R1 |---(_ ISP 1 _)------/ \
/ \ +----+ (_ _) / \
/ Small \ (_____) ( )
( ) ( The Internet )
( ) _____ ( )
\ net / _( )_ \ /
\ / +----+ _( )_ \ /
\___/---| R2 |---(_ ISP 2 _)-------`. ,'
+----+ (_ _) `. ,'
(_____) ``-------''
Example of multihomed small network
Each ISP will allocate to the network IP address (or small range of
IP addresses) to use as source address for Internet communications.
Since connectivity providers generally secure their ingress along the Since connectivity providers generally secure their ingress along the
lines of BCP 38 [RFC2827], small multihomed networks have a need to lines of BCP 38 [RFC2827], small multihomed networks have a need to
ensure their traffic leaves their network with a correct combination ensure their traffic leaves their network with a correct combination
of source address and exit taken. This applies to networks of a of source address and exit taken. This applies to networks of a
particular pattern where the provider's default (dynamic) address particular pattern where the provider's default (dynamic) address
provisioning methods are used and no fixed IP space is allocated, provisioning methods are used and no fixed IP space is allocated,
e.g. home networks, small business users and mobile ad-hoc setups. e.g. home networks, small business users and mobile ad-hoc setups.
While IPv4 networks would conventionally use NAT or policy routing to While IPv4 networks would conventionally use NAT or policy routing to
produce correct behaviour, this not desirable to carry over to IPv6. produce correct behaviour, this not desirable to carry over to IPv6.
Instead, assigning addresses from multiple prefixes in parallel Instead, assigning addresses from multiple prefixes in parallel
shifts the choice of uplink to the host. However, now for finding shifts the choice of uplink to the host. However, now for finding
the proper exit the source address of packets must be taken into the proper exit the source address of packets must be taken into
account. account.
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.
For a general introduction and aspects of interfacing routers to For a general introduction and aspects of interfacing routers to
hosts, refer to [I-D.sarikaya-6man-sadr-overview]. hosts, refer to [I-D.sarikaya-6man-sadr-overview].
1.1. Requirements Language 2.2. Degree of traffic engineering
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Consider enterprise consisting of a headquarter (HQ) and branch
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this offices. A branch office is connected to the enterprise HQ network
document are to be interpreted as described in [RFC2119]. 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).
2. Principle of operation Source-destination routing provides an easy way to sort traffic going
to the branch based on its source address.
2.3. Distributed filtering based on source address
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.
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.
3. Principle of operation
The mechanism in this document is such that a source prefix is added The mechanism in this document is such that a source prefix is added
to all route entries. This document assumes all entries have a to all route entries. This document assumes all entries have a
source prefix, with ::/0 as default value for entries installed source prefix, with ::/0 as default value for entries installed
without a specified source prefix. This need not be implemented in without a specified source prefix. This need not be implemented in
this particular way, however the system MUST behave exactly as if it this particular way, however the system MUST behave exactly as if it
were. In particular, a difference in behaviour between routes with a were. In particular, a difference in behaviour between routes with a
source prefix of ::/0 and routes without source prefix MUST NOT be source prefix of ::/0 and routes without source prefix MUST NOT be
visible. visible.
For uniqueness considerations, the source prefix factors MUST be For uniqueness considerations, the source prefix factors MUST be
taken into account for comparisons. Two routes with identical taken into account for comparisons. Two routes with identical
information except the source prefix MAY exist and MUST be installed information except the source prefix MAY exist and MUST be installed
and matched. and matched.
2.1. Lookup ordering and disambiguation 3.1. Lookup ordering and disambiguation
Adding further criteria to be looked up when forwarding packets on a When a router is making packet forwarding decision, that is
hop-by-hop basis has the very fundamental requirement that all consulting its routing table in order to determine outgoing interface
routers behave the same way in choosing the most specific route when and next-hop to forward the packet to, it will use information from
there are multiple eligible routes. packet's header to look up best matching route from the routing
table. This section describes lookup into the source-destination
routing table.
For longest-match lookups, the source prefix is matched after the For longest-match lookups, the source prefix is matched after the
destination prefix. This is to say, first the longest matching destination prefix. This is to say, first the longest matching
destination prefix is found, then the table is searched for the route destination prefix is found, then the table is searched for the route
with the longest source prefix match, while only considering routes with the longest source prefix match, while only considering routes
with exactly the destination prefix previously found. If and only if with exactly the destination prefix previously found. If and only if
no such route exists (because none of the source prefixes match), the no such route exists (because none of the source prefixes match), the
lookup moves to the next less specific destination prefix. lookup moves to the next less specific destination prefix.
A router MUST continue to a less specific destination prefix if no A router MUST continue to a less specific destination prefix if no
route matches on the source prefix. It MUST NOT terminate lookup on route matches on the source prefix. It MUST NOT terminate lookup on
such an event. such an event.
Using A < B to mean "A is more specific than B", this is represented Using A < B to mean "A is more specific than B", this is represented
as: as:
A < B := Adst < Bdst A < B := Adst < Bdst
|| (Adst == Bdst && Asrc < Bsrc) || (Adst == Bdst && Asrc < Bsrc)
2.2. Ordering Rationale 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 Section 3.3.
The ordering described by this document (destination before source) 3.2. Ordering Rationale
could as well be reversed, which would lead to semantically different
behavior. 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.
Choosing destination to be evaluated first caters to the assumption Choosing destination to be evaluated first caters to the assumption
that local networks should have full, contiguous connectivity to each that local networks should have full, contiguous connectivity to each
other. This implies that those specific local routes always match other. This implies that those specific local routes always match
first based on destination, and use a zero ("all sources") source first based on destination, and use a zero ("all sources") source
prefix. prefix.
If the source prefix were to be matched first, this would result in a 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 less specific (e.g. default) route with a source prefix to match
before those local routes. In other terms, this would essentially before those local routes. In other terms, this would essentially
divide local connectivity into zones based on source prefix, which is divide local connectivity into zones based on source prefix, which is
not the intention of this document. not the intention of this document.
Hence, this document describes destination-first lookup. Hence, this document describes destination-first match search.
3. Applicability To Specific Situations 3.3. Multi-FIB lookup
3.1. Recursive Route Lookups Routing table lookup algorithm described in Section 3.1 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.
TBD, multiple possible approaches: 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.
variant 1: ignore dst-src routes, only use routes with src ::/0 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.
variant 2: exact-match src prefixes from resolvee to resolvent After source-destination routing information has been collected, one
(will not work for a lot of cases) 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.
variant 3: longer-match src prefixes from resolvee to resolvent In case when multiple routes with the same destination prefix are
(nexthop src may be superset of looked-up route) replicated into the same FIB table only route with the most specific
source address range is installed.
variant 4: create multiple instances of the route whose nexthop is For example, if source-destination routing table contains these
resolved, with different source prefixes routes:
(Variant 4:) Destination prefix Source range Next Hop
------------------- ------------------------ --------
::/0, ::/0, NH1
2001:101:1234::/48, 2001:db8:3456:8000::/56, NH2
2001:101:5678::/48, 2001:db8:3456:8000::/56, NH3
::/0, NH4
2001:101:abcd::/48, 2001:db8:3456::/48, NH5
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.
And content of these FIB tables will be:
FIB 1 (source range ::/0):
Destination prefix Next Hop
------------------- --------
::/0, NH1
2001:101:5678::/48, NH4
FIB 2 (source range 2001:db8:3456::/48):
Destination prefix Next Hop
------------------- --------
::/0, NH1
2001:101:5678::/48, NH4
2001:101:abcd::/48, NH5
FIB 3 (source range 2001:db8:3456:8000::/56):
Destination prefix Next Hop
------------------- --------
::/0, NH1
2001:101:1234::/48, NH2
2001:101:5678::/48, NH3
2001:101:abcd::/48, NH5
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.
4. Requirements to the dynamic routing protocols providing source-
destination routing information
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.
4.1. Source information
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.
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.
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.
4.2. Loop-freeness considerations
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.
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.
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.
There are 3 possible approaches to avoid looping condition:
1. 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
2. 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
3. Discard the packet (i.e. treat source-destination route as
unreachable)
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 (Section 2.1), both routers R1
and R2 will have default static routes pointing to ISPs.
Above considerations require a knowledge of the next-hop router's
capabilities. For routing protocols based on hop-by-hop flooding
(RIP [RFC2080], BGP [RFC4271]), 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 (OSPFv3 [RFC5340], IS-IS [RFC5308]) 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.
4.3. Recursive routing
Dynamic routing protocols may propagate routing information in a
recursive way. Examples of such recursion is forwarding address in
OSPFv3 [RFC5340] AS-External-LSAs and NEXT_HOP attribute in BGP
[RFC4271] NLRI.
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. Section 5.1 lists
several possible strategies protocols can choose from.
5. Applicability To Specific Situations
This section discusses how source-destination routing is used
together with some common networking techniques dependent on routes
in the routing table.
5.1. Recursive Route Lookups
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.
Recursive source-destination routes have additional complication in
how source address range should be considered while finding source-
destination route to resolve recusion.
There are several possible approaches:
1. Ignore source-destination routes, resolve recursion only via
destination-only routes (i.e. routes with source range ::/0)
2. 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
3. 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)
4. Create multiple instances of the route whose nexthop is being
resolved with different source prefixes; this option is further
elaborated in Section 5.1.1
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.
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.
5.1.1. Recursive route expansion
When doing recursive nexthop resolution, the route that is being When doing recursive nexthop resolution, the route that is being
resolved is installed in potentially multiple copies, inheriting all resolved is installed in potentially multiple copies, inheriting all
possible more-specific routes that match the nexthop as destination. possible more-specific routes that match the nexthop as destination.
The algorithm to do this is: The algorithm to do this is:
1. form the set of attributes for lookup by using the (unresolved, 1. form the set of attributes for lookup by using the (unresolved,
recursive) nexthop as destination (with full host prefix length, recursive) nexthop as destination (with full host prefix length,
i.e. /128), copy all other attributes from the original route i.e. /128), copy all other attributes from the original route
skipping to change at page 5, line 28 skipping to change at page 12, line 45
::/0, via fe80::1 ::/0, via fe80::1
2001:db8:abcd::/48, via fe80::2 2001:db8:abcd::/48, via fe80::2
2001:db8:abcd::/48, source 2001:db8:3456:3::/64, via fe80::3 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 2001:db8:abcd::1/128, source 2001:db8:3456:4::/64, via fe80::4
recursive resolution result: recursive resolution result:
2001:db8:1234::/48, source 2001:db8:3456::/48, via fe80::2 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:3::/64, via fe80::3
2001:db8:1234::/48, source 2001:db8:3456:4::/64, via fe80::4 2001:db8:1234::/48, source 2001:db8:3456:4::/64, via fe80::4
3.2. Unicast Reverse Path Filtering 5.2. Unicast Reverse Path Filtering
Unicast reverse path filtering MUST use dst-src routes analog to its Unicast reverse path filtering MUST use dst-src routes analog to its
usage of destination-only routes. However, the system MAY match usage of destination-only routes. However, the system MAY match
either only incoming source against routes' destinations, or it MAY either only incoming source against routes' destinations, or it MAY
match source and destination against routes' destination and source. match source and destination against routes' destination and source.
It MUST NOT ignore dst-src routes on uRPF checks. It MUST NOT ignore dst-src routes on uRPF checks.
3.3. Multicast Reverse Path Forwarding 5.3. Multicast Reverse Path Forwarding
Multicast Reverse Path Lookups are used to find paths towards the Multicast Reverse Path Lookups are used to find paths towards the
(known) sender of multicast packets. Since the destination of these (known) sender of multicast packets. Since the destination of these
packets is the multicast group, it cannot be matched against the packets is the multicast group, it cannot be matched against the
source part of a dst-src route. Therefore, dst-src routes MUST be source part of a dst-src route. Therefore, dst-src routes MUST be
ignored for Multicast RPF lookups. ignored for Multicast RPF lookups.
4. Interoperability 6. Interoperability
Since a router implementing source/destination routing can have As pointed out in Section 4.2 traffic may permanently loop between
additional, more specific routes than one that doesn't implement routers forwarding packets based only on their destination IP address
source/destination routing, persistent loops can form between these and routers using both source and destination addresses for
systems. To prevent this from happening, a simple rule must be forwarding decision.
followed:
The set of qualifiers used to route a particular packet MUST be a In networks where the same dynamic routing protocol is being used to
subset of the qualifiers supported by the next hop. 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 Section 4.2.
This means in particular that a router using the source address as When routing information is coming from outside of the routing
extra qualifier MUST NOT route packets based on a source/destination protocol (for example, being provided by operator in the form of
route to a system that doesn't support source/destination routes (and static routes or network protocols not aware of source-destination
hence doesn't understand the route). 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.
There are 3 possible approaches to avoid such a condition: 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.
1. discard the packet (treat as destination unreachable) 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 Section 2.1 which demonstrates this design approach:
2. calculate an alternate topology including only routers that ______ ___ ,,------.
support qualifier A / \ _( )_ ,' ``.
___ / +----+ _( )_ ,' `.
/ \ / | R1 |---(_ ISP 1 _)---/ \
/ \----/ +----+ (_ _) / \
/ Dst \ / Source- \ (___) ( )
( only )( destination ) ( The Internet )
( routing )( aware ) ___ ( )
\ area / \ routing / _( )_ \ /
\ /----\ area +----+ _( )_ \ /
\___/ \ | R2 |---(_ ISP 2 _)----`. ,'
\ +----+ (_ _) `. ,'
\______/ (___) ``------''
3. if the lookup returns the same nexthop without using qualifier A, |----------------------------|
use that result (i.e., the nexthop is known to correctly route SOHO network
the packet)
Above considerations require under all circumstances a knowledge of Example of multihomed small network with partial deployment of
the next router's capabilities. For routing protocols based on hop- source-destination routing
by-hop flooding (RIP [RFC2080], BGP [RFC4271]), knowing the peer's
capabilities - or simply relying on systems to only flood what they
understand - is sufficient. Protocols building a link-state database
(OSPF [RFC5340], IS-IS [RFC5308]) have the additional opportunity to
calculate alternate paths based on knowledge of the entire domain,
but cannot rely on routers flooding only link state they support
themselves.
5. IANA Considerations 7. IANA Considerations
This document makes no requests to IANA. This document makes no requests to IANA.
6. Security Considerations 8. Security Considerations
Systems operating under the principles of this document can have Systems operating under the principles of this document can have
routes that are more specific than the previously most specific, i.e. routes that are more specific than the previously most specific, i.e.
host routes. This can be a security concern if an operator was host routes. This can be a security concern if an operator was
relying on the impossibility of hijacking such a route. relying on the impossibility of hijacking such a route.
While source/destination routing could be used as part of a security While source/destination routing could be used as part of a security
solution, it is not really intended for the purpose. The approach solution, it is not really intended for the purpose. The approach
limits routing, in the sense that it routes traffic to an appropriate limits routing, in the sense that it routes traffic to an appropriate
egress, or gives a way to prevent communication between systems not egress, or gives a way to prevent communication between systems not
included in a source/destination route, and in that sense could be included in a source/destination route, and in that sense could be
considered similar to an access list that is managed by and scales considered similar to an access list that is managed by and scales
with routing. with routing.
7. Privacy Considerations 9. Privacy Considerations
If a host's addresses are known, injecting a dst-src route allows If a host's addresses are known, injecting a dst-src route allows
isolation of traffic from that host, which may compromise privacy. isolation of traffic from that host, which may compromise privacy.
However, this requires access to the routing system. As with similar However, this requires access to the routing system. As with similar
problems with the destination only, defending against it is left to problems with the destination only, defending against it is left to
general mechanisms protecting the routing infrastructure. general mechanisms protecting the routing infrastructure.
8. Acknowledgements 10. Acknowledgements
The base underlying this document was first outlaid by Ole Troan and The base underlying this document was first outlaid by Ole Troan and
Lorenzo Colitti in [I-D.troan-homenet-sadr] for application in the Lorenzo Colitti in [I-D.troan-homenet-sadr] for application in the
homenet area. homenet area.
This document is largely the result of discussions with Fred Baker This document is largely the result of discussions with Fred Baker
and derives from [I-D.baker-ipv6-isis-dst-src-routing]. and derives from [I-D.baker-ipv6-isis-dst-src-routing].
9. Change Log 11. Change Log
November 2015 [-01]:
added section on source-destination routing use cases
added section on alternative lookup algorithm
added section on requirement for dynamic routing protocols
dessiminating source-destination informaton
October 2015 [-00]: renamed to draft-ietf-rtgwg-dst-src-routing-00, October 2015 [-00]: renamed to draft-ietf-rtgwg-dst-src-routing-00,
no content changes from draft-lamparter-rtgwg-dst-src-routing-01. no content changes from draft-lamparter-rtgwg-dst-src-routing-01.
April 2015 [-01]: merged routing-extra-qualifiers draft, new April 2015 [-01]: merged routing-extra-qualifiers draft, new
ordering rationale section ordering rationale section
October 2014 [-00]: Initial Version October 2014 [-00]: Initial Version
10. References 12. References
10.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
10.2. Informative References 12.2. Informative References
[I-D.baker-ipv6-isis-dst-src-routing] [I-D.baker-ipv6-isis-dst-src-routing]
Baker, F. and D. Lamparter, "IPv6 Source/Destination Baker, F. and D. Lamparter, "IPv6 Source/Destination
Routing using IS-IS", draft-baker-ipv6-isis-dst-src- Routing using IS-IS", draft-baker-ipv6-isis-dst-src-
routing-04 (work in progress), October 2015. routing-05 (work in progress), April 2016.
[I-D.sarikaya-6man-sadr-overview] [I-D.sarikaya-6man-sadr-overview]
Sarikaya, B. and M. Boucadair, "Source Address Dependent Sarikaya, B. and M. Boucadair, "Source Address Dependent
Routing and Source Address Selection for IPv6 Hosts: Routing and Source Address Selection for IPv6 Hosts:
Problem Space Overview", draft-sarikaya-6man-sadr- Problem Space Overview", draft-sarikaya-6man-sadr-
overview-09 (work in progress), January 2016. overview-09 (work in progress), January 2016.
[I-D.troan-homenet-sadr] [I-D.troan-homenet-sadr]
Troan, O. and L. Colitti, "IPv6 Multihoming with Source Troan, O. and L. Colitti, "IPv6 Multihoming with Source
Address Dependent Routing (SADR)", draft-troan-homenet- Address Dependent Routing (SADR)", draft-troan-homenet-
sadr-01 (work in progress), September 2013. sadr-01 (work in progress), September 2013.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
DOI 10.17487/RFC2080, January 1997, DOI 10.17487/RFC2080, January 1997,
<http://www.rfc-editor.org/info/rfc2080>. <http://www.rfc-editor.org/info/rfc2080>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>. May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
 End of changes. 43 change blocks. 
87 lines changed or deleted 455 lines changed or added

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