| Network Working Group | F. Baker |
| Internet-Draft | |
| Intended status: Standards Track | D. Lamparter |
| Expires: July 28, 2018 | NetDEF |
| January 24, 2018 |
IPv6 Source/Destination Routing using IS-IS
draft-ietf-isis-ipv6-dst-src-routing-00
This note describes the changes necessary for IS-IS to route IPv6 traffic from a specified prefix to a specified prefix.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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 https://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 July 28, 2018.
Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This specification defines how to exchange destination/source routing information in IS-IS for IPv6[IS-IS] routing environments. To this extent, a new sub-TLV for an IPv6 Source Prefix is added, and Multi Topology Routing is employed to address compatibility and isolation concerns.
The router MUST implement the Destination/Source Routing mechanism described in [I-D.ietf-rtgwg-dst-src-routing]. This implies not simply routing "to a destination", but routing "to that destination AND from a specified source". The obvious application is egress routing, as required for a multihomed entity with a provider-allocated prefix from each of several upstream networks. Traffic within the network could be source/destination routed as well, or could be implicitly or explicitly routed from "any prefix", ::/0. Other use cases are described in [I-D.baker-rtgwg-src-dst-routing-use-cases]. If a FIB contains a route to a given destination from one or more prefixes not including ::/0, and a given packet destined there that has a source address that is in none of them, the packet in effect has no route, just as if the destination itself were not in the route table.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Both IS-IS and OSPF perform their calculations by building a lattice of routers and links from the router performing the calculation to each router, and then use routes (sequences in the lattice) to get to destinations that those routes advertise connectivity to. Following the SPF algorithm, calculation starts by selecting a starting point (typically the router doing the calculation), and successively adding {link, router} pairs until one has calculated a route to every router in the network. As each router is added, including the original router, destinations that it is directly connected to are turned into routes in the route table: "to get to 2001:db8::/32, route traffic to {interface, list of next hop routers}". For immediate neighbors to the originating router, of course, there is no next hop router; traffic is handled locally.
In this context, the route is qualified by a source prefix; It is installed into the FIB with the destination prefix, and the FIB applies the route if and only if the IPv6 source address also matches the advertised prefix. Of course, there may be multiple LSPs in the RIB with the same destination and differing source prefixes; these may also have the same or differing next hop lists. The intended forwarding action is to forward matching traffic to one of the next hop routers associated with this destination and source prefix, or to discard non-matching traffic as "destination unreachable".
TLVs that lack a source prefix sub-TLV match any source address (i.e., the source prefix TLV defaults to ::/0), by definition.
To ensure that routers without support for Destination/Source routing are excluded from path calculation for routes with a non-default source prefix, a separate MTID is used to carry Destination/Source routes. A router MUST NOT participate in a topology with such an MTID unless it implements Destination/Source routing.
There is a distinct Destination/Source Routing MTID for each of the underlying base MT topologies the information applies to. The set of routes propagated towards the forwarding plane is the union of the information in the base topology and the D/S Routing MTID. Incoming connectivity information with a default or non-present source prefix is advertised in the base topology, routes with non-default source prefix are advertised in the D/S Routing MTID.
For the purposes of this document, a route from the prefix A to the prefix B (in other words, whose source prefix is A and whose destination prefix is B) is expressed as A->B. A packet with the source address A and the destination address B is similarly described as A->B.
In any routing protocol, there is the possibility of ambiguity. For example, one router might advertise a fairly general prefix - a default route, a discard prefix (which consumes all traffic that is not directed to an instantiated subnet), or simply an aggregated prefix while another router advertises a more specific one. In source/destination routing, potentially ambiguous cases include cases in which the link state database contains two routes A->B' and A'->B, in which A' is a more specific prefix within the prefix A and B' is a more specific prefix within the prefix B. Traditionally, we have dealt with ambiguous destination routes using a "longest match first" rule. If the same datagram matches more than one destination prefix advertised within an area, we follow the route with the longest matching prefix.
With source/destination routes, as noted in [I-D.baker-rtgwg-src-dst-routing-use-cases], we follow a similar but slightly different rule; the FIB lookup MUST yield the route with the longest matching destination prefix that also matches the source prefix constraint. In the event of a tie on the destination prefix, it MUST also match the longest matching source prefix among those options.
An example of the issue is this. Suppose we have two routes:
and a packet
If we require the algorithm to follow the longest destination match without regard to the source, the destination address matches 2001:db8:3:3::/64 (the first route), and the source address doesn't match the constraint of the first route; we therefore have no route. The FIB algorithm, in this example, must therefore match the second route, even though it is not the longest destination match, because it also matches the source address.
As outlined in Section 2, this document specifies the use of separate topologies for Multi Topology Routing to carry Destination/Source routing information. These topologies form pairs with a base topology each as follows:
base base D/S designated usage MTID MTID ---------------------------------- default topology 0 TBD-MT0 IPv4 management 1 n/a IPv6 default 2 TBD-MT2 IPv4 multicast 3 n/a IPv6 multicast 4 n/a IPv6 management 5 TBD-MT5
Figure 1: Destination/Source Routing MTIDs
The rationale for in-/excluding base MTIDs to provide a D/S MTID for is as follows:
Note that the different topology ID is the sole and only mechanism of both capability detection and backwards compatibility. D/S routing will operate correctly if D/S routing information is put in the same topology as non-D/S information, but adding an IS that does not support D/S routing will then -undetectably- lead to incorrect routing decisions, possibly including loops.
Therefore, all routers participating in D/S routing MUST implement M-ISIS and participate in the appropriate D/S topology per the table above. Conversely, routers not supporting D/S routing (or not configured to participate) MUST NOT participate in these topologies. Even installations that previously used only MTID 0 (i.e. no M-ISIS) would need to start using M-ISIS on all D/S routers. This results in correct operation in the face of partial deployment of D/S routing.
Note it is implied by the separate topology that there is a separate SPF calculation for that topology - using only the participants of that topology - and D/S routes use paths according to the result from that calculation. This is an aspect of Multi-topology operation itself, not this document.
Routers MUST NOT advertise non-D/S routing information using a D/S-Routing MTID. This includes both reachability information with a source prefix TLV with value ::/0, as well as without a source prefix sub-TLV. On receipt, routers MUST ignore any reachability information in a D/S-Routing MTID that does not have non-default source prefix information.
To limit complexity, each IPv6 Reachability TLV in a D/S-Routing MTID MUST have exactly one Source Prefix sub-TLV. Routers MUST NOT advertise TLVs with more than one Source Prefix sub-TLV, and MUST ignore any received TLV with more than one Source Prefix sub-TLV.
Systems that use topology IDs different than the values reserved by IANA should apply the considerations from this section analogously.
The Multi-topology mechanism described in the previous section introduces a distinct, independently operating topology that covers D/S routers. This easily allows partial and incremental deployments.
Such deployments then contain one or more D/S "subdomains" of neighboring routers that have D/S routing capability. Since shortest paths for D/S routes are calculated using a separate topology, traffic routed on D/S routes will be forwarded inside such a subdomain until it reaches the router originating the reachability.
Routers unaware or not participating in D/S routing will in such a case forward traffic according to only non-D/S routes. This can produce 2 distinct outcomes:
Since the latter case provides no guarantee that there is no D/S route in the routing domain that could have matched, operators must pay careful attention to where non-D/S reachabilities are originated when more specific D/S routes are covered by them.
A very simple configuration that guarantees correct operation is to ensure covering destination-only reachabilities for D/S routes are originated by D/S routers themselves, and only by them. This results in traffic entering the D/S subdomain and D/S routes applying.
Lastly, in partial deployments, disconnected D/S subdomains may exist. Routers in such a subdomain cannot calculate a path for reachabilities in a subdomain they're not in. In this case a router MAY discard packets matching a D/S reachability for which it was unable to calculate a valid path. Alternatively, it MAY behave as if the D/S reachability didn't exist to begin with, i.e. routing the packet using the next less specific route (which could be D/S or non-D/S). It MUST NOT keep stale SPF calculation results that have become invalid as result of the topology partition.
This can be remediated by the operator adding connectivity between the subdomains, for example using some tunneling interface. The new link is then used to form an IS-IS adjacency fusing the previously split subdomains. The link will then be used to forward D/S traffic, possibly incurring some tunnel encapsulation overhead. To the IS-IS implementation, this link is no different from other links.
Destination/Source reachabilities are originated using TLV 237, using an additional sub-TLV to carry the source prefix as follows.
As noted in Section 2, any IPv6 Reachability TLV that does not specify a source prefix is functionally identical to specifying ::/0 as the source prefix. Such routes SHOULD NOT be originated into the D/S MTID, but rather into the base MTID.
The following Sub-TLV is defined for TLV 237:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Prefix Length | Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Prefix Sub-TLV
This Sub-TLV MUST occur exactly once in all reachability originated in any of the D/S topologies listed in Figure 1. A reachability in these topologies with the Sub-TLV either missing or present more than once MUST be ignored in its entirety.
IANA is requested to allocate Values from the "IS-IS Multi-Topology ID Values" registry as follows:
Additionally, IANA is requested to allocate an IS-IS codepoint from the "Sub-TLVs for TLVs 135, 235, 236, and 237" registry:
The same injection and resource exhaustion attack scenarios as with all routing protocols apply.
Security considerations from [I-D.ietf-rtgwg-dst-src-routing] are particularly relevant to this document, in particular the possibility to inject (more) specific routes to hijack traffic.
No privacy considerations apply to this document, as it only specifies routing control plane information.
Thanks to Les Ginsberg, Chris Hopps, Acee Lindem, Chris Bowers and Tony Przygienda for valuable feedback on this document. (TODO: incomplete, and sort by name.)
| [I-D.ietf-rtgwg-dst-src-routing] | Lamparter, D. and A. Smirnov, "Destination/Source Routing", Internet-Draft draft-ietf-rtgwg-dst-src-routing-06, October 2017. |
| [IS-IS] | ISO/IEC, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, 2002. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5120] | Przygienda, T., Shen, N. and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008. |
| [RFC5308] | Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008. |
| [RFC8200] | Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017. |
| [I-D.baker-rtgwg-src-dst-routing-use-cases] | Baker, F., Xu, M., Yang, S. and J. Wu, "Requirements and Use Cases for Source/Destination Routing", Internet-Draft draft-baker-rtgwg-src-dst-routing-use-cases-02, April 2016. |
While Multi-Topology routing in general can be assumed to work correctly when used on its own, this may not apply to a scenario mixing route calculation results as suggested in this document. However, this specific application is easily understandable as correct:
The compatibility mechanics thus rest on 2 pillars:
Note that the latter assumption holds true even if D/S routers fall back to non-D/S paths if they cannot calculate a shortest path towards the advertising system (either because SPF reaches the maximum path metric, or because there are multiple discontiguous D/S subdomains). This is because if a router A receives a packet routed on a D/S path, this implies the previous router B was able to successfully calculate SPF, via A, and that A has a path towards the originating system with a lower path metric than B. Conversely, if router A is unable to find a valid path, it is safe to assume router B was unable to do so either, and B forwarded the packet on a path calculated on non-D/S information.
Lastly, in terms of application use cases, it is also worth pointing out that loops will always result if (for example on a boundary to an upstream) the prefix routed incoming to the IS-IS domain is not fully covered by routes. Just as in non-D/S routing, this may cause a less specific (default) route to apply and loop packets back onto the same upstream. With D/S routing, this can now also occur if the incoming prefix is not covered for all sources. The solution remains the same: making sure the entire prefix is covered (for all sources), usually with a discard route. This is not an IS-IS consideration.
(to be removed)