One document matched: draft-baker-fun-multi-router-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="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-fun-multi-router-00"
ipr="trust200902">
<front>
<title abbrev="">Exploring the multi-router SOHO network</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date year="2011" />
<area>Internet Engineering Task Force</area>
<workgroup></workgroup>
<abstract>
<t>This note explores the ramifications of a multi-router or multihomed
small network, such as a residential or SOHO network.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<note title="Requirements">
<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>
<t>For clarity, in this document the word "may" is distinguished from
"MAY". Consistent with <xref target="RFC2119"></xref>, "MAY" refers to
permission - something MAY or MAY NOT be done within a context. The word
"may" refers to possibility; it is possible and correct for something to
happen.</t>
</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 note explores the ramifications of a multi-router or multihomed
small network, such as a residential or SOHO network. It has relevance
to the IETF CPE Router discussion in the IPv6 Operations Working Group,
numbering and renumbering in the "renum" effort, and scoping of the
"fun" effort.</t>
<t>Much of the commentary in this draft applies equally to <xref
target="RFC0791">IPv4</xref> or <xref target="RFC2460">IPv6</xref>. As
such, the protocol will simply be called "IP" unless there is a reason
to distinguish. References will be IPv6-related unless there is a reason
for an IPv4-specific reference.</t>
<section anchor="definitions" title="Definitions">
<t>I don't think I'm introducing new terms, but let me state the
definitions of the terms I'm using for clarity. <list style="hanging">
<t hangText="LAN:">A Local Area Network (LAN) is a network of link
layer interfaces that can directly communicate without the use of
a router. Example of LANs include IEEE 802.3 Ethernet, IEEE 802.11
WiFi, and IEEE 802.15.1 and IEEE 802.15.4 WPANs.</t>
<t hangText="Subnet:">A Subnet is a set of IP interfaces connected
by a LAN. It by definition has a prefix, which serves as a locator
in routing. Multiple subnets may use the same LAN, and the
membership of those subnets may or may not be congruent.</t>
<t hangText="LAN Switch:">A LAN switch connects different physical
media (wired or wireless) in a LAN, switching packets to make them
appear to be a single LAN from the perspective of the systems
attached to it.</t>
<t hangText="Host:">With respect to a given subnet, a host is a
system that has an address in it and may originate traffic using
that address, but does not switch packets between it and other
subnets. See <xref target="RFC2460"></xref>.</t>
<t hangText="Router:">With respect to a given subnet, a router is
a system that has an address in it, may originate traffic using
that address, and additionally switches packets between it and
other subnets. See <xref target="RFC2460"></xref>.</t>
<t hangText="CPE Router:">The Customer Premises Equipment (CPE)
Router is the router on the customer premises that connects it to
another network. The term is often used in the context of a
Managed Service, which is a service in which an upstream network
own and operates the router. In residential broadband networks, it
is more common for the customer to own the router. For the
purposes of this document, the term "CPE" simply means that it is
on the customer's premises.</t>
</list></t>
</section>
<section anchor="usecase" title="Use Cases">
<t>The <xref target="RFC6204">Basic Requirements for IPv6 Customer
Edge Routers</xref> postulate a very simple network: a single router
connecting a single subnet to a single upstream ISP. In general, one
would expect that router to also implement a simple firewall
implementing the <xref target="RFC6092">Recommended Simple Security
Capabilities</xref>.</t>
<t>However, it is common, and in the future perhaps normal, for
residential and SOHO networks to be more complex, with separate
domains for <list style="symbols">
<t>domain-wide wired and/or wireless LANs with IP subnets,</t>
<t>offices with differing corporate security requirements for the
residents,</t>
<t>networks with different PHY/MAC layers supporting the Smart
Grid HAN or medical telemetry, and</t>
<t>networks for entertainment such as home-wide audio systems or
high definition TV.</t>
</list></t>
<t>In addition, there is evidence that individual residences are
likely to be multihomed, in the sense of having multiple upstream
networks. There are at least three obvious cases: <list
style="symbols">
<t>One obvious case is a home using traditional broadband (DSL or
Cable Modem) and additionally using 3GPP or LTE as an
upstream.</t>
<t>Another is a home equipped with a Smart Grid Energy Services
Interface (ESI); such a home could be assigned a prefix by the
utility for use in communications through the Advanced Metering
Infrastructure (AMI). This is not an "ISP" in the usual sense of
the term, as it provides limited services and only communicates to
the relevant utility. It is, however, an "upstream" network in the
sense that it allocates a prefix to the home and provides services
for hire.</t>
<t>A third, which has been proposed in Japan, is a Content
Delivery Network (CDN) that delivers entertainment via IP, and
allocates a prefix to the home for communication with it. Again,
this is not an "ISP" in the usual sense of the term, as it
provides limited services and only communicates to the CDN
servers. It is, however, an "upstream" network in the sense that
it allocates a prefix to the home and provides services for
hire.</t>
</list></t>
<t>As such services are deployed, it is reasonable to expect that the
typical residence or SOHO will be multihomed.</t>
<t>If one takes <xref target="RFC6204"></xref>'s view of such a
network, one gets a picture something like <xref
target="router0"></xref> (in that picture, consider "ISP" to be a
generalized upstream network, not specifically one that delivers
Internet access as a service). From the perspective of some, this
would be a wireless LAN, or at most a wired LAN and a wireless LAN
bridged together.</t>
<t></t>
<figure anchor="router0" title="Single router multihomed residence">
<artwork align="center"><![CDATA[
|
---. +--------+ | HAN Sensors, ESI,.
\ | | |
ISP1 )-----+ | | Medical Sensors, .
/ | | |
---' | CPE | | Office Equipment
| Router +-----+
---. | | | A/V Equipment
\ | | |
ISP2 )-----+ | |
/ | | |
---' +--------+ |
|
home-wide|
LAN |
|
]]></artwork>
</figure>
<t>The model in <xref target="router0"></xref> has some obvious
problems, however. Cisco Systems, for example, requires that
telecommuter's offices have a security guard (firewall or separate
Internet access) between the office and the home. There are known
cases in which husband and wife or roommates each work for different
companies and each company has such an information security guideline.
In addition, especially with a single SSID 802.11 implementation, one
could readily imagine HD TV crowding out other uses, or BitTorrent
crowding out the A/V uses. Separating the uses into separate LANs for
manageability and service isolation, and especially with the Smart
Grid's Home Area Network having a different physical interface (IEEE
802.15.4 being a prominent option), such a network begins to look like
<xref target="router1"></xref>.</t>
<figure anchor="router1" title="Single router multihomed SOHO">
<artwork align="center"><![CDATA[
+--------+ HAN Sensors, ESI,...
| +------------------
| |
---. | | Medical Sensors, ...
\ | +------------------
ISP1 )-----+ |
/ | | Office Equipment
---' | CPE +------------------
| Router |
---. | | Office Equipment
\ | +------------------
ISP2 )-----+ |
/ | | A/V Equipment
---' | +------------------
| |
| | SOHO-wide LAN
| +------------------
+--------+
]]></artwork>
</figure>
<t>Modulo the 802.15.4 interface, such routers exist today, providing
multiple 802.3 and 802.11 LANs and routing between their subnets.
However, such a router begins to look like the IT counterpart to a
Swiss Army knife, and networks are constrained by their interface
count and type. An alternative would be to build the network out of
two-port routers, as in <xref target="router2"></xref>.</t>
<figure anchor="router2" title="Multiple router multihomed SOHO">
<artwork align="center"><![CDATA[
| +------+
+--+HAN | HAN Sensors, ESI,...
| |Router+-------------------
| +------+
---. +------+ | +-------+
\ |CPE +-+ |Medical| Medical Sensors, ...
ISP1 )-----+Router| +-+Router +-------------------
/ +------+ | +-------+
---' | +---------+
| |Office #1| Office Equipment
---. +------+ +-+FW/Router+-----------------
\ |CPE +-+ +---------+
ISP2 )-----+Router| | +---------+
/ +------+ | |Office #2| Office Equipment
---' +-+FW/Router+-----------------
| +---------+
| +----------+
SOHO-wide+-+A/V Domain| A/V Equipment
LAN | |Router +----------------
| +----------+
]]></artwork>
</figure>
<t>Reality is probably somewhere in the middle - some multiport
routers and some two-port routers, depending on the application.</t>
</section>
</section>
<?rfc needLines="5"?>
<section anchor="sect2" title="Issues">
<t>Three obvious questions arise in such networks: <list style="symbols">
<t>How does routing, including routing between interior routers and
to exit routers, actually work? What features are needed?</t>
<t>How does the network identify and number its subnets?</t>
</list></t>
<section anchor="routing" title="Routing in a small network">
<t>A brief analysis of the advertised features of commercial
residential routers - products designed for use by the uninitiated in
their homes - found that almost without exception, they support <xref
target="RFC2453">RIP Version 2</xref>. At least one was found that
supports <xref target="RFC1058">RIP Version 1</xref>, and one that
supports <xref target="RFC2328">OSPF Version 2</xref>. By analogy, it
seems rational to expect residential and SOHO routers for IPv6 to
support <xref target="RFC2080">RIPng</xref>, and possibly <xref
target="RFC5340">OSPF</xref>.</t>
<t>The issues in distance vector routing, which are discussed in some
detail in <xref target="RFC1058"></xref>, primarily relate to bogus
information that has not been removed from the routing system,
especially during a "count to infinity" event. Such events happen in
networks that have parallel connectivity, which is usually implemented
for robustness. The network in <xref target="router2"></xref> does not
have parallel paths, and so would be unlikely to have that issue. More
generally, an outage in a small network would likely result in the
network administrator resetting the router in question. So RIPng
should be adequate for the purpose.</t>
<t>Another issue that arises, however, has to do with upstream <xref
target="RFC2827">Ingress Filtering</xref>. In a network with a router
per upstream network, one would really like to direct traffic intended
for a specific upstream network to the correct router. If hosts select
the correct source address using <xref
target="I-D.ietf-6man-rfc3484-revise"></xref>, <xref
target="RFC3704"></xref> addresses that in part by suggesting that
such routers redirect traffic to each other; a better approach would
be to have a routing protocol that looks at {source, destination}
address pairs and routes traffic to the appropriate exit.</t>
</section>
<section anchor="numbering" title="Assigning Subnet Numbers">
<t>In order for an upstream network such as an ISP or utility to
assign a prefix to a small network, the CPE router must support <xref
target="RFC3315">DHCPv6</xref> and its <xref target="RFC3633">IPv6
Prefix Options</xref>. This enables the CPE Router to obtain a prefix
from its upstream network, be it an ISP, a content delivery service,
or a utility, and begin to use it.</t>
<t>If, for example, an ISP allocated a global prefix to the CPE, one
would expect the CPE to allocate a default unicast route (in IPv6, a
route to 2000::/3, which is to say "all unicast addresses", as opposed
to ::/0, which would include link-local addresses, ULAs, and multicast
traffic) toward the ISP. In the more limited cases of a CDN or
utility, it may be appropriate for the upstream prefix to be more
limited - it might recommend an upstream route to exactly the CDN
service, or the address of a single anycast server/service.</t>
<t>Within the small network, one would also hope for a way to assign
subnet numbers; as others have suggested, this could build on the same
capability as in <xref target="RFC3633"></xref>. If the CPE router has
a prefix shorter than /64, other routers within the domain could ask
it for /64s and have them assigned by the same mechanism. A hand-wave
description would have any small-network router<list style="numbers">
<t>Come up as a host on each interface, emitting an RS and
awaiting an RA from another router. On any interface that
calculates its address using SLAAC, one would expect the router to
use the same prefix(es) that it learned.</t>
<t>If no address is allocated on an interface via SLAAC within
some interval, perhaps sixty microfortnights, the router could
request a prefix using the mechanisms in <xref
target="RFC3315"></xref> and <xref target="RFC3633"></xref>. For
the ISP-facing CPE Router, this would result in a prefix shorter
than /64; within the domain, it should result in a /64. In the
ISP-facing case, one would expect the router to allocate a /64 to
each of its non-ISP-facing interfaces and immediately emitting an
RA; routers in those subnets would then create addresses using
SLAAC.</t>
<t>If an additional interval of (perhaps) sixty microfortnights
elapses, and the router has an IPv6 address on one or more of its
interfaces, one could imagine the router requesting a new /64 on
one of its addressed interfaces and assigning it to an
un-addressed interface.</t>
</list></t>
<t>This procedure has an obvious race condition: if there are two
routers on the same LAN, they could both request a prefix and
simultaneously apply it. While not incorrect (IPv6 allows for multiple
subnets on a LAN), it is inefficient. Two obvious mechanisms exist to
counter this. If an SPF-based protocol such as OSPF or IS-IS is in
use, and only the designated router requests a prefix, there will be a
minimum number of subnets on the LAN. Alternatively, if the DHCPv6
server allocates prefixes with some non-trivial inter-assignment
interval, the LANs should similarly have a minimum number of
subnets.</t>
</section>
</section>
<section title="Possible Requirements">
<t>As the document is written, various possible requirements have popped
up. These include at least the following.</t>
<section anchor="sdroute" title="Source/Destination Routing">
<t><xref target="routing"></xref> notes that it would be nice to have
a routing protocol that steered traffic toward an appropriate exit.
Stated generally, it would be nice to have a routing protocol that
could generate routes *from* a source *to* a destination, as opposed
to being simply *to* a destination.</t>
</section>
<section title="Subnet assignment">
<t>A subnet assignment procedure such as described in <xref
target="numbering"></xref> is needed. That section shows a "hand-wavy"
mechanism, but the mechanism needs to be worked out in detail.</t>
</section>
<section title="Recommended upstream route">
<t><xref target="numbering"></xref> notes that it would be nice to
have a way for the upstream network that provides a prefix to a
customer also be able to give it a recommended upstream route. One
obvious solution would be a DHCPv6 option that indicated some number
of tuples, each consisting of <list style="symbols">
<t>A source prefix (which could be ::/0, the prefix assigned to
the small network, or something else)</t>
<t>A destination prefix (which could be ::/0, 2000::/3, or a more
specific appropriate to the service such as an anycast address or
a data center prefix for a specific service offered by the
ISP)</t>
<t>A set of DSCP values, which could be "any" or any more specific
subset</t>
<t>One or more next hop router addresses</t>
</list></t>
<t>If source/destination routing is implemented as described in <xref
target="sdroute"></xref>, it might want to be able to specify that
such datagrams must come *from* the prefix it assigned to the network.
This could be implemented using a routing protocol, but that is a big
change to the way residential broadband networks usually work; a more
acceptable approach may be a DHCPv6 option.</t>
</section>
</section>
<?rfc needLines="5"?>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
<?rfc needLines="2"?>
<t>Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are required,
or if those assignments or registries are created during the RFC
publication process. From the author"s perspective, it may therefore be
removed upon publication as an RFC at the RFC Editor"s discretion.</t>
</section>
<?rfc needLines="5"?>
<section anchor="Security" title="Security Considerations">
<t></t>
<?rfc needLines="5"?>
<section anchor="Privacy" title="Privacy Considerations">
<t></t>
</section>
</section>
<?rfc needLines="5"?>
<section anchor="Acknowledgements" title="Acknowledgements">
<t></t>
</section>
<?rfc needLines="5"?>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">17 June 2011</t>
</list></t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<?rfc needLines="5"?>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460"?>
</references>
<?rfc needLines="5"?>
<references title="Informative References">
<?rfc include="reference.RFC.0791"?>
<?rfc include="reference.RFC.2080" ?>
<?rfc include="reference.I-D.ietf-6man-rfc3484-revise" ?>
<?rfc include="reference.RFC.1058" ?>
<?rfc include="reference.RFC.2328" ?>
<?rfc include="reference.RFC.2453" ?>
<?rfc include="reference.RFC.2827" ?>
<?rfc include="reference.RFC.3704" ?>
<?rfc include="reference.RFC.3315" ?>
<?rfc include="reference.RFC.3633" ?>
<?rfc include="reference.RFC.5340" ?>
<?rfc include="reference.RFC.6092" ?>
<?rfc include="reference.RFC.6204" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:25:43 |