IPv6 Source/Destination
Routing using OSPFv3Cisco SystemsSanta Barbara93117CaliforniaUSAfred@cisco.com
Routing
OSPFThis note describes the changes necessary for OSPFv3 to route IPv6
traffic from a specified prefix to a specified prefix. This specification builds on OSPF for
IPv6 and the extensible LSAs defined in . It defines the TLV for an IPv6 Source Prefix, to define routes from a
source prefix to a destination prefix.This implies not simply routing "to a destination", but routing "to
that destination AND from a specified source". It may be combined with
other qualifying attributes, such as "traffic going to that destination
AND using a specified flow label AND from a specified source prefix".
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 LSAs in the LSDB
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".LSAs that lack a source prefix TLV match any source address (i.e.,
the source prefix TLV defaults to ::/0), by definition.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.In the event that there are other constraints on routing, such as
proposed in , the effect is a
logical AND. The FIB lookup must yield the route with the longest
matching destination prefix that also matches each of the
constraints.The extensible LSA format defined in requires one additional option to
accomplish source/destination routing: the source prefix. This is
defined here. As noted in , any prefix LSA
that does not specify a source prefix is understood to as specifying
::/0 as the source prefix.assigned by IANALength of the value portion of the TLV
in octets. This is by definition 20.Representation
of an IPv6 address prefix, as described in Appendix A.4.1As discussed in , the IPv6
Source Prefix TLV code should be allocated from the OSPFv3 IANA
registry.While source/destination routing could be used as part of a security
solution, it is not really intended for the purpose. The approach limits
routing, in the sense that it routes traffic to an appropriate egress,
or gives a way to prevent communication between systems not included in
a source/destination route, and in that sense could be considered
similar to an access list that is managed by and scales with
routing.Acee Lindem contributed to the concepts in this draft.February 2013April 2013Corrected the reference to Remove appendices, clarify the discussion of
ambiguity and refer to