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

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2011-10-04
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           F. Baker
Internet-Draft                                                  R. Droms
Intended status: Informational                             Cisco Systems
Expires: April 6, 2012                                   October 4, 2011

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

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.

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

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

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

Baker & Droms             Expires April 6, 2012                 [Page 1]
Internet-Draft              Prefix Assignment               October 2011

   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.  Scope of this Document . . . . . . . . . . . . . . . . . . . .  4
   3.  Simple Tree Network Case . . . . . . . . . . . . . . . . . . .  4
     3.1.  Assignment of prefxies in a simple network . . . . . . . .  4
       3.1.1.  CPE Router Behavior  . . . . . . . . . . . . . . . . .  5
       3.1.2.  Interior Router Behavior . . . . . . . . . . . . . . .  5
   4.  Issues in a simple cascade procedure . . . . . . . . . . . . .  8
     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.  Router Advertisement Allocator Information Element . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
     7.1.  Privacy Considerations . . . . . . . . . . . . . . . . . . 10
   8.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

Baker & Droms             Expires April 6, 2012                 [Page 2]
Internet-Draft              Prefix Assignment               October 2011

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.
Show full document text