One document matched: draft-baker-ipv6-prefix-subdelegation-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-ipv6-prefix-subdelegation-00"
ipr="trust200902">
<front>
<title abbrev="Prefix Sub-delegation">Prefix Sub-delegation in a SOHO/SMB
Environment</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>
<date year="2009" />
<area>Internet</area>
<workgroup>IPv6 Maintenance</workgroup>
<abstract>
<t>This memo considers the question of IPv6 prefix sub-delegation.</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>
-->
<!--
<?rfc needLines="10" ?>
<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 title="Introduction">
<t>In the IPv6 Operations Working Group and the Homegate BOF, there have
been questions raised about IPv6 Prefix Sub-delegation. In short, the
CPE Router documents would like to require an algorithm for
sub-delegation, and the indicated document does not exist. This note is
intended to raise the question to the IPv6 Maintenance Working
Group.</t>
<t>By IPv6 Prefix Sub-delegation, we refer to the issue that an upstream
provider delegates a prefix to a downstream network such as a home or
small business, which is turn allocates prefixes to LANs and other
structures within its domain. The means of delegation to the SOHO/SMB is
not really important here, although we note that DHCP has a <xref
target="RFC3633">tool</xref> for the purpose. In general, this is
presumed to apply to networks using <xref target="RFC2460">IPv6</xref>
and using addressing conforming to the <xref target="RFC4291">IPv6
Addressing Architecture</xref>.</t>
</section>
<section anchor="SmallNetworks"
title="Assigning prefixes to small networks">
<t>There are several special cases that are relatively easily solved,
and more complex cases that can be solved by divide-and-conquer methods.
The most general case, that of assigning subnet numbers throughout an
arbitrary complex topology, may be beyond algorithmic description. Here
we walk through some of the simpler cases.</t>
<section anchor="soho64" title="Single-router network assigned a /64">
<t>The simplest residential case, that of <xref
target="single"></xref>, is that of an apartment or single family
dwelling whose upstream provider delegates a single /64 to it. Such a
SOHO probably has multiple internal LANs (wired and wireless), and
uses a single residential CPE router. In this case, there are few
choices. As described in passing in <xref target="RFC2460"></xref> in
that a prefix can be assigned to a "set of interfaces", the CPE Router
uses the delegated prefix on all of its non-upstream interfaces, and
tracks the location of various devices on its LANs.</t>
<t>For external routing, it assigns a single default route to its
upstream router.</t>
<t>There are some complexities in this architecture, as it doesn't
scale well to add even a second router. While a single CPE router can
track the addresses allocated by other devices, it will be forced to
proxy for them in <xref target="RFC4862">Neighbor Discovery</xref>; it
will respond to a Neighbor Solicitation for a device on another
interface, including a device using a link-local address. This will
create issues in <xref target="RFC3971"> Secure Neighbor
Discovery</xref>, in that it will not have the private key of the
device it is proxying for. However, it can enable the connection of
devices on its various LANs by this means. Vendor implementations may
well choose to implement this using IEEE 802.1 technology for
simplicity, to make it appear to be one interface to the software.</t>
<figure anchor="single" title="SOHO with /64 prefix">
<artwork align="center"><![CDATA[
-------
// \\ //
/ \ /
/ Wired LAN \ /
| ----------- | |
|prefix +---+ | |
| |RTR+-------------ISP
|prefix +---+ | |
| ----------- | |
\ Wireless LAN/ \
\ / \
\\ // \\
-------
]]></artwork>
</figure>
<t>For this reason if no other, although both it and <xref
target="RFC2460"></xref> talk about prefixes being assigned to
"interfaces or sets of interfaces", <xref target="RFC4291"></xref>
states that <list style="empty">
<t>Currently, IPv6 continues the IPv4 model in that a subnet
prefix is associated with one link. Multiple subnet prefixes may
be assigned to the same link.</t>
</list></t>
</section>
<section anchor="srml60"
title="Single-router network assigned a prefix shorter than /64">
<figure anchor="srml" title="SOHO with longer prefix">
<artwork align="center"><![CDATA[
-------
// \\ //
/ \ /
/ Wired LAN \ /
| ----------- | |
|prefix:2 +---+ | |
| |RTR+-------------ISP
|prefix:1 +---+ | |
| ----------- | |
\ Wireless LAN/ \
\ / \
\\ // \\
-------
]]></artwork>
</figure>
<t>The preferred architecture in the residential case, that of <xref
target="srml"></xref>, has the upstream provider delegate a longer
prefix such as a /60, /56, or /48 to it. As in <xref
target="soho64"></xref>, a SOHO often has multiple internal wired and
wireless LANs, and often uses a single residential CPE router. The CPE
router can, however, unambiguously sub-delegate /64 prefixes to its
interfaces from the prefix delegated to it. This will facilitate
future extensions of the network which may require other routers.</t>
<t>This configuration also simplifies <xref target="RFC4862">Neighbor
Discovery</xref> and <xref target="RFC3971"> Secure Neighbor
Discovery</xref>, in that there is no question of the CPE Router
proxying for other devices. For external routing, as in <xref
target="soho64"></xref>, the CPE assigns a single default route to its
upstream router.</t>
</section>
<section title="Small Multi-router network">
<t>A more complex case might be found in a residential network that is
multihomed (has multiple upstream providers) and has multiple zoned
LANs within the home. A couple might, for example, work for different
employers who require them to maintain separate and secure LANs for
their offices and who keep a common network for their home. In this
case, the SOHO has the equivalent of two corporate networks and one
common network, each comprised of some number of wired and wireless
LANs, connected via the couple's multihomed upstream networks. This is
shown in <xref target="mrml"></xref>.</t>
<t>The network in <xref target="mrml"></xref> remains conceptually
simple in that it is a simple tree; the two office routers and the
home router can query the CPE Routers for sub-delegated prefixes from
their upstream networks without ambiguity. It becomes more complex if
there are additional routers further to the left in the diagram, or if
there exist LANs between interior routers turning the network into a
general graph.</t>
<t>To handle a case such as this, the simplest approach will be to
manually configure the CPE routers to further sub-delegate prefixes
(via DHCP?), perhaps /60s from an upstream's /56, turning this into a
collection of cases more similar to that of <xref
target="srml60"></xref>. If the network contains internal complexities
beyond a simple tree structure, there may be a need for disambiguating
rules about which router's delegation from the CPE has precedence.</t>
<t>Routing in such an environment calls for a routing protocol such as
<xref target="RFC2080">RIPv6</xref>,
<xref target="RFC5308">IS-IS</xref>, or
<xref target="RFC5340">OSPF</xref>.
In addition, each CPE router will need to install a static default
route upstream and advertise a default route in the chosen routing
protocol. The issues raised in <xref target="RFC3704"></xref> also
apply, meaning that the two CPE routers may each need to observe the
source addresses in datagrams they handle to divert them to the other
CPE to handle upstream ingress filtering issues.</t>
<figure anchor="mrml" title="Complex SOHO">
<artwork align="center"><![CDATA[
/-------+-/ /
prefix:2| |
+---+--+ |
|Office| |
|RTR 1 +--+ --
+---+--+ | +-------+ /
prefix:3| | |CPE RTR| |
/-------+-/ +--+ISP 1 +------ ISP 1
| +-------+ |
/-------+-/ |p \
prefix:4| |r --
+---+--+ |e
|Office| |f
|RTR 2 +--+i
+---+--+ |x
prefix:5| |: --
/-------+-/ |0 +-------+ /
| |CPE RTR| |
/-------+-/ +--+ISP 2 +------ ISP 2
prefix:6| | +-------+ |
+---+--+ | \
|Home | | --
|RTR +--+
+---+--+ |
prefix:7| |
/-------+-/ /
]]></artwork>
</figure>
</section>
</section>
<section title="Requirements for a generalized subnet numbering tool">
<t>If the IETF were to build a generalized tool for enumerating subnets
in a domain, it needs to meet at least the following requirements:<list
style="numbers">
<t>It needs to work with IPv6 prefixes of any type and length that
might be delegated by an ISP (PA), by an RIR (PI), or as a ULA.</t>
<t>It needs to be able to identify or have identified to it enclaves
of interest. These may be as simple as a set of subnets that
comprise an internal administrative zone, or might more generally be
campuses.</t>
<t>It needs to be able to enumerate enclaves of interest in a manner
that enhances aggregation - assign the longest prefix possible that
can be subdivided into the needed /64s.</t>
<t>It needs to be able to configure one or more preferred aggregate
prefix lengths; for example, if there are /59, /62, and /57
sub-domains within a network, the administration may prefer to
allocate /56 prefixes to each of them.</t>
<t>It needs to be able to draw its site prefix or prefixes from an
ISP or other source.</t>
<t>The algorithm should work readily with arbitrarily complex
networks of any size consistent with RIR, NIR, or LIR allocation
practice (e.g., /60, /56, or /48 prefixes).</t>
</list></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
<t>Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are required,
or if those assignments or registries are created during the RFC
publication process. From the author"s perspective, it may therefore be
removed upon publication as an RFC at the RFC Editor"s discretion.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>There are no new security concerns with the approaches suggested in
this memo beyond those analogous to neighbor discovery or other subnet
delegation approaches. There are, however, clear concerns with
complexity in the absence of a defined sub-delegation architecture in
the more general cases.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Input resulting in this came from Wes Beebee, James Woodyatt,
Iljitsch van Beijnum, and Barbara Stark. The documents suggesting a need
for sub-delegation of prefixes are <xref
target="I-D.donley-ipv6-cpe-rtr-use-cases-and-reqs"></xref> and <xref
target="I-D.ietf-v6ops-ipv6-cpe-router"></xref>.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.4291"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2080" ?>
<?rfc include="reference.RFC.3633" ?>
<?rfc include="reference.RFC.3704" ?>
<?rfc include="reference.RFC.3971" ?>
<?rfc include="reference.RFC.4862" ?>
<?rfc include="reference.RFC.5308" ?>
<?rfc include="reference.RFC.5340" ?>
<?rfc include="reference.I-D.donley-ipv6-cpe-rtr-use-cases-and-reqs" ?>
<?rfc include="reference.I-D.ietf-v6ops-ipv6-cpe-router" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:47:50 |