Internet DRAFT - draft-baker-homenet-prefix-assignment

draft-baker-homenet-prefix-assignment






Home Networking                                                 F. Baker
Internet-Draft                                                  R. Droms
Intended status: Informational                             Cisco Systems
Expires: September 9, 2012                                 March 8, 2012


                IPv6 Prefix Assignment in Small Networks
                draft-baker-homenet-prefix-assignment-01

Abstract

   It is necessary to allocate prefixes in small networks, which include
   residential and Small Office/Home Office (SOHO) networks in a manner
   that minimizes or eliminates manual configuration.  This note
   suggests an approach.

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 September 9, 2012.

Copyright Notice

   Copyright (c) 2012 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.




Baker & Droms           Expires September 9, 2012               [Page 1]

Internet-Draft              Prefix Assignment                 March 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Scope of this Document . . . . . . . . . . . . . . . . . . . .  4
   3.  Simple Tree Network Case . . . . . . . . . . . . . . . . . . .  4
     3.1.  Assignment of prefixes in a simple network . . . . . . . .  5
       3.1.1.  CPE Router Behavior  . . . . . . . . . . . . . . . . .  5
       3.1.2.  Interior Router Behavior . . . . . . . . . . . . . . .  6
   4.  Issues in a simple cascade procedure . . . . . . . . . . . . .  7
     4.1.  Sequence of subnet number allocation . . . . . . . . . . .  8
     4.2.  Multihoming Issues . . . . . . . . . . . . . . . . . . . .  8
     4.3.  Race Conditions  . . . . . . . . . . . . . . . . . . . . .  8
     4.4.  Scaling Issues . . . . . . . . . . . . . . . . . . . . . .  9
     4.5.  Prefix Stability . . . . . . . . . . . . . . . . . . . . .  9
     4.6.  When you run out of prefixes . . . . . . . . . . . . . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
     6.1.  Privacy Considerations . . . . . . . . . . . . . . . . . . 10
   7.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11



























Baker & Droms           Expires September 9, 2012               [Page 2]

Internet-Draft              Prefix Assignment                 March 2012


1.  Introduction

   One of the objectives of the design of IPv6 [RFC2460] has been to
   reduce or minimize the need for manual configuration in networks.
   IPv4 [RFC0791] networks, when it became widely deployed in the
   1980's, required manual configuration, and the scaling limits of the
   approach quickly became apparent.  One of the outcomes of that was
   the Dynamic Host Configuration Protocol [RFC2131] (DHCP), which
   facilitated central administration of desktop computers.  In
   practice, DHCP itself has been of limited utility in the
   administration of network equipment; while it is conceptually
   possible to use it for any kind of configuration, more flexible
   protocols such as the Network Configuration Protocol
   [RFC6241][RFC6242] have been preferred.

   Allocation of prefixes in small networks calls for an approach that
   can be completely automated.  This note documents a procedure that
   has been suggested by several.  It builds on a few basic assumptions:

   o  IPv6 prefixes are allocated to a small network by one or more
      upstream service providers using [RFC3315] and [RFC3363].

   o  IPv6 prefixes may allocated to LAN within a small network by the
      CPE Router using [RFC3315] and [RFC3363].

   o  Occasional inefficiencies such as allocating two /64s to a LAN
      from a given upstream prefix are acceptable, especially if short-
      lived.

   o  Small networks, such as described in Home Networking Architecture
      for IPv6 [I-D.chown-homenet-arch], are simple enough in structure
      that the mechanism described in this note is adequate.

   These assumptions bear analysis.  The first two, that prefixes can
   and may be allocated using mechanisms designed for the purpose, seems
   self-evident.  The third builds on the IPv6 premise that a host may
   have more than one prefix on an interface and one or more addresses
   in each prefix; in such a case, while it may be suboptimal to
   allocate more than one /64 from the same upstream prefix, the hosts
   will not complain and the routing protocols will route them.  The
   fourth may be considered the limit of applicability; if a network
   requires a prefix aggregation design or is otherwise too complex for
   this procedure to be effective, other procedures are more
   appropriate.







Baker & Droms           Expires September 9, 2012               [Page 3]

Internet-Draft              Prefix Assignment                 March 2012


1.1.  Requirements Language

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


2.  Scope of this Document

   This document describes a procedure for prefix delegation and
   assignment.  It results in the assignment of a series of /64 prefixes
   on the links in a small home network.

   While this document describes the use of DHCPv6 for prefix
   delegation, specification of the use of DHCPv6 for address assignment
   and other purposes is out of scope.

   If a network includes interior routers and the CPE router is not
   directly to all of the links in the network, the routers in the
   network will need routing information to forward traffic in the
   network and between the network and the service provider network.
   The specification of a routing protocol or other mechanism to provide
   that routing information to the routers is beyond the scope of this
   document.


3.  Simple Tree Network Case

   The first case to describe is that of a network with a simple tree
   topology.  In this network, there is a single CPE router attached to
   a single SP network.  The interior of the network is organized as a
   tree.  Each interior router has one "upstream" interface and one or
   more "downstream" interfaces.  Each link in the network has a single
   interior router with a downstream interface attached and zero or more
   interior routers with an upstream interface attached.

   The fundamental procedure for prefix allocation takes three phases:

   o  Allocating a prefix from the upstream network,

   o  Prefix allocation by the CPE Router, and

   o  Prefix allocation by a subsequent router.








Baker & Droms           Expires September 9, 2012               [Page 4]

Internet-Draft              Prefix Assignment                 March 2012


3.1.  Assignment of prefixes in a simple network

   This section describes the assignment of prefixes in a simple
   network.  The network is assumed to be tree-structured, including one
   CPE router that is connected to a SP network and one or more interior
   routers.  The interior routers each have a single "upstream"
   interface and one or more "downstream" interfaces.  The upstream
   interface of each interior router is connected to a link in the
   network to which a downstream interface of a router closer to the CPE
   router is already connected.

   The CPE router obtains a delegated prefix for the entire home
   network, and manages prefix allocations for all of the interior
   routers.  Each interior router uses DHCPv6 on its upstream interface
   to obtain delegated prefixes from the CPE router for each of the
   interior routers downstream interfaces.

3.1.1.  CPE Router Behavior

   The CPE router obtains a delegated prefix from the SP provisioning
   system using [RFC3315] and [RFC3363] and other appropriate
   provisioning systems.  The prefix delegated from the service provider
   includes a preferred and valid lifetime for the prefix.

   Once the CPE router has received a delegated prefix, it assigns a /64
   subprefix to each of the links to which the router is attached.  The
   CPE router configures an address to each of its interfaces from the
   prefix assigned to the link to which the interface is attached.

   After assigning the interface addresses, the CPE router begins
   sending Router Advertisement (RA) messages [RFC4861] advertising the
   appropriate prefix on each attached link.  The RAs include preferred
   and valid lifetimes derived from the lifetimes associated with the
   delegated prefix from the service provider.  The RA also advertises
   the CPE router as the default router for the link.  Other fields in
   the RAs are set as appropriate.

   At this point, the links to which the CPE router is attached are now
   provisioned with prefixes taken from the prefix obtained from the
   service provider.  The CPE router uses ongoing DHCPv6 messages
   exchanges according to [RFC3315] and [RFC3363] to maintain and update
   its delegated prefix.

   The CPE router implements a DHCPv6 server for prefix subdelegation
   throughout the rest of the network.  In preparation for assigning
   prefixes to links in the rest of the network, the CPE router makes
   all of the remaining prefixes from the network prefix available for
   subdelegation through a DHCPv6 server.  The CPE router configures the



Baker & Droms           Expires September 9, 2012               [Page 5]

Internet-Draft              Prefix Assignment                 March 2012


   preferred and valid lifetimes for the subdelegated prefixes from the
   values received from the service provider.

3.1.2.  Interior Router Behavior

   When an interior router is connected to the home network, its
   upstream interface is attached to a link in the home network, and its
   downstream interfaces are connected to other links to be added to the
   home network.

3.1.2.1.  Network with a Tree Topology

   After the upstream interface is attached to a link, the interior
   router listens for RAs on the upstream interface and configures the
   upstream interface according to the information contained in the
   received RAs.

   When the interior router receives an RA, the router initiates a
   DHCPv6 message exchange to obtain any needed prefixes from the prefix
   managed by the allocating router.  The interior router requests the
   delegation of a separate /64 prefix for each of its downstream
   interfaces.  The DHCPv6 service in the home network delivers the
   DHCPv6 traffic between the interior router and the CPE router.

   The CPE router delegates the requested prefixes from the prefix
   delegated to the network.  The interior router then assigns a prefix
   to each link attached to which a downstream interface is attached,
   configures those downstream interfaces with addresses from the
   assigned prefixes and begins sending RAs on the downstream
   interfaces.  The preferred and valid lifetimes for the advertised
   prefix are derived from the lifetimes in the DHCPv6 delegation, and
   the RAs advertise the interior router as the default router for the
   link.

3.1.2.2.  Non-tree Topologies

   It is quite likely that real world deployments will violate the
   assumption in the previous section that only one downstream interface
   will be attached to each link in the home network.  In this
   situation, it is desirable that the link only be assigned one prefix
   and, therefore, only one of the interior routers with a downstream
   interface on the link be responsible for assigning a prefix and
   sending RAs on the link.

   To avoid duplicate address assignment, a router first listens for RAs
   on the link attached to its downstream interface.  If the router does
   not receive an RA after listening for INTERVAL1 microfortnights, the
   router assumes it is responsible for assigning a prefix to that link



Baker & Droms           Expires September 9, 2012               [Page 6]

Internet-Draft              Prefix Assignment                 March 2012


   and initiates the DHCPv6 process for obtaining a delegated prefix.

   After the router determines it is responsible for the link attached
   to its downstream interface, it continues to listen for RAs from
   other routers on the link.  If it receives an RA from another router,
   it deassigns its delegated prefix from the link, unconfigures any
   addresses assigned from that prefix and releases the delegated prefix
   to the CPE router using DHCPv6.

      Discussion: there is a race condition in this; two routers may
      make the decision to manage the link's prefix simultaneously.  To
      avoid this, the timing should be jittered enough to make this
      unlikely.

   If a router hears an RA such as described in Section 3.1.2, it uses
   IPv6 Stateless Address Autoconfiguration [RFC4862][RFC4941] or a
   DHCPv6 [RFC3315] request to each announced allocator to generate an
   address within the prefix for use in that subnet.

   After the router determines that some other router is responsible for
   the link attached to its downstream interface, it continues to listen
   on the interface for RAs.  If the router receives no RA on the
   interface for INTERVAL2 microfortnights, the router takes
   responsibility for the link and initiates the process described above
   to obtain and assign a prefix to the link.

3.1.2.3.  Multi-homed Network

   If a network has multiple service provider networks, it will have
   multiple prefixes.  This situation is easiest to describe if the
   network is connected to each service provider through a separate CPE
   router.

   Each CPE router obtains a delegated prefix from its service provider
   and then manages the prefix according to the discussion in Section 1.

   First layer of interior router get multiple direct DHCPv6 prefixes.
   Assigns each prefix in parallel.  Sets up DHCPv6 relay agent to point
   to each of the CPE routers.

   Next layer receives DHCPv6 transaction from each CPE router because
   upstream router forwards DHCPv6 messages to each of the CPE routers.


4.  Issues in a simple cascade procedure

   There are a number of potential issues in this procedure.




Baker & Droms           Expires September 9, 2012               [Page 7]

Internet-Draft              Prefix Assignment                 March 2012


4.1.  Sequence of subnet number allocation

   Apart from cases in which the administration has chosen to fix a
   given subnet to a given LAN, such as to support server deployment in
   DNS, it is generally advised that subnet numbers be randomized.  This
   is to make certain network attacks a little more difficult.

4.2.  Multihoming Issues

   One issue is "what happens if one has multiple upstream networks with
   multiple CPE Routers and therefore multiple allocators?"  The design
   of the RA information element announcing the allocator is intended to
   simplify that by announcing an allocator.

4.3.  Race Conditions

   In the simplest case, there are no race conditions; the home has
   exactly one router, it obtains a prefix from its upstream network,
   and sub-allocates to its interfaces.  If there are additional routers
   in the home, however, either there are one or more links that are not
   attached to the CPE Router or there are zero; in the event that there
   are one or more such links, they may be connected by one router or by
   multiple routers.

   One race condition is when two interior routers are attached to the
   same LANs as the CPE.  For example, one might have a wireless router
   in the home that connects both to the wired and the wireless network
   that the CPE Router is on.  In such a case, it will hear and
   interpret one of the CPE Router's RAs first, and then the other some
   amount of time later.  The purpose of the INTERVAL1 delay in
   Section 3.1.2 is to allow this race condition to stabilize before the
   router acts on this information it has.

   A second race condition occurs when two "subsequent" routers are on
   the same LAN but it is not serviced by the CPE Router.  These routers
   will both use the procedure of Section 3.1.2 to attempt to allocate a
   prefix to the LAN and so create a subnet.  It is RECOMMENDED that the
   allocator allocate at most one prefix per INTERVAL2, ignoring all
   other requests, in order to allow the "subsequent" routers to sort
   out this class of race condition.  If needed, ignored routers will
   re-request the allocation.

   Due to the possibility of packet loss in the network, it is possible
   that these race conditions may result in a given LAN developing
   multiple subnets.  While suboptimal, this is not a violation of the
   architecture and should cause no issues.  However, in the event that
   two routers observe that they are announcing different subnets in the
   same upstream prefix on the same LAN, the one with the numerically



Baker & Droms           Expires September 9, 2012               [Page 8]

Internet-Draft              Prefix Assignment                 March 2012


   least subnet number SHOULD NOT allow its prefix to expire, but any
   others SHOULD allow their prefixes to expire.

4.4.  Scaling Issues

   Obviously, use of this procedure in a complex network results in a
   serialization of prefix allocation that may take more time to settle
   than is operationally desirable (number of LANs times INTERVAL2).  In
   such cases, the administration will have to decide how it wants to
   handle the issue.  One approach would be to divide the network into
   easily-aggregated sections and use the procedure within each section;
   another would be to use a different procedure.

   In such networks, the routers requesting prefixes can also act as a
   denial of service attack, by flooding the CPE Router with requests.
   Given that the procedure eventually terminates, this is undesirable
   but of limited duration.

4.5.  Prefix Stability

   In networks that contain servers or names that are announced in DNS,
   it is often valuable to have the same LAN always have the same subnet
   number applied to it.  The procedure as described could accomplish
   that if the CPE Router maintains memory of what router it has
   allocated a given prefix to recently, or would fail to provide that
   if it does not.  The distinction is essentially a marketing
   requirement that the implementation will need to decide for itself.

4.6.  When you run out of prefixes

   If a network runs out of subnet numbers and therefore subnet
   prefixes, this is considered a provisioning failure.  It can result
   when multiple prefixes are allocated to the same LAN, which should be
   unusual and will end when one of the routers releases its prefix.  It
   can also result when the upstream network allocates a prefix that is
   too long and as a result contains too few potential prefixes.  In
   that case, the administration is forced to either reorganize its
   network or negotiate for a shorter prefix.


5.  IANA Considerations

   This specification makes no request of the IANA.


6.  Security Considerations

   <TBD>



Baker & Droms           Expires September 9, 2012               [Page 9]

Internet-Draft              Prefix Assignment                 March 2012


6.1.  Privacy Considerations

   <TBD>


7.  Change Log

   Initial Version:  4 October 2011

   March 2012  Removed RA option.


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.

8.2.  Informative References

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

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

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

   [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
              Hain, "Representing Internet Protocol version 6 (IPv6)
              Addresses in the Domain Name System (DNS)", RFC 3363,
              August 2002.

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



Baker & Droms           Expires September 9, 2012              [Page 10]

Internet-Draft              Prefix Assignment                 March 2012


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

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)",
              RFC 6241, June 2011.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, June 2011.


Authors' Addresses

   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Email: fred@cisco.com


   Ralph Droms
   Cisco Systems
   1414 Massachusetts Avenue
   Boxborough, Massachusetts  01719
   USA

   Email: rdroms@cisco.com



















Baker & Droms           Expires September 9, 2012              [Page 11]