draft-ietf-rtgwg-dst-src-routing-00.txt   draft-ietf-rtgwg-dst-src-routing-01.txt 
rtgwg D. Lamparter rtgwg D. Lamparter
Internet-Draft NetDEF Internet-Draft NetDEF
Intended status: Standards Track October 17, 2015 Intended status: Standards Track A. Smirnov
Expires: April 19, 2016 Expires: September 10, 2016 Cisco Systems, Inc.
March 9, 2016
Destination/Source Routing Destination/Source Routing
draft-ietf-rtgwg-dst-src-routing-00 draft-ietf-rtgwg-dst-src-routing-01
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 33 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 April 19, 2016. This Internet-Draft will expire on September 10, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Principle of operation . . . . . . . . . . . . . . . . . . . 3 2. Principle of operation . . . . . . . . . . . . . . . . . . . 3
2.1. Lookup ordering and disambiguation . . . . . . . . . . . 3 2.1. Lookup ordering and disambiguation . . . . . . . . . . . 3
2.2. Ordering Rationale . . . . . . . . . . . . . . . . . . . 4 2.2. Ordering Rationale . . . . . . . . . . . . . . . . . . . 3
3. Applicability To Specific Situations . . . . . . . . . . . . 4 3. Applicability To Specific Situations . . . . . . . . . . . . 4
3.1. Recursive Route Lookups . . . . . . . . . . . . . . . . . 4 3.1. Recursive Route Lookups . . . . . . . . . . . . . . . . . 4
3.2. Unicast Reverse Path Filtering . . . . . . . . . . . . . 5 3.2. Unicast Reverse Path Filtering . . . . . . . . . . . . . 5
3.3. Multicast Reverse Path Forwarding . . . . . . . . . . . . 5 3.3. Multicast Reverse Path Forwarding . . . . . . . . . . . . 5
4. Interoperability . . . . . . . . . . . . . . . . . . . . . . 5 4. Interoperability . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
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.
For a general introduction and aspects of interfacing routers to For a general introduction and aspects of interfacing routers to
hosts, refer to [I-D.sarikaya-6man-sadr-overview]. hosts, refer to [I-D.sarikaya-6man-sadr-overview].
skipping to change at page 4, line 18 skipping to change at page 4, line 12
could as well be reversed, which would lead to semantically different could as well be reversed, which would lead to semantically different
behavior. behavior.
Choosing destination to be evaluated first caters to the assumption Choosing destination to be evaluated first caters to the assumption
that local networks should have full, contiguous connectivity to each that local networks should have full, contiguous connectivity to each
other. This implies that those specific local routes always match other. This implies that those specific local routes always match
first based on destination, and use a zero ("all sources") source first based on destination, and use a zero ("all sources") source
prefix. prefix.
If the source prefix were to be matched first, this would result in a If the source prefix were to be matched first, this would result in a
less specific (e.g. default) route with a source prefix to match less specific (e.g. default) route with a source prefix to match
before those local routes. In other terms, this would essentially before those local routes. In other terms, this would essentially
divide local connectivity into zones based on source prefix, which is divide local connectivity into zones based on source prefix, which is
not the intention of this document. not the intention of this document.
Hence, this document describes destination-first lookup. Hence, this document describes destination-first lookup.
3. Applicability To Specific Situations 3. Applicability To Specific Situations
3.1. Recursive Route Lookups 3.1. Recursive Route Lookups
skipping to change at page 4, line 51 skipping to change at page 4, line 45
(Variant 4:) (Variant 4:)
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
attributes by what was covered by the route just installed attributes by what was covered by the route just installed
("logical AND NOT"). ("logical AND NOT").
Example recursive route resolution Example recursive route resolution
route to be resolved: route to be resolved:
skipping to change at page 7, line 42 skipping to change at page 7, line 37
April 2015 [-01]: merged routing-extra-qualifiers draft, new April 2015 [-01]: merged routing-extra-qualifiers draft, new
ordering rationale section ordering rationale section
October 2014 [-00]: Initial Version October 2014 [-00]: Initial Version
10. References 10. References
10.1. Normative References 10.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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
6 (IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
10.2. Informative References 10.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-03 (work in progress), July 2015. 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-08 (work in progress), August 2015. 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.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997. DOI 10.17487/RFC2080, 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, May 2000. Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Protocol 4 (BGP-4)", RFC 4271, January 2006. Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
2008. DOI 10.17487/RFC5308, October 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, July 2008. for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
Author's Address Authors' Addresses
David Lamparter David Lamparter
NetDEF NetDEF
Leipzig 04103 Leipzig 04103
Germany Germany
Email: david@opensourcerouting.org Email: david@opensourcerouting.org
Anton Smirnov
Cisco Systems, Inc.
De Kleetlaan 6a
Diegem 1831
Belgium
Email: as@cisco.com
 End of changes. 21 change blocks. 
25 lines changed or deleted 34 lines changed or added

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