--- 1/draft-ietf-rtgwg-dst-src-routing-04.txt 2017-07-19 09:13:11.741809263 -0700 +++ 2/draft-ietf-rtgwg-dst-src-routing-05.txt 2017-07-19 09:13:11.781810214 -0700 @@ -1,19 +1,19 @@ rtgwg D. Lamparter Internet-Draft NetDEF Intended status: Standards Track A. Smirnov -Expires: November 18, 2017 Cisco Systems, Inc. - May 17, 2017 +Expires: January 20, 2018 Cisco Systems, Inc. + July 19, 2017 Destination/Source Routing - draft-ietf-rtgwg-dst-src-routing-04 + draft-ietf-rtgwg-dst-src-routing-05 Abstract This note specifies using packets' source addresses in route lookups as additional qualifier to be used in route lookup. This applies to IPv6 [RFC2460] in general with specific considerations for routing protocol left for separate documents. Status of This Memo @@ -23,21 +23,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 18, 2017. + This Internet-Draft will expire on January 20, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -48,46 +48,50 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Dual-connected home / SOHO network . . . . . . . . . . . 3 2.2. Degree of traffic engineering . . . . . . . . . . . . . . 4 2.3. Distributed filtering based on source address . . . . . . 5 - 3. Principle of operation . . . . . . . . . . . . . . . . . . . 5 + 2.4. Walled-garden Enterprise services . . . . . . . . . . . . 5 + 2.5. Information Source for Neighbor Management . . . . . . . 6 + 3. Principle of operation . . . . . . . . . . . . . . . . . . . 6 3.1. Lookup ordering and disambiguation . . . . . . . . . . . 6 - 3.2. Ordering Rationale . . . . . . . . . . . . . . . . . . . 6 - 3.3. Backtracking caveats . . . . . . . . . . . . . . . . . . 7 - 3.4. Multi-FIB lookup . . . . . . . . . . . . . . . . . . . . 7 - 4. Routing protocol considerations . . . . . . . . . . . . . . . 9 - 4.1. Source information . . . . . . . . . . . . . . . . . . . 9 - 4.2. Loop-freeness considerations . . . . . . . . . . . . . . 10 - 4.3. Recursive routing . . . . . . . . . . . . . . . . . . . . 11 - 5. Applicability To Specific Situations . . . . . . . . . . . . 11 - 5.1. Recursive Route Lookups . . . . . . . . . . . . . . . . . 11 - 5.1.1. Recursive route expansion . . . . . . . . . . . . . . 12 - 5.2. Unicast Reverse Path Filtering . . . . . . . . . . . . . 13 - 5.3. Multicast Reverse Path Forwarding . . . . . . . . . . . . 13 - 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . 13 - 6.1. Interoperability in Distance-Vector Protocols . . . . . . 14 - 6.2. Interoperability in Link-State Protocols . . . . . . . . 15 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 - 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 12.2. Informative References . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + 3.2. Ordering Rationale . . . . . . . . . . . . . . . . . . . 7 + 4. Routing protocol considerations . . . . . . . . . . . . . . . 7 + 4.1. Source information . . . . . . . . . . . . . . . . . . . 8 + 4.2. Loop-freeness considerations . . . . . . . . . . . . . . 8 + 4.3. Recursive routing . . . . . . . . . . . . . . . . . . . . 9 + 5. Applicability To Specific Situations . . . . . . . . . . . . 9 + 5.1. Recursive Route Lookups . . . . . . . . . . . . . . . . . 10 + 5.1.1. Recursive route expansion . . . . . . . . . . . . . . 11 + 5.2. Unicast Reverse Path Filtering . . . . . . . . . . . . . 11 + 5.3. Multicast Reverse Path Forwarding . . . . . . . . . . . . 12 + 5.4. Testing for Connectivity Availability . . . . . . . . . . 12 + 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . 12 + 6.1. Interoperability in Distance-Vector Protocols . . . . . . 13 + 6.2. Interoperability in Link-State Protocols . . . . . . . . 14 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 + 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 12.2. Informative References . . . . . . . . . . . . . . . . . 16 + Appendix A. Implementation Options . . . . . . . . . . . . . . . 17 + A.1. Pre-expanded 2-step lookup without backtracking . . . . . 18 + A.2. Translation to Multi-FIB (Policy Routing) perspective . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Both IPv4 [RFC0791] and IPv6 [RFC2460] architectures specify that determination of the outgoing interface and next-hop gateway for packet forwarding is based solely on the destination address contained in the packet header. There exists class of network design problems which require packet forwarding to consider more than just the destination IP address (see Section 2 for examples). At present these problems are routinely resolved by configuring on routers @@ -172,23 +175,24 @@ the proper exit the source address of packets must be taken into account. Source-destination routing, when enabled on routers in the multihomed small network (including routers R1 and R2), solves the problem by driving packets originated by internal hosts to the correct Internet exit point considering IP source address assigned to the packet by originating host. For a general introduction and aspects of interfacing routers to - hosts, refer to [I-D.sarikaya-6man-sadr-overview]. + hosts, refer to [RFC8043]. 2.2. Degree of traffic engineering + Consider enterprise consisting of a headquarter (HQ) and branch offices. A branch office is connected to the enterprise HQ network via 2 links. For performance or security reasons it is desired to route corporate traffic via one link and Internet traffic via another link. In direction branch -> HQ the problem is easily solvable by having the default route pointing to the Internet link and HQ routes pointing to another link. But destination routing does not provide an easy way to achieve traffic separation in direction HQ -> branch because destination is the same (branch network). @@ -209,20 +213,47 @@ If routers in the untrusted zone are configured with source- destination routing (and, possibly, unicast RPF check) and receive via dynamic routing protocol routes then DDOS attack is dropped by routers on the edge of source-destination routing area. DDOS attack does not even reach the firewall whose resources are freed to deal with Deep Packet Inspection. On the other hand, security policy is managed in a single point - on a router injecting relevant source-destination routes into the dynamic routing protocol. +2.4. Walled-garden Enterprise services + + Apart from transfering from multihomed personal networks to + multihomed PA enterprise setups without any changes, source- + destination routing can also be used to correctly route services that + assign their own prefixes to customers using the particular service. + This is distinct from internet connectivity only in that it does not + provide a default route. Applying source-destination routing, the + entire routing domain is aware of the specific constraints of the + routes involved. + + Additionally, if the walled-garden's destination prefix is advertised + as blackhole route, this ensures that communication with the service + will only be routed using the specific D/S route, never leaking onto + unintended paths like a default route. + + This is very similar to firewall/filtering functionality, except the + feature is distributed onto routers. + +2.5. Information Source for Neighbor Management + + Having information on source address restrictions for routes + distributed, routers can rely on this additional information to + improve their behaviour towards hosts connected to them. This + specifically includes IPv6 Router Advertisements, which is described + in [I-D.linkova-v6ops-conditional-ras]. + 3. Principle of operation The mechanism in this document is such that a source prefix is added to all route entries. This document assumes all entries have a source prefix, with ::/0 as default value for entries installed without a specified source prefix. This need not be implemented in this particular way, however the system MUST behave exactly as if it were. In particular, a difference in behaviour between routes with a source prefix of ::/0 and routes without source prefix MUST NOT be visible. @@ -254,22 +285,24 @@ such an event. Using A < B to mean "A is more specific than B", this is represented as: A < B := Adst < Bdst || (Adst == Bdst && Asrc < Bsrc) Implementations MAY implement lookup algorithm differently from step- by-step description given above but if they do so then outcome of the - algorithm MUST be exactly the same as if above steps were used. One - example of equivalent lookup algorithm is given in Section 3.4. + 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 would lead to semantically different behavior. This standard requires most specific match on destination address to be found before looking for match on source address. Choosing destination to be evaluated first caters to the assumption that local networks should have full, contiguous connectivity to each @@ -278,125 +311,20 @@ prefix. If the source prefix were to be matched first, this would result in a less specific (e.g. default) route with a source prefix to match before those local routes. In other terms, this would essentially divide local connectivity into zones based on source prefix, which is not the intention of this document. Hence, this document describes destination-first match search. -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 - and looks for destination match first. This section outlines - alternative implementation of the lookup algorithm which produces the - same outcome but does match on the source address first. Algorithm - in this section is given for illustration purposes only. - - Lookup algorithm described in this section is not iterative at the - expense of maintaining multiple lookup tables. Such tradeoff may be - desirable for implementation on routers where packet forwarding is - assisted by specialized ASICs. - - The crux of the algorithm is in creating multiple destination-only - tables for forwarding lookups (FIB tables) with each table being - associated with unique range of source addresses. - - After source-destination routing information has been collected, one - FIB table is created for each source range including the default - range ::/0. Source-destination routes then replicated into each - destination-only FIB table whose associated source address range is a - subset of route's source range. Note that this rule means routes - with default source range ::/0 are replicated into each FIB table. - - In case when multiple routes with the same destination prefix are - replicated into the same FIB table only route with the most specific - source address range is installed. - - For example, if source-destination routing table contains these - routes: - - Destination prefix Source range Next Hop - ------------------- ------------------------ -------- - ::/0, ::/0, NH1 - 2001:101:1234::/48, 2001:db8:3456:8000::/56, NH2 - 2001:101:5678::/48, 2001:db8:3456:8000::/56, NH3 - ::/0, NH4 - 2001:101:abcd::/48, 2001:db8:3456::/48, NH5 - - then 3 FIB tables will be created associated with source ranges ::/0, - 2001:db8:3456::/48 and 2001:db8:3456:8000::/56. In this example - range 2001:db8:3456:8000::/56 is a subset of less specific range - 2001:db8:3456::/48. Such inclusion makes a somewhat artificial - example but was intentionally selected to demonstrate hierarchy of - route replication. - - And content of these FIB tables will be: - - FIB 1 (source range ::/0): - - Destination prefix Next Hop - ------------------- -------- - ::/0, NH1 - 2001:101:5678::/48, NH4 - - FIB 2 (source range 2001:db8:3456::/48): - - Destination prefix Next Hop - ------------------- -------- - ::/0, NH1 - 2001:101:5678::/48, NH4 - 2001:101:abcd::/48, NH5 - - FIB 3 (source range 2001:db8:3456:8000::/56): - - Destination prefix Next Hop - ------------------- -------- - ::/0, NH1 - 2001:101:1234::/48, NH2 - 2001:101:5678::/48, NH3 - 2001:101:abcd::/48, NH5 - - During packet forwarding, lookup first matches source address against - the list of address ranges associated with FIB tables to select a FIB - table with the most specific source address range and then does - destination-only lookup in the selected FIB table. - 4. Routing protocol considerations As with the destination-only routing, source-destination routes will typically be disseminated throughout the network by dynamic routing protocols. It is expected that multiple dynamic routing protocols will be adapted to the needs of source-destination routing architecture. Specification of dynamic routing protocols is outside of scope of this document. This section lists requirements and considerations for the dynamic source-destination routing protocols. @@ -590,20 +518,49 @@ It MUST NOT ignore dst-src routes on uRPF checks. 5.3. Multicast Reverse Path Forwarding Multicast Reverse Path Lookups are used to find paths towards the (known) sender of multicast packets. Since the destination of these packets is the multicast group, it cannot be matched against the source part of a dst-src route. Therefore, dst-src routes MUST be ignored for Multicast RPF lookups. +5.4. Testing for Connectivity Availability + + There are situations where systems' behaviour depends on the fact + whether "connectivity" is available in a broad sense. These systems + may have previously tested for the existence of a default route in + the routing table. + + Since the default route may now be qualified with a source prefix, + this test can fail. If no additional information is available to + qualify this test, systems SHOULD test for the existence of any + default route instead, e.g. include routes with default destination + but non-default source prefix. + + However, if the test can be associated with a source address or + source prefix, this data SHOULD be used in looking up a default + route. Depending on the application, it MAY also be useful to - + possibly additionally - consider "connectivity" to be available if + any route exists where the route's source prefix covers the prefix or + address under consideration, allowing arbitrary destination prefixes. + + Note though that this approach to routing SHOULD NOT be used to infer + a list of source prefixes in an enumerative manner, or even to guess + domain information. Specifically, if an operator uses more specific + source prefixes to refine their routing, the inferred information + will provide bogus extraneous output. This is distinct from the + connectivity tests mentioned above in that those actually inquire the + routing system, unlike domain information or enumeration, which is + higher-layer application information. + 6. Interoperability As pointed out in Section 4.2 traffic may permanently loop between routers forwarding packets based only on their destination IP address and routers using both source and destination addresses for forwarding decision. In networks where the same dynamic routing protocol is being used to propagate routing information between both types of systems the protocol may address some or all traffic looping problems. @@ -729,24 +687,31 @@ If a host's addresses are known, injecting a dst-src route allows isolation of traffic from that host, which may compromise privacy. However, this requires access to the routing system. As with similar problems with the destination only, defending against it is left to general mechanisms protecting the routing infrastructure. 10. Acknowledgements The base underlying this document was first outlaid by Ole Troan and Lorenzo Colitti in [I-D.troan-homenet-sadr] for application in the - homenet area. + homenet area. Significant contributions to source-specific routing + as a whole came from Juliusz Chroboczek and Matthieu Boutier. - This document is largely the result of discussions with Fred Baker - and derives from [I-D.baker-ipv6-isis-dst-src-routing]. + This document itself is largely the result of discussions with Fred + Baker and derives from [I-D.baker-ipv6-isis-dst-src-routing]. + + Thanks to Chris Bowers, Acee Lindem and Tony Przygienda for their + input and review. + + The Linux kernel is providing an implementation of the behaviour + described here since even before the document was started. 11. Change Log May 2017 [-04]: no changes November 2016 [-03]: added DV/LS protocol considerations note backtracking workaround/caveat @@ -766,62 +731,193 @@ April 2015 [-01]: merged routing-extra-qualifiers draft, new ordering rationale section October 2014 [-00]: Initial Version 12. References 12.1. Normative References [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, + . - [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version - 6 (IPv6) Specification", RFC 2460, December 1998. + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, . 12.2. Informative References + [hal-00947234v1] + Boutier, M. and J. Chroboczek, "Source-sensitive routing", + hal 00947234v1, 2014, . + [I-D.baker-ipv6-isis-dst-src-routing] Baker, F. and D. Lamparter, "IPv6 Source/Destination Routing using IS-IS", draft-baker-ipv6-isis-dst-src- - routing-04 (work in progress), October 2015. + routing-07 (work in progress), July 2017. - [I-D.sarikaya-6man-sadr-overview] - Sarikaya, B. and M. Boucadair, "Source Address Dependent - Routing and Source Address Selection for IPv6 Hosts: - Problem Space Overview", draft-sarikaya-6man-sadr- - overview-09 (work in progress), January 2016. + [I-D.linkova-v6ops-conditional-ras] + Linkova, J. and s. stucchi-lists@glevia.com, "Using + Conditional Router Advertisements for Enterprise + Multihoming", draft-linkova-v6ops-conditional-ras-01 (work + in progress), July 2017. [I-D.troan-homenet-sadr] Troan, O. and L. Colitti, "IPv6 Multihoming with Source Address Dependent Routing (SADR)", draft-troan-homenet- sadr-01 (work in progress), September 2013. - [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI - 10.17487/RFC0791, September 1981, + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, + DOI 10.17487/RFC0791, September 1981, . [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, - January 1997. + DOI 10.17487/RFC2080, January 1997, + . [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 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, . - [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway - Protocol 4 (BGP-4)", RFC 4271, January 2006. + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + DOI 10.17487/RFC4271, January 2006, + . - [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October - 2008. + [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, + DOI 10.17487/RFC5308, October 2008, + . [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, + . + + [RFC8043] Sarikaya, B. and M. Boucadair, "Source-Address-Dependent + Routing and Source Address Selection for IPv6 Hosts: + Overview of the Problem Space", RFC 8043, + DOI 10.17487/RFC8043, January 2017, + . + +Appendix A. Implementation Options +A.1. Pre-expanded 2-step lookup without backtracking + + The backtracking behavior (specified in Section 3.1 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. (The degenerate case is 129 destination lookups in + decreasing prefix length, each followed by a failing longest-match on + the source prefix.) + + 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 (after exactly one destination + longest-match, the source longest-match will provide the final, + correct result; any no-match is a final no-match). + +A.2. Translation to Multi-FIB (Policy Routing) perspective + + The lookup procedure described in this document requires destination- + first lookup. This is not a fit with most existing implementations + of Policy Routing. While Policy Routing has no formal specification, + it generally permits choosing from multiple routing tables / FIBs + based on, among other things, source address. Some implementations + 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 + address is capable of correct forwarding according to this document, + provided that it supports enough FIBs. One FIB will be used for each + unique source prefix. + + For a complete description of the required translation algorithm, + please refer to [hal-00947234v1]. It roughly works as follows: + + After source-destination routing information has been collected, one + FIB table is created for each source range including the default + range ::/0. Source-destination routes then replicated into each + destination-only FIB table whose associated source address range is a + subset of route's source range. Note that this rule means routes + with default source range ::/0 are replicated into each FIB table. + + In case when multiple routes with the same destination prefix are + replicated into the same FIB table only route with the most specific + source address range is installed. + + For example, if source-destination routing table contains these + routes: + + Destination prefix Source range Next Hop + ------------------- ------------------------ -------- + ::/0, ::/0, NH1 + 2001:101:1234::/48, 2001:db8:3456:8000::/56, NH2 + 2001:101:5678::/48, 2001:db8:3456:8000::/56, NH3 + ::/0, NH4 + 2001:101:abcd::/48, 2001:db8:3456::/48, NH5 + + then 3 FIB tables will be created associated with source ranges ::/0, + 2001:db8:3456::/48 and 2001:db8:3456:8000::/56. In this example + range 2001:db8:3456:8000::/56 is a subset of less specific range + 2001:db8:3456::/48. Such inclusion makes a somewhat artificial + example but was intentionally selected to demonstrate hierarchy of + route replication. + + And content of these FIB tables will be: + + FIB 1 (source range ::/0): + + Destination prefix Next Hop + ------------------- -------- + ::/0, NH1 + 2001:101:5678::/48, NH4 + + FIB 2 (source range 2001:db8:3456::/48): + + Destination prefix Next Hop + ------------------- -------- + ::/0, NH1 + 2001:101:5678::/48, NH4 + 2001:101:abcd::/48, NH5 + + FIB 3 (source range 2001:db8:3456:8000::/56): + + Destination prefix Next Hop + ------------------- -------- + ::/0, NH1 + 2001:101:1234::/48, NH2 + 2001:101:5678::/48, NH3 + 2001:101:abcd::/48, NH5 + + During packet forwarding, lookup first matches source address against + the list of address ranges associated with FIB tables to select a FIB + table with the most specific source address range and then does + destination-only lookup in the selected FIB table. Authors' Addresses David Lamparter NetDEF Leipzig 04103 Germany Email: david@opensourcerouting.org