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