A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block
RFC 3531

Document Type RFC - Informational (April 2003; No errata)
Last updated 2015-10-14
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3531 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Thomas Narten
IESG note appears 2003-04-28.
Send notices to <mrw@windriver.com>
Network Working Group                                        M. Blanchet
Request for Comments: 3531                                      Viagenie
Category:Informational                                        April 2003

         A Flexible Method for Managing the Assignment of Bits
                        of an IPv6 Address Block

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document proposes a method to manage the assignment of bits of
   an IPv6 address block or range.  When an organisation needs to make
   an address plan for its subnets or when an ISP needs to make an
   address plan for its customers, this method enables the organisation
   to postpone the final decision on the number of bits to partition in
   the address space they have.  It does it by keeping the bits around
   the borders of the partition to be free as long as possible.  This
   scheme is applicable to any bits addressing scheme using bits with
   partitions in the space, but its first intended use is for IPv6.  It
   is a generalization of RFC 1219 and can be used for IPv6 assignments.

Table of Contents

   1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  Description of the Algorithm . . . . . . . . . . . . . . . . .  3
     3.1 Leftmost . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.2 Rightmost  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.3 Centermost . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
       References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
       Full Copyright Statement . . . . . . . . . . . . . . . . . . .  7

Blanchet                     Informational                      [Page 1]
RFC 3531        Bits Assignment of an IPv6 Address Block      April 2003

1. Rationale

   IPv6 addresses have a flexible structure for address assignments.
   This enables registries, internet service providers, network
   designers and others to assign address ranges to organizations and
   networks based on different criteria, like size of networks,
   estimated growth rate, etc.  Often, the initial assignment doesn't
   scale well because a small network becomes larger than expected,
   needing more addresses.  But then, the assignment authority cannot
   allocate contiguous addresses because they were already assigned to
   another network.

   RFC 1219 [1] describes an allocation scheme for IPv4 where address
   space is kept unallocated between the leftmost bits of the subnet
   part and the rightmost bits of the host part of the address.  This
   enables the network designer to change the subnet mask without
   renumbering, for the central bits not allocated.

   This work generalizes the previous scheme by extending the algorithm
   so it can be applied on any part of an IP address, which are assigned
   by any assignment authority level (registries, ISPs of any level,
   organizations, ...).  It can be used for both IPv4 and IPv6.

   This document does not provide any recommendation to registries on
   how to assign address ranges to their customers.

2. Scheme

   We define parts of the IP address as p1, p2 , p3, ...  pN in order,
   so that an IP address is composed of these parts contiguously.
   Boundaries between each part are based on the prefix assigned by the
   next level authority.  Part p1 is the leftmost part probably assigned
   to a registry, Part p2 can be allocated to a large internet service
   provider or to a national registry.  Part p3 can be allocated to a
   large customer or a smaller provider, etc.  Each part can be of
   different length.  We define l(pX) the length of part X.

   +------+------+------+------+------+------+
   | p1   | p2   | p3   | p4   | ...  | pN   |
   +------+------+------+------+------+------+
   <------- ipv6 or ipv4 address ------------>

   The algorithm for allocating addresses is as follows: a) for the
   leftmost part (p1), assign addresses using the leftmost bits first b)
   for the rightmost part (pN), assign addresses using the rightmost
   bits first c) for all other parts (center parts), predefine an
   arbitrary boundary (prefix) and then assign addresses using the
   center bits first of the part being assigned.
Show full document text