One document matched: draft-baker-ipv6-isis-dst-src-routing-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents, but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="4"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc rfcprocack="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-baker-ipv6-isis-dst-src-routing-05"
ipr="trust200902">
<front>
<title abbrev="IS-IS Source/Destination Routing">IPv6 Source/Destination
Routing using IS-IS</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street/>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<author fullname="David Lamparter" initials="D." surname="Lamparter">
<organization>NetDEF</organization>
<address>
<postal>
<street/>
<city>Leipzig</city>
<code>04229</code>
<region></region>
<country>Germany</country>
</postal>
<email>david@opensourcerouting.org</email>
</address>
</author>
<date day="17" month="April" year="2016" />
<area>Internet Engineering Task Force</area>
<workgroup/>
<abstract>
<t>This note describes the changes necessary for IS-IS to route IPv6
traffic from a specified prefix to a specified prefix.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This specification defines how to exchange <xref
target="I-D.ietf-rtgwg-dst-src-routing">destination/source
routing</xref> information in <xref target="RFC5308">IS-IS for
IPv6</xref> routing environments. To this extent, a new sub-TLV for
an <xref target="RFC2460">IPv6</xref> Source Prefix is added, and
<xref target="RFC5120">Multi Topology Routing</xref> is employed to
address compatibility and isolation concerns.</t>
<t>The router MUST implement the Destination/Source Routing mechanism
described in <xref target="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 <xref
target="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.</t>
<?rfc needLines="5" ?>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119"/>.</t>
</section>
</section>
<section anchor="routing" title="Theory of Routing">
<t>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.</t>
<t>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".</t>
<t>TLVs that lack a source prefix sub-TLV match any source address
(i.e., the source prefix TLV defaults to ::/0), by definition.</t>
<t>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.</t>
<t>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.</t>
<?rfc needLines="5" ?>
<section title="Notation">
<t>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.</t>
</section>
<?rfc needLines="5" ?>
<section title="Dealing with ambiguity">
<t>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.</t>
<t>With source/destination routes, as noted in <xref
target="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.</t>
<t>An example of the issue is this. Suppose we have two routes: <list
style="numbers">
<t>2001:db8:1::/48 -> 2001:db8:3:3::/64</t>
<t>2001:db8:2::/48 -> 2001:db8:3::/48</t>
</list></t>
<t>and a packet <list style="empty">
<t>2001:db8:2::1 -> 2001:db8:3:3::1</t>
</list></t>
<t>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.</t>
</section>
<?rfc needLines="5" ?>
<section title="Multi-topology Routing">
<t>As outlined in <xref target="routing"/>, this document specifies the
use of separate topologies for <xref target="RFC5120">Multi Topology
Routing</xref> to carry Destination/Source routing information.
These topologies form pairs with a base topology each as follows:</t>
<figure title="Destination/Source Routing MTIDs">
<artwork align="left"><![CDATA[
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
]]></artwork></figure>
<t>The rationale for in-/excluding base MTIDs to provide a D/S MTID for
is as follows:</t>
<t><list style="hanging">
<t hangText="MTID 0:">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.
</t>
<t hangText="MTIDs 1 and 3:">Topologies with MTID 1 and 3 carry
exclusively IPv4 reachabilities. Thus, no IPv6 D/S topology is
created to associate with them.</t>
<t hangText="MTID 2:">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.</t>
<t hangText="MTID 4:">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.</t>
<t hangText="MTID 5:">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.</t>
</list></t>
<t>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.</t>
<t>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.</t>
<t>Systems that use topology IDs different than the values reserved by
IANA should apply the considerations from this section
analogously.</t>
</section>
</section>
<section anchor="new-tlvs"
title="Protocol encoding for IPv6 Source Prefix information">
<t>Destination/Source reachabilities are originated using TLV 237, using
an additional sub-TLV to carry the source prefix as follows.</t>
<t>As noted in <xref target="routing"/>, 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.</t>
<section anchor="IS-IS-source" title="Source Prefix sub-TLV">
<?rfc needLines="10"?>
<t>The following Sub-TLV is defined for TLV 237:</t>
<figure title="Source Prefix Sub-TLV">
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Source Prefix Type:">TBD-TLV (assigned by IANA)</t>
<t hangText="TLV Length:">Length of the sub-TLV in octets</t>
<t hangText="Prefix Length:">Length of the prefix in bits</t>
<t hangText="Prefix:">(source prefix length+7)/8 octets of
prefix</t>
</list></t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA is requested to allocate Values from the "IS-IS Multi-Topology ID Values" registry as follows:</t>
<t><list style="hanging">
<t hangText="TBD-MT0:">IPv6 Dest/Source routing corresponding to topology 0</t>
<t hangText="TBD-MT2:">Reserved for IPv6 Dest/Source routing corresponding to topology 2</t>
<t hangText="TBD-MT5:">Reserved for IPv6 Dest/Source routing corresponding to topology 5</t>
</list></t>
<t>Additionally, IANA is requested to allocate an IS-IS codepoint from
the "Sub-TLVs for TLVs 135, 235, 236, and 237" registry:</t>
<t><list style="hanging">
<t hangText="Type:">TBD-TLV</t>
<t hangText="Description:">IPv6 SADR Source Prefix</t>
<t hangText="Applicable to TLV 237:">Yes</t>
<t hangText="Applicable to TLVs 135, 235, 236:">No</t>
</list></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The same injection and resource exhaustion attack scenarios as with
all routing protocols apply.</t>
<t>Security considerations from <xref
target="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.</t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>No privacy considerations apply to this document, as it only specifies
routing control plane information.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Les Ginsberg, Chris Hopps and Acee Lindem for valuable
feedback on this document. (TODO: incomplete.)</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<reference anchor="IS-IS">
<front>
<!-- [IS-IS] ISO/IEC 10589:2002, Second Edition, "", 2002. -->
<title>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)</title>
<author>
<organization>ISO/IEC</organization>
</author>
<date year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
</reference>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460" ?>
<?rfc include="reference.RFC.5120" ?>
<?rfc include="reference.RFC.5308" ?>
<?rfc include="reference.I-D.ietf-rtgwg-dst-src-routing"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.baker-rtgwg-src-dst-routing-use-cases"?>
<?rfc include="reference.I-D.baker-ipv6-isis-dst-flowlabel-routing"?>
</references>
<section title="Correctness considerations">
<t>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:</t>
<t><list>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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).</t>
</list></t>
<t>The compatibility mechanics thus rest on 2 pillars:
<list>
<t>D/S routes will match as more specific if applicable</t>
<t>Packets will transit into D/S routing but not out of it</t>
</list></t>
</section>
<section anchor="log" title="Change Log">
<t>(to be removed)</t>
<t><list style="hanging">
<t hangText="Initial Version:">February 2013</t>
<t hangText="updated Version:">August 2013</t>
<t hangText="Added MTR:">August 2014</t>
<t hangText="Split into 4 drafts:">October 2014</t>
<t hangText="Dropped 'Critical Sub-TLV' drafts">June 2015</t>
<t hangText="MT clarifications">October 2015</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:37:54 |