draft-ietf-rtgwg-dst-src-routing-02.txt   draft-ietf-rtgwg-dst-src-routing-03.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: November 3, 2016 Cisco Systems, Inc. Expires: May 18, 2017 Cisco Systems, Inc.
May 2, 2016 November 14, 2016
Destination/Source Routing Destination/Source Routing
draft-ietf-rtgwg-dst-src-routing-02 draft-ietf-rtgwg-dst-src-routing-03
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 November 3, 2016. This Internet-Draft will expire on May 18, 2017.
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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Dual-connected home / SOHO network . . . . . . . . . . . 3 2.1. Dual-connected home / SOHO network . . . . . . . . . . . 3
2.2. Degree of traffic engineering . . . . . . . . . . . . . . 4 2.2. Degree of traffic engineering . . . . . . . . . . . . . . 4
2.3. Distributed filtering based on source address . . . . . . 5 2.3. Distributed filtering based on source address . . . . . . 5
3. Principle of operation . . . . . . . . . . . . . . . . . . . 5 3. Principle of operation . . . . . . . . . . . . . . . . . . . 5
3.1. Lookup ordering and disambiguation . . . . . . . . . . . 6 3.1. Lookup ordering and disambiguation . . . . . . . . . . . 6
3.2. Ordering Rationale . . . . . . . . . . . . . . . . . . . 6 3.2. Ordering Rationale . . . . . . . . . . . . . . . . . . . 6
3.3. Multi-FIB lookup . . . . . . . . . . . . . . . . . . . . 7 3.3. Backtracking caveats . . . . . . . . . . . . . . . . . . 7
4. Requirements to the dynamic routing protocols providing 3.4. Multi-FIB lookup . . . . . . . . . . . . . . . . . . . . 7
source-destination routing information . . . . . . . . . . . 8 4. Routing protocol considerations . . . . . . . . . . . . . . . 9
4.1. Source information . . . . . . . . . . . . . . . . . . . 9 4.1. Source information . . . . . . . . . . . . . . . . . . . 9
4.2. Loop-freeness considerations . . . . . . . . . . . . . . 9 4.2. Loop-freeness considerations . . . . . . . . . . . . . . 10
4.3. Recursive routing . . . . . . . . . . . . . . . . . . . . 10 4.3. Recursive routing . . . . . . . . . . . . . . . . . . . . 11
5. Applicability To Specific Situations . . . . . . . . . . . . 10 5. Applicability To Specific Situations . . . . . . . . . . . . 11
5.1. Recursive Route Lookups . . . . . . . . . . . . . . . . . 11 5.1. Recursive Route Lookups . . . . . . . . . . . . . . . . . 11
5.1.1. Recursive route expansion . . . . . . . . . . . . . . 12 5.1.1. Recursive route expansion . . . . . . . . . . . . . . 12
5.2. Unicast Reverse Path Filtering . . . . . . . . . . . . . 12 5.2. Unicast Reverse Path Filtering . . . . . . . . . . . . . 13
5.3. Multicast Reverse Path Forwarding . . . . . . . . . . . . 13 5.3. Multicast Reverse Path Forwarding . . . . . . . . . . . . 13
6. Interoperability . . . . . . . . . . . . . . . . . . . . . . 13 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1. Interoperability in Distance-Vector Protocols . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6.2. Interoperability in Link-State Protocols . . . . . . . . 15
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 15 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 interface and next-hop gateway for
packet forwarding is based solely on the destination address packet forwarding is based solely on the destination address
contained in the packet header. There exists class of network design contained in the packet header. There exists class of network design
problems which require packet forwarding to consider more than just problems which require packet forwarding to consider more than just
the destination IP address (see Section 2 for examples). At present the destination IP address (see Section 2 for examples). At present
these problems are routinely resolved by configuring on routers these problems are routinely resolved by configuring on routers
skipping to change at page 3, line 39 skipping to change at page 3, line 42
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. Dual-connected home / SOHO network
Small networks - such as SOHO or the home networks (homenet) - may be Small networks - such as SOHO or the home networks (homenet) - may be
multihomed (i.e. dual-connected) to two different Internet Service multihomed (i.e. dual-connected) to two different Internet Service
Providers (ISPs). Benefits of doing this may include resiliency or Providers (ISPs). Benefits of doing this may include resiliency or
faster access to important resources (for example, video or cloud faster access to important resources (for example, video or cloud
services) local to ISPs. services) local to ISPs.
_____ ,,-------. _____ ,,-------.
_( )_ ,' ``. _( )_ ,' ``.
___ +----+ _( )_ ,' `. ___ +----+ _( )_ ,' `.
/ \---| R1 |---(_ ISP 1 _)------/ \ / \---| R1 |---(_ ISP 1 _)------/ \
/ \ +----+ (_ _) / \ / \ +----+ (_ _) / \
/ Small \ (_____) ( )
( ) ( The Internet ) / Small \ (_____) ( )
( ) _____ ( ) ( ) ( 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 Each ISP will allocate to the network IP address (or small range of
IP addresses) to use as source address for Internet communications. 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 Source-destination routing, when enabled on routers in the multihomed
small network (including routers R1 and R2), solves the problem by small network (including routers R1 and R2), solves the problem by
skipping to change at page 6, line 35 skipping to change at page 6, line 40
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- Implementations MAY implement lookup algorithm differently from step-
by-step description given above but if they do so then outcome of the 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 algorithm MUST be exactly the same as if above steps were used. One
example of equivalent lookup algorithm is given in Section 3.3. example of equivalent lookup algorithm is given in Section 3.4.
3.2. Ordering Rationale 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
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 match search. Hence, this document describes destination-first match search.
3.3. Multi-FIB lookup 3.3. Backtracking caveats
The backtracking behavior (specified above as "A router MUST continue
to a less specific destination prefix") has been shown to potentially
cause a significant loss of forwarding performance since forwarding a
single packet may require a large number of table lookups.
To avoid this, implementations can install synthetic routes to
achieve the same lookup result. This works as follows, to be
evaluated for each unique destination prefix:
1. If there is a route (D, S=::/0), end processing for D.
2. Iterate upwards one level (from D if first iteration, previous D'
otherwise) to a less specific destination. Call this D'.
3. For all routes (D', S'), i.e. all source prefixes S' under that
destiation prefix, install a copy (D, S') if and only if S'
covers some source prefix that isn't covered yet. (In terms of
set theory, S' cut by all existing S under D is not empty.)
4. Repeat at step 1.
The effect of this algorithm is that after performing a lookup on the
destination prefix, looking up the source prefix directly yields the
result that backtracking would give. This eliminates backtracking
and provides constant 2 lookup cost.
3.4. Multi-FIB lookup
Routing table lookup algorithm described in Section 3.1 is iterative Routing table lookup algorithm described in Section 3.1 is iterative
and looks for destination match first. This section outlines and looks for destination match first. This section outlines
alternative implementation of the lookup algorithm which produces the alternative implementation of the lookup algorithm which produces the
same outcome but does match on the source address first. Algorithm same outcome but does match on the source address first. Algorithm
in this section is given for illustration purposes only. in this section is given for illustration purposes only.
Lookup algorithm described in this section is not iterative at the Lookup algorithm described in this section is not iterative at the
expense of maintaining multiple lookup tables. Such tradeoff may be expense of maintaining multiple lookup tables. Such tradeoff may be
desirable for implementation on routers where packet forwarding is desirable for implementation on routers where packet forwarding is
skipping to change at page 8, line 39 skipping to change at page 9, line 27
::/0, NH1 ::/0, NH1
2001:101:1234::/48, NH2 2001:101:1234::/48, NH2
2001:101:5678::/48, NH3 2001:101:5678::/48, NH3
2001:101:abcd::/48, NH5 2001:101:abcd::/48, NH5
During packet forwarding, lookup first matches source address against During packet forwarding, lookup first matches source address against
the list of address ranges associated with FIB tables to select a FIB the list of address ranges associated with FIB tables to select a FIB
table with the most specific source address range and then does table with the most specific source address range and then does
destination-only lookup in the selected FIB table. destination-only lookup in the selected FIB table.
4. Requirements to the dynamic routing protocols providing source- 4. Routing protocol considerations
destination routing information
As with the destination-only routing, source-destination routes will As with the destination-only routing, source-destination 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 source-destination 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 source-destination routing protocols.
4.1. Source information 4.1. Source information
skipping to change at page 10, line 11 skipping to change at page 10, line 44
supports source-destination routing, for example calculate an supports source-destination routing, for example calculate an
alternate topology including only routers that support source- alternate topology including only routers that support source-
destination routing architecture destination routing architecture
2. If next-hop gateway is not aware of source-destination routing 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 then a source-destination 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 source-destination 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 source-
destination routing domain will be provided by an operator via destination 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
skipping to change at page 11, line 22 skipping to change at page 12, line 6
either be carried by dynamic routing protocols or provided via either be carried by dynamic routing protocols or provided via
configuration as recursive static routes. configuration as recursive static routes.
Recursive source-destination routes have additional complication in Recursive source-destination routes have additional complication in
how source address range should be considered while finding source- how source address range should be considered while finding source-
destination route to resolve recusion. destination 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 source-destination 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)
4. Create multiple instances of the route whose nexthop is being 4. Create multiple instances of the route whose nexthop is being
resolved with different source prefixes; this option is further resolved with different source prefixes; this option is further
elaborated in Section 5.1.1 elaborated in Section 5.1.1
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.
skipping to change at page 12, line 14 skipping to change at page 12, line 43
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,
i.e. /128), copy all other attributes from the original route i.e. /128), copy all other attributes from the original route
2. find all routes that overlap with this set of attributes 2. find all routes that overlap with this set of attributes
(including both more-specific and less-specific routes) (including both more-specific and less-specific routes)
3. order the result from most to less specific 3. order the result from most to less specific
4. for each route, install a route using the original route's 4. for each route, install a route using the original route's
destination and the "logical and" overlap of each extra match destination and the "logical and" overlap of each extra match
attribute with same attribute from the set. Copy nexthop data attribute with same attribute from the set. Copy nexthop data
from the route under iteration. Then, reduce the set of extra from the route under iteration. Then, reduce the set of extra
skipping to change at page 14, line 25 skipping to change at page 14, line 51
\___/ \ | 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 source-destination routing
6.1. Interoperability in Distance-Vector Protocols
Distance-Vector routing protocols (BGP, RIPng, BABEL), operating on a
hop-by-hop basis, can address interoperability and migration concerns
on that level. With routing information being flooded in the reverse
direction of traffic being forwarded using that information, a hop
that floods is the same hop that forwards.
This makes dealing with destination/source-unaware routers easy if
destination/source routes are made to be ignored by such unaware
routers, and flooding of such routes is inhibited.
If D/S routes are discarded by non-D/S routers, D/S routers will not
receive non-working routes and can select from other available
working D/S routes.
Note that for this to work, non-D/S routers MUST NOT flood D/S
routing information. This can be achieved in 2 ways:
1. Using some preexisting encoding to signal non-D/S routers to not
flood these particular routes
2. Ignoring flooded D/S information on D/S routers by having them
detect that they received it from a non-D/S router (e.g. using
some capability signalling to identify non-D/S routers.) This
handling likely needs to be performed on a level of same-link
neighborships.
Also note that the considerations in this section only apply if data
path and flooding path are congruent.
6.2. Interoperability in Link-State Protocols
For Link-State routing protocols (OSPF, IS-IS), there is no relation
between route flooding and forwarding. Instead, forwarding decisions
are based on shortest-path calculation on top of the received
topology information.
For a D/S router to avoid loops, there are again two choices
available:
1. Detect that forwarding for a D/S route transits over a non-D/S
router and convert the route into a blackhole route to replace
looping with blackholing. This obviously impacts connectivity.
2. Perform separate SPF calculations using only the subset of D/
S-capable routers; thus D/S routers can forward D/S-routed
packets as long as they stay in contiguous islands.
The latter approach is facilitated by Multi-Topology extensions to
the respective protocols. These extensions provide a way to both
isolate D/S routing information and perform the separate SPF
calculation. Note that it is not neccessary to use multiple
topologies for distinct source prefixes; only a single additional
topology encompassing all D/S-capable routers is sufficient.
7. IANA Considerations 7. IANA Considerations
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.
skipping to change at page 15, line 16 skipping to change at page 17, line 7
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].
11. Change Log 11. Change Log
November 2015 [-01]: November 2016 [-03]:
added DV/LS protocol considerations
note backtracking workaround/caveat
November 2015 [-02]:
added section on source-destination routing use cases added section on source-destination 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 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.
skipping to change at page 15, line 38 skipping to change at page 17, line 35
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, March 1997.
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 6 (IPv6) Specification", RFC 2460, December 1998.
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
12.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-05 (work in progress), April 2016. routing-04 (work in progress), October 2015.
[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, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI
DOI 10.17487/RFC0791, September 1981, 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <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, January 1997.
<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, May 2000.
May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Protocol 4 (BGP-4)", RFC 4271, January 2006.
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
DOI 10.17487/RFC5308, October 2008, 2008.
<http://www.rfc-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, July 2008.
<http://www.rfc-editor.org/info/rfc5340>.
Authors' Addresses Authors' Addresses
David Lamparter David Lamparter
NetDEF NetDEF
Leipzig 04103 Leipzig 04103
Germany Germany
Email: david@opensourcerouting.org Email: david@opensourcerouting.org
Anton Smirnov Anton Smirnov
Cisco Systems, Inc. Cisco Systems, Inc.
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Email: as@cisco.com Email: as@cisco.com
 End of changes. 30 change blocks. 
67 lines changed or deleted 150 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/