idnits 2.17.1 draft-baker-ipv6-prefix-subdelegation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 25, 2009) is 5382 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-09) exists of draft-ietf-v6ops-ipv6-cpe-router-00 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational July 25, 2009 5 Expires: January 26, 2010 7 Prefix Sub-delegation in a SOHO/SMB Environment 8 draft-baker-ipv6-prefix-subdelegation-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 26, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This memo considers the question of IPv6 prefix sub-delegation. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Assigning prefixes to small networks . . . . . . . . . . . . . 3 52 2.1. Single-router network assigned a /64 . . . . . . . . . . . 3 53 2.2. Single-router network assigned a prefix shorter than 54 /64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.3. Small Multi-router network . . . . . . . . . . . . . . . . 5 56 3. Requirements for a generalized subnet numbering tool . . . . . 6 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 In the IPv6 Operations Working Group and the Homegate BOF, there have 68 been questions raised about IPv6 Prefix Sub-delegation. In short, 69 the CPE Router documents would like to require an algorithm for sub- 70 delegation, and the indicated document does not exist. This note is 71 intended to raise the question to the IPv6 Maintenance Working Group. 73 By IPv6 Prefix Sub-delegation, we refer to the issue that an upstream 74 provider delegates a prefix to a downstream network such as a home or 75 small business, which is turn allocates prefixes to LANs and other 76 structures within its domain. The means of delegation to the SOHO/ 77 SMB is not really important here, although we note that DHCP has a 78 tool [RFC3633] for the purpose. In general, this is presumed to 79 apply to networks using IPv6 [RFC2460] and using addressing 80 conforming to the IPv6 Addressing Architecture [RFC4291]. 82 2. Assigning prefixes to small networks 84 There are several special cases that are relatively easily solved, 85 and more complex cases that can be solved by divide-and-conquer 86 methods. The most general case, that of assigning subnet numbers 87 throughout an arbitrary complex topology, may be beyond algorithmic 88 description. Here we walk through some of the simpler cases. 90 2.1. Single-router network assigned a /64 92 The simplest residential case, that of Figure 1, is that of an 93 apartment or single family dwelling whose upstream provider delegates 94 a single /64 to it. Such a SOHO probably has multiple internal LANs 95 (wired and wireless), and uses a single residential CPE router. In 96 this case, there are few choices. As described in passing in 97 [RFC2460] in that a prefix can be assigned to a "set of interfaces", 98 the CPE Router uses the delegated prefix on all of its non-upstream 99 interfaces, and tracks the location of various devices on its LANs. 101 For external routing, it assigns a single default route to its 102 upstream router. 104 There are some complexities in this architecture, as it doesn't scale 105 well to add even a second router. While a single CPE router can 106 track the addresses allocated by other devices, it will be forced to 107 proxy for them in Neighbor Discovery [RFC4862]; it will respond to a 108 Neighbor Solicitation for a device on another interface, including a 109 device using a link-local address. This will create issues in Secure 110 Neighbor Discovery [RFC3971], in that it will not have the private 111 key of the device it is proxying for. However, it can enable the 112 connection of devices on its various LANs by this means. Vendor 113 implementations may well choose to implement this using IEEE 802.1 114 technology for simplicity, to make it appear to be one interface to 115 the software. 117 ------- 118 // \\ // 119 / \ / 120 / Wired LAN \ / 121 | ----------- | | 122 |prefix +---+ | | 123 | |RTR+-------------ISP 124 |prefix +---+ | | 125 | ----------- | | 126 \ Wireless LAN/ \ 127 \ / \ 128 \\ // \\ 129 ------- 131 Figure 1: SOHO with /64 prefix 133 For this reason if no other, although both it and [RFC2460] talk 134 about prefixes being assigned to "interfaces or sets of interfaces", 135 [RFC4291] states that 137 Currently, IPv6 continues the IPv4 model in that a subnet prefix 138 is associated with one link. Multiple subnet prefixes may be 139 assigned to the same link. 141 2.2. Single-router network assigned a prefix shorter than /64 143 ------- 144 // \\ // 145 / \ / 146 / Wired LAN \ / 147 | ----------- | | 148 |prefix:2 +---+ | | 149 | |RTR+-------------ISP 150 |prefix:1 +---+ | | 151 | ----------- | | 152 \ Wireless LAN/ \ 153 \ / \ 154 \\ // \\ 155 ------- 157 Figure 2: SOHO with longer prefix 159 The preferred architecture in the residential case, that of Figure 2, 160 has the upstream provider delegate a longer prefix such as a /60, 161 /56, or /48 to it. As in Section 2.1, a SOHO often has multiple 162 internal wired and wireless LANs, and often uses a single residential 163 CPE router. The CPE router can, however, unambiguously sub-delegate 164 /64 prefixes to its interfaces from the prefix delegated to it. This 165 will facilitate future extensions of the network which may require 166 other routers. 168 This configuration also simplifies Neighbor Discovery [RFC4862] and 169 Secure Neighbor Discovery [RFC3971], in that there is no question of 170 the CPE Router proxying for other devices. For external routing, as 171 in Section 2.1, the CPE assigns a single default route to its 172 upstream router. 174 2.3. Small Multi-router network 176 A more complex case might be found in a residential network that is 177 multihomed (has multiple upstream providers) and has multiple zoned 178 LANs within the home. A couple might, for example, work for 179 different employers who require them to maintain separate and secure 180 LANs for their offices and who keep a common network for their home. 181 In this case, the SOHO has the equivalent of two corporate networks 182 and one common network, each comprised of some number of wired and 183 wireless LANs, connected via the couple's multihomed upstream 184 networks. This is shown in Figure 3. 186 The network in Figure 3 remains conceptually simple in that it is a 187 simple tree; the two office routers and the home router can query the 188 CPE Routers for sub-delegated prefixes from their upstream networks 189 without ambiguity. It becomes more complex if there are additional 190 routers further to the left in the diagram, or if there exist LANs 191 between interior routers turning the network into a general graph. 193 To handle a case such as this, the simplest approach will be to 194 manually configure the CPE routers to further sub-delegate prefixes 195 (via DHCP?), perhaps /60s from an upstream's /56, turning this into a 196 collection of cases more similar to that of Section 2.2. If the 197 network contains internal complexities beyond a simple tree 198 structure, there may be a need for disambiguating rules about which 199 router's delegation from the CPE has precedence. 201 Routing in such an environment calls for a routing protocol such as 202 RIPv6 [RFC2080], IS-IS [RFC5308], or OSPF [RFC5340]. In addition, 203 each CPE router will need to install a static default route upstream 204 and advertise a default route in the chosen routing protocol. The 205 issues raised in [RFC3704] also apply, meaning that the two CPE 206 routers may each need to observe the source addresses in datagrams 207 they handle to divert them to the other CPE to handle upstream 208 ingress filtering issues. 210 /-------+-/ / 211 prefix:2| | 212 +---+--+ | 213 |Office| | 214 |RTR 1 +--+ -- 215 +---+--+ | +-------+ / 216 prefix:3| | |CPE RTR| | 217 /-------+-/ +--+ISP 1 +------ ISP 1 218 | +-------+ | 219 /-------+-/ |p \ 220 prefix:4| |r -- 221 +---+--+ |e 222 |Office| |f 223 |RTR 2 +--+i 224 +---+--+ |x 225 prefix:5| |: -- 226 /-------+-/ |0 +-------+ / 227 | |CPE RTR| | 228 /-------+-/ +--+ISP 2 +------ ISP 2 229 prefix:6| | +-------+ | 230 +---+--+ | \ 231 |Home | | -- 232 |RTR +--+ 233 +---+--+ | 234 prefix:7| | 235 /-------+-/ / 237 Figure 3: Complex SOHO 239 3. Requirements for a generalized subnet numbering tool 241 If the IETF were to build a generalized tool for enumerating subnets 242 in a domain, it needs to meet at least the following requirements: 244 1. It needs to work with IPv6 prefixes of any type and length that 245 might be delegated by an ISP (PA), by an RIR (PI), or as a ULA. 247 2. It needs to be able to identify or have identified to it enclaves 248 of interest. These may be as simple as a set of subnets that 249 comprise an internal administrative zone, or might more generally 250 be campuses. 252 3. It needs to be able to enumerate enclaves of interest in a manner 253 that enhances aggregation - assign the longest prefix possible 254 that can be subdivided into the needed /64s. 256 4. It needs to be able to configure one or more preferred aggregate 257 prefix lengths; for example, if there are /59, /62, and /57 sub- 258 domains within a network, the administration may prefer to 259 allocate /56 prefixes to each of them. 261 5. It needs to be able to draw its site prefix or prefixes from an 262 ISP or other source. 264 6. The algorithm should work readily with arbitrarily complex 265 networks of any size consistent with RIR, NIR, or LIR allocation 266 practice (e.g., /60, /56, or /48 prefixes). 268 4. IANA Considerations 270 This memo asks the IANA for no new parameters. 272 Note to RFC Editor: This section will have served its purpose if it 273 correctly tells IANA that no new assignments or registries are 274 required, or if those assignments or registries are created during 275 the RFC publication process. From the author"s perspective, it may 276 therefore be removed upon publication as an RFC at the RFC Editor"s 277 discretion. 279 5. Security Considerations 281 There are no new security concerns with the approaches suggested in 282 this memo beyond those analogous to neighbor discovery or other 283 subnet delegation approaches. There are, however, clear concerns 284 with complexity in the absence of a defined sub-delegation 285 architecture in the more general cases. 287 6. Acknowledgements 289 Input resulting in this came from Wes Beebee, James Woodyatt, 290 Iljitsch van Beijnum, and Barbara Stark. The documents suggesting a 291 need for sub-delegation of prefixes are 292 [I-D.donley-ipv6-cpe-rtr-use-cases-and-reqs] and 293 [I-D.ietf-v6ops-ipv6-cpe-router]. 295 7. References 296 7.1. Normative References 298 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 299 (IPv6) Specification", RFC 2460, December 1998. 301 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 302 Architecture", RFC 4291, February 2006. 304 7.2. Informative References 306 [I-D.donley-ipv6-cpe-rtr-use-cases-and-reqs] 307 Donley, C., Kharbanda, D., Brzozowski, J., Lee, Y., Weil, 308 J., Erichsen, K., Howard, L., and J. Tremblay, "Use Cases 309 and Requirements for an IPv6 CPE Router", 310 draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00 (work in 311 progress), July 2009. 313 [I-D.ietf-v6ops-ipv6-cpe-router] 314 Singh, H. and W. Beebee, "IPv6 CPE Router 315 Recommendations", draft-ietf-v6ops-ipv6-cpe-router-00 316 (work in progress), March 2009. 318 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 319 January 1997. 321 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 322 Host Configuration Protocol (DHCP) version 6", RFC 3633, 323 December 2003. 325 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 326 Networks", BCP 84, RFC 3704, March 2004. 328 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 329 Neighbor Discovery (SEND)", RFC 3971, March 2005. 331 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 332 Address Autoconfiguration", RFC 4862, September 2007. 334 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 335 October 2008. 337 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 338 for IPv6", RFC 5340, July 2008. 340 Author's Address 342 Fred Baker 343 Cisco Systems 344 Santa Barbara, California 93117 345 USA 347 Email: fred@cisco.com