One document matched: draft-baker-ipv6-ospf-dst-src-routing-03.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-ospf-dst-src-routing-03"
ipr="trust200902">
<front>
<title abbrev="OSPF Source/Destination Routing">IPv6 Source/Destination
Routing using OSPFv3</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/>
<area>Routing</area>
<workgroup>OSPF</workgroup>
<abstract>
<t>This note describes the changes necessary for OSPFv3 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>
-->
<?rfc needLines="5" ?>
<section title="Introduction">
<t>This specification builds on <xref target="RFC5340">OSPF for
IPv6</xref> and the extensible LSAs defined in <xref
target="I-D.acee-ospfv3-lsa-extend"/>. It defines the 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>
<?rfc needLines="5" ?>
<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 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".</t>
<t>LSAs that lack a source prefix 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-ospf-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>
<?rfc needLines="5" ?>
<section title="Extensions necessary for IPv6 Source/Destination Routing in OSPFv3">
<t>The extensible LSA format defined in <xref
target="I-D.acee-ospfv3-lsa-extend"/> requires one additional option to
accomplish source/destination routing: the source prefix. This is
defined here. As noted in <xref target="extensions"/>, any prefix LSA
that does not specify a source prefix is understood to as specifying
::/0 as the source prefix.</t>
<?rfc needLines="20" ?>
<section anchor="OSPFv3-IPv6-source" title="IPv6 Source Prefix TLV">
<figure title="Source Prefix 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Type:">assigned by IANA</t>
<t hangText="TLV Length:">Length of the value portion of the TLV
in octets. This is by definition 20.</t>
<t
hangText="PrefixLength, PrefixOptions, and Address Prefix:">Representation
of an IPv6 address prefix, as described in <xref
target="RFC5340"/> Appendix A.4.1</t>
</list></t>
</section>
</section>
<?rfc needLines="5" ?>
<section anchor="IANA" title="IANA Considerations">
<t>As discussed in <xref target="I-D.acee-ospfv3-lsa-extend"/>, the IPv6
Source Prefix TLV code should be allocated from the OSPFv3 IANA
registry.</t>
</section>
<?rfc needLines="5" ?>
<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>
<?rfc needLines="5" ?>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Acee Lindem contributed to the concepts in this draft.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2460" ?>
<?rfc include="reference.RFC.5340" ?>
<?rfc include="reference.I-D.acee-ospfv3-lsa-extend" ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.baker-rtgwg-src-dst-routing-use-cases"?>
<?rfc include="reference.I-D.baker-ipv6-ospf-dst-flowlabel-routing"?>
</references>
<?rfc needLines="5" ?>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">February 2013</t>
<t hangText="First revision:">April 2013</t>
<t hangText="Correction:">Corrected the reference to <xref
target="I-D.acee-ospfv3-lsa-extend"/></t>
<t hangText="Use Case:">Remove appendices, clarify the discussion of
ambiguity and refer to <xref
target="I-D.baker-rtgwg-src-dst-routing-use-cases"/></t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:36:22 |