[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Posted a new copy of CPE Rtr draft
here is an example of the kind of draft I might hope 6man discussed.
If you want, we can hack this into a better input to them.
<?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 Subdelegation">Prefix Subdelegation 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 subdelegation.</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 Subdelegation. In short, the CPE
Router documents would like to require an algorithm for subdelegation,
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 Subdelegation, 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 often has multiple internal wired and wireless LANs, but often
uses a single residential CPE router. In this case, there are few
choices. As described in ???, 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>
<figure anchor="single" title="SOHO with /64 prefix">
<artwork align="center"><![CDATA[
-------
// \\ //
/ \ /
/ Wired LAN \ /
| ----------- | |
|prefix +---+ | |
| |RTR+-------------ISP
|prefix +---+ | |
| ----------- | |
\ Wireless LAN/ \
\ / \
\\ // \\
-------
]]></artwork>
</figure>
<t>There are some complexities in this architecture, as it doesn't
scale well to multiple routers or other such configurations. 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. 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.</t>
<t>For external routing, it assigns a single default route to its
upstream router.</t>
</section>
<section anchor="srml60"
title="Single-router network assigned a prefix shorter than /64">
<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>
<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>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>
<figure anchor="mrml" title="Complex SOHO">
<artwork align="center"><![CDATA[
--------+--- |
prefix:0| |
+---+--+ |
|Office| | --
|RTR 1 +-| /
+---+--+ | +-------+ |
prefix:1| | |CPE RTR| |
--------+--- +--+ISP 1 +------ ISP 1
| +-------+ |
--------+--- | \
prefix:2| | --
+---+--+ |
|Office| |
|RTR 2 +-+ --
+---+--+ | /
prefix:3| | +-------+ |
--------+--- | |CPE RTR| |
+--+ISP 2 +------ ISP 2
--------+--- | +-------+ |
prefix:4| | \
+---+--+ | --
|Home | |
|RTR +-+
+---+--+ |
prefix:5| |
--------+--- |
]]></artwork>
</figure>
<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 subdelegate 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="RFC5340">OSPF</xref>, <xref
target="RFC5308">IS-IS</xref>, or <xref target="RFC2080">RIPv6</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>
</section>
</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.4291"?>
<?rfc include='reference.RFC.2460'?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3633"?>
<?rfc include='reference.RFC.4862' ?>
<?rfc include='reference.RFC.2080' ?>
<?rfc include='reference.RFC.5308' ?>
<?rfc include='reference.RFC.5340' ?>
<?rfc include='reference.RFC.3704' ?>
<?rfc include='reference.RFC.3971' ?>
<?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>
IPv6 Maintenance F. Baker
Internet-Draft Cisco Systems
Intended status: Informational July 20, 2009
Expires: January 21, 2010
Prefix Subdelegation in a SOHO/SMB Environment
draft-baker-ipv6-prefix-subdelegation-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 21, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This memo considers the question of IPv6 prefix subdelegation.
Baker Expires January 21, 2010 [Page 1]
Internet-Draft Prefix Subdelegation July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Assigning prefixes to small networks . . . . . . . . . . . . . 3
2.1. Single-router network assigned a /64 . . . . . . . . . . . 3
2.2. Single-router network assigned a prefix shorter than
/64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Small Multi-router network . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Baker Expires January 21, 2010 [Page 2]
Internet-Draft Prefix Subdelegation July 2009
1. Introduction
In the IPv6 Operations Working Group and the Homegate BOF, there have
been questions raised about IPv6 Prefix Subdelegation. In short, the
CPE Router documents would like to require an algorithm for
subdelegation, and the indicated document does not exist. This note
is intended to raise the question to the IPv6 Maintenance Working
Group.
By IPv6 Prefix Subdelegation, 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
tool [RFC3633] for the purpose. In general, this is presumed to
apply to networks using IPv6 [RFC2460] and using addressing
conforming to the IPv6 Addressing Architecture [RFC4291].
2. Assigning prefixes to small networks
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.
2.1. Single-router network assigned a /64
The simplest residential case, that of Figure 1, is that of an
apartment or single family dwelling whose upstream provider delegates
a single /64 to it. Such a SOHO often has multiple internal wired
and wireless LANs, but often uses a single residential CPE router.
In this case, there are few choices. As described in ???, the CPE
Router uses the delegated prefix on all of its non-upstream
interfaces, and tracks the location of various devices on its LANs.
Baker Expires January 21, 2010 [Page 3]
Internet-Draft Prefix Subdelegation July 2009
-------
// \\ //
/ \ /
/ Wired LAN \ /
| ----------- | |
|prefix +---+ | |
| |RTR+-------------ISP
|prefix +---+ | |
| ----------- | |
\ Wireless LAN/ \
\ / \
\\ // \\
-------
Figure 1: SOHO with /64 prefix
There are some complexities in this architecture, as it doesn't scale
well to multiple routers or other such configurations. While a
single CPE router can track the addresses allocated by other devices,
it will be forced to proxy for them in Neighbor Discovery [RFC4862];
it will respond to a Neighbor Solicitation for a device on another
interface. This will create issues in Secure Neighbor Discovery
[RFC3971], 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.
For external routing, it assigns a single default route to its
upstream router.
2.2. Single-router network assigned a prefix shorter than /64
The preferred architecture in the residential case, that of Figure 2,
has the upstream provider delegate a longer prefix such as a /60,
/56, or /48 to it. As in Section 2.1, 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.
Baker Expires January 21, 2010 [Page 4]
Internet-Draft Prefix Subdelegation July 2009
-------
// \\ //
/ \ /
/ Wired LAN \ /
| ----------- | |
|prefix:2 +---+ | |
| |RTR+-------------ISP
|prefix:1 +---+ | |
| ----------- | |
\ Wireless LAN/ \
\ / \
\\ // \\
-------
Figure 2: SOHO with longer prefix
This configuration also simplifies Neighbor Discovery [RFC4862] and
Secure Neighbor Discovery [RFC3971], in that there is no question of
the CPE Router proxying for other devices. For external routing, as
in Section 2.1, the CPE assigns a single default route to its
upstream router.
2.3. Small Multi-router network
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 Figure 3.
Baker Expires January 21, 2010 [Page 5]
Internet-Draft Prefix Subdelegation July 2009
--------+--- |
prefix:0| |
+---+--+ |
|Office| | --
|RTR 1 +-| /
+---+--+ | +-------+ |
prefix:1| | |CPE RTR| |
--------+--- +--+ISP 1 +------ ISP 1
| +-------+ |
--------+--- | \
prefix:2| | --
+---+--+ |
|Office| |
|RTR 2 +-+ --
+---+--+ | /
prefix:3| | +-------+ |
--------+--- | |CPE RTR| |
+--+ISP 2 +------ ISP 2
--------+--- | +-------+ |
prefix:4| | \
+---+--+ | --
|Home | |
|RTR +-+
+---+--+ |
prefix:5| |
--------+--- |
Figure 3: Complex SOHO
The network in Figure 3 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.
To handle a case such as this, the simplest approach will be to
manually configure the CPE routers to further subdelegate prefixes
(via DHCP?), perhaps /60s from an upstream's /56, turning this into a
collection of cases more similar to that of Section 2.2. 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.
Routing in such an environment calls for a routing protocol such as
OSPF [RFC5340], IS-IS [RFC5308], or RIPv6 [RFC2080]. In addition,
each CPE router will need to install a static default route upstream
Baker Expires January 21, 2010 [Page 6]
Internet-Draft Prefix Subdelegation July 2009
and advertise a default route in the chosen routing protocol. The
issues raised in [RFC3704] 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.
3. IANA Considerations
This memo asks the IANA for no new parameters.
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.
4. Security Considerations
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.
5. Acknowledgements
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
[I-D.donley-ipv6-cpe-rtr-use-cases-and-reqs] and
[I-D.ietf-v6ops-ipv6-cpe-router].
6. References
6.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Baker Expires January 21, 2010 [Page 7]
Internet-Draft Prefix Subdelegation July 2009
6.2. Informative References
[I-D.donley-ipv6-cpe-rtr-use-cases-and-reqs]
Donley, C., Kharbanda, D., Brzozowski, J., Lee, Y., Weil,
J., Erichsen, K., Howard, L., and J. Tremblay, "Use Cases
and Requirements for an IPv6 CPE Router",
draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00 (work in
progress), July 2009.
[I-D.ietf-v6ops-ipv6-cpe-router]
Singh, H. and W. Beebee, "IPv6 CPE Router
Recommendations", draft-ietf-v6ops-ipv6-cpe-router-00
(work in progress), March 2009.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
October 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
Author's Address
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Email: fred@cisco.com
Baker Expires January 21, 2010 [Page 8]