Internet DRAFT - draft-chakrabarti-homenet-prefix-alloc

draft-chakrabarti-homenet-prefix-alloc






HOMENET WG                                                   E. Nordmark
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                          S. Chakrabarti
Expires: April 30, 2012                                      S. Krishnan
                                                               W. Haddad
                                                                Ericsson
                                                        October 28, 2011


     Simple Approach to Prefix Distribution in Basic Home Networks
               draft-chakrabarti-homenet-prefix-alloc-01

Abstract

   Modern IPv4 home networks are often configured with multi-level of
   NATs and Residential gateways to separate islands of networks used
   for different purposes.  With the introduction of IPv6 home networks
   we'd like to be able to maintain the same topological freedom as we
   have with IPv4 but without requiring any IPv6 NATs.  This document
   specifies the topological restrictions for what we term Basic Home
   Networks and specifies how DHCPv6 Prefix Delegation can be used to
   autoconfigure IPv6 address prefixes in such networks.

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 April 30, 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



Nordmark, et al.         Expires April 30, 2012                 [Page 1]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


   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
   2.  Definition Of Terms  . . . . . . . . . . . . . . . . . . . . .  4
   3.  Conceptual model of a Basic Home Router  . . . . . . . . . . .  5
   4.  Topology Assumptions . . . . . . . . . . . . . . . . . . . . .  5
   5.  Topology Examples  . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Automatic hierarchical DHCPv6 Prefix Delegation  . . . . . . . 10
     6.1.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  Configurability  . . . . . . . . . . . . . . . . . . . . . 13
     6.3.  Routing Implications . . . . . . . . . . . . . . . . . . . 13
     6.4.  Neighbor Discovery Implications  . . . . . . . . . . . . . 14
     6.5.  Ensuring stable prefixes . . . . . . . . . . . . . . . . . 14
   7.  Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1.  DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 16
   9.  Host Behavior  . . . . . . . . . . . . . . . . . . . . . . . . 17
   10. Router Behavior  . . . . . . . . . . . . . . . . . . . . . . . 17
   11. Bootstrapping  . . . . . . . . . . . . . . . . . . . . . . . . 17
   12. What if there are loops? . . . . . . . . . . . . . . . . . . . 18
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     16.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
















Nordmark, et al.         Expires April 30, 2012                 [Page 2]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


1.  Introduction

   In the past decade due to explosion of IP-enabled devices and home
   Internet usage, many homes have become testbeds of multi-subnet and
   often multi-level subnetworks.  While the simple case of a single
   Residential Gateway with NAT functionality is the most common, there
   is a desire to have separate guest subnets.  And the future
   introduction of new low-power radio technologies will result in
   additional subnets since such technologies typically can not be
   bridged to Ethernet networks.  Using IPv4 it is possible to get
   connectivity by connecting several RG's with NAT together to form a
   tree or a daisy-chain of NATs.  That can more or less be performed in
   a plug and play fashion.  It is also possible to manually configure
   routers with IP subnet numbers, routing protocols, etc, resulting in
   a home network which does not require any internal NATs.  But such
   configuration requires a fair bit of expertize.

   With the introduction of IPv6 in the home networks we would like to
   avoid assuming IPv6 NATs, yet we want to allow for cases that require
   separate subnets (for security reasons as in the case of the guest
   network, or for technology reasons as in the case of new radio
   networks).  We want this without requiring networking experts to
   manually configure IP subnet numbers and routing protocols.

   IPv6 has already taken steps to facilitate some aspects of this
   configuration through DHCP Prefix delegation [RFC3633] which is used
   to configure a single Residential Gateway with an IPv6 address prefix
   that can be used inside the home.  However, that does not handle
   cases where there are multiple routers in the home.  The homenet WG
   desires to solve this more general architecture, with a set of
   example topologies shown ina [I-D.chown-homenet-arch].

   In this draft we argue for separating out a subset of those
   topologies, and focusing on those first.  We will call the subset
   "Basic Homenets".  The criteria used for this is the set of
   topologies that can be implemented using consumer-grade IPv4
   Residential Gateways without (significant) manual configuration.  As
   we will see, those topologies end up being constrained to be a single
   tree rooted in the connection to the ISP.  In such a topology we then
   apply hierarchical DHCPv6 Prefix Delegation in an automated way with
   sensible defaults.  The approach is as robust against
   misconfiguration and loops as is the use of IPv4 NATs.

   Adding the prefix allocation specified in this draft for IPv6 support
   will have no effect on IPv4; the current use of DHCP, NAT, or even
   routed IPv4 without NAT in the home routers will function as before.

   The approach provides stable IPv6 prefixes in the home network by



Nordmark, et al.         Expires April 30, 2012                 [Page 3]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


   relying on the ability for DHCPv6 servers to keep the assignments in
   stable storage.

   This draft follows the architecture and terminology outlined in the
   homenet architecture [I-D.chown-homenet-arch].


2.  Definition Of Terms

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

   Some of the following terms are taken from [I-D.chown-homenet-arch]:

   Customer Edge Router (CER)
      The IPv6 router which connects to the ISP network on its uplink
      interface.  Such a routers has one or more down-link interfaces
      which can be used by hosts and routers.  This router can be co-
      located with the CPE.

   Interior Router (IR)
      The other IPv6 routers in the home network.  These routers are not
      connected to the ISP directly.

   Router:
      In this document we use "router" to refer to either CERs or IRs.
      In fact, CER and IR is a topological role which we expect can be
      played by a router which implements this specification.

   Host:
      A host in a IPv6 network is a device which does not forward IPv6
      packets (that are not addressed to itself).  A host can be
      connected to one or more routers.

   CPE:
      Customer Premises Equipment aka Home Gateway attached to the DSL
      or cable modem.  The CER and CPE could be co-located in the same
      device.

   Link:
      A communication facility or medium over which nodes can
      communicate at the link layer, i.e., the layer immediately below
      IPv6.







Nordmark, et al.         Expires April 30, 2012                 [Page 4]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


3.  Conceptual model of a Basic Home Router

   A key assumption we make is that a Basic Home Router has a designated
   uplink port.  Today such home routers include IPv4 NAT functionality
   and as IPv6 support is added the goal is to not require IPv6 NAT
   functionality but instead rely on different prefixes being allocated
   to different links.

   A Basic Home Router can have different configuration and number of
   downlink ports, whether physical ports (e.g., Ethernet), VLANs, or
   wireless (e.g., WiFi, 802.15.4).  In the case of wireless interfaces
   it might make sense to think of them as potentially different ports.
   For example, a WiFi access point with a private and a guest ESSID
   might be thought of as two separate ports.  A device is free to
   choose which collections of ports it wants to handle as a single link
   from IP's perspective.  For example, a device with 4 Ethernet
   downlink ports and a WiFi AP is free to handle that as e.g.:

      A single link, by bridging the Ethernet ports and WiFi together.

      One link for the 4 Ethernet ports (bridged together), and two
      links for WiFi - one for the private ESSID and one for the guest
      ESSID.

      Dynamically create a separate link for each station that is
      authenticated using 802.1X and its WiFi counterparts.

   The key point in the conceptual model is the assumption of a single
   uplink port on a separate IP link, and some set of links covering the
   set of downlink ports.  On typical home router products the uplink
   port is colors and labeled differently, perhaps with "Internet" or
   "WAN".

   While there are IPv6 routers which do not have those limitations, if
   the device is also operating as a IPv4 home router with NAT, then
   most likely it would have the single uplink for the purposes of
   DHCPv4 and NAT.


4.  Topology Assumptions

   The existence of the single uplink interface naturally drives the
   topology towards a tree.  At first sight one might think that the
   network can have destructive loops even with a single uplink port.
   For instance, some set of downlink interfaces on some of the routers
   could be bridged together using a commonly available Ethernet switch.
   The key question is whether that would work using IPv4 home routers
   with NAT.



Nordmark, et al.         Expires April 30, 2012                 [Page 5]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


   Many IPv4 home routers have a default configuration with
   192.168.1.1/24 configured on their LAN interface.  Plugging two
   downlink ports from two different routers into a single switch would
   cause an IP address conflict; both routers would claim the same above
   IP address.  Such a conflict can be avoided if one of the routers is
   configured to have a different IP address on its LAN interface such
   as 10.0.0.1/24.  In that case there would still be two uncoordinated
   DHCP servers on the same LAN.  Thus one host might send a DHCP
   request to one router, and be assigned 192.168.1.5/24 a default
   router of 192.168.1.1 while some other host happens to use the other
   router's DHCP server and be assigned 10.0.0.27/24 with 10.0.0.1 as
   the default router.  Thus this doesn't cause any looping problems for
   IPv4 and NAT, but it isn't useful as a topology since there is no
   coordinated IPv4 address assignment for the bridged LAN.

   For IPv6 we want to support the same topologies that are useful in
   the IPv4 NAT case, and ensure that even for non-useful topologies
   such as the above bridged LAN case IPv6 wouldn't be any worse that
   the IPv4 NAT case.


5.  Topology Examples

   The following diagrams show the typical topology scenarios of home
   network for which the draft is based on.  For simplicity the diagram
   limits the levels of subnets.  Figure 1 shows a rather wide tree of
   routers, and as a result a large number of hosts can be connected
   using a shallow tree.

   Figure 2 shows a daisy-chain of routers, which result in a deeper
   tree with more levels of routers.  But both of those topologies are
   trees.



















Nordmark, et al.         Expires April 30, 2012                 [Page 6]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


                      +------+--------+                    \
                      |     IPv6      |                     \
                      | Customer Edge |                      \
                      |    Router     |                      |
                      +----+-----+----+                      |
          Network A        |     |      Network B            |
    ----+-------------+----+     +---+-------------+-----    |
        |             |              |             |         |
   +----+-----+ +-----+----+    +----+-----+ +-----+----+    |
   |IPv6 Host | |IPv6 Int. |    |IPv6 Int. | |IPv6 Int. |    |
   |          | | Router   |    | Router   | | Router   |    | End-User
   +----------+ +-----+----+    +----+-----+ +-----+----+    | networks
                      |              |             | Net G   |
          Network C   |              | Network D   +-------  |
    ----+-------------+----       ---+-------------+-----    |
        |             |              |             |         |
   +----+-----+ +-----+----+    +----+-----+ +-----+----+    |
   |IPv6 Host | |IPv6 Int. |    |IPv6 Int. | |IPv6 Int. |    |
   |          | | Router   |    | Router   | | Router   |    |
   +----------+ +-----+----+    +----+-----+ +-----+----+    |
                      |              |             | Net H   |
           Network E  |              | Network F   +-------  |
    ----+-------------+-----      ---+-------------+-        |
        |             |              |             |         |
   +----+-----+ +-----+----+    +----+-----+ +-----+----+    |
   |IPv6 Host | |IPv6 Host |    | IPv6 Host| |IPv6 Host |    |
   |          | |          |    |          | |          |   /
   +----------+ +-----+----+    +----------+ +----------+  /

                         Figure 1: Tree of routers


                      +------+--------+                    \
                      |     IPv6      |                     \
                      | Customer Edge |                      \
                      |    Router     |                      |
                      +----+-+---+----+                      |
          Network A        | |   |      Network B            |
    ----+-------------+----+ |   +---+-------------+-----    |
        |             |      |       |             |         |
   +----+-----+ +-----+----+ |  +----+-----+ +-----+----+    |
   |IPv6 Host | |IPv6 Host | |  |IPv6 Host | |IPv6 Host |    |
   |          | |          | |  |          | |          |    |
   +----------+ +----------+ |  +----------+ +----------+    |
                             |                               |
                             |                               |
                      +------+--------+                      |
                      |     IPv6      |                      |



Nordmark, et al.         Expires April 30, 2012                 [Page 7]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


                      |   Interior    |                      |
                      |    Router     |                      |
                      +----+-+---+----+                      |
          Network C        | |   |      Network D            |
    ----+-------------+----+ |   +---+-------------+-----    |
        |             |      |       |             |         |
   +----+-----+ +-----+----+ |  +----+-----+ +-----+----+    |
   |IPv6 Host | |IPv6 Host | |  |IPv6 Host | |IPv6 Host |    |
   |          | |          | |  |          | |          |    |
   +----------+ +----------+ |  +----------+ +----------+    |
                             |                               |
                             |                               |
                      +------+--------+                      | End-User
                      |     IPv6      |                      | networks
                      |   Interior    |                      |
                      |    Router     |                      |
                      +----+-+---+----+                      |
          Network E        | |   |      Network F            |
    ----+-------------+----+ |   +---+-------------+-----    |
        |             |      |       |             |         |
   +----+-----+ +-----+----+ |  +----+-----+ +-----+----+    |
   |IPv6 Host | |IPv6 Host | |  |IPv6 Host | |IPv6 Host |    |
   |          | |          | |  |          | |          |    |
   +----------+ +----------+ |  +----------+ +----------+    |
                             |                               |
                             |                               |
                      +------+--------+                      |
                      |     IPv6      |                      |
                      |   Interior    |                      |
                      |    Router     |                      |
                      +---+-------+---+                      |
          Network G       |       |     Network H            |
    ----+-------------+---+-      +---+-------------+-       |
        |             |               |             |        |
   +----+-----+ +-----+----+     +----+-----+ +-----+----+   |
   |IPv6 Host | |IPv6 Host |     | IPv6 Host| |IPv6 Host |   |
   |          | |          |     |          | |          |   /
   +----------+ +----------+     +----------+ +----------+  /

                      Figure 2: Daisy-chained routers

   Note that none of the figures about have any multihoming.  However,
   hosts might be multihomed as shown in Figure 3 and Figure 4.








Nordmark, et al.         Expires April 30, 2012                 [Page 8]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


                      +------+--------+                    \
                      |     IPv6      |                     \
                      | Customer Edge |                      \
                      |    Router     |                      |
                      +----+-+---+----+                      |
          Network A        | |   |      Network B            |
    ----+-------------+----+ |   +---+-------------+-----    |
        |             |      |       |             |         |
   +----+-----+ +-----+----+ |  +----+-----+ +-----+----+    |
   |IPv6 Host | |IPv6 Host | |  |   IPv6   | |IPv6 Host |    |
   |          | |          | |  |  Router  | |    Y     |    |
   +----------+ +----------+ |  +----+-----+ +-----+----+    |
                             |       |             |         |
                             |     --+-------------+---+-    |
                             |         Network E       |     |
                      +------+--------+                |     | End-User
                      |     IPv6      |                |     | networks
                      |   Interior    |                |     |
                      |    Router     |                |     |
                      +---+-------+---+                |     |
          Network C       |       |   Network D        |     |
    ----+-------------+---+       +---+---------+-     |     |
        |             |               |         |      |     |
   +----+-----+ +-----+----+     +----+-----+ +-+------+-+   |
   |IPv6 Host | |IPv6 Host |     | IPv6 Host| |IPv6 Host |   |
   |          | |          |     |          | |     X    |   /
   +----------+ +----------+     +----------+ +----------+  /

                Figure 3: Allowed internal host multihoming






















Nordmark, et al.         Expires April 30, 2012                 [Page 9]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


           +-------+-------+     +-------+-------+         \
           |   Service     |     |   Service     |          \
           |  Provider A   |     |  Provider B   |           | Service
           |    Router     |     |    Router     |           | Provider
           +------+--------+     +-------+-------+           | network
                  |                      |                   /
                  |      Customer        |                  /
                  | Internet connections |                 /
                  |                      |
           +------+--------+     +-------+-------+         \
           |     IPv6      |     |    IPv6       |          \
           | Customer Edge |     | Customer Edge |           \
           |   Router 1    |     |   Router 2    |           /
           +------+--------+     +-------+-------+          /
                  |                      |                 /
                  |                      |                | End-User
     ---+---------+---------+    +-------+---------+---   | network(s)
        |                   |    |                 |       \
   +----+-----+          +--+----+--+        +-----+----+   \
   |IPv6 Host |          |IPv6 Host |        |IPv6 Host |   /
   |          |          |          |        |          |  /
   +----------+          +----------+        +----------+

                    Figure 4: Allowed site multihoming


6.  Automatic hierarchical DHCPv6 Prefix Delegation

   The basic idea is that each router operates a DHCP PD client on their
   uplink interface, and a DHCP PD server on each of their downlink
   interfaces.  The router can then take the prefix it is delegated on
   its uplink interface, and carve that up into

      Prefixes that are advertised in router advertisements on its
      downlink interfaces for Stateless Address autoconfiguration
      [RFC4862] of neighboring host and router interfaces.

      Prefixes that are made available to its DHCP PD server, from which
      downlink neighboring routers can request allocations.

   A router would typically know how many downlink interfaces it has
   (unless it creates they on the fly based on 802.1X, but that isn't a
   zero-configuration case).  But in general a router does not know how
   many downlink neighboring routers it might have - whether the
   topology of routers will look like a wire tree or a narrow daisy-
   chain.  However, we recommend a heuristic approach.  If a router has
   e.g., four wired Ethernet ports and two radio interfaces, it would
   seem unlikely for it to have more than about six neighboring downlink



Nordmark, et al.         Expires April 30, 2012                [Page 10]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


   routers.  Based on this we recommend that a router of that size by
   default reserve seven sub-prefixes for PD allocation.  That is the
   basis for automating the sub-delegations.

6.1.  Example

   We assume the ISP allocates a /56 prefix to the CER, and that all the
   routers use the above default of 7 sub-prefixes.  Let the prefix be
   2001:DB8:0:CD00::/56.  The router adds "3" to the prefix length which
   results in 8 different /59 prefixes:

      2001:DB8:0:CD00::/59

      2001:DB8:0:CD20::/59

      2001:DB8:0:CD40::/59

      2001:DB8:0:CD60::/59

      2001:DB8:0:CD80::/59

      2001:DB8:0:CDA0::/59

      2001:DB8:0:CDC0::/59

   The router can use the first /59 to create 32 different /64 prefixes
   for its downlinks, and has 7 different /59 prefixes it can allocate
   to downlink neighboring IRs.

   When an IR that is directly attached to the CER invokes the DHCP PD
   client on its uplink interface it might be assigned 2001:DB8:0:
   CD60::/59.  That router operates in exactly the same manner and adds
   "3" to the prefix length to create 8 different /62 prefixes:

      2001:DB8:0:CD60::/62

      2001:DB8:0:CD64::/62

      2001:DB8:0:CD68::/62

      2001:DB8:0:CD6C::/62

      2001:DB8:0:CD70::/62

      2001:DB8:0:CD74::/62

      2001:DB8:0:CD78::/62




Nordmark, et al.         Expires April 30, 2012                [Page 11]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


      2001:DB8:0:CD7C::/62

   The router can use the first /62 to create 4 different /64 prefixes
   for its downlink links and has 7 different /62 prefixes to assign to
   its child IRs should there be any.

   Suppose there is a third layer of routers, so that an IR requests a
   prefix from the above IR.  Then it might be assigned 2001:DB8:0:
   CD78::/62.  It carves that into four /64 prefixes (it can't carve
   into smaller chunks than /64):

      2001:DB8:0:CD78::/64

      2001:DB8:0:CD79::/64

      2001:DB8:0:CD7A::/64

      2001:DB8:0:CD7B::/64

   If the router has less than four downlink interfaces, then it would
   keep the leftover /64 prefixes in reserve for its DHCP PD client.

   One such example network is depicted in Figure 5.  In this figure
   L(Prefix) is used to denote that the prefix is being advertised in an
   RA as an on-link prefix and D(Prefix) is used to denote that the
   prefix is being delegated from the Delegating Router (DR) to the
   Requesting Router (RR) in the downward direction.
























Nordmark, et al.         Expires April 30, 2012                [Page 12]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


                                |
         D(2001:DB8:0:CD00::/56)|
                                |
                         +------+--------+                    \
                         |     IPv6      |                     \
                         | Customer Edge |                      \
                         |    Router     |                      |
                         +----+-----+----+                      |
     L(2001:DB8:0:CD00::/64)  |     |  L(2001:DB8:0:CD01::/64)  |
       ----+-------------+----+     +----------+------------    |
           |             |                     |                |
           |  D(2001:DB8:0:CD20::/59) D(2001:DB8:0:CD40::/59)   |
           |             |                     |                |
      +----+-----+ +-----+----+          +-----+----+           |
      |IPv6 Host | |IPv6 Int. |          |IPv6 Int. |           |
      |          | | Router   |          | Router   |           |
      +----------+ +-----+----+          +-----+----+           |
                         |                     |                |
     L(2001:DB8:0:CD20::/64)        L(2001:DB8:0:CD40::/64)     |
                         |                     |                |
       ----+-------------+----       --+--------------+----     |
           |             |             |              |         |
           |  D(2001:DB8:0:CD24::/59)  | D(2001:DB8:0:CD44::/62)|
           |             |             |              |         |
      +----+-----+ +-----+----+   +----+-----+  +-----+----+    |
      |IPv6 Host | |IPv6 Int. |   |IPv6 Host |  |IPv6 Int. |    |
      |          | | Router   |   |          |  | Router   |    |
      +----------+ +-----+----+   +----+-----+  +-----+----+    |
                                                                /
                                                               /
                                                              /

                   Figure 5: Automatic prefix delegation

6.2.  Configurability

   A router SHOULD provide a configuration interface where that allows
   both adjusting the added prefix length ("3" in the above example),
   and also allows manual assignment of prefixes to DHCP PD clients (in
   the same manner than many IPv4 home routers allow pre-assignment of
   IPv4 addresses today).

6.3.  Routing Implications

   If a router (CER or IR) has been assigned a prefix on its uplink
   interface (e.g., 2001:DB8:0:CD60::/59) then any destination address
   which is outside of that prefix should be routed to its uplink.  The
   router maintains a default route to its uplink for this purpose using



Nordmark, et al.         Expires April 30, 2012                [Page 13]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


   Neighbor Discovery [RFC4861] on its uplink interface.  Destination
   addresses that fall in its delegated prefix will either be routed to
   downlink interfaces (if they are assigned as a subnet prefix on an
   interface, or delegated to a downlink router) or dropped (for
   unassigned prefixes).

   Thus there is no need to run a routing protocol to handle the Basic
   Homenet topologies.

6.4.  Neighbor Discovery Implications

   A router (CER or IR) will perform Neighbor Discovery as a host on its
   uplink interface, thus it will send Router Solicitations and use
   received Router Advertisements to track its default uplink router.
   Note that in some suboptimal topologies there might be multiple
   uplink routers (if some bridge has been inserted) thus a router
   should handle multiple default routers on its uplink interface.

   A CER and IR needs to perform Neighbor Discovery as a router on its
   downlink interfaces.  Thus it will send Router Advertisements
   periodically and respond to Router Solicitations.

   If the prefix delegated by the uplink router changes, this means that
   the router needs to change both the /64 prefixes it is advertising in
   RAs and also get the downlink routers to which it has delegated sub-
   prefixes to get reconfigured.  For planned changes that can be
   handled by ensuring that the lifetime, T0 and T1 [RFC3315] are
   carried from the PD client in a router to its PD server.  But for
   unplanned changes, for instance when someone manually changes the
   prefixes on a CER or IR, one would like a way to have that be
   propagated to downlink PD clients.  In theory DHCP Reconfigure
   messages [RFC3315] could be used, but they require some security
   configuration.  Thus we suggest using prefix changes in received
   Router Advertisements (on the uplink interface) as a hint that the
   router's PD client should attempt to renew its DHCP lease and as a
   result of that discover changes in the delegated prefixes.

6.5.  Ensuring stable prefixes

   It is highly desirable that the home network maintain the same prefix
   allocation even if parts or all of the network are powered off and
   back on, or otherwise fail and come back.  That can be handled if the
   DHCP PD servers in each router (and also in the ISP) maintain the
   delegated prefixes in stable storage (to guard against the router
   itself failing) and also retain information about the last holder of
   a lease even after the lease has expired.  That way, as long as the
   number of downlink routers is less than the size of the pool of
   prefixes available for delegation (7 in the example above), even if a



Nordmark, et al.         Expires April 30, 2012                [Page 14]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


   downlink router is powered off for a long time, when it comes back it
   will receive the same prefix.


7.  Addressing

   This document suggests delegating Unique link-local Addresses
   [RFC4193] and IPv6 Global addresses.  The ULA can be only generated
   or manually configured at the Customer Edge Router (CER) and then
   delegated down the link the same way IPv6 Global prefix is delegated.
   A CER SHOULD be capable of delegating a ULA prefix and a IPv6 Global
   prefix obtained from the ISP.

   When the home network is initialized the hosts and routers on the
   network will start off with only having link local addresses.  They
   will use the link local addresses to bootstrap address acquisition
   using DHCP PD for the other scopes of addresses.

   Depending on whether the CER has working upstream connectivity or
   not, it is possible that differently scoped addresses/prefixes could
   be assigned to the home network.

   When the home network permanently has no upstream connectivity
   towards the ISP, it is RECOMMENDED that the CER create an Unique
   Local Prefix as specified in [RFC4193].  We recommend using a /48 ULA
   prefix as specified in that RFC.  Note that it might be difficult to
   automatically determine whether 1) the home network is permanently
   disconnected from the ISP and 2) whether a particular router is the
   CER.  Thus it is RECOMMENDED that the generation of the ULA prefix is
   triggered by manual configuration in the case of a disconnected
   network.

   Even for a connected home network it is RECOMMENDED to trigger the
   generation of the ULA manually on the CER.  The CER will then
   automatically delegate parts of that prefix concurrently with sub-
   delegating the global prefix it received from the ISP.  Potentially
   one could do this automatically by leveraging the bootstrapping
   behavior to determine whether a router is a CER or an IR, with the
   assumption that the ISP would never delegate a ULA prefix to its
   customer.  In that case, if a router receives a prefix delegation
   that contains a global prefix but no ULA, then it can assume it is
   the CER and (if it hasn't already) generate a ULA, store that ULA in
   its persistent storage, and sub-delegate the global prefix and the
   ULA in parallel to any downlink PD clients.

   In many cases the ISP will select the prefix length it will delegate.
   Thus it is RECOMMENDED that a router (CER or IR) by default set the
   prefix-length field [RFC3633] in field of a IA_PD Prefix option



Nordmark, et al.         Expires April 30, 2012                [Page 15]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


   (OPTION_IAPREFIX) to zero.  A router that has the role of a CER may
   be manually configured to request a particular prefix-length, but the
   default allocation scheme in this document assumes that IRs do not
   set the prefix-length.


8.  Basic Operations

   It is assumed that CER requests one or more IPv6 prefixes from the
   ISP Prefix delegating router for IPv6 prefixes for a specified prefix
   length if the service agreement allows the CER to support multi-level
   subnets without NAT66 [RFC6296].  Currently DHCP-PD [RFC3633] allows
   a requesting router to request a specific prefix through the IA
   prefix option.  This document discusses a simple mechanism for
   assigning and delegating prefixes through the hierarchy in the home
   network (section 6 and section 6.1).  However, the implementation
   SHOULD also support ability of the requesting router to request a
   prefix of a specific length by filling-in the Prefix Length field of
   the IA prefix option while the IPv6-prefix field being the
   unspecified address.

   In addition, this specification requires all IRs to be able to store
   and delegate prefixes on its downlink interfaces only.  The prefix
   should be stored during reboots and power failure.

   The 'Topology' section diagrams are the typical home networking
   scenarios where the above prefix delegation mechanism is believed to
   work well.

8.1.  DHCPv6 Prefix Delegation

   The DHCPv6 prefix delegation at CER follows DHCP-PD [RFC3633] in
   order to receive the Prefix(es) from the ISP Prefix delegator and it
   can act as a local prefix delegator for the home network.

   DHCP-PD [RFC3633] suggests that in a typical scenario, /48 prefix is
   assigned to the requesting router.  The operational procedures by an
   ISP might limit this default to a /56.  The CER may be configured
   with a specific prefix length to request from the delegating router.

   Thus CER will include IA_PD option(s) as specified in [RFC3633].  In
   the IA_PD Prefix option, the IPv6-Prefix field is set to zero if the
   requesting router does not have any prior knowledge about its IPv6
   Prefix.  The prefix length MAY be set between /48 and /64 inclusive
   when the requesting router likes to specify a prefix len.  By default
   the delegating router (CER and delegating IR) adds bits to the prefix
   before delegating downwards.  The automatic bits calculation and
   prefix formation is described in section 6 and 7 above.



Nordmark, et al.         Expires April 30, 2012                [Page 16]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


   The IRs also operate as a DHCP PD requesting router on their uplink
   interface, but unlike the CER there is no need to specify a prefix
   length that they will request.

   Each CER and IR SHOULD act as a default routers on its downlink
   interfaces by selecting a /64 prefix for each downlink interface and
   advertising it in Router Advertisements downlink interface.  The IRs
   can use Stateless Address Autoconfiguration to configure the IPv6
   addresses on the uplink interface as specified in [RFC4862].  If a
   CER or IR is only delegated a /64 prefix from its delegating router
   then it can advertise in Router Advertisements for one of its
   downlink interfaces, but it can not run a DHCP PD server.

   There is no need for a dynamic routing protocol since each IR will
   have a default route towards its delegating router on its uplink
   interface.


9.  Host Behavior

   Whether a host uses Stateless Address autoconfiguration or DHCPv6, it
   does not require any change due to the solutions proposed in this
   draft.


10.  Router Behavior

   All home routers (CER and IRs) behave the same as specified in
   section 6 and section 8, with the exception that a CER might be
   configured to generate a ULA prefix and delegate sub-prefixes of that
   ULA.


11.  Bootstrapping

   It is desirable that the prefix delegation flow in an orderly manner
   from the ISP to the CER and further down to the IRs, and down to
   hosts.  We do not want any prefix flapping (some IR guessing a prefix
   to advertise before it has received anything from its uplink), hence
   it is RECOMMENDED that a router wait until its PD client on the
   uplink interface has received a prefix allocation, and at that point
   in time in enable its PD server on its downlink interface and also
   enable the sending of Router Advertisements on its downlink
   interfaces.  The only exception to this is a CER which has been
   configured to generate and advertise a ULA prefix even when the ISP
   connection is down; such a CER would sub-delegate and advertise the
   ULA prefix in parallel with requesting a prefix delegation from the
   ISP.



Nordmark, et al.         Expires April 30, 2012                [Page 17]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


   The above behavior implies that when the whole home network is
   brought up (e.g., after a power failure) it might take a while until
   a host will start receiving Router Advertisement messages.  But once
   those RAs arrive they will contain at least a ULA prefix and in many
   cases both a ULA and a global prefix.


12.  What if there are loops?

   Even if the configuration falls outside of the topology constraints
   we have specified, we still want the home network to be no worse than
   the same topology with IPv4 NAT routers.  One such topology is when
   there is a L2 bridge which connects some downlink interfaces on two
   or more routers, and there are some hosts attached to that bridge
   and/or there are routers that attach their uplink interface to that
   bridge.  See Figure 6.

                      +------+--------+                    \
                      |     IPv6      |                     \
                      | Customer Edge |                      \
                      |    Router     |                      |
                      +----+-----+----+                      |
          Network A        |     |      Network B            |
    ----+-------------+----+     +---+-------------+-----    |
        |             |              |             |         |
   +----+-----+ +-----+----+    +----+-----+ +-----+----+    |
   |IPv6 Host | |IPv6 Int. |    |IPv6 Int. | |IPv6 Host |    |
   |          | | Router X |    | Router Y | |          |    | End-User
   +----------+ +-----+----+    +----+-----+ +----------+    | networks
                      |              |                       |
          Network C   |              | Network C             |
    ----+-------------+--------------+-------------+-----    |
        |             |              |             |         |
   +----+-----+ +-----+----+    +----+-----+ +-----+----+    |
   |IPv6 Host | |IPv6 Int. |    |IPv6 Int. | |IPv6 Host |    |
   |          | | Router Z |    | Router W | |          |    |
   +----------+ +-----+----+    +----+-----+ +----------+    |
                      |              |                       |
           Network E  |              | Network F             |
    ----+-------------+-----     ----+-------------+-        |
        |             |              |             |         |
   +----+-----+ +-----+----+    +----+-----+ +-----+----+    |
   |IPv6 Host | |IPv6 Host |    | IPv6 Host| |IPv6 Host |    |
   |          | |          |    |          | |          |   /
   +----------+ +-----+----+    +----------+ +----------+  /

             Figure 6: Bridge causing multiple uplink routers




Nordmark, et al.         Expires April 30, 2012                [Page 18]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


   In the figure the downlink interfaces of Router X and Router Y have
   been bridged together.  Router X and Y will have received their own
   prefix delegation from the CER.  They will each have pick some /64
   prefix from that to advertise in Router Advertisement on Network C.
   Thus one effect of the bridge is that the hosts that attach to
   network C will, following [RFC4862], configure multiple addresses on
   their interface.  The same might happen for the routers that have an
   uplink interface to Network C; they might configure multiple
   addresses on that interface.

   A second effect of the bridge is that the PD clients in router Z and
   W now has two potential DHCP PD servers.  Presumably this means that
   they pick one of them that responds to their DHCP request.  Thus
   router Z and W might end up picking a different uplink router for
   their PD allocation.  That isn't any different than in the DHCPv4 and
   NAT case.  What is different with IPv6 is that the default router
   assignment is being done using Router Advertisements, thus both
   router Z and W will end up with two default routers; X and Y. This is
   independent of which uplink router assigned them a sub-prefix.  As
   long as the home routers do not perform ingress filtering based on
   the allocated prefixes this will work, but we might want to consider
   somehow tying the PD allocation to the choice of default router?





























Nordmark, et al.         Expires April 30, 2012                [Page 19]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


                      +------+--------+                    \
                      |     IPv6      |                     \
                      | Customer Edge |                      \
                      |    Router 1   |                      |
                      +------+--------+      +------------+  |
          Network A          |               |            |  |
        +-------------+------+-------+-------+-----+      |  |
        |             |      |       |             |      |  |
   +----+-----+ +-----+----+ |  +----+-----+ +-----+----+ |  |
   |IPv6 Host | |IPv6 Host | |  |   IPv6   | |IPv6 Host | |  |
   |          | |          | |  |  Router 2| |          | |  |
   +----------+ +----------+ |  +----+-----+ +----------+ |  |
                             |       |                    |  |
                             |       +-------------+      |  |
                             |       | Network B   |      |  |
                             |       |             |      |  |
                             |  +----+-----+ +-----+----+ |  |
                             |  |   IPv6   | |IPv6 Host | |  |
                             |  |  Router 3| |          | |  |
                             |  +----+-----+ +----------+ |  |
                             |       |                    |  |
                             |       +--------------------+  |
                             |         Network C/A           |
                      +------+--------+                      | End-User
                      |     IPv6      |                      | networks
                      |    Router 4   |                      |
                      +------+--------+                      |
          Network D          |                               |
        +-------------+------+--------+---------+            |
        |             |               |         |            |
   +----+-----+ +-----+----+     +----+-----+ +-+------+-+   |
   |IPv6 Host | |IPv6 Host |     | IPv6 Host| |IPv6 Host |   |
   |          | |          |     |          | |          |   /
   +----------+ +----------+     +----------+ +----------+  /

                  Figure 7: Bridges causing uplink loops

   In Figure 7 we see a loop which is caused by having the downlink
   interface of router 3 be an attached as an uplink of router 2.  This
   means that Router 2 and Router 4 see two different uplink router;
   router 1 and router 3.

   In the IPv4 case, just as above, the default configuration of R1 and
   R3 might cause IP address conflicts since both might have
   192.168.1.1/24 as defaults on their downlink ports in which case the
   network doesn't work at all.  Just as above that can be manually
   corrected by e.g., configuring R3 to have 10.0.0.1/24 on its downlink
   interface.  In that when case R2 and R4 uses DHCPv4 they might pick



Nordmark, et al.         Expires April 30, 2012                [Page 20]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


   the DHCP response from either R1 or R3 and configure themselves to
   either have a 192.168 address and 192.168.1.1 as their default
   router, or a 10.0 address and 10.0.0.1 as a default router.  If R2
   picks picks the latter (R3), then outbound traffic will loop, since
   it will be sent to R3 which will NAT and send to R2 which will NAT
   and send to R3.  If R2 picks R1 and R4 picks R3 then traffic from R4
   to the Internet will merely go through two extra NATs.  In general we
   can't predict which DHCP server R2 and R4 will pick, hence sometimes
   the network will work and sometimes not.

   With the proposed prefix delegation scheme and associated
   bootstrapping for IPv6 things can work a little bit better, since we
   recommend that a router not enable its PD client on the downlinks
   until its PD server on the uplink has been delegated a prefix.  Thus
   R1 will be delegated a prefix from the ISP, and then assign a /64 to
   Network A and enable the PD server.  Then R2 and R4 can receive
   delegations only from R1, since R3 has not yet enabled its PD server.
   Later when R3 has received a delegation from R2 it will enable the PD
   server.  Note that it isn't much better than for IPv4 since it R4 is
   powered off and back on or just boots very slowly after a complete
   power failure it might come up after the R1 -> R2 -> R3 delegation
   chain has already occurred, in which case R4 might pick R3 as its
   delegating router.  And if R2 crashes and comes back, it might also
   pick R3 since R2's delegation to R3 will have a non-zero lifetime.

   [DISCUSSION: It is possible to improve on the above by having the PD
   client use the delegated prefix-length to determine which DHCP lease
   to accept; preferring longer prefixes will make it choose a
   delegating router which is closer to the ISP.  In the above example
   R1 might delegate /59 prefixes while R3 can delegate only /64
   prefixes.  But it isn't clear that such added complexity is worth-
   while.  Note that for that to help we'd also need to pick the
   delegating router as the default router, instead of building a
   default router list with all the routers which send RAs.


13.  Security Considerations

   No new threats against Neighbor Discovery beyond what is already
   documented for IPv6 ND [RFC3756] due to IPv6 Address
   autoconfiguration and Neighbor Discovery at the last hop of Prefix
   distribution.  The recommendations in this document does not prevent
   using Secure Neighbor Discovery [RFC3971].

   The security threats for this solution is believed to be no worse
   than DHCPv6 Prefix delegation[RFC3633].  See Section 15 of RFC 3633
   for further information.




Nordmark, et al.         Expires April 30, 2012                [Page 21]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


   A malicious host inside the end user network can perform a prefix
   exhaustion attack on the CER or the IRs.  It works as follows; the
   malicious router keeps on requesting prefixes from the delegating
   router (DR), which could be the CER or another IR, until all the
   prefixes have been delegated.  At this point a legitimate router that
   attaches to the delegating router will fail to get a prefix delegated
   as the DR has no more prefixes available to delegate.  This means
   that the subset of the network behind this newly attaching router
   will not get any connectivity.  This can be avoided by using some
   form of authorization on the delegating router but the specification
   of such a mechanism is outside the scope of this document.  It might
   make sense to offer configuration capability so that prefix
   delegation can be disables on certain links such as a guest network.


14.  IANA Considerations

   This document does not require any IANA actions.


15.  Acknowledgements

   The authors like to thank David Allan, Joel Halpern, Acee Lindem and
   Jari Arkko for comments on the proposal of the draft.  Alan Kavangh
   suggested using the default prefix len(/56) as per Broadband Forum's
   recommendation.  We thank Tim Chown for the ASCII-art drawings that
   we reused and in some cases expanded on it this draft.


16.  References

16.1.  Normative References

   [I-D.chown-homenet-arch]
              Arkko, J., Chown, T., Weil, J., and O. Troan, "Home
              Networking Architecture for IPv6",
              draft-chown-homenet-arch-00 (work in progress),
              September 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,



Nordmark, et al.         Expires April 30, 2012                [Page 22]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

16.2.  Informative References

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

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

   [RFC3756]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
              Discovery (ND) Trust Models and Threats", RFC 3756,
              May 2004.

   [RFC3769]  Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
              Delegation", RFC 3769, June 2004.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC6296]  Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
              Translation", RFC 6296, June 2011.


Authors' Addresses

   Erik Nordmark
   Cisco Systems
   San Jose, CA
   USA

   Email: nordmark@cisco.com


   Samita Chakrabarti
   Ericsson
   San Jose, CA
   USA

   Email: samita.chakrabarti@ericsson.com




Nordmark, et al.         Expires April 30, 2012                [Page 23]

Internet-Draft      Simple Approach to Basic Homenet        October 2011


   Suresh Krishnan
   Ericsson
   Montreal,
   CANADA

   Email: suresh.krishnan@ericsson.com


   Wassim Haddad
   Ericsson
   San Jose, CA
   USA

   Email: wassim.haddad@ericsson.com





































Nordmark, et al.         Expires April 30, 2012                [Page 24]