draft-ietf-rtgwg-dst-src-routing-05.txt   draft-ietf-rtgwg-dst-src-routing-06.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: January 20, 2018 Cisco Systems, Inc. Expires: May 3, 2018 Cisco Systems, Inc.
July 19, 2017 October 30, 2017
Destination/Source Routing Destination/Source Routing
draft-ietf-rtgwg-dst-src-routing-05 draft-ietf-rtgwg-dst-src-routing-06
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 hop-by-hop routing decisions.
IPv6 [RFC2460] in general with specific considerations for routing This applies to IPv6 [RFC2460] in general with specific
protocol left for separate documents. considerations for routing protocol left for separate documents.
There is nothing precluding similar operation in IPv4, but this is
not in scope of this document.
Note that destination/source routing, source/destination routing,
SADR, source-specific routing, source-sensitive routing, S/D routing
and D/S routing are all used synonymously.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 20, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Dual-connected home / SOHO network . . . . . . . . . . . 3 2.1. Multihomed networks with provider assigned prefixes . . . 4
2.2. Degree of traffic engineering . . . . . . . . . . . . . . 4 2.2. Degree of traffic engineering . . . . . . . . . . . . . . 5
2.3. Distributed filtering based on source address . . . . . . 5 2.3. Distributed filtering based on source address . . . . . . 5
2.4. Walled-garden Enterprise services . . . . . . . . . . . . 5 2.4. Walled-garden Enterprise services . . . . . . . . . . . . 5
2.5. Information Source for Neighbor Management . . . . . . . 6 2.5. Information Source for Neighbor Management . . . . . . . 6
3. Principle of operation . . . . . . . . . . . . . . . . . . . 6 3. Principle of operation . . . . . . . . . . . . . . . . . . . 6
3.1. Lookup ordering and disambiguation . . . . . . . . . . . 6 3.1. Frame of reference . . . . . . . . . . . . . . . . . . . 6
3.2. Ordering Rationale . . . . . . . . . . . . . . . . . . . 7 3.2. Route information and equality . . . . . . . . . . . . . 6
4. Routing protocol considerations . . . . . . . . . . . . . . . 7 3.3. Lookup ordering and disambiguation . . . . . . . . . . . 7
3.4. Ordering Rationale . . . . . . . . . . . . . . . . . . . 7
4. Routing protocol considerations . . . . . . . . . . . . . . . 8
4.1. Source information . . . . . . . . . . . . . . . . . . . 8 4.1. Source information . . . . . . . . . . . . . . . . . . . 8
4.2. Loop-freeness considerations . . . . . . . . . . . . . . 8 4.2. Loop-freeness considerations . . . . . . . . . . . . . . 8
4.3. Recursive routing . . . . . . . . . . . . . . . . . . . . 9 4.3. Recursive routing . . . . . . . . . . . . . . . . . . . . 10
5. Applicability To Specific Situations . . . . . . . . . . . . 9 5. Applicability To Specific Situations . . . . . . . . . . . . 10
5.1. Recursive Route Lookups . . . . . . . . . . . . . . . . . 10 5.1. Recursive Route Lookups . . . . . . . . . . . . . . . . . 10
5.1.1. Recursive route expansion . . . . . . . . . . . . . . 11 5.1.1. Recursive route expansion . . . . . . . . . . . . . . 11
5.2. Unicast Reverse Path Filtering . . . . . . . . . . . . . 11 5.2. Unicast Reverse Path Filtering . . . . . . . . . . . . . 12
5.3. Multicast Reverse Path Forwarding . . . . . . . . . . . . 12 5.3. Multicast Reverse Path Forwarding . . . . . . . . . . . . 12
5.4. Testing for Connectivity Availability . . . . . . . . . . 12 5.4. Testing for Connectivity Availability . . . . . . . . . . 12
6. Interoperability . . . . . . . . . . . . . . . . . . . . . . 12 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Interoperability in Distance-Vector Protocols . . . . . . 13 6.1. Interoperability in Distance-Vector Protocols . . . . . . 14
6.2. Interoperability in Link-State Protocols . . . . . . . . 14 6.2. Interoperability in Link-State Protocols . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Implementation Options . . . . . . . . . . . . . . . 17 Appendix A. Implementation Options . . . . . . . . . . . . . . . 19
A.1. Pre-expanded 2-step lookup without backtracking . . . . . 18 A.1. Pre-expanded 2-step lookup without backtracking . . . . . 19
A.2. Translation to Multi-FIB (Policy Routing) perspective . . 18 A.2. Translation to Multi-FIB (Policy Routing) perspective . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Both IPv4 [RFC0791] and IPv6 [RFC2460] architectures specify that Both IPv4 [RFC0791] and IPv6 [RFC2460] architectures specify that
determination of the outgoing interface and next-hop gateway for determination of the outgoing next-hop for packet forwarding is based
packet forwarding is based solely on the destination address solely on the destination address contained in the packet header.
contained in the packet header. There exists class of network design There exists class of network design problems which require packet
problems which require packet forwarding to consider more than just forwarding to consider more than just the destination IP address (see
the destination IP address (see Section 2 for examples). At present Section 2 for examples).
these problems are routinely resolved by configuring on routers
special forwarding based on a local policy. The policy enforces At present these problems are routinely resolved by configuring
packet forwarding decision outcome based not only on the destination special forwarding based on a local policy on routers. The policy
address but also on other fields in the packet's IP header, most enforces packet forwarding decision outcome based not only on the
notably the source address. Such policy-based routing is destination address but also on other fields in the packet's IP
conceptually similar to static routes in that it is highly static in header, most notably the source address. Such policy-based routing
nature and must be closely governed via the management plane (most 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 frequently - via managing configuration by an operator). Thus
policy-based routing configuration and maintenance is costly and policy-based routing configuration and maintenance is costly and
error-prone. error-prone.
Rapid expansion of IPv6 to networks were static configuration is not Rapid expansion of IPv6 to networks were static configuration is not
acceptable due to both its static nature and necessity of frequent acceptable due to both its static nature and necessity of frequent
intervention by a skilled operator requires change in the paradigm of intervention by a skilled operator requires change in the paradigm of
forwarding IP packets based only on their destination address. forwarding IP packets based only on their destination address.
This document describes architecture of source-destination routing. This document describes architecture of destination-source routing.
This includes description of making a packet forwarding decision and It includes both forwarding plane and control plane considerations
requirements to dynamic routing protocols which will disseminate and requirements. Specific considerations for particular dynamic
source-destination routing information. Specific considerations for routing protocols are outside of the scope of this note and will be
particular dynamic routing protocols are outside of the scope of this covered in separate documents, for example handling of a
note and will be covered in separate documents. noncontiguous sub-topology in a link-state protocol.
General concepts covered by this document are equally applicable to General concepts covered by this document are equally applicable to
both IPv4 and IPv6. Considering limited backward compatibility of both IPv4 and IPv6. Considering the implementation complexity of
the source-destination routing with the traditional destination-only backward compatibility of destination-source routing with traditional
routing, it appears likely that at this stage of IPv4 deployment destination-only routing, IPv4 is left outside the scope of this
change of routing paradigm in existing networks is not feasible (see document.
Section 6 for discussion of backwards compatibility). So examples in
this document will be given using IPv6 addresses.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Use cases 2. Use cases
2.1. Dual-connected home / SOHO network 2.1. Multihomed networks with provider assigned prefixes
Small networks - such as SOHO or the home networks (homenet) - may be There are good reasons for networks to be multihomed - benefits of
multihomed (i.e. dual-connected) to two different Internet Service doing this may include redundandy, better performance or faster
Providers (ISPs). Benefits of doing this may include resiliency or access to important resources (for example, video or cloud services)
faster access to important resources (for example, video or cloud local to ISPs.
services) local to ISPs.
However, in a range from smaller home networks to even larger
enterprises, it is likely that each service provider will assign some
address space (from their PA allocation) to the network.
_____ ,,-------. _____ ,,-------.
_( )_ ,' ``. _( )_ ,' ``.
___ +----+ _( )_ ,' `. ___ +----+ _( )_ ,' `.
/ \---| R1 |---(_ ISP 1 _)------/ \ / \---| R1 |---(_ ISP 1 _)------/ \
/ \ +----+ (_ _) / \ / \ +----+ (_ _) / \
/ Small \ (_____) ( ) / Small \ (_____) ( )
( ) ( The Internet ) ( ) ( The Internet )
( ) _____ ( ) ( ) _____ ( )
\ net / _( )_ \ / \ net / _( )_ \ /
\ / +----+ _( )_ \ / \ / +----+ _( )_ \ /
\___/---| R2 |---(_ ISP 2 _)-------`. ,' \___/---| R2 |---(_ ISP 2 _)-------`. ,'
+----+ (_ _) `. ,' +----+ (_ _) `. ,'
(_____) ``-------'' (_____) ``-------''
Example of multihomed small network Example of multihomed small network
Each ISP will allocate to the network IP address (or small range of In this situation, providers are expected to perform ingress
IP addresses) to use as source address for Internet communications. filtering according to BCP 38 [RFC2827]. Ths means only packets with
a source address from the prefix that the provider assigned will be
Since connectivity providers generally secure their ingress along the accepted. In addition, the assigned prefix can usually not be
lines of BCP 38 [RFC2827], small multihomed networks have a need to expected to remain the same.
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.
While IPv4 networks would conventionally use NAT or policy routing to Conventionally, NAT or policy routing would be used to produce
produce correct behaviour, this not desirable to carry over to IPv6. correct behaviour. These are not desirable solutions: NAT66 breaks
Instead, assigning addresses from multiple prefixes in parallel end-to-end connectivity (and may restrict concurrent use of parallel
shifts the choice of uplink to the host. However, now for finding paths.) Policy routing requires a sufficiently skilled operator to
the proper exit the source address of packets must be taken into manually manage these policies.
account.
Source-destination routing, when enabled on routers in the multihomed By assigning addresses from multiple prefixes each to end host (as a
small network (including routers R1 and R2), solves the problem by policy routing solution could do), the choice of uplink is left to
driving packets originated by internal hosts to the correct Internet host, including the option to choose multiple at once. Destination-
exit point considering IP source address assigned to the packet by source routing provides the neccessary behaviour for routers (e.g.
originating host. R1 and R2 in above example) to forward packets to the appropriate
exit. It does so without requiring the manual configuration
maintenance that policy routing would entail.
For a general introduction and aspects of interfacing routers to For a general introduction and aspects of interfacing routers to
hosts, refer to [RFC8043]. hosts, refer to [RFC8043].
2.2. Degree of traffic engineering 2.2. Degree of traffic engineering
Consider enterprise consisting of a headquarter (HQ) and branch Consider enterprise consisting of a headquarter (HQ) and branch
offices. A branch office is connected to the enterprise HQ network offices. A branch office is connected to the enterprise HQ network
via 2 links. For performance or security reasons it is desired to via 2 links. For performance or security reasons it is desired to
route corporate traffic via one link and Internet traffic via another route corporate traffic via one link and Internet traffic via another
skipping to change at page 5, line 25 skipping to change at page 5, line 34
A network has untrusted zone and secure one (and both zones comprise A network has untrusted zone and secure one (and both zones comprise
many links and routers). Computers from the secure zone need to be many links and routers). Computers from the secure zone need to be
able to communicate with some selected hosts in the untrusted zone. able to communicate with some selected hosts in the untrusted zone.
The secure zone is protected by a firewall. The firewall is The secure zone is protected by a firewall. The firewall is
configured to check that packets arriving from the untrusted zone configured to check that packets arriving from the untrusted zone
have destination address in the range of secure zone and source have destination address in the range of secure zone and source
address of trusted hosts in the untrusted zone. This works but address of trusted hosts in the untrusted zone. This works but
leaves the firewall open to DDOS attack from outside. leaves the firewall open to DDOS attack from outside.
If routers in the untrusted zone are configured with source- If routers in the untrusted zone are configured with destination-
destination routing (and, possibly, unicast RPF check) and receive source routing (and, possibly, unicast RPF check) and receive via
via dynamic routing protocol routes <destination: secure zone; dynamic routing protocol routes <destination: secure zone; source:
source: trusted host in the untrusted zone> then DDOS attack is trusted host in the untrusted zone> then DDOS attack is dropped by
dropped by routers on the edge of source-destination routing area. routers on the edge of destination-source routing area. DDOS attack
DDOS attack does not even reach the firewall whose resources are does not even reach the firewall whose resources are freed to deal
freed to deal with Deep Packet Inspection. On the other hand, with Deep Packet Inspection. On the other hand, security policy is
security policy is managed in a single point - on a router injecting managed in a single point - on a router injecting relevant
relevant source-destination routes into the dynamic routing protocol. destination-source routes into the dynamic routing protocol.
2.4. Walled-garden Enterprise services 2.4. Walled-garden Enterprise services
Apart from transfering from multihomed personal networks to Apart from transfering from multihomed personal networks to
multihomed PA enterprise setups without any changes, source- multihomed PA enterprise setups without any changes, destination-
destination routing can also be used to correctly route services that source routing can also be used to correctly route services that
assign their own prefixes to customers using the particular service. assign their own prefixes to customers using the particular service.
This is distinct from internet connectivity only in that it does not This is distinct from internet connectivity only in that it does not
provide a default route. Applying source-destination routing, the provide a default route. Applying destination-source routing, the
entire routing domain is aware of the specific constraints of the entire routing domain is aware of the specific constraints of the
routes involved. routes involved.
Additionally, if the walled-garden's destination prefix is advertised Additionally, if the walled-garden's destination prefix is advertised
as blackhole route, this ensures that communication with the service as blackhole route, this ensures that communication with the service
will only be routed using the specific D/S route, never leaking onto will only be routed using the specific D/S route, never leaking onto
unintended paths like a default route. unintended paths like a default route.
This is very similar to firewall/filtering functionality, except the This is very similar to firewall/filtering functionality, except the
feature is distributed onto routers. feature is distributed onto routers.
2.5. Information Source for Neighbor Management 2.5. Information Source for Neighbor Management
Having information on source address restrictions for routes Having information on source address restrictions for routes
distributed, routers can rely on this additional information to distributed, routers can rely on this additional information to
improve their behaviour towards hosts connected to them. This improve their behaviour towards hosts connected to them. This
specifically includes IPv6 Router Advertisements, which is described specifically includes IPv6 Router Advertisements, which is described
in [I-D.linkova-v6ops-conditional-ras]. in [RFC8028] and [I-D.linkova-v6ops-conditional-ras].
3. Principle of operation 3. Principle of operation
3.1. Frame of reference
The principles described here are define on a functional level what
the semantics of routing information exchanged between systems is.
It is neither a prescription in how to efficiently implement these
semantics, nor does it preclude an implementation from providing
other administrator-friendly views of the same routing information.
More specifically, forwarding plane implementations are expected to
internally diverge from the lookup algorithm described below. The
router as a whole MUST ultimately behave as if the steps below were
followed. An internal variation providing improved performance, as
well as a variation matching existing implementations with reversed
order are described in Appendix A.1 and Appendix A.2, respectively.
3.2. Route information and equality
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.
3.1. Lookup ordering and disambiguation 3.3. Lookup ordering and disambiguation
When a router is making packet forwarding decision, that is When a router is making packet forwarding decision, that is
consulting its routing table in order to determine outgoing interface consulting its routing table in order to determine next-hop to
and next-hop to forward the packet to, it will use information from forward the packet to, it will use information from packet's header
packet's header to look up best matching route from the routing to look up best matching route from the routing table. This section
table. This section describes lookup into the source-destination describes lookup into the destination-source routing table.
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)
Implementations MAY implement lookup algorithm differently from step- 3.4. Ordering Rationale
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. A
variation providing improved performance, as well as a variation
matching existing implementations with reversed order are described
in Appendix A.1 and Appendix A.2, respectively.
3.2. Ordering Rationale
Ordering of searching for address match is important and reversing it Ordering of searching for address match is important and reversing it
would lead to semantically different behavior. This standard would lead to semantically different behavior. This standard
requires most specific match on destination address to be found requires most specific match on destination address to be found
before looking for match on source address. 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
skipping to change at page 7, line 41 skipping to change at page 8, line 11
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 match search. Hence, this document describes destination-first match search.
4. Routing protocol considerations 4. Routing protocol considerations
As with the destination-only routing, source-destination routes will As with the destination-only routing, destination-source routes will
typically be disseminated throughout the network by dynamic routing typically be disseminated throughout the network by dynamic routing
protocols. It is expected that multiple dynamic routing protocols protocols. It is expected that multiple dynamic routing protocols
will be adapted to the needs of source-destination routing will be adapted to the needs of destination-source routing
architecture. Specification of dynamic routing protocols is outside architecture. Specification of dynamic routing protocols is outside
of scope of this document. This section lists requirements and of scope of this document. This section lists requirements and
considerations for the dynamic source-destination routing protocols. considerations for the dynamic destination-source routing protocols.
4.1. Source information 4.1. Source information
Dynamic routing protocols will need to be able to propagate source Dynamic routing protocols will need to be able to propagate source
range information together with destination prefix and other range information together with destination prefix and other
accompanying routing information. Source range information may be accompanying routing information. Source range information may be
propagated with all destination prefixes or only some of them. propagated with all destination prefixes or only some of them.
Destination prefixes advertised without associated source range MUST Destination prefixes advertised without associated source range MUST
be treated as having default source range ::/0. be treated as having default source range ::/0.
Dynamic routing protocols MUST be able to propagate multiple routes Dynamic routing protocols MUST be able to propagate multiple routes
whose destination prefix is the same but associated source ranges are whose destination prefix is the same but associated source ranges are
different. Such unique pairs of source and destination MUST be different. Such unique pairs of destination and source MUST be
treated as different source-destination routes. treated as different destination-source routes.
There is no limitation on how source range information is propagated There is no limitation on how source range information is propagated
and associated with destination prefixes. Individual protocols may and associated with destination prefixes. Individual protocols may
choose to propagate source range together with a destination prefix 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 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 ranges or in any other form allowing receiver to reconstruct pair of
destination prefix and associated source range. destination prefix and associated source range.
4.2. Loop-freeness considerations 4.2. Loop-freeness considerations
It is expected that some existing dynamic routing protocols will be It is expected that some existing dynamic routing protocols will be
enhanced to propagate source-destination routing information. In enhanced to propagate destination-source routing information. In
this case the protocol may be configured to operate in a network this case the protocol may be configured to operate in a network
where some, but not all, routers support source-destination routing where some, but not all, routers support destination-source routing
and others are still using destination-only routing. Even if all and others are still using destination-only routing. Even if all
routers within a network are capable of source-destination routing, routers within a network are capable of destination-source routing,
it is very likely that on edges of the network they will have to it is very likely that on edges of the network they will have to
forward packets to routers doing destination-only routing. forward packets to routers doing destination-only routing.
Since a router implementing source-destination routing can have Since a router implementing destination-source routing can have
additional, more granular routes than one that doesn't implement it, additional, more granular routes than one that doesn't implement it,
persistent loops can form between these systems. persistent loops can form between these systems.
Thus specifications of source-destination routing protocols (either Thus specifications of destination-source routing protocols (either
newly defined protocols or enhancements to already existing one) MUST newly defined protocols or enhancements to already existing one) MUST
take provisions to guarantee loop-free operations. take provisions to guarantee loop-free operations.
There are 3 possible approaches to avoid looping condition: There are 3 possible approaches to avoid looping condition:
1. Guarantee that next-hop gateway of a source-destination route 1. Guarantee that next-hop gateway of a destination-source route
supports source-destination routing, for example calculate an supports destination-source routing, for example calculate an
alternate topology including only routers that support source- alternate topology including only routers that support
destination routing architecture destination-source routing architecture
2. If next-hop gateway is not aware of source-destination routing 2. If next-hop gateway is not aware of destination-source routing
then a source-destination path can lead to it only if next-hop then a destination-source path can lead to it only if next-hop
router is 'closer' to the destination in terms of protocol's router is 'closer' to the destination in terms of protocol's
routing metric; important particular case of the rule is if routing metric; important particular case of the rule is if
destination-only routing is pointing to the same next-hop gateway destination-only routing is pointing to the same next-hop gateway
3. Discard the packet (i.e. treat source-destination route as 3. Discard the packet (i.e. treat destination-source route as
unreachable) unreachable)
In many practical cases routing information on the edges of source- In many practical cases routing information on the edges of
destination routing domain will be provided by an operator via destination-source routing domain will be provided by an operator via
configuration. Dynamic routing protocol will only disseminate this configuration. Dynamic routing protocol will only disseminate this
trusted external routing information. For example, returning to the trusted external routing information. For example, returning to the
use case of multihomed Home network (Section 2.1), both routers R1 use case of multihomed Home network (Section 2.1), both routers R1
and R2 will have default static routes pointing to ISPs. and R2 will have default static routes pointing to ISPs.
Above considerations require a knowledge of the next-hop router's Above considerations require a knowledge of the next-hop router's
capabilities. For routing protocols based on hop-by-hop flooding capabilities. For routing protocols based on hop-by-hop flooding
(RIP [RFC2080], BGP [RFC4271]), knowing the peer's capabilities is (RIP [RFC2080], BGP [RFC4271]), knowing the peer's capabilities is
sufficient. Information about if peer supports source-destination sufficient. Information about if peer supports destination-source
routing can either be negotiated explicitly or simply be deduced from routing can either be negotiated explicitly or simply be deduced from
the fact that systems would propagate source-destination routing the fact that systems would propagate destination-source routing
information only if they understand it. Protocols building a link- information only if they understand it. Protocols building a link-
state database (OSPFv3 [RFC5340], IS-IS [RFC5308]) have the state database (OSPFv3 [RFC5340], IS-IS [RFC5308]) have the
additional opportunity to calculate alternate paths based on additional opportunity to calculate alternate paths based on
knowledge of the entire domain but cannot assume that routers knowledge of the entire domain but cannot assume that routers
understand source-destination routing information only because they understand destination-source routing information only because they
participated in its flooding. Such protocols MUST explicitly participated in its flooding. Such protocols MUST explicitly
advertise support for the source-destination routing. advertise support for the destination-source routing.
4.3. Recursive routing 4.3. Recursive routing
Dynamic routing protocols may propagate routing information in a Dynamic routing protocols may propagate routing information in a
recursive way. Examples of such recursion is forwarding address in recursive way. Examples of such recursion is forwarding address in
OSPFv3 [RFC5340] AS-External-LSAs and NEXT_HOP attribute in BGP OSPFv3 [RFC5340] AS-External-LSAs and NEXT_HOP attribute in BGP
[RFC4271] NLRI. [RFC4271] NLRI.
Dynamic routing protocol supporting recursive routes MUST specify how Dynamic routing protocol supporting recursive routes MUST specify how
this recursive routing information is interpreted in the context of this recursive routing information is interpreted in the context of
source-destination routing as part of standardizing source- destination-source routing as part of standardizing destination-
destination routing extensions for the protocol. Section 5.1 lists source routing extensions for the protocol. Section 5.1 lists
several possible strategies protocols can choose from. several possible strategies protocols can choose from.
5. Applicability To Specific Situations 5. Applicability To Specific Situations
This section discusses how source-destination routing is used This section discusses how destination-source routing is used
together with some common networking techniques dependent on routes together with some common networking techniques dependent on routes
in the routing table. in the routing table.
5.1. Recursive Route Lookups 5.1. Recursive Route Lookups
Recursive routes provide indirect path information where instead of Recursive routes provide indirect path information where instead of
supplying outgoing interface and next-hop gateway directly they supplying the next-hop directly they specify that next-hop
specify that next-hop information must be taken from another route in information must be taken from another route in the same routing
the same routing table. It is said that one route 'recurses' via table. It is said that one route 'recurses' via another route which
another route which is 'resolving' recursion. Recursive routes may is 'resolving' recursion. Recursive routes may either be carried by
either be carried by dynamic routing protocols or provided via dynamic routing protocols or provided via configuration as recursive
configuration as recursive static routes. static routes.
Recursive source-destination routes have additional complication in Recursive destination-source routes have additional complication in
how source address range should be considered while finding source- how source address range should be considered while finding
destination route to resolve recusion. destination-source route to resolve recusion.
There are several possible approaches: There are several possible approaches:
1. Ignore source-destination routes, resolve recursion only via 1. Ignore destination-source routes, resolve recursion only via
destination-only routes (i.e. routes with source range ::/0) destination-only routes (i.e. routes with source range ::/0)
2. Require that both the recursive and resolving routes have the 2. Require that both the recursive and resolving routes have the
same source range associated with them; this requirement may be same source range associated with them; this requirement may be
too restrictive to be useful in many cases too restrictive to be useful in many cases
3. Require that source range associated with recursive route is a 3. Require that source range associated with recursive route is a
subset of source range associated with route resolving recursion subset of source range associated with route resolving recursion
(i.e. source range of the resolving route is less specific (i.e. source range of the resolving route is less specific
superset of recursive route's source range) superset of recursive route's source range)
skipping to change at page 10, line 47 skipping to change at page 11, line 19
When recursive routing information is propagated in a dynamic routing When recursive routing information is propagated in a dynamic routing
protocol, it is up to the protocol specification to select and protocol, it is up to the protocol specification to select and
standardize appropriate scheme of recusrsive resolution. standardize appropriate scheme of recusrsive resolution.
Recursive resolution of configured static routes is local to router Recursive resolution of configured static routes is local to router
where recursive static routes were configured, thus behavior is where recursive static routes were configured, thus behavior is
implementation's choice. Implementations SHOULD provide option (3) implementation's choice. Implementations SHOULD provide option (3)
from the above list as their default method of recursive static route from the above list as their default method of recursive static route
resolution. This is both to guarantee that destination-only resolution. This is both to guarantee that destination-only
recursive static routes do not change their behavior when router's recursive static routes do not change their behavior when router's
software is upgraded to support source-destination routing and at the software is upgraded to support destination-source routing and at the
same time make source-destination recursive routes useful. same time make destination-source recursive routes useful.
5.1.1. Recursive route expansion 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,
skipping to change at page 13, line 7 skipping to change at page 13, line 32
and routers using both source and destination addresses for and routers using both source and destination addresses for
forwarding decision. forwarding decision.
In networks where the same dynamic routing protocol is being used to In networks where the same dynamic routing protocol is being used to
propagate routing information between both types of systems the propagate routing information between both types of systems the
protocol may address some or all traffic looping problems. protocol may address some or all traffic looping problems.
Recommendations to protocol designers are discussed in Section 4.2. Recommendations to protocol designers are discussed in Section 4.2.
When routing information is coming from outside of the routing When routing information is coming from outside of the routing
protocol (for example, being provided by operator in the form of protocol (for example, being provided by operator in the form of
static routes or network protocols not aware of source-destination static routes or network protocols not aware of destination-source
routing paradigm) it may not be possible for the router to ascertain routing paradigm) it may not be possible for the router to ascertain
loop-free properties of such routing information. In these cases loop-free properties of such routing information. In these cases
consistent (and loop-free) packet forwarding is woven into network consistent (and loop-free) packet forwarding is woven into network
topology and must be taken into consideration at design time. topology and must be taken into consideration at design time.
It is possible to design network with mixed deployment of routers It is possible to design network with mixed deployment of routers
supporting and not supporting source-destination routing. Thus supporting and not supporting destination-source routing. Thus
gradual enablement of source-destination routing in existing networks gradual enablement of destination-source routing in existing networks
is also possible but has to be carefully planned and evaluated for is also possible but has to be carefully planned and evaluated for
each network design individually. each network design individually.
Generally, source-destination routing will not cause traffic loops Generally, destination-source routing will not cause traffic loops
when disjoint 'islands' of source-destination routing do not exchange when disjoint 'islands' of destination-source routing do not exchange
source-destination routing information. One particular case of this destination-source routing information. One particular case of this
rule is a network which contains single contiguous 'island' of rule is a network which contains single contiguous 'island' of
routers aware of source-destination routing. Example SOHO network routers aware of destination-source routing. Example SOHO network
from Section 2.1 which demonstrates this design approach: from Section 2.1 which demonstrates this design approach:
______ ___ ,,------. ______ ___ ,,------.
/ \ _( )_ ,' ``. / \ _( )_ ,' ``.
___ / +----+ _( )_ ,' `. ___ / +----+ _( )_ ,' `.
/ \ / | R1 |---(_ ISP 1 _)---/ \ / \ / | R1 |---(_ ISP 1 _)---/ \
/ \----/ +----+ (_ _) / \ / \----/ +----+ (_ _) / \
/ Dst \ / Source- \ (___) ( ) / Dst \ / Source- \ (___) ( )
( only )( destination ) ( The Internet ) ( only )( destination ) ( The Internet )
( routing )( aware ) ___ ( ) ( routing )( aware ) ___ ( )
\ area / \ routing / _( )_ \ / \ area / \ routing / _( )_ \ /
\ /----\ area +----+ _( )_ \ / \ /----\ area +----+ _( )_ \ /
\___/ \ | R2 |---(_ ISP 2 _)----`. ,' \___/ \ | R2 |---(_ ISP 2 _)----`. ,'
\ +----+ (_ _) `. ,' \ +----+ (_ _) `. ,'
\______/ (___) ``------'' \______/ (___) ``------''
|----------------------------| |----------------------------|
SOHO network SOHO network
Example of multihomed small network with partial deployment of Example of multihomed small network with partial deployment of
source-destination routing destination-source routing
6.1. Interoperability in Distance-Vector Protocols 6.1. Interoperability in Distance-Vector Protocols
Distance-Vector routing protocols (BGP, RIPng, BABEL), operating on a Distance-Vector routing protocols (BGP, RIPng, BABEL), operating on a
hop-by-hop basis, can address interoperability and migration concerns hop-by-hop basis, can address interoperability and migration concerns
on that level. With routing information being flooded in the reverse on that level. With routing information being flooded in the reverse
direction of traffic being forwarded using that information, a hop direction of traffic being forwarded using that information, a hop
that floods is the same hop that forwards. that floods is the same hop that forwards.
This makes dealing with destination/source-unaware routers easy if This makes dealing with destination/source-unaware routers easy if
skipping to change at page 15, line 16 skipping to change at page 15, line 44
This document makes no requests to IANA. This document makes no requests to IANA.
8. 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 destination-source 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 destination-source 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.
9. 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.
10. 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. Significant contributions to source-specific routing homenet area. Significant contributions to source-specific routing
as a whole came from Juliusz Chroboczek and Matthieu Boutier. as a whole came from Juliusz Chroboczek and Matthieu Boutier.
Matthieu has also provided a huge amount of review and editing input
on this document.
This document itself is largely the result of discussions with Fred This document itself is largely the result of discussions with Fred
Baker and derives from [I-D.baker-ipv6-isis-dst-src-routing]. Baker and derives from [I-D.baker-ipv6-isis-dst-src-routing].
Thanks to Chris Bowers, Acee Lindem and Tony Przygienda for their Thanks to Chris Bowers, Acee Lindem and Tony Przygienda for their
input and review. input and review.
The Linux kernel is providing an implementation of the behaviour The Linux kernel is providing an implementation of the behaviour
described here since even before the document was started. described here since even before the document was started.
11. Change Log 11. Change Log
October 2017 [-06]:
clarify described operation is not an implementation guide
editorial cleanups
July 2017 [-05]:
clarify connectivity tests
extend use cases
editorial cleanups
May 2017 [-04]: no changes May 2017 [-04]: no changes
November 2016 [-03]: November 2016 [-03]:
added DV/LS protocol considerations added DV/LS protocol considerations
note backtracking workaround/caveat note backtracking workaround/caveat
November 2015 [-02]: November 2015 [-02]:
added section on source-destination routing use cases added section on destination-source routing use cases
added section on alternative lookup algorithm added section on alternative lookup algorithm
added section on requirement for dynamic routing protocols added section on requirement for dynamic routing protocols
dessiminating source-destination informaton dessiminating destination-source 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
12. References 12. References
12.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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. 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, <https://www.rfc-editor.org/info/rfc2460>.
12.2. Informative References 12.2. Informative References
[hal-00947234v1] [hal-00947234v1]
Boutier, M. and J. Chroboczek, "Source-sensitive routing", Boutier, M. and J. Chroboczek, "Source-sensitive routing",
hal 00947234v1, 2014, <https://hal-univ-diderot.archives- hal 00947234v1, 2014, <https://hal-univ-diderot.archives-
ouvertes.fr/hal-00947234v1>. ouvertes.fr/hal-00947234v1>.
[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
skipping to change at page 17, line 17 skipping to change at page 18, line 17
Conditional Router Advertisements for Enterprise Conditional Router Advertisements for Enterprise
Multihoming", draft-linkova-v6ops-conditional-ras-01 (work Multihoming", draft-linkova-v6ops-conditional-ras-01 (work
in progress), July 2017. in progress), July 2017.
[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, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc791>. 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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2080>. 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, <https://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
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4271>. editor.org/info/rfc4271>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008, DOI 10.17487/RFC5308, October 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5308>. editor.org/info/rfc5308>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016, <https://www.rfc-
editor.org/info/rfc8028>.
[RFC8043] Sarikaya, B. and M. Boucadair, "Source-Address-Dependent [RFC8043] Sarikaya, B. and M. Boucadair, "Source-Address-Dependent
Routing and Source Address Selection for IPv6 Hosts: Routing and Source Address Selection for IPv6 Hosts:
Overview of the Problem Space", RFC 8043, Overview of the Problem Space", RFC 8043,
DOI 10.17487/RFC8043, January 2017, DOI 10.17487/RFC8043, January 2017, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc8043>. editor.org/info/rfc8043>.
Appendix A. Implementation Options Appendix A. Implementation Options
A.1. Pre-expanded 2-step lookup without backtracking A.1. Pre-expanded 2-step lookup without backtracking
The backtracking behavior (specified in Section 3.1 as "A router MUST The backtracking behavior (specified in Section 3.3 as "A router MUST
continue to a less specific destination prefix") has been shown to continue to a less specific destination prefix") has been shown to
potentially cause a significant loss of forwarding performance since potentially cause a significant loss of forwarding performance since
forwarding a single packet may require a large number of table forwarding a single packet may require a large number of table
lookups. (The degenerate case is 129 destination lookups in lookups. (The degenerate case is 129 destination lookups in
decreasing prefix length, each followed by a failing longest-match on decreasing prefix length, each followed by a failing longest-match on
the source prefix.) the source prefix.)
To avoid this, implementations can install synthetic routes to To avoid this, implementations can install synthetic routes to
achieve the same lookup result. This works as follows, to be achieve the same lookup result. This works as follows, to be
evaluated for each unique destination prefix: evaluated for each unique destination prefix:
skipping to change at page 19, line 8 skipping to change at page 20, line 8
support using more than one FIB for a single lookup, but not all do. support using more than one FIB for a single lookup, but not all do.
An implementation that can choose from multiple FIBs based on source An implementation that can choose from multiple FIBs based on source
address is capable of correct forwarding according to this document, address is capable of correct forwarding according to this document,
provided that it supports enough FIBs. One FIB will be used for each provided that it supports enough FIBs. One FIB will be used for each
unique source prefix. unique source prefix.
For a complete description of the required translation algorithm, For a complete description of the required translation algorithm,
please refer to [hal-00947234v1]. It roughly works as follows: please refer to [hal-00947234v1]. It roughly works as follows:
After source-destination routing information has been collected, one After destination-source routing information has been collected, one
FIB table is created for each source range including the default FIB table is created for each source range including the default
range ::/0. Source-destination routes then replicated into each range ::/0. Source-destination routes then replicated into each
destination-only FIB table whose associated source address range is a destination-only FIB table whose associated source address range is a
subset of route's source range. Note that this rule means routes subset of route's source range. Note that this rule means routes
with default source range ::/0 are replicated into each FIB table. with default source range ::/0 are replicated into each FIB table.
In case when multiple routes with the same destination prefix are In case when multiple routes with the same destination prefix are
replicated into the same FIB table only route with the most specific replicated into the same FIB table only route with the most specific
source address range is installed. source address range is installed.
For example, if source-destination routing table contains these For example, if destination-source routing table contains these
routes: routes:
Destination prefix Source range Next Hop Destination prefix Source range Next Hop
------------------- ------------------------ -------- ------------------- ------------------------ --------
::/0, ::/0, NH1 ::/0, ::/0, NH1
2001:101:1234::/48, 2001:db8:3456:8000::/56, NH2 2001:101:1234::/48, 2001:db8:3456:8000::/56, NH2
2001:101:5678::/48, 2001:db8:3456:8000::/56, NH3 2001:101:5678::/48, 2001:db8:3456:8000::/56, NH3
::/0, NH4 ::/0, NH4
2001:101:abcd::/48, 2001:db8:3456::/48, NH5 2001:101:abcd::/48, 2001:db8:3456::/48, NH5
 End of changes. 75 change blocks. 
177 lines changed or deleted 213 lines changed or added

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