[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]
Versions: 00
Network Working Group F. Baker
Internet-Draft Cisco Systems
Intended status: Informational July 1, 2011
Expires: January 2, 2012
Exploring the multi-router SOHO network
draft-baker-fun-multi-router-00
Abstract
This note explores the ramifications of a multi-router or multihomed
small network, such as a residential or SOHO network.
Requirements
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 [RFC2119].
For clarity, in this document the word "may" is distinguished from
"MAY". Consistent with [RFC2119], "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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Baker Expires January 2, 2012 [Page 1]
Internet-Draft Exploring the multi-router SOHO network July 2011
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Routing in a small network . . . . . . . . . . . . . . . . 7
2.2. Assigning Subnet Numbers . . . . . . . . . . . . . . . . . 8
3. Possible Requirements . . . . . . . . . . . . . . . . . . . . 9
3.1. Source/Destination Routing . . . . . . . . . . . . . . . . 9
3.2. Subnet assignment . . . . . . . . . . . . . . . . . . . . 9
3.3. Recommended upstream route . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Baker Expires January 2, 2012 [Page 2]
Internet-Draft Exploring the multi-router SOHO network July 2011
1. Introduction
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.
Much of the commentary in this draft applies equally to IPv4
[RFC0791] or IPv6 [RFC2460]. 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.
1.1. Definitions
I don't think I'm introducing new terms, but let me state the
definitions of the terms I'm using for clarity.
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.
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.
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.
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
[RFC2460].
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 [RFC2460].
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
Baker Expires January 2, 2012 [Page 3]
Internet-Draft Exploring the multi-router SOHO network July 2011
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.
1.2. Use Cases
The Basic Requirements for IPv6 Customer Edge Routers [RFC6204]
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
Recommended Simple Security Capabilities [RFC6092].
However, it is common, and in the future perhaps normal, for
residential and SOHO networks to be more complex, with separate
domains for
o domain-wide wired and/or wireless LANs with IP subnets,
o offices with differing corporate security requirements for the
residents,
o networks with different PHY/MAC layers supporting the Smart Grid
HAN or medical telemetry, and
o networks for entertainment such as home-wide audio systems or high
definition TV.
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:
o One obvious case is a home using traditional broadband (DSL or
Cable Modem) and additionally using 3GPP or LTE as an upstream.
o 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.
o 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,
Baker Expires January 2, 2012 [Page 4]
Internet-Draft Exploring the multi-router SOHO network July 2011
however, an "upstream" network in the sense that it allocates a
prefix to the home and provides services for hire.
As such services are deployed, it is reasonable to expect that the
typical residence or SOHO will be multihomed.
If one takes [RFC6204]'s view of such a network, one gets a picture
something like Figure 1 (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.
|
---. +--------+ | HAN Sensors, ESI,.
\ | | |
ISP1 )-----+ | | Medical Sensors, .
/ | | |
---' | CPE | | Office Equipment
| Router +-----+
---. | | | A/V Equipment
\ | | |
ISP2 )-----+ | |
/ | | |
---' +--------+ |
|
home-wide|
LAN |
|
Figure 1: Single router multihomed residence
The model in Figure 1 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 Figure 2.
Baker Expires January 2, 2012 [Page 5]
Internet-Draft Exploring the multi-router SOHO network July 2011
+--------+ HAN Sensors, ESI,...
| +------------------
| |
---. | | Medical Sensors, ...
\ | +------------------
ISP1 )-----+ |
/ | | Office Equipment
---' | CPE +------------------
| Router |
---. | | Office Equipment
\ | +------------------
ISP2 )-----+ |
/ | | A/V Equipment
---' | +------------------
| |
| | SOHO-wide LAN
| +------------------
+--------+
Figure 2: Single router multihomed SOHO
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 Figure 3.
Baker Expires January 2, 2012 [Page 6]
Internet-Draft Exploring the multi-router SOHO network July 2011
| +------+
+--+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 +----------------
| +----------+
Figure 3: Multiple router multihomed SOHO
Reality is probably somewhere in the middle - some multiport routers
and some two-port routers, depending on the application.
2. Issues
Three obvious questions arise in such networks:
o How does routing, including routing between interior routers and
to exit routers, actually work? What features are needed?
o How does the network identify and number its subnets?
2.1. Routing in a small network
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 RIP Version 2
[RFC2453]. At least one was found that supports RIP Version 1
[RFC1058], and one that supports OSPF Version 2 [RFC2328]. By
analogy, it seems rational to expect residential and SOHO routers for
IPv6 to support RIPng [RFC2080], and possibly OSPF [RFC5340].
The issues in distance vector routing, which are discussed in some
detail in [RFC1058], primarily relate to bogus information that has
Baker Expires January 2, 2012 [Page 7]
Internet-Draft Exploring the multi-router SOHO network July 2011
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 Figure 3 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.
Another issue that arises, however, has to do with upstream Ingress
Filtering [RFC2827]. 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 [I-D.ietf-6man-rfc3484-revise],
[RFC3704] 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.
2.2. Assigning Subnet Numbers
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 DHCPv6
[RFC3315] and its IPv6 Prefix Options [RFC3633]. 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.
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.
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 [RFC3633]. 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
1. 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.
Baker Expires January 2, 2012 [Page 8]
Internet-Draft Exploring the multi-router SOHO network July 2011
2. 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 [RFC3315] and [RFC3633]. 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.
3. 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.
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.
3. Possible Requirements
As the document is written, various possible requirements have popped
up. These include at least the following.
3.1. Source/Destination Routing
Section 2.1 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.
3.2. Subnet assignment
A subnet assignment procedure such as described in Section 2.2 is
needed. That section shows a "hand-wavy" mechanism, but the
mechanism needs to be worked out in detail.
Baker Expires January 2, 2012 [Page 9]
Internet-Draft Exploring the multi-router SOHO network July 2011
3.3. Recommended upstream route
Section 2.2 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
o A source prefix (which could be ::/0, the prefix assigned to the
small network, or something else)
o 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)
o A set of DSCP values, which could be "any" or any more specific
subset
o One or more next hop router addresses
If source/destination routing is implemented as described in
Section 3.1, 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.
4. IANA Considerations
This memo asks the IANA for no new parameters.
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.
5. Security Considerations
5.1. Privacy Considerations
Baker Expires January 2, 2012 [Page 10]
Internet-Draft Exploring the multi-router SOHO network July 2011
6. Acknowledgements
7. Change Log
Initial Version: 17 June 2011
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
8.2. Informative References
[I-D.ietf-6man-rfc3484-revise]
Matsumoto, A., Kato, J., and T. Fujisaki, "Update to RFC
3484 Default Address Selection for IPv6",
draft-ietf-6man-rfc3484-revise-01 (work in progress),
October 2010.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
Baker Expires January 2, 2012 [Page 11]
Internet-Draft Exploring the multi-router SOHO network July 2011
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092,
January 2011.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011.
Author's Address
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Email: fred@cisco.com
Baker Expires January 2, 2012 [Page 12]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/