| Network Working Group | F.J. Baker |
| Internet-Draft | Cisco Systems |
| Intended status: Informational | July 02, 2011 |
| Expires: January 03, 2012 |
Exploring the multi-router SOHO network
draft-baker-fun-multi-router-00
This note explores the ramifications of a multi-router or multihomed small network, such as a residential or SOHO network.
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.
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 03, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
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.
I don't think I'm introducing new terms, but let me state the definitions of the terms I'm using for clarity.
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
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:
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 |
|
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.
+--------+ HAN Sensors, ESI,...
| +------------------
| |
---. | | Medical Sensors, ...
\ | +------------------
ISP1 )-----+ |
/ | | Office Equipment
---' | CPE +------------------
| Router |
---. | | Office Equipment
\ | +------------------
ISP2 )-----+ |
/ | | A/V Equipment
---' | +------------------
| |
| | SOHO-wide LAN
| +------------------
+--------+
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.
| +------+
+--+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 +----------------
| +----------+
Reality is probably somewhere in the middle - some multiport routers and some two-port routers, depending on the application.
Three obvious questions arise in such networks:
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 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.
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
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.
As the document is written, various possible requirements have popped up. These include at least the following.
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.
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.
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
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.
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2460] | Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. |