One document matched: draft-baker-rtgwg-src-dst-routing-use-cases-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="3"?>
<!-- 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" ?>
<!-- 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="info" docName="draft-baker-rtgwg-src-dst-routing-use-cases-01"
ipr="trust200902">
<front>
<title abbrev="Source/Destination Routing">Requirements and Use Cases for
Source/Destination Routing</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/>
<abstract>
<t>This note attempts to capture important use cases for
source/destination routing.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<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>Source/Destination routing has been proposed in the IPv6 community
and specifically in homenet as a means of dealing with multihomed
networks whose upstream networks give them provider-allocated addresses.
An initial approach was suggested in <xref target="RFC3704"/>, which
assumed that a packet following a default route to an egress CPE Router
might arrive at the wrong one, and need to be redirected to the right
CPE Router. Subsequent approaches, including those listed in the
bibliography, have focused on using routing protocols or routing
procedures with extensions that make decisions based on both the source
and the destination address.</t>
<t>"Source/Destination Routing" is defined as routing in which both the
source and the destination address must be considered in selecting the
next hop. It might be thought of as routing "to a destination with a
constraint" - a router might have multiple routes to a given
destination, and follow the one that also obeys the constraint, or it
might have only one route to a destination but correctly fail to forward
a packet that doesn't meet the constraint. From that perspective, the
logic here extends to other cases in which a constraint might be placed
on the route. As with all routing, a primary requirement is to follow
the longest-match-first rule to the destination; following a less
specific route may well take traffic to the wrong place.</t>
<t>As a side note, source address spoofing in this case will be limited
to addresses from the indicated source prefixes, obviating the need for
upstream ingress filtering. Ingress filtering within the domain in LAN
switches can prevent spoofing of addresses within those prefixes.</t>
<t>This note attempts to capture common use cases. These will be in
terms of a general statement of intent coupled with a specific example
of the intent for clarity. The use cases are obviously not limited to
these, but these should be a reasonably complete set.</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"/>.</t>
</section>
</section>
<section anchor="sect2" title="Use Cases">
<t>The use cases proposed here are not an exhaustive set, but are
representative of a set of possibilities. At least three are
presently-deployed use cases; the fourth is a possible use case within
an edge network.</t>
<section title="Simple Egress Routing">
<t>One use case is as shown in <xref target="simple_egress_figure"/>.
A customer network has two or more upstream networks, and a single CPE
Router. Each upstream network allocates a prefix for use in the
customer network, and the customer network configures a subnet from
each of those ISP prefixes on each of its LANs. The CPE Router
advertises default routes into the network that are "from" each PA
prefix. Apart from prefix itself, the services of the upstream ISPs
are indistinguishable; they each get the customer to the Internet.</t>
<figure anchor="simple_egress_figure"
title="Egress Routing in a Multihomed Environment with One CPE Router">
<artwork align="center"><![CDATA[
,-------.
,-' `-.
,---. ,-----. ,' `.
/ \ ,' `. / \
/ \ ( ISP 1 --+--- \
/ \ / `. ,' ; :
; Customer : +-+/ `-----' | The Internet |
| Network +-+R|\ ,-----. : ;
: ; +-+ \ ,' `. \ /
\ / ( ISP 2 ---+-- /
\ / `. ,' `. ,'
\ / `-----' '-. ,-'
`---' `-------'
]]></artwork>
</figure>
<t>The big issue in this network is, of course, <xref
target="RFC2827"> ingress filtering</xref> by the upstream ISP. If
packets intended for a remote destination pass through the wrong ISP,
they will be blocked. In the ideal case, traffic following default
route gets to the upstream network indicated by its source
address.</t>
<t>The CPE Router could, at least in concept, advertise a single
default route into the network, as all traffic to an upstream ISP must
pass through that CPE Router. However, should another CPE Router be
added later, it would have to change its behavior to accomodate that
CPE Router (as in <xref target="egress"/>). Hence, the single CPE
Router must advertise two default routes into the network, one "from"
each PA prefix.</t>
<t>In this case, the destination prefix in routing is a default route,
::/0. The source prefix is the prefix allocated by the ISP. In this
case, routing within the network is largely unchanged, as all traffic
to another network goes to the CPE Router, but the CPE Router must
send it to the correct ISP.</t>
<t>Note that in this use case, if there are other routers or internal
routes in the network, there is no need for them to specify source
prefixes on their routes, and if they do, the prefix specified is
likely to be :;/0. The reason is that traffic arriving from the ISPs
must be delivered to destinations within the network, so routing
cannot preclude them.</t>
</section>
<section anchor="egress" title="General Egress Routing">
<t>A more general use case is as shown in <xref
target="egress_figure"/>. A customer network has two or more upstream
networks, with a separate CPE Router for each one. Each upstream
network allocates a prefix for use in the customer network, and the
customer network configures a subnet from each of those ISP prefixes
on each of its LANs. Each CPE Router advertises a default route into
the customer network. Apart from prefix itself, the services of the
upstream ISPs are indistinguishable; they each get the customer to the
Internet.</t>
<figure anchor="egress_figure"
title="Egress Routing in a Multihomed Environment">
<artwork align="center"><![CDATA[
,-------.
,-' `-.
,---. ,-----. ,' `.
/ \ +-+ ,' `. / \
/ +---+R+-+ ISP 1 --+--- \
/ \ +-+ `. ,' ; :
; Customer : `-----' | The Internet |
| Network | ,-----. : ;
: ; +-+ ,' `. \ /
\ +--+R+-+ ISP 2 ---+-- /
\ / +-+ `. ,' `. ,'
\ / `-----' '-. ,-'
`---' `-------'
]]></artwork>
</figure>
<t>The big issue in this network is again <xref target="RFC2827">
ingress filtering</xref> by the upstream ISP. If packets intended for
a remote destination pass through the wrong ISP, they will be blocked.
Traffic following default route gets to the upstream network indicated
by its source address.</t>
<t>In this case, the destination prefix in routing is a default route,
::/0. The source prefix is the prefix allocated by the ISP. We want a
routing algorithm that sends packets matching such a specification to
the CPE Router advertising that default route.</t>
<t>Note that in this use case, if there are other routers or internal
routes in the network, there is no need for them to specify source
prefixes on their routes, and if they do, the prefix specified is
likely to be :;/0. The reason is that traffic arriving from the ISPs
must be delivered to destinations within the network, so routing
cannot preclude them.</t>
</section>
<section anchor="specific" title="Specialized Egress Routing">
<t>A more specialized use case is as shown in <xref
target="specific_figure"/>. A customer network has two or more
upstream networks, with one or more CPE Routers; the example shows a
separate CPE Router for each one. Each upstream network allocates a
prefix for use in the customer network, and the customer network
configures a subnet from each of those ISP prefixes on each of its
LANs. Some CPE Routers might advertise a default route into the
customer network; one or more of the other CPE Routers, perhaps all of
them, advertise a more-specific route. The services offered by the
upstream networks differ in some important way.</t>
<figure anchor="specific_figure"
title="Egress Routing with a specialized upstream network">
<artwork align="center"><![CDATA[
,-------.
,-' `-.
,---. ,-----. ,' `.
/ \ +-+ ,' `. / \
/ +---+R+-+ ISP 1 --+--- \
/ \ +-+ `. ,' ; :
; Customer : `-----' | The Internet |
| Network | ,-----. : ;
: ; +-+ ,' `. \ /
\ +--+R+-+ ISP 2 ) \ /
\ / +-+ `. ,' `. ,'
\ / `--+--' '-. ,-'
`---' | `-------'
Some specialized
Service
]]></artwork>
</figure>
<t>A specific example of such a service is the NTT B-FLETS video
service in Japan; however, the use case describes any use with one or
more walled gardens. In the B-FLETS case, a customer may purchase
services from a number of ISPs, providing general Internet access.
However, the video service requires customers accessing it to use its
allocated prefix, and other ISPs (following <xref target="RFC2827"/>)
will not accept that prefix as a source address. This is similar to
the previous use cases, but <list style="symbols">
<t>the only application at that "ISP" is the video service,</t>
<t>packets using the video service MUST use the video service's
source and destination addresses, and</t>
<t>no other service will accept a video service address as a
source address.</t>
</list></t>
<t>The big issue in this network is, once again, <xref
target="RFC2827"> ingress filtering</xref> by the upstream ISP, with
the additional caveat that the upstream services are far from
identical. If packets intended for a remote destination pass through
the wrong ISP, they will be blocked. Additionally, while other ISPs
advertise access to the general Internet, they may not provide service
to the specialized service in question. Hence, egress routing in this
case also ensures delivery to the intended destination using the
bandwidth it provides. In the ideal case, traffic following default
route gets to the upstream network indicated by its source
address.</t>
<t>In this case, one or more ISPs might offer a default route as a
destination prefix in routing, ::/0. The source prefix is the prefix
allocated by the ISP. In addition, the ISP offering the specialized
service advertises one or more specific prefixes for those services,
with appropriate source prefixes for their use. We want a routing
algorithm that sends packets matching such a specification to the CPE
Router advertising that indicated route, and dropping, perhaps with an
ICMPv6 response, packets for which it effectively has no route.</t>
<t>Note that in this use case, if there are other routers or internal
routes in the network, there is no need for them to specify source
prefixes on their routes, and if they do, the prefix specified is
likely to be :;/0. The reason is that traffic arriving from the ISPs
must be delivered to destinations within the network, so routing
cannot preclude them.</t>
</section>
<section anchor="intra" title="Intra-domain access control">
<t>A use case within the confines of a single network is as shown in
<xref target="intra_figure"/>. A network has one or more internal
networks with differing access permission sets; the financial servers
might only be accessible from a set of other prefixes that financial
people are located in, or university grade records is only reachable
from the offices of professors. This could be implemented using
firewalls between the domains, or using application layer filters; in
this case, the routing architecture replaces an exclusive firewall
rule.</t>
<t>In this case, each domain advertises reachability to its prefix,
listing acceptable source prefixes. Domains that are willing to be
generally reached might advertise ::/0 as a source prefix, or the
prefix in use in the general domain.</t>
<figure anchor="intra_figure" title="Intradomain Access Control">
<artwork align="center"><![CDATA[
_.--------------.
_.-'' `---.
,-'' `--.
,' `.
,' ,---------. ,---------. `.
/ ( Domain 1 ) ( Domain 2 ) \
; `---------' `---------' :
| Inter-domain |
: Backbone ;
\ ,---------. ,---------. /
`. ( Domain 3 ) ( Domain 4 ) ,'
`. `---------' `---------' ,'
`--. _.-'
`---. _.-''
`--------------''
]]></artwork>
</figure>
<t>The big issue in this network is a difference in policy.</t>
</section>
</section>
<section anchor="requirements" title="Derived Requirements">
<t>The use cases in can each be met if:<list style="symbols">
<t>The routing protocol or mechanism includes a source prefix. It is
acceptable that a default source prefix of ::/0 (all addresses)
applies to routes that don't specify a prefix.</t>
<t>The routing protocol or mechanism includes a destination prefix,
which may be a default route (::/0) or any more specific prefix up
to and including a host route (/128).</t>
<t>The FIB lookup yields the route with the most specific (e.g.
longest-match) destination prefix that also matches the source
prefix constraint, or no match.</t>
</list></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>As a descriptive document, this note adds no new security risks to
the network. </t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>As a descriptive document, this note adds no new privacy risks to the
network.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This note was discussed with Acee Lindem, Jianping Wu, Juliusz
Chroboczek, Les Ginsberg Lorenzo Colitti, Mark Townsley, Markus
Stenberg, Matthieu Boutier, Ole Troan, Ray Bellis, Shu Yang, and Xia
Yin.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2827" ?>
<?rfc include="reference.RFC.3704" ?>
<?rfc include="reference.I-D.baker-ipv6-isis-dst-src-routing" ?>
<?rfc include="reference.I-D.baker-ipv6-ospf-dst-src-routing" ?>
<?rfc include="reference.I-D.boutier-homenet-source-specific-routing" ?>
<?rfc include="reference.I-D.troan-homenet-sadr" ?>
<?rfc include="reference.I-D.xu-homenet-traffic-class" ?>
<?rfc include="reference.I-D.baker-fun-routing-class" ?>
</references>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">August 2013</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:24:39 |