IPv6 Maintenance F. Baker
Internet-Draft Cisco Systems
Intended status: Informational July 25, 2009
Expires: January 26, 2010
Prefix Sub-delegation 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 26, 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 sub-delegation.
Baker Expires January 26, 2010 [Page 1]
Internet-Draft Prefix Sub-delegation 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. Requirements for a generalized subnet numbering tool . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Baker Expires January 26, 2010 [Page 2]
Internet-Draft Prefix Sub-delegation July 2009
1. Introduction
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.
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
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 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
[RFC2460] 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.
For external routing, it assigns a single default route to its
upstream router.
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 Neighbor Discovery [RFC4862]; 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 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
Baker Expires January 26, 2010 [Page 3]
Internet-Draft Prefix Sub-delegation July 2009
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.
-------
// \\ //
/ \ /
/ Wired LAN \ /
| ----------- | |
|prefix +---+ | |
| |RTR+-------------ISP
|prefix +---+ | |
| ----------- | |
\ Wireless LAN/ \
\ / \
\\ // \\
-------
Figure 1: SOHO with /64 prefix
For this reason if no other, although both it and [RFC2460] talk
about prefixes being assigned to "interfaces or sets of interfaces",
[RFC4291] states that
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.
2.2. Single-router network assigned a prefix shorter than /64
-------
// \\ //
/ \ /
/ Wired LAN \ /
| ----------- | |
|prefix:2 +---+ | |
| |RTR+-------------ISP
|prefix:1 +---+ | |
| ----------- | |
\ Wireless LAN/ \
\ / \
\\ // \\
-------
Figure 2: SOHO with longer prefix
The preferred architecture in the residential case, that of Figure 2,
Baker Expires January 26, 2010 [Page 4]
Internet-Draft Prefix Sub-delegation July 2009
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.
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.
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 sub-delegate 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
RIPv6 [RFC2080], IS-IS [RFC5308], or OSPF [RFC5340]. 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 [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
Baker Expires January 26, 2010 [Page 5]
Internet-Draft Prefix Sub-delegation July 2009
ingress filtering issues.
/-------+-/ /
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| |
/-------+-/ /
Figure 3: Complex SOHO
3. Requirements for a generalized subnet numbering tool
If the IETF were to build a generalized tool for enumerating subnets
in a domain, it needs to meet at least the following requirements:
1. 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.
2. 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.
3. 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.
Baker Expires January 26, 2010 [Page 6]
Internet-Draft Prefix Sub-delegation July 2009
4. 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.
5. It needs to be able to draw its site prefix or prefixes from an
ISP or other source.
6. 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).
4. 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.
5. 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.
6. 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].
7. References
Baker Expires January 26, 2010 [Page 7]
Internet-Draft Prefix Sub-delegation July 2009
7.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.
7.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.
Baker Expires January 26, 2010 [Page 8]
Internet-Draft Prefix Sub-delegation July 2009
Author's Address
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Email: fred@cisco.com
Baker Expires January 26, 2010 [Page 9]