One document matched: draft-lamparter-rtgwg-routing-extra-qualifiers-00.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="yes" ?>
<!-- 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/sections... 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-lamparter-rtgwg-routing-extra-qualifiers-00"
ipr="trust200902">
<front>
<title abbrev="Extending IP route lookup">
Considerations and Registry for extending IP route lookup</title>
<author fullname="David Lamparter" initials="D." surname="Lamparter">
<organization>NetDEF</organization>
<address>
<postal>
<street/>
<city>Leipzig</city>
<code>04103</code>
<region></region>
<country>Germany</country>
</postal>
<email>david@opensourcerouting.org</email>
</address>
</author>
<date/>
<area>Routing</area>
<workgroup>rtgwg</workgroup>
<abstract>
<t>This document describes the behaviour of a routing system that
takes additional specifications on routes--extra qualifiers--into
account on a hop-by-hop basis, augmenting longest match behaviour.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>IP Routing systems at the time of creation of this document are
occasionally already capable of matching more than the packet's
destination addresses to lookup routes, preexisting patterns include
virtual routers (i.e. keying by routing instance), QoS-aware routing
(keying by DSCP bits) and the relatively unspecific "policy routing."
</t>
<t>Additional developments extend this field to the point where a lack
of well-defined specification may lead to interoperability problems.
The intent of this document is to construct a reference framework for
extensions on the match aspect of IP routes.</t>
<t>Specifically, since IP Routing includes longest-match route selection,
the ordering of all match qualifiers must be the same among all routers
to prevent loops or connectivity loss.</t>
<t>While this document is written with IPv6 in mind, it applies to IP
router architecture in general, including IPv4 routers.</t>
<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"></xref>.</t>
</section>
</section>
<section title="Applicability">
<t>While the conceptually same longest-prefix routing is used not only
for routing packets, but also recursive route/nexthop lookups,
multicast reverse path forwarding and unicast reverse path filtering.
However, while based on the same base principle, these applications
may differ in their requirements. For example, multicast RPF cannot
use source address discriminators since no source address is known at
the time of lookup.</t>
<t>The intent of this specification is only to provide a basic framework;
individual extensions to route match behaviour MUST clarify their
respective applicability.</t>
</section>
<section title="Match criteria (informational)">
<section title="Virtual routers">
<t>While not documented to this extent, an implementation capable of
partitioning a physical router into multiple virtual routers is an
application that essentially has the virtual router identifier as
first key in lookup operations. This may not be implemented as such,
for example by keeping tables completely separate, however the end
behaviour is the same; lookups are made local to the router
instance.
</t>
</section>
<section title="Policy routing">
<t>Equally little specified as virtual routers, policy routing usually
applies certain qualifiers (source address, traffic class, firewall
markers) prior to destination address match.
</t>
</section>
<section title="Destination address longest match">
<t>The conventional destination IP address longest match is included
at this point as it is, barring implementation specific extensions
mentioned above, the first qualifier used to match packets against
the route table.</t>
</section>
<section title="Source address longest match">
<t>Currently under development, matching on the source address permits
routers to choose the correct (in terms of <xref target="RFC2827" />)
exit in smaller multihomed networks. This is distinct from policy
routing in that only few select (usually default) routes would be
annotated with source prefixes.</t>
<t>Various aspects of this are described in:</t>
<t><list style="hanging">
<t><xref target="I-D.troan-homenet-sadr"/></t>
<t><xref target="I-D.boutier-homenet-source-specific-routing"/></t>
<t><xref target="I-D.sarikaya-6man-sadr-overview"/></t>
<t><xref target="I-D.baker-rtgwg-src-dst-routing-use-cases"/></t>
<t><xref target="I-D.baker-ipv6-isis-dst-src-routing"/></t>
<t><xref target="I-D.baker-ipv6-ospf-dst-src-routing"/></t>
<t><xref target="I-D.baker-rtgwg-src-dst-routing-use-cases"/></t>
</list></t>
</section>
<section title="Flowlabel routing">
<t>TBD, described in:</t>
<t><list style="hanging">
<t><xref target="I-D.baker-ipv6-isis-dst-flowlabel-routing" /></t>
<t><xref target="I-D.baker-ipv6-ospf-dst-flowlabel-routing" /></t>
</list></t>
</section>
<section title="QoS/DSCP traffic class based routing">
<t>TBD (deprecated, reference only)</t>
</section>
</section>
<section title="Requirements to extending match behaviour">
<section title="Match ordering">
<t>Adding further criteria to be looked up when forwarding packets on
a hop-by-hop basis has the very fundamental requirement that all
routers behave the same way in choosing the most specific route when
there are multiple eligible routes.</t>
<t>This document disambiguates this situation by recording the order of
specificness in a registry. This means that the comparison for "more
specific", here indicated by A < B (to mean A is more specific
than B), is redefined as concatenation for attributes a, b, c as:</t>
<figure><artwork><![CDATA[
A < B := Aa < Ba
|| (Aa == Ba && Ab < Bb)
|| (Aa == Ba && Ab == Bb && Ac < Bc )
]]>
</artwork>
</figure>
<t>This transfers to a sample situation (using source address,
destination address and flowlabel as qualifiers):</t>
<figure><preamble>Example route table</preamble>
<artwork>
destination source flowlabel
route A: 2001:db8::/32
route B: 2001:db8:1234::/48 2001:db8:4567::/48
route C: 2001:db8:1234::/48 abcde
route D: 2001:db8:1234:5678::/64 2001:db8:4567::/48 abcde
route E: 2001:db8:1234:5678::/64
</artwork>
</figure>
<t>Showing the different results between "destination, source,
flowlabel" ("DSF") and "destination, flowlabel, source" ("DFS")
ordering:</t>
<figure><preamble>Example match results</preamble>
<artwork>
packet to be routed result
# destination source flowlabel "DSF" "DFS"
1 2001:db8::1 2001:db8:4567::1 abcde A A
2 2001:db8:1234::1 2001:db8:4567::1 abcde B C
3 2001:db8:1234::1 2001:db8:4567::1 11111 B B
4 2001:db8:1234::1 2001:db8:1111::1 abcde C C
5 2001:db8:1234::1 2001:db8:1111::1 11111 A A
6 2001:db8:1234:5678::1 2001:db8:4567::1 abcde D D
7 2001:db8:1234:5678::1 2001:db8:4567::1 11111 E E
8 2001:db8:1234:5678::1 2001:db8:1111::1 abcde E E
</artwork>
</figure>
<t>It should be noted that lookup may not result in usage of the most
specific element even for the first attribute (destination in the
example). As displayed in #5 above, the route used is the most
specific one that satisfies all conditions. If a system cannot "back
out" to less specific matches on earlier attributes, this MUST be
worked around by installing synthetic routes for these cases.</t>
</section>
<section title="Compatibility / Interoperability">
<t>Since a router implementing extra match qualifiers can have
additional, more specific routes than one that doesn't implement
these qualifiers, persistent loops can form between these systems.
To prevent this from happening, a simple rule must be followed:</t>
<t>The set of qualifiers used to route a particular packet MUST be a
subset of the qualifiers supported by the next hop.</t>
<t>This means in particular that a router using extra qualifier A MUST
NOT route packets based on a route that checks this qualifier to a
system that doesn't support qualifier A (and hence doesn't understand
the route).</t>
<t>There are 3 possible approaches to avoid such a condition:</t>
<t><list style="numbers">
<t>discard the packet (treat as destination unreachable)</t>
<t>calculate an alternate topology including only routers that
support qualifier A</t>
<t>if the lookup returns the same nexthop without using qualifier
A, use that result (i.e., the nexthop is known to correctly route
the packet)</t>
</list></t>
<t>Above considerations require under all circumstances a knowledge of
the next router's capabilities. For routing protocols based on
hop-by-hop flooding (RIP <xref target="RFC2080" />, BGP <xref
target="RFC4271" />), knowing the peer's capabilities - or simply
relying on systems to only flood what they understand - is
sufficient. Protocols building a link-state database (OSPF <xref
target="RFC5340" />, IS-IS <xref target="RFC5308" />) have the
additional opportunity to calculate alternate paths based on
knowledge of the entire domain, but cannot rely on routers flooding
only link state they support themselves.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requests creation of a new registry called the
"Routing Qualifier Registry." The registry consists of an ordered
list of items, no identifier value needs to be assigned. The only
purpose of the registry is to document the order in which qualifiers
are evaluated.</t>
<t>Registry items must specify the following information:
<list style="symbols">
<t>Name of the qualifier</t>
<t>Applicable protocols (IP version 4 and/or IP version 6)</t>
<t>Specification reference (possibly distinct between IPv4 and IPv6)</t>
<t>Insertion position, listing both the previous and next entry to avoid
confusion</t>
</list>
</t>
<t>The allocation policy per <xref target="RFC5226" /> is "IETF Review."
This is intended to help keep routing systems compatible with each
other.</t>
<section title="Initial list">
<t>The list is prepropagated with a single entry describing "classical"
destination-based routing:</t>
<t><list style="hanging">
<t>Name: Destination lookup</t>
<t>Applicable to IPv4 and IPv6</t>
<t>Specification references: <xref target="RFC4632" /> for IPv4,
<xref target="RFC2460" /> for IPv6</t>
</list></t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document specifies only the ordering of lookups. Making no
change to the existing situation, there are no security considerations
for this document.</t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>As with security considerations, no privacy considerations apply to
this document.</t>
<t>Introducing additional routing qualifiers has the potential to expose
information that was not previously visible, in particular if such
information would otherwise be scrubbed by a process like NAT.
However, these considerations are left for documents actually
introducing new routing qualifiers.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This document is largely the result of discussions with Fred Baker.</t>
<t>A lot of drafts exists in this general area, refer to the informative
references section below.</t>
</section>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">October 2014</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.4632"?>
<?rfc include="reference.RFC.5226"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2080"?>
<?rfc include="reference.RFC.2827"?>
<?rfc include="reference.RFC.4271"?>
<?rfc include="reference.RFC.5308"?>
<?rfc include="reference.RFC.5340"?>
<?rfc include="reference.I-D.troan-homenet-sadr"?>
<?rfc include="reference.I-D.boutier-homenet-source-specific-routing"?>
<?rfc include="reference.I-D.sarikaya-6man-sadr-overview"?>
<?rfc include="reference.I-D.baker-rtgwg-src-dst-routing-use-cases"?>
<?rfc include="reference.I-D.baker-ipv6-isis-dst-flowlabel-routing"?>
<?rfc include="reference.I-D.baker-ipv6-ospf-dst-flowlabel-routing"?>
<?rfc include="reference.I-D.baker-ipv6-isis-dst-src-routing"?>
<?rfc include="reference.I-D.baker-ipv6-ospf-dst-src-routing"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:58:16 |