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]