One document matched: draft-baker-homenet-prefix-assignment-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info" docName="draft-baker-homenet-prefix-assignment-01"
ipr="trust200902">
<front>
<title abbrev="Prefix Assignment">IPv6 Prefix Assignment in Small
Networks</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<author fullname="Ralph Droms" initials="R. E." surname="Droms">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>1414 Massachusetts Avenue</street>
<city>Boxborough</city>
<code>01719</code>
<region>Massachusetts</region>
<country>USA</country>
</postal>
<email>rdroms@cisco.com</email>
</address>
</author>
<date year="2012" />
<area>Internet Area</area>
<workgroup>Home Networking</workgroup>
<abstract>
<t>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.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section anchor="intro" title="Introduction">
<t>One of the objectives of the design of <xref target="RFC2460">IPv6
</xref> has been to reduce or minimize the need for manual configuration
in networks. <xref target="RFC0791">IPv4 </xref> 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 <xref target="RFC2131">Dynamic Host
Configuration Protocol</xref> (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 <xref target="RFC6241">Network
Configuration Protocol</xref><xref target="RFC6242"></xref> have been
preferred.</t>
<t>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: <list
style="symbols">
<t>IPv6 prefixes are allocated to a small network by one or more
upstream service providers using <xref target="RFC3315"></xref> and
<xref target="RFC3363"></xref>.</t>
<t>IPv6 prefixes may allocated to LAN within a small network by the
CPE Router using <xref target="RFC3315"></xref> and <xref
target="RFC3363"></xref>.</t>
<t>Occasional inefficiencies such as allocating two /64s to a LAN
from a given upstream prefix are acceptable, especially if
short-lived.</t>
<t>Small networks, such as described in <xref
target="I-D.chown-homenet-arch">Home Networking Architecture for
IPv6</xref>, are simple enough in structure that the mechanism
described in this note is adequate.</t>
</list></t>
<t>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.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
</section>
<section anchor="scope" title="Scope of this Document">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="simple_tree" title="Simple Tree Network Case">
<t>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.</t>
<t>The fundamental procedure for prefix allocation takes three phases:
<list style="symbols">
<t>Allocating a prefix from the upstream network,</t>
<t>Prefix allocation by the CPE Router, and</t>
<t>Prefix allocation by a subsequent router.</t>
</list></t>
<section anchor="dhcp"
title="Assignment of prefixes in a simple network">
<t>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.</t>
<t>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.</t>
<section anchor="CPE_Router" title="CPE Router Behavior">
<t>The CPE router obtains a delegated prefix from the SP
provisioning system using <xref target="RFC3315"></xref> and <xref
target="RFC3363"></xref> and other appropriate provisioning systems.
The prefix delegated from the service provider includes a preferred
and valid lifetime for the prefix.</t>
<t>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.</t>
<t>After assigning the interface addresses, the CPE router begins
sending Router Advertisement (RA) messages <xref
target="RFC4861"></xref> 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.</t>
<t>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 <xref target="RFC3315"></xref> and <xref
target="RFC3363"></xref> to maintain and update its delegated
prefix.</t>
<t>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 preferred and valid lifetimes for the subdelegated
prefixes from the values received from the service provider.</t>
</section>
<section anchor="interior_router" title="Interior Router Behavior">
<t>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.</t>
<section anchor="tree_topology" title="Network with a Tree Topology">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="non-tree_topology" title="Non-tree Topologies">
<t>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.</t>
<t>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 and initiates the DHCPv6 process
for obtaining a delegated prefix.</t>
<t>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. <list>
<t>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.</t>
</list></t>
<t>If a router hears an RA such as described in <xref
target="interior_router"></xref>, it uses <xref
target="RFC4862">IPv6 Stateless Address
Autoconfiguration</xref><xref target="RFC4941"></xref> or a <xref
target="RFC3315">DHCPv6</xref> request to each announced allocator
to generate an address within the prefix for use in that
subnet.</t>
<t>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.</t>
</section>
<section anchor="multihomed_net" title="Multi-homed Network">
<t>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.</t>
<t>Each CPE router obtains a delegated prefix from its service
provider and then manages the prefix according to the discussion
in <xref target="intro"></xref>.</t>
<t>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.</t>
<t>Next layer receives DHCPv6 transaction from each CPE router
because upstream router forwards DHCPv6 messages to each of the
CPE routers.</t>
</section>
</section>
</section>
</section>
<section anchor="issues" title="Issues in a simple cascade procedure">
<t>There are a number of potential issues in this procedure.</t>
<section title="Sequence of subnet number allocation">
<t>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.</t>
</section>
<section anchor="multihoming" title="Multihoming Issues">
<t>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.</t>
</section>
<section anchor="racing" title="Race Conditions">
<t>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.</t>
<t>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 <xref
target="interior_router"></xref> is to allow this race condition to
stabilize before the router acts on this information it has.</t>
<t>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 <xref target="interior_router"></xref>
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.</t>
<t>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
least subnet number SHOULD NOT allow its prefix to expire, but any
others SHOULD allow their prefixes to expire.</t>
</section>
<section anchor="scaling" title="Scaling Issues">
<t>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.</t>
<t>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.</t>
</section>
<section anchor="stability" title="Prefix Stability">
<t>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.</t>
</section>
<section anchor="toosmall" title="When you run out of prefixes">
<t>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.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This specification makes no request of the IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t><TBD></t>
<section anchor="Privacy" title="Privacy Considerations">
<t><TBD></t>
</section>
</section>
<!--
<section anchor="Acknowledgments" title="Acknowledgments">
<t></t>
</section>
-->
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">4 October 2011</t>
<t hangText="March 2012">Removed RA option.</t>
<!--
<t hangText="Rev 01:">28 September 2011, RD</t>
<t>Added section 2 describing scope of document.</t>
<t>Added section 3 describing a simple tree use case and
section 4 describing how to use DHCPv6 for prefix assignment
from the CPE router to the interior routers.</t>
<t>Discussion in section 3 regarding use of direct unicast
for DHCPv6.</t>
-->
</list></t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.chown-homenet-arch" ?>
<?rfc include="reference.RFC.0791"?>
<?rfc include="reference.RFC.2131" ?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.3315" ?>
<?rfc include="reference.RFC.3363" ?>
<?rfc include="reference.RFC.4861" ?>
<?rfc include="reference.RFC.4862" ?>
<?rfc include="reference.RFC.4941" ?>
<?rfc include="reference.RFC.6241" ?>
<?rfc include="reference.RFC.6242" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:24:37 |