TOC 
IPv6 MaintenanceF. Baker
Internet-DraftCisco Systems
Intended status: InformationalJuly 27, 2009
Expires: January 28, 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 28, 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.



Table of Contents

1.  Introduction
2.  Assigning prefixes to small networks
    2.1.  Single-router network assigned a /64
    2.2.  Single-router network assigned a prefix shorter than /64
    2.3.  Small Multi-router network
3.  Requirements for a generalized subnet numbering tool
4.  IANA Considerations
5.  Security Considerations
6.  Acknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Author's Address




 TOC 

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 (Troan, O. and R. Droms, “IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6,” December 2003.) [RFC3633] for the purpose. In general, this is presumed to apply to networks using IPv6 (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) [RFC2460] and using addressing conforming to the IPv6 Addressing Architecture (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.) [RFC4291].



 TOC 

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.



 TOC 

2.1.  Single-router network assigned a /64

The simplest residential case, that of Figure 1 (SOHO with /64 prefix), 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] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) 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 (Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration,” September 2007.) [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 (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) [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. 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] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) talk about prefixes being assigned to "interfaces or sets of interfaces", [RFC4291] (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.) 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.



 TOC 

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 (SOHO with longer prefix), has the upstream provider delegate a longer prefix such as a /60, /56, or /48 to it. As in Section 2.1 (Single-router network assigned a /64), 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 (Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration,” September 2007.) [RFC4862] and Secure Neighbor Discovery (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) [RFC3971], in that there is no question of the CPE Router proxying for other devices. For external routing, as in Section 2.1 (Single-router network assigned a /64), the CPE assigns a single default route to its upstream router.



 TOC 

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 (Complex SOHO).

The network in Figure 3 (Complex SOHO) 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 (Single-router network assigned a prefix shorter than /64). 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 (Malkin, G. and R. Minnear, “RIPng for IPv6,” January 1997.) [RFC2080], IS-IS (Hopps, C., “Routing IPv6 with IS-IS,” October 2008.) [RFC5308], or OSPF (Coltun, R., Ferguson, D., Moy, J., and A. Lindem, “OSPF for IPv6,” July 2008.) [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] (Baker, F. and P. Savola, “Ingress Filtering for Multihomed Networks,” March 2004.) 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.



/-------+-/   /
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 



 TOC 

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.
  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).


 TOC 

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.



 TOC 

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.



 TOC 

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] (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,” July 2009.) and [I‑D.ietf‑v6ops‑ipv6‑cpe‑router] (Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, “Basic Requirements for IPv6 Customer Edge Routers,” January 2010.).



 TOC 

7.  References



 TOC 

7.1. Normative References

[RFC2460] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1998 (TXT, HTML, XML).
[RFC4291] Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” RFC 4291, February 2006 (TXT).


 TOC 

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 (TXT).
[I-D.ietf-v6ops-ipv6-cpe-router] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, “Basic Requirements for IPv6 Customer Edge Routers,” draft-ietf-v6ops-ipv6-cpe-router-04 (work in progress), January 2010 (TXT).
[RFC2080] Malkin, G. and R. Minnear, “RIPng for IPv6,” RFC 2080, January 1997 (TXT).
[RFC3633] Troan, O. and R. Droms, “IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6,” RFC 3633, December 2003 (TXT).
[RFC3704] Baker, F. and P. Savola, “Ingress Filtering for Multihomed Networks,” BCP 84, RFC 3704, March 2004 (TXT).
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” RFC 3971, March 2005 (TXT).
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration,” RFC 4862, September 2007 (TXT).
[RFC5308] Hopps, C., “Routing IPv6 with IS-IS,” RFC 5308, October 2008 (TXT).
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, “OSPF for IPv6,” RFC 5340, July 2008 (TXT).


 TOC 

Author's Address

  Fred Baker
  Cisco Systems
  Santa Barbara, California 93117
  USA
Email:  fred@cisco.com