IPv6 Source/Destination
Routing using IS-ISCisco SystemsSanta Barbara93117CaliforniaUSAfred@cisco.comNetDEFLeipzig04229Germanydavid@opensourcerouting.org
Internet Engineering Task Force
This note describes the changes necessary for IS-IS to route IPv6
traffic from a specified prefix to a specified prefix.This specification defines how to exchange destination/source
routing information in IS-IS for
IPv6 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 .
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 . 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 .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 , 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: 2001:db8:1::/48 -> 2001:db8:3:3::/642001:db8:2::/48 -> 2001:db8:3::/48and a packet 2001:db8:2::1 -> 2001:db8:3:3::1If 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 , 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:The rationale for in-/excluding base MTIDs to provide a D/S MTID for
is as follows:The base (non-MTR) topology in some
installations carries all routing information, including IPv6
reachabilities. In such a setup, the topology with MTID TBD-MT0
is used to carry associated D/S reachabilities.
Topologies with MTID 1 and 3 carry
exclusively IPv4 reachabilities. Thus, no IPv6 D/S topology is
created to associate with them.The topology with MTID 2 carries IPv6
reachabilities in common M-ISIS setups. (MTID 0 in such cases
carries exclusively IPv4 reachability information.) Associated
IPv6 D/S reachabilities MUST be carried in MTID TBD-MT2.MTID 4, while carrying IPv6 connectivity
information, is used for multicast RPF lookups. Since
Destination/Source routing is not compatible with multicast
RPF lookups, no associated D/S MTID is defined for IS-IS.An alternate management/administration
topology may carry its routing information in MTID 5.
Destination/Source routing is applicable to this and MUST use
MTID TBD-MT5 to carry associated reachability TLVs.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.As this compatibility mechanism is not considered optional, M-ISIS
MUST therefore be implemented for supporting the protocol outlined in
this document. Even installations that previously used only MTID 0
(i.e. no M-ISIS) would need to start using MTID TBD-MT0.Systems that use topology IDs different than the values reserved by
IANA should apply the considerations from this section
analogously.Destination/Source reachabilities are originated using TLV 237, using
an additional sub-TLV to carry the source prefix as follows.As noted in , 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:TBD-TLV (assigned by IANA)Length of the sub-TLV in octetsLength of the prefix in bits(source prefix length+7)/8 octets of
prefixIANA is requested to allocate Values from the "IS-IS Multi-Topology ID Values" registry as follows:IPv6 Dest/Source routing corresponding to topology 0Reserved for IPv6 Dest/Source routing corresponding to topology 2Reserved for IPv6 Dest/Source routing corresponding to topology 5Additionally, IANA is requested to allocate an IS-IS codepoint from
the "Sub-TLVs for TLVs 135, 235, 236, and 237" registry:TBD-TLVIPv6 SADR Source PrefixYesNoThe same injection and resource exhaustion attack scenarios as with
all routing protocols apply.Security considerations from 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 and Acee Lindem for valuable
feedback on this document. (TODO: incomplete.)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/IECWhile 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:Systems that do not implement D/S routing will not participate in
the D/S topology. They will calculate SPF in the base topology.
Packets routed by such system will either (a) cross only non-D/S
routers and reach the last hop as intended, or (b) cross a D/S
router at some point.For case (b), the D/S router may (b1) or may not (b2) have a more
specific D/S route. In case (b2), packets will be routed based on
the same decisions that a non-D/S system would apply, so they will
reach their last hop without any differences.For case (b1), a break in forwarding behaviour happens for packets
as they hit the first D/S-capable router, possibly after traversing
some non-D/S systems. That router will apply D/S routing - which,
since the path calculation is performed in the D/S topology, means
that the packet is from there on routed on a path that only
contains D/S capable systems. It will thus reach the D/S last hop
as intended.Packets starting out on a D/S-capable router fall into cases (b1)
or (b2) as if a non-D/S router routed them first.If, for case (b1), the system knows of the existence of a more
specific D/S route, but cannot calculate a valid path, it may
either apply non-D/S routing (i.e. not install any route) or
discard the packet (i.e. install a discard route). The next hop
will either be a non-D/S system, or a D/S system with the same
link-state information (and thus again unable to calculate a valid
path -- or, more specifically, won't calculate a path that includes
the previous router).The compatibility mechanics thus rest on 2 pillars:
D/S routes will match as more specific if applicablePackets will transit into D/S routing but not out of it(to be removed)February 2013August 2013August 2014October 2014June 2015October 2015