One document matched: draft-lamparter-rtgwg-dst-src-routing-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-dst-src-routing-00"
ipr="trust200902">
<front>
<title abbrev="Destination/Source Routing">
Destination/Source Routing</title>
<author fullname="David Lamparter" initials="D." surname="Lamparter">
<organization>NetDEF</organization>
<address>
<postal>
<street></street>
<city>Leipzig</city>
<code>04103</code>
<region></region>
<country>Germany</country>
</postal>
<email>david@opensourcerouting.org</email>
</address>
</author>
<date year="2014" />
<area>Routing</area>
<workgroup>rtgwg</workgroup>
<abstract>
<t>This note specifies using packets' source addresses in route lookups
as additional qualifier per <xref target="extra-qualifiers"/>, as
applicable to <xref target="RFC2460">IPv6</xref> without specific
considerations for any routing protocol.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Since connectivity providers generally secure their ingress along
the lines of <xref target="RFC2827">BCP 38</xref>,
small multihomed networks have a need to ensure their traffic
leaves their network with a correct combination of source address and
exit taken. This applies to networks of a particular pattern where
the provider's default (dynamic) address provisioning methods are used
and no fixed IP space is allocated, e.g. home networks, small business
users and mobile ad-hoc setups.</t>
<t>While IPv4 networks would conventionally use NAT or policy routing to
produce correct behaviour, this not desirable to carry over to IPv6.
Instead, assigning addresses from multiple prefixes in parallel shifts
the choice of uplink to the host. However, now for finding the proper
exit the source address of packets must be taken into account.</t>
<t>For a general introduction and aspects of interfacing routers to
hosts, refer to <xref target="I-D.sarikaya-6man-sadr-overview"/>.</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="Principle of operation">
<t>The mechanism in this document is such that a source prefix is added
to all route entries. This document assumes all entries have a source
prefix, with ::/0 as default value for entries installed without a
specified source prefix. This need not be implemented in this
particular way, however the system MUST behave exactly as if it were.
In particular, a difference in behaviour between routes with a source
prefix of ::/0 and routes without source prefix MUST NOT be visible.
</t>
<t>For uniqueness considerations, the source prefix factors MUST be
taken into account for comparisons. Two routes with identical
information except the source prefix MAY exist and MUST be installed
and matched.</t>
<section title="Lookup ordering and disambiguation">
<t>As outlined in <xref target="extra-qualifiers"/>, there is a fixed
longest-match ordering dor route lookup.</t>
<t>For longest-match lookups, the source prefix is matched after the
destination prefix. This is to say, first the longest matching
destination prefix is found, then the table is searched for the route
with the longest source prefix match, while only considering routes
with exactly the destination prefix previously found. If and only if
no such route exists (because none of the source prefixes match), the
lookup moves to the next less specific destination prefix.</t>
<t>A router MUST continue to a less specific destination prefix if no
route matches on the source prefix. It MUST NOT terminate lookup
on such an event.</t>
</section>
</section>
<section title="Applicability">
<section title="Recursive Route Lookups">
<!-- XXX V - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<t>TBD, multiple possible approaches:</t>
<t><list style="hanging">
<t>variant 1: ignore dst-src routes, only use routes with src ::/0</t>
<t>variant 2: exact-match src prefixes from resolvee to resolvent (will not work for a lot of cases)</t>
<t>variant 3: longer-match src prefixes from resolvee to resolvent (nexthop src may be superset of looked-up route)</t>
<t>variant 4: create multiple instances of the route whose nexthop is resolved,
with different source prefixes</t>
</list></t>
<!-- XXX A - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<t>(Variant 4:)</t>
<t>When doing recursive nexthop resolution, the route that is being
resolved is installed in potentially multiple copies, inheriting all
possible more-specific routes that match the nexthop as
destination. The algorithm to do this is:</t>
<t><list style="numbers">
<t>form the set of attributes for lookup by using the (unresolved,
recursive) nexthop as destination (with full host prefix length,
i.e. /128), copy all other attributes from the original route</t>
<t>find all routes that overlap with this set of attributes
(including both more-specific and less-specific routes)</t>
<t>order the result from most to less specific</t>
<t>for each route, install a route using the original route's
destination and the "logical and" overlap of each extra match
attribute with same attribute from the set. Copy nexthop data
from the route under iteration. Then, reduce the set of extra
attributes by what was covered by the route just installed
("logical AND NOT").</t>
</list></t>
<figure><preamble>Example recursive route resolution</preamble>
<artwork>
route to be resolved:
2001:db8:1234::/48, source 2001:db8:3456::/48,
recursive nexthop via 2001:db8:abcd::1
routes considered for recursive nexthop:
::/0, via fe80::1
2001:db8:abcd::/48, via fe80::2
2001:db8:abcd::/48, source 2001:db8:3456:3::/64, via fe80::3
2001:db8:abcd::1/128, source 2001:db8:3456:4::/64, via fe80::4
recursive resolution result:
2001:db8:1234::/48, source 2001:db8:3456::/48, via fe80::2
2001:db8:1234::/48, source 2001:db8:3456:3::/64, via fe80::3
2001:db8:1234::/48, source 2001:db8:3456:4::/64, via fe80::4
</artwork>
</figure>
</section>
<section title="Unicast Reverse Path Filtering">
<t>Unicast reverse path filtering MUST use dst-src routes analog to its
usage of destination-only routes. However, the system MAY match
either only incoming source against routes' destinations, or it MAY
match source and destination against routes' destination and
source. It MUST NOT ignore dst-src routes on uRPF checks.</t>
</section>
<section title="Multicast Reverse Path Forwarding">
<t>Multicast Reverse Path Lookups are used to find paths towards the
(known) sender of multicast packets. Since the destination of these
packets is the multicast group, it cannot be matched against the
source part of a dst-src route. Therefore, dst-src routes MUST be
ignored for Multicast RPF lookups.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document updates the "Routing Qualifier Registry" described in
<xref target="extra-qualifiers"/>. The following entry is added:</t>
<t><list style="hanging">
<t>Name: IPv6 Source Address</t>
<t>Applicable Protocols: IPv6</t>
<t>Reference: this document</t>
<t>Position: after IPv6 Destination Address, before end of list</t>
</list></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Systems operating under the principles of this document can have
routes that are more specific than the previously most specific, i.e.
host routes. This can be a security concern if an operator was relying
on the impossibility of hijacking such a route.</t>
<!-- from draft-baker-ipv6-dst-src-routing -->
<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="Privacy" title="Privacy Considerations">
<t>If a host's addresses are known, injecting a dst-src route allows
isolation of traffic from that host, which may compromise privacy.
However, this requires access to the routing system. As with similar
problems with the destination only, defending against it is left to
general mechanisms protecting the routing infrastructure.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The base underlying this document was first outlaid by Ole Troan and
Lorenzo Colitti in <xref target="I-D.troan-homenet-sadr"/> for application in the
homenet area.</t>
<t>This document is largely the result of discussions with Fred Baker and
derives from <xref target="I-D.baker-ipv6-isis-dst-src-routing"/>.</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"?>
<!-- draft-lamparter-rtgwg-routing-discriminators-00.xml -->
<reference anchor="extra-qualifiers"><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/>
<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, augmenting longest match behaviour.</t>
</abstract>
</front>
</reference>
<!-- draft-lamparter-rtgwg-routing-discriminators-00.xml -->
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2827"?>
<?rfc include="reference.I-D.sarikaya-6man-sadr-overview"?>
<?rfc include="reference.I-D.troan-homenet-sadr"?>
<?rfc include="reference.I-D.baker-ipv6-isis-dst-src-routing"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:43:13 |