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 03, 2012.

Copyright Notice

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.

Table of Contents

• 1. Introduction
• 1.1. Definitions
• 1.2. Use Cases
• 2. Issues
• 2.1. Routing in a small network
• 2.2. Assigning Subnet Numbers
• 3. Possible Requirements
• 3.1. Source/Destination Routing
• 3.2. Subnet assignment
• 3.3. Recommended upstream route
• 4. IANA Considerations
• 5. Security Considerations
• 5.1. Privacy Considerations
• 6. Acknowledgements
• 7. Change Log
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Author's Address

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 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

• domain-wide wired and/or wireless LANs with IP subnets,
• offices with differing corporate security requirements for the residents,
• networks with different PHY/MAC layers supporting the Smart Grid HAN or medical telemetry, and
• 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:

• One obvious case is a home using traditional broadband (DSL or Cable Modem) and additionally using 3GPP or LTE as an upstream.
• 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.
• 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.

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.

2. Issues

Three obvious questions arise in such networks:

• How does routing, including routing between interior routers and to exit routers, actually work? What features are needed?
• 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 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.
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.

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

• A source prefix (which could be ::/0, the prefix assigned to the small network, or something else)
• 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)
• A set of DSCP values, which could be "any" or any more specific subset
• 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

6. Acknowledgements

7. Change Log

Initial Version:

17 June 2011

8. References

8.1. Normative References

8.2. Informative References

Author's Address