One document matched: draft-baker-homenet-prefix-assignment-00.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-00"
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="2011" />
<area>Internet Engineering Task Force</area>
<workgroup></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>
-->
<note title="Requirements">
<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>
</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>
<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 prefxies 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. 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.</t>
<t>The CPE router includes a Router Advertisement Allocator
Information (RAAI) option, identifying itself as the
allocating server for prefixes related to the prefix announced
in the RA. 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 is 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 uses 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 with an RAAI
option, the router initiates a DHCPv6 message exchange to
obtain 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.
<list style="hanging">
<t hangText="Discussion:">The interior router conducts the
DHCPv6 message exchange directly with the allocating
DHCPv6 server using IPv6 unicast. This technique assumes
that the interior router has already obtained an address
of sufficient scope through SLAAC or an earlier DHCPv6
address assignment. This technique also breaks the rule
in RFC 3315 requiring the use of multicast and the DHCPv6
client's link-local address.</t>
<t>The requirements regarding DHCPv6 message addressing in
RFC 3315 are based primarily on the need for some sort of
address on the DHCPv6 client before address assigment is
completed and the desire to forward all DHCPv6 traffic
through a relay agent to allow for relay agent
processing. The procedures in this specification require
that the interior router (DHCPv6 client) already has an
IPv6 address of sufficient scope before initiating any
DHCPv6 message exchanges for prefix delegation. There is
no need, in this specification, for realy agent
processing, so direct communication between the interior
router and the allocating DHCPv6 server is allowed.</t>
<t>The primary advantage to allowing direct DHCPv6 message
exchanges in this specification is the avoiding the need
for a relay agent infrastrcuture throughout the network.
Otherwise, each interior router would have to act as a
realy agent for potentially several DHCPv6 servers
delegating prefixes for the network.</t>
</list>
</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
interior router includes an RAAI option in the RAs,
indentifying the CPE router as the allocating DHCPv6 server.
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.</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 </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 title="Original Introduction">
<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="sect2.1"
title="Allocating a prefix from the upstream network">
<t><xref target="RFC3315"></xref> and <xref target="RFC3363"></xref>
describe a means by which a CPE Router may request an upstream network
to allocate a prefix to it. The CPE uses this mechanism.</t>
</section>
<section anchor="interior_router" title="Prefix allocation by the CPE Router">
<t>The CPE Router now allocates a prefix to each of its own
interfaces. It MAY implement an <xref target="RFC4389">Neighbor
Discovery Proxy</xref> and appropriate forwarding to use the same
prefix on multiple interfaces, but the generally RECOMMENDED procedure
is to allocate a different prefix to each interface and route among
them.</t>
<t>It now uses the Router Advertisement of <xref target="RFC4861">IPv6
Neighbor Discovery</xref><xref target="RFC3971"></xref> to announce
the prefixes it has allocated to each LAN or set of LANs. In that RA,
it also announces itself as a DHCPv6 allocator (see <xref
target="allocator"></xref>).</t>
</section>
<section anchor="sect2.3"
title="Prefix allocation by a subsquent router">
<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, and applies the announced prefix to the
interface for the purposes of routing.</t>
<t>It then waits INTERVAL1 microfortnights, to allow other routers in
the network that happen to be on the same LAN to also join the
subnet.</t>
<t>Finally, it uses <xref target="RFC3363"></xref> to allocate a
prefix from each advertised allocator. Since packets may be lost in
the network and the allocator may ignore requests to manage race
conditions, the router MUST repeat unsatisfied requests periodically
until they are satisfied. This SHOULD be no more frequently than once
per INTERVAL2 microfortnights, and the interval SHOULD be
randomised.</t>
<t>Having allocated a prefix from one or more allocators, it announces
prefixes in an RA as described in <xref target="interior_router"></xref>, with
the proviso that it announces the allocator for the upstream prefix
rather than itself. If there are other "subsequent" routers beyond it,
they will similarly use the procedure of this section to allocate
prefixes as needed.</t>
</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="allocator"
title="Router Advertisement Allocator Information Element ">
<t>On a Neighbor Discovery RA, <xref target="interior_router"></xref> and <xref
target="interior_router"></xref> call for the RA to identify the allocator that
a "subsequent" router may use to request a related prefix for use on a
different interface. This information element contains a list of the
IPv6 addresses of one or more allocators, and an element length option
to permit parsing of the information element.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>In <xref target="allocator"/>, this note specifies an
information element to be carried in the Router Advertisement
message specified in Neighbor Discovery.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t><TBD></t>
<section anchor="Privacy" title="Privacy Considerations">
<t><TBD></t>
</section>
</section>
<!--
<section anchor="Acknowledgements" title="Acknowledgements">
<t></t>
</section>
-->
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">4 Octoboer 2011</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 setion 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.3971" ?>
<?rfc include="reference.RFC.4389" ?>
<?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 20:34:50 |