One document matched: draft-baker-ipv6-isis-dst-src-routing-01.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-01"
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>
<date year="2013"/>
<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>
<!--
<note title="Foreword">
</note>
-->
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section title="Introduction">
<t>This specification builds on <xref target="RFC5308">IS-IS for
IPv6</xref> and its extensible TLV. This note defines the sub-TLV for
an <xref target="RFC2460">IPv6</xref> Source Prefix, to define routes
from a source prefix to a destination prefix.</t>
<t>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 <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="extensions" 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>LSAs that lack a source prefix sub-TLV match any source address
(i.e., the source prefix TLV defaults to ::/0), by definition.</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="Interactions with other constraints">
<t>In the event that there are other constraints on routing, such as
proposed in <xref
target="I-D.baker-ipv6-isis-dst-flowlabel-routing"/>, 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.</t>
</section>
</section>
<section anchor="IS-IS-extensions-ipv6" title="Extensions necessary for IPv6 Source/Destination Routing in IS-IS">
<t>Section 2 of <xref target="RFC5308"/> defines the "IPv6
Reachability TLV", and carries in it destination prefix
advertisements. It has the capability of extension, using
sub-TLVs.</t>
<t>We define the Source Prefix Sub-TLV as in <xref
target="IS-IS-source"/>. As noted in <xref target="extensions"/>, any
IPv6 Reachability TLV that does not specify a source prefix is
understood to as specifying ::/0 as the source prefix.</t>
<section anchor="IS-IS-source" title="Source Prefix sub-TLV">
<?rfc needLines="10"?>
<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:">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>The source prefix type mentioned in <xref
target="IS-IS-extensions-ipv6"/> must be defined.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t/>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.ISO.10589.1992" ?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460" ?>
<?rfc include="reference.RFC.5308" ?>
</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 anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">February 2013</t>
<t hangText="updated Version:">August 2013</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:38:08 |