idnits 2.17.1 draft-chakrabarti-homenet-prefix-alloc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 9 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 28, 2011) is 4564 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2460' is defined on line 952, but no explicit reference was found in the text == Unused Reference: 'RFC3769' is defined on line 963, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-chown-homenet-arch-00 ** Downref: Normative reference to an Informational draft: draft-chown-homenet-arch (ref. 'I-D.chown-homenet-arch') ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HOMENET WG E. Nordmark 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track S. Chakrabarti 5 Expires: April 30, 2012 S. Krishnan 6 W. Haddad 7 Ericsson 8 October 28, 2011 10 Simple Approach to Prefix Distribution in Basic Home Networks 11 draft-chakrabarti-homenet-prefix-alloc-01 13 Abstract 15 Modern IPv4 home networks are often configured with multi-level of 16 NATs and Residential gateways to separate islands of networks used 17 for different purposes. With the introduction of IPv6 home networks 18 we'd like to be able to maintain the same topological freedom as we 19 have with IPv4 but without requiring any IPv6 NATs. This document 20 specifies the topological restrictions for what we term Basic Home 21 Networks and specifies how DHCPv6 Prefix Delegation can be used to 22 autoconfigure IPv6 address prefixes in such networks. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 30, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 4 60 3. Conceptual model of a Basic Home Router . . . . . . . . . . . 5 61 4. Topology Assumptions . . . . . . . . . . . . . . . . . . . . . 5 62 5. Topology Examples . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Automatic hierarchical DHCPv6 Prefix Delegation . . . . . . . 10 64 6.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 6.2. Configurability . . . . . . . . . . . . . . . . . . . . . 13 66 6.3. Routing Implications . . . . . . . . . . . . . . . . . . . 13 67 6.4. Neighbor Discovery Implications . . . . . . . . . . . . . 14 68 6.5. Ensuring stable prefixes . . . . . . . . . . . . . . . . . 14 69 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 8. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 16 71 8.1. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 16 72 9. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 17 73 10. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 17 74 11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 17 75 12. What if there are loops? . . . . . . . . . . . . . . . . . . . 18 76 13. Security Considerations . . . . . . . . . . . . . . . . . . . 21 77 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 78 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 79 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 16.1. Normative References . . . . . . . . . . . . . . . . . . . 22 81 16.2. Informative References . . . . . . . . . . . . . . . . . . 23 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 84 1. Introduction 86 In the past decade due to explosion of IP-enabled devices and home 87 Internet usage, many homes have become testbeds of multi-subnet and 88 often multi-level subnetworks. While the simple case of a single 89 Residential Gateway with NAT functionality is the most common, there 90 is a desire to have separate guest subnets. And the future 91 introduction of new low-power radio technologies will result in 92 additional subnets since such technologies typically can not be 93 bridged to Ethernet networks. Using IPv4 it is possible to get 94 connectivity by connecting several RG's with NAT together to form a 95 tree or a daisy-chain of NATs. That can more or less be performed in 96 a plug and play fashion. It is also possible to manually configure 97 routers with IP subnet numbers, routing protocols, etc, resulting in 98 a home network which does not require any internal NATs. But such 99 configuration requires a fair bit of expertize. 101 With the introduction of IPv6 in the home networks we would like to 102 avoid assuming IPv6 NATs, yet we want to allow for cases that require 103 separate subnets (for security reasons as in the case of the guest 104 network, or for technology reasons as in the case of new radio 105 networks). We want this without requiring networking experts to 106 manually configure IP subnet numbers and routing protocols. 108 IPv6 has already taken steps to facilitate some aspects of this 109 configuration through DHCP Prefix delegation [RFC3633] which is used 110 to configure a single Residential Gateway with an IPv6 address prefix 111 that can be used inside the home. However, that does not handle 112 cases where there are multiple routers in the home. The homenet WG 113 desires to solve this more general architecture, with a set of 114 example topologies shown ina [I-D.chown-homenet-arch]. 116 In this draft we argue for separating out a subset of those 117 topologies, and focusing on those first. We will call the subset 118 "Basic Homenets". The criteria used for this is the set of 119 topologies that can be implemented using consumer-grade IPv4 120 Residential Gateways without (significant) manual configuration. As 121 we will see, those topologies end up being constrained to be a single 122 tree rooted in the connection to the ISP. In such a topology we then 123 apply hierarchical DHCPv6 Prefix Delegation in an automated way with 124 sensible defaults. The approach is as robust against 125 misconfiguration and loops as is the use of IPv4 NATs. 127 Adding the prefix allocation specified in this draft for IPv6 support 128 will have no effect on IPv4; the current use of DHCP, NAT, or even 129 routed IPv4 without NAT in the home routers will function as before. 131 The approach provides stable IPv6 prefixes in the home network by 132 relying on the ability for DHCPv6 servers to keep the assignments in 133 stable storage. 135 This draft follows the architecture and terminology outlined in the 136 homenet architecture [I-D.chown-homenet-arch]. 138 2. Definition Of Terms 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 Some of the following terms are taken from [I-D.chown-homenet-arch]: 146 Customer Edge Router (CER) 147 The IPv6 router which connects to the ISP network on its uplink 148 interface. Such a routers has one or more down-link interfaces 149 which can be used by hosts and routers. This router can be co- 150 located with the CPE. 152 Interior Router (IR) 153 The other IPv6 routers in the home network. These routers are not 154 connected to the ISP directly. 156 Router: 157 In this document we use "router" to refer to either CERs or IRs. 158 In fact, CER and IR is a topological role which we expect can be 159 played by a router which implements this specification. 161 Host: 162 A host in a IPv6 network is a device which does not forward IPv6 163 packets (that are not addressed to itself). A host can be 164 connected to one or more routers. 166 CPE: 167 Customer Premises Equipment aka Home Gateway attached to the DSL 168 or cable modem. The CER and CPE could be co-located in the same 169 device. 171 Link: 172 A communication facility or medium over which nodes can 173 communicate at the link layer, i.e., the layer immediately below 174 IPv6. 176 3. Conceptual model of a Basic Home Router 178 A key assumption we make is that a Basic Home Router has a designated 179 uplink port. Today such home routers include IPv4 NAT functionality 180 and as IPv6 support is added the goal is to not require IPv6 NAT 181 functionality but instead rely on different prefixes being allocated 182 to different links. 184 A Basic Home Router can have different configuration and number of 185 downlink ports, whether physical ports (e.g., Ethernet), VLANs, or 186 wireless (e.g., WiFi, 802.15.4). In the case of wireless interfaces 187 it might make sense to think of them as potentially different ports. 188 For example, a WiFi access point with a private and a guest ESSID 189 might be thought of as two separate ports. A device is free to 190 choose which collections of ports it wants to handle as a single link 191 from IP's perspective. For example, a device with 4 Ethernet 192 downlink ports and a WiFi AP is free to handle that as e.g.: 194 A single link, by bridging the Ethernet ports and WiFi together. 196 One link for the 4 Ethernet ports (bridged together), and two 197 links for WiFi - one for the private ESSID and one for the guest 198 ESSID. 200 Dynamically create a separate link for each station that is 201 authenticated using 802.1X and its WiFi counterparts. 203 The key point in the conceptual model is the assumption of a single 204 uplink port on a separate IP link, and some set of links covering the 205 set of downlink ports. On typical home router products the uplink 206 port is colors and labeled differently, perhaps with "Internet" or 207 "WAN". 209 While there are IPv6 routers which do not have those limitations, if 210 the device is also operating as a IPv4 home router with NAT, then 211 most likely it would have the single uplink for the purposes of 212 DHCPv4 and NAT. 214 4. Topology Assumptions 216 The existence of the single uplink interface naturally drives the 217 topology towards a tree. At first sight one might think that the 218 network can have destructive loops even with a single uplink port. 219 For instance, some set of downlink interfaces on some of the routers 220 could be bridged together using a commonly available Ethernet switch. 221 The key question is whether that would work using IPv4 home routers 222 with NAT. 224 Many IPv4 home routers have a default configuration with 225 192.168.1.1/24 configured on their LAN interface. Plugging two 226 downlink ports from two different routers into a single switch would 227 cause an IP address conflict; both routers would claim the same above 228 IP address. Such a conflict can be avoided if one of the routers is 229 configured to have a different IP address on its LAN interface such 230 as 10.0.0.1/24. In that case there would still be two uncoordinated 231 DHCP servers on the same LAN. Thus one host might send a DHCP 232 request to one router, and be assigned 192.168.1.5/24 a default 233 router of 192.168.1.1 while some other host happens to use the other 234 router's DHCP server and be assigned 10.0.0.27/24 with 10.0.0.1 as 235 the default router. Thus this doesn't cause any looping problems for 236 IPv4 and NAT, but it isn't useful as a topology since there is no 237 coordinated IPv4 address assignment for the bridged LAN. 239 For IPv6 we want to support the same topologies that are useful in 240 the IPv4 NAT case, and ensure that even for non-useful topologies 241 such as the above bridged LAN case IPv6 wouldn't be any worse that 242 the IPv4 NAT case. 244 5. Topology Examples 246 The following diagrams show the typical topology scenarios of home 247 network for which the draft is based on. For simplicity the diagram 248 limits the levels of subnets. Figure 1 shows a rather wide tree of 249 routers, and as a result a large number of hosts can be connected 250 using a shallow tree. 252 Figure 2 shows a daisy-chain of routers, which result in a deeper 253 tree with more levels of routers. But both of those topologies are 254 trees. 256 +------+--------+ \ 257 | IPv6 | \ 258 | Customer Edge | \ 259 | Router | | 260 +----+-----+----+ | 261 Network A | | Network B | 262 ----+-------------+----+ +---+-------------+----- | 263 | | | | | 264 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 265 |IPv6 Host | |IPv6 Int. | |IPv6 Int. | |IPv6 Int. | | 266 | | | Router | | Router | | Router | | End-User 267 +----------+ +-----+----+ +----+-----+ +-----+----+ | networks 268 | | | Net G | 269 Network C | | Network D +------- | 270 ----+-------------+---- ---+-------------+----- | 271 | | | | | 272 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 273 |IPv6 Host | |IPv6 Int. | |IPv6 Int. | |IPv6 Int. | | 274 | | | Router | | Router | | Router | | 275 +----------+ +-----+----+ +----+-----+ +-----+----+ | 276 | | | Net H | 277 Network E | | Network F +------- | 278 ----+-------------+----- ---+-------------+- | 279 | | | | | 280 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 281 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 282 | | | | | | | | / 283 +----------+ +-----+----+ +----------+ +----------+ / 285 Figure 1: Tree of routers 287 +------+--------+ \ 288 | IPv6 | \ 289 | Customer Edge | \ 290 | Router | | 291 +----+-+---+----+ | 292 Network A | | | Network B | 293 ----+-------------+----+ | +---+-------------+----- | 294 | | | | | | 295 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | 296 |IPv6 Host | |IPv6 Host | | |IPv6 Host | |IPv6 Host | | 297 | | | | | | | | | | 298 +----------+ +----------+ | +----------+ +----------+ | 299 | | 300 | | 301 +------+--------+ | 302 | IPv6 | | 303 | Interior | | 304 | Router | | 305 +----+-+---+----+ | 306 Network C | | | Network D | 307 ----+-------------+----+ | +---+-------------+----- | 308 | | | | | | 309 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | 310 |IPv6 Host | |IPv6 Host | | |IPv6 Host | |IPv6 Host | | 311 | | | | | | | | | | 312 +----------+ +----------+ | +----------+ +----------+ | 313 | | 314 | | 315 +------+--------+ | End-User 316 | IPv6 | | networks 317 | Interior | | 318 | Router | | 319 +----+-+---+----+ | 320 Network E | | | Network F | 321 ----+-------------+----+ | +---+-------------+----- | 322 | | | | | | 323 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | 324 |IPv6 Host | |IPv6 Host | | |IPv6 Host | |IPv6 Host | | 325 | | | | | | | | | | 326 +----------+ +----------+ | +----------+ +----------+ | 327 | | 328 | | 329 +------+--------+ | 330 | IPv6 | | 331 | Interior | | 332 | Router | | 333 +---+-------+---+ | 334 Network G | | Network H | 335 ----+-------------+---+- +---+-------------+- | 336 | | | | | 337 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 338 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 339 | | | | | | | | / 340 +----------+ +----------+ +----------+ +----------+ / 342 Figure 2: Daisy-chained routers 344 Note that none of the figures about have any multihoming. However, 345 hosts might be multihomed as shown in Figure 3 and Figure 4. 347 +------+--------+ \ 348 | IPv6 | \ 349 | Customer Edge | \ 350 | Router | | 351 +----+-+---+----+ | 352 Network A | | | Network B | 353 ----+-------------+----+ | +---+-------------+----- | 354 | | | | | | 355 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | 356 |IPv6 Host | |IPv6 Host | | | IPv6 | |IPv6 Host | | 357 | | | | | | Router | | Y | | 358 +----------+ +----------+ | +----+-----+ +-----+----+ | 359 | | | | 360 | --+-------------+---+- | 361 | Network E | | 362 +------+--------+ | | End-User 363 | IPv6 | | | networks 364 | Interior | | | 365 | Router | | | 366 +---+-------+---+ | | 367 Network C | | Network D | | 368 ----+-------------+---+ +---+---------+- | | 369 | | | | | | 370 +----+-----+ +-----+----+ +----+-----+ +-+------+-+ | 371 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 372 | | | | | | | X | / 373 +----------+ +----------+ +----------+ +----------+ / 375 Figure 3: Allowed internal host multihoming 377 +-------+-------+ +-------+-------+ \ 378 | Service | | Service | \ 379 | Provider A | | Provider B | | Service 380 | Router | | Router | | Provider 381 +------+--------+ +-------+-------+ | network 382 | | / 383 | Customer | / 384 | Internet connections | / 385 | | 386 +------+--------+ +-------+-------+ \ 387 | IPv6 | | IPv6 | \ 388 | Customer Edge | | Customer Edge | \ 389 | Router 1 | | Router 2 | / 390 +------+--------+ +-------+-------+ / 391 | | / 392 | | | End-User 393 ---+---------+---------+ +-------+---------+--- | network(s) 394 | | | | \ 395 +----+-----+ +--+----+--+ +-----+----+ \ 396 |IPv6 Host | |IPv6 Host | |IPv6 Host | / 397 | | | | | | / 398 +----------+ +----------+ +----------+ 400 Figure 4: Allowed site multihoming 402 6. Automatic hierarchical DHCPv6 Prefix Delegation 404 The basic idea is that each router operates a DHCP PD client on their 405 uplink interface, and a DHCP PD server on each of their downlink 406 interfaces. The router can then take the prefix it is delegated on 407 its uplink interface, and carve that up into 409 Prefixes that are advertised in router advertisements on its 410 downlink interfaces for Stateless Address autoconfiguration 411 [RFC4862] of neighboring host and router interfaces. 413 Prefixes that are made available to its DHCP PD server, from which 414 downlink neighboring routers can request allocations. 416 A router would typically know how many downlink interfaces it has 417 (unless it creates they on the fly based on 802.1X, but that isn't a 418 zero-configuration case). But in general a router does not know how 419 many downlink neighboring routers it might have - whether the 420 topology of routers will look like a wire tree or a narrow daisy- 421 chain. However, we recommend a heuristic approach. If a router has 422 e.g., four wired Ethernet ports and two radio interfaces, it would 423 seem unlikely for it to have more than about six neighboring downlink 424 routers. Based on this we recommend that a router of that size by 425 default reserve seven sub-prefixes for PD allocation. That is the 426 basis for automating the sub-delegations. 428 6.1. Example 430 We assume the ISP allocates a /56 prefix to the CER, and that all the 431 routers use the above default of 7 sub-prefixes. Let the prefix be 432 2001:DB8:0:CD00::/56. The router adds "3" to the prefix length which 433 results in 8 different /59 prefixes: 435 2001:DB8:0:CD00::/59 437 2001:DB8:0:CD20::/59 439 2001:DB8:0:CD40::/59 441 2001:DB8:0:CD60::/59 443 2001:DB8:0:CD80::/59 445 2001:DB8:0:CDA0::/59 447 2001:DB8:0:CDC0::/59 449 The router can use the first /59 to create 32 different /64 prefixes 450 for its downlinks, and has 7 different /59 prefixes it can allocate 451 to downlink neighboring IRs. 453 When an IR that is directly attached to the CER invokes the DHCP PD 454 client on its uplink interface it might be assigned 2001:DB8:0: 455 CD60::/59. That router operates in exactly the same manner and adds 456 "3" to the prefix length to create 8 different /62 prefixes: 458 2001:DB8:0:CD60::/62 460 2001:DB8:0:CD64::/62 462 2001:DB8:0:CD68::/62 464 2001:DB8:0:CD6C::/62 466 2001:DB8:0:CD70::/62 468 2001:DB8:0:CD74::/62 470 2001:DB8:0:CD78::/62 471 2001:DB8:0:CD7C::/62 473 The router can use the first /62 to create 4 different /64 prefixes 474 for its downlink links and has 7 different /62 prefixes to assign to 475 its child IRs should there be any. 477 Suppose there is a third layer of routers, so that an IR requests a 478 prefix from the above IR. Then it might be assigned 2001:DB8:0: 479 CD78::/62. It carves that into four /64 prefixes (it can't carve 480 into smaller chunks than /64): 482 2001:DB8:0:CD78::/64 484 2001:DB8:0:CD79::/64 486 2001:DB8:0:CD7A::/64 488 2001:DB8:0:CD7B::/64 490 If the router has less than four downlink interfaces, then it would 491 keep the leftover /64 prefixes in reserve for its DHCP PD client. 493 One such example network is depicted in Figure 5. In this figure 494 L(Prefix) is used to denote that the prefix is being advertised in an 495 RA as an on-link prefix and D(Prefix) is used to denote that the 496 prefix is being delegated from the Delegating Router (DR) to the 497 Requesting Router (RR) in the downward direction. 499 | 500 D(2001:DB8:0:CD00::/56)| 501 | 502 +------+--------+ \ 503 | IPv6 | \ 504 | Customer Edge | \ 505 | Router | | 506 +----+-----+----+ | 507 L(2001:DB8:0:CD00::/64) | | L(2001:DB8:0:CD01::/64) | 508 ----+-------------+----+ +----------+------------ | 509 | | | | 510 | D(2001:DB8:0:CD20::/59) D(2001:DB8:0:CD40::/59) | 511 | | | | 512 +----+-----+ +-----+----+ +-----+----+ | 513 |IPv6 Host | |IPv6 Int. | |IPv6 Int. | | 514 | | | Router | | Router | | 515 +----------+ +-----+----+ +-----+----+ | 516 | | | 517 L(2001:DB8:0:CD20::/64) L(2001:DB8:0:CD40::/64) | 518 | | | 519 ----+-------------+---- --+--------------+---- | 520 | | | | | 521 | D(2001:DB8:0:CD24::/59) | D(2001:DB8:0:CD44::/62)| 522 | | | | | 523 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 524 |IPv6 Host | |IPv6 Int. | |IPv6 Host | |IPv6 Int. | | 525 | | | Router | | | | Router | | 526 +----------+ +-----+----+ +----+-----+ +-----+----+ | 527 / 528 / 529 / 531 Figure 5: Automatic prefix delegation 533 6.2. Configurability 535 A router SHOULD provide a configuration interface where that allows 536 both adjusting the added prefix length ("3" in the above example), 537 and also allows manual assignment of prefixes to DHCP PD clients (in 538 the same manner than many IPv4 home routers allow pre-assignment of 539 IPv4 addresses today). 541 6.3. Routing Implications 543 If a router (CER or IR) has been assigned a prefix on its uplink 544 interface (e.g., 2001:DB8:0:CD60::/59) then any destination address 545 which is outside of that prefix should be routed to its uplink. The 546 router maintains a default route to its uplink for this purpose using 547 Neighbor Discovery [RFC4861] on its uplink interface. Destination 548 addresses that fall in its delegated prefix will either be routed to 549 downlink interfaces (if they are assigned as a subnet prefix on an 550 interface, or delegated to a downlink router) or dropped (for 551 unassigned prefixes). 553 Thus there is no need to run a routing protocol to handle the Basic 554 Homenet topologies. 556 6.4. Neighbor Discovery Implications 558 A router (CER or IR) will perform Neighbor Discovery as a host on its 559 uplink interface, thus it will send Router Solicitations and use 560 received Router Advertisements to track its default uplink router. 561 Note that in some suboptimal topologies there might be multiple 562 uplink routers (if some bridge has been inserted) thus a router 563 should handle multiple default routers on its uplink interface. 565 A CER and IR needs to perform Neighbor Discovery as a router on its 566 downlink interfaces. Thus it will send Router Advertisements 567 periodically and respond to Router Solicitations. 569 If the prefix delegated by the uplink router changes, this means that 570 the router needs to change both the /64 prefixes it is advertising in 571 RAs and also get the downlink routers to which it has delegated sub- 572 prefixes to get reconfigured. For planned changes that can be 573 handled by ensuring that the lifetime, T0 and T1 [RFC3315] are 574 carried from the PD client in a router to its PD server. But for 575 unplanned changes, for instance when someone manually changes the 576 prefixes on a CER or IR, one would like a way to have that be 577 propagated to downlink PD clients. In theory DHCP Reconfigure 578 messages [RFC3315] could be used, but they require some security 579 configuration. Thus we suggest using prefix changes in received 580 Router Advertisements (on the uplink interface) as a hint that the 581 router's PD client should attempt to renew its DHCP lease and as a 582 result of that discover changes in the delegated prefixes. 584 6.5. Ensuring stable prefixes 586 It is highly desirable that the home network maintain the same prefix 587 allocation even if parts or all of the network are powered off and 588 back on, or otherwise fail and come back. That can be handled if the 589 DHCP PD servers in each router (and also in the ISP) maintain the 590 delegated prefixes in stable storage (to guard against the router 591 itself failing) and also retain information about the last holder of 592 a lease even after the lease has expired. That way, as long as the 593 number of downlink routers is less than the size of the pool of 594 prefixes available for delegation (7 in the example above), even if a 595 downlink router is powered off for a long time, when it comes back it 596 will receive the same prefix. 598 7. Addressing 600 This document suggests delegating Unique link-local Addresses 601 [RFC4193] and IPv6 Global addresses. The ULA can be only generated 602 or manually configured at the Customer Edge Router (CER) and then 603 delegated down the link the same way IPv6 Global prefix is delegated. 604 A CER SHOULD be capable of delegating a ULA prefix and a IPv6 Global 605 prefix obtained from the ISP. 607 When the home network is initialized the hosts and routers on the 608 network will start off with only having link local addresses. They 609 will use the link local addresses to bootstrap address acquisition 610 using DHCP PD for the other scopes of addresses. 612 Depending on whether the CER has working upstream connectivity or 613 not, it is possible that differently scoped addresses/prefixes could 614 be assigned to the home network. 616 When the home network permanently has no upstream connectivity 617 towards the ISP, it is RECOMMENDED that the CER create an Unique 618 Local Prefix as specified in [RFC4193]. We recommend using a /48 ULA 619 prefix as specified in that RFC. Note that it might be difficult to 620 automatically determine whether 1) the home network is permanently 621 disconnected from the ISP and 2) whether a particular router is the 622 CER. Thus it is RECOMMENDED that the generation of the ULA prefix is 623 triggered by manual configuration in the case of a disconnected 624 network. 626 Even for a connected home network it is RECOMMENDED to trigger the 627 generation of the ULA manually on the CER. The CER will then 628 automatically delegate parts of that prefix concurrently with sub- 629 delegating the global prefix it received from the ISP. Potentially 630 one could do this automatically by leveraging the bootstrapping 631 behavior to determine whether a router is a CER or an IR, with the 632 assumption that the ISP would never delegate a ULA prefix to its 633 customer. In that case, if a router receives a prefix delegation 634 that contains a global prefix but no ULA, then it can assume it is 635 the CER and (if it hasn't already) generate a ULA, store that ULA in 636 its persistent storage, and sub-delegate the global prefix and the 637 ULA in parallel to any downlink PD clients. 639 In many cases the ISP will select the prefix length it will delegate. 640 Thus it is RECOMMENDED that a router (CER or IR) by default set the 641 prefix-length field [RFC3633] in field of a IA_PD Prefix option 642 (OPTION_IAPREFIX) to zero. A router that has the role of a CER may 643 be manually configured to request a particular prefix-length, but the 644 default allocation scheme in this document assumes that IRs do not 645 set the prefix-length. 647 8. Basic Operations 649 It is assumed that CER requests one or more IPv6 prefixes from the 650 ISP Prefix delegating router for IPv6 prefixes for a specified prefix 651 length if the service agreement allows the CER to support multi-level 652 subnets without NAT66 [RFC6296]. Currently DHCP-PD [RFC3633] allows 653 a requesting router to request a specific prefix through the IA 654 prefix option. This document discusses a simple mechanism for 655 assigning and delegating prefixes through the hierarchy in the home 656 network (section 6 and section 6.1). However, the implementation 657 SHOULD also support ability of the requesting router to request a 658 prefix of a specific length by filling-in the Prefix Length field of 659 the IA prefix option while the IPv6-prefix field being the 660 unspecified address. 662 In addition, this specification requires all IRs to be able to store 663 and delegate prefixes on its downlink interfaces only. The prefix 664 should be stored during reboots and power failure. 666 The 'Topology' section diagrams are the typical home networking 667 scenarios where the above prefix delegation mechanism is believed to 668 work well. 670 8.1. DHCPv6 Prefix Delegation 672 The DHCPv6 prefix delegation at CER follows DHCP-PD [RFC3633] in 673 order to receive the Prefix(es) from the ISP Prefix delegator and it 674 can act as a local prefix delegator for the home network. 676 DHCP-PD [RFC3633] suggests that in a typical scenario, /48 prefix is 677 assigned to the requesting router. The operational procedures by an 678 ISP might limit this default to a /56. The CER may be configured 679 with a specific prefix length to request from the delegating router. 681 Thus CER will include IA_PD option(s) as specified in [RFC3633]. In 682 the IA_PD Prefix option, the IPv6-Prefix field is set to zero if the 683 requesting router does not have any prior knowledge about its IPv6 684 Prefix. The prefix length MAY be set between /48 and /64 inclusive 685 when the requesting router likes to specify a prefix len. By default 686 the delegating router (CER and delegating IR) adds bits to the prefix 687 before delegating downwards. The automatic bits calculation and 688 prefix formation is described in section 6 and 7 above. 690 The IRs also operate as a DHCP PD requesting router on their uplink 691 interface, but unlike the CER there is no need to specify a prefix 692 length that they will request. 694 Each CER and IR SHOULD act as a default routers on its downlink 695 interfaces by selecting a /64 prefix for each downlink interface and 696 advertising it in Router Advertisements downlink interface. The IRs 697 can use Stateless Address Autoconfiguration to configure the IPv6 698 addresses on the uplink interface as specified in [RFC4862]. If a 699 CER or IR is only delegated a /64 prefix from its delegating router 700 then it can advertise in Router Advertisements for one of its 701 downlink interfaces, but it can not run a DHCP PD server. 703 There is no need for a dynamic routing protocol since each IR will 704 have a default route towards its delegating router on its uplink 705 interface. 707 9. Host Behavior 709 Whether a host uses Stateless Address autoconfiguration or DHCPv6, it 710 does not require any change due to the solutions proposed in this 711 draft. 713 10. Router Behavior 715 All home routers (CER and IRs) behave the same as specified in 716 section 6 and section 8, with the exception that a CER might be 717 configured to generate a ULA prefix and delegate sub-prefixes of that 718 ULA. 720 11. Bootstrapping 722 It is desirable that the prefix delegation flow in an orderly manner 723 from the ISP to the CER and further down to the IRs, and down to 724 hosts. We do not want any prefix flapping (some IR guessing a prefix 725 to advertise before it has received anything from its uplink), hence 726 it is RECOMMENDED that a router wait until its PD client on the 727 uplink interface has received a prefix allocation, and at that point 728 in time in enable its PD server on its downlink interface and also 729 enable the sending of Router Advertisements on its downlink 730 interfaces. The only exception to this is a CER which has been 731 configured to generate and advertise a ULA prefix even when the ISP 732 connection is down; such a CER would sub-delegate and advertise the 733 ULA prefix in parallel with requesting a prefix delegation from the 734 ISP. 736 The above behavior implies that when the whole home network is 737 brought up (e.g., after a power failure) it might take a while until 738 a host will start receiving Router Advertisement messages. But once 739 those RAs arrive they will contain at least a ULA prefix and in many 740 cases both a ULA and a global prefix. 742 12. What if there are loops? 744 Even if the configuration falls outside of the topology constraints 745 we have specified, we still want the home network to be no worse than 746 the same topology with IPv4 NAT routers. One such topology is when 747 there is a L2 bridge which connects some downlink interfaces on two 748 or more routers, and there are some hosts attached to that bridge 749 and/or there are routers that attach their uplink interface to that 750 bridge. See Figure 6. 752 +------+--------+ \ 753 | IPv6 | \ 754 | Customer Edge | \ 755 | Router | | 756 +----+-----+----+ | 757 Network A | | Network B | 758 ----+-------------+----+ +---+-------------+----- | 759 | | | | | 760 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 761 |IPv6 Host | |IPv6 Int. | |IPv6 Int. | |IPv6 Host | | 762 | | | Router X | | Router Y | | | | End-User 763 +----------+ +-----+----+ +----+-----+ +----------+ | networks 764 | | | 765 Network C | | Network C | 766 ----+-------------+--------------+-------------+----- | 767 | | | | | 768 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 769 |IPv6 Host | |IPv6 Int. | |IPv6 Int. | |IPv6 Host | | 770 | | | Router Z | | Router W | | | | 771 +----------+ +-----+----+ +----+-----+ +----------+ | 772 | | | 773 Network E | | Network F | 774 ----+-------------+----- ----+-------------+- | 775 | | | | | 776 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 777 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 778 | | | | | | | | / 779 +----------+ +-----+----+ +----------+ +----------+ / 781 Figure 6: Bridge causing multiple uplink routers 783 In the figure the downlink interfaces of Router X and Router Y have 784 been bridged together. Router X and Y will have received their own 785 prefix delegation from the CER. They will each have pick some /64 786 prefix from that to advertise in Router Advertisement on Network C. 787 Thus one effect of the bridge is that the hosts that attach to 788 network C will, following [RFC4862], configure multiple addresses on 789 their interface. The same might happen for the routers that have an 790 uplink interface to Network C; they might configure multiple 791 addresses on that interface. 793 A second effect of the bridge is that the PD clients in router Z and 794 W now has two potential DHCP PD servers. Presumably this means that 795 they pick one of them that responds to their DHCP request. Thus 796 router Z and W might end up picking a different uplink router for 797 their PD allocation. That isn't any different than in the DHCPv4 and 798 NAT case. What is different with IPv6 is that the default router 799 assignment is being done using Router Advertisements, thus both 800 router Z and W will end up with two default routers; X and Y. This is 801 independent of which uplink router assigned them a sub-prefix. As 802 long as the home routers do not perform ingress filtering based on 803 the allocated prefixes this will work, but we might want to consider 804 somehow tying the PD allocation to the choice of default router? 805 +------+--------+ \ 806 | IPv6 | \ 807 | Customer Edge | \ 808 | Router 1 | | 809 +------+--------+ +------------+ | 810 Network A | | | | 811 +-------------+------+-------+-------+-----+ | | 812 | | | | | | | 813 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | | 814 |IPv6 Host | |IPv6 Host | | | IPv6 | |IPv6 Host | | | 815 | | | | | | Router 2| | | | | 816 +----------+ +----------+ | +----+-----+ +----------+ | | 817 | | | | 818 | +-------------+ | | 819 | | Network B | | | 820 | | | | | 821 | +----+-----+ +-----+----+ | | 822 | | IPv6 | |IPv6 Host | | | 823 | | Router 3| | | | | 824 | +----+-----+ +----------+ | | 825 | | | | 826 | +--------------------+ | 827 | Network C/A | 828 +------+--------+ | End-User 829 | IPv6 | | networks 830 | Router 4 | | 831 +------+--------+ | 832 Network D | | 833 +-------------+------+--------+---------+ | 834 | | | | | 835 +----+-----+ +-----+----+ +----+-----+ +-+------+-+ | 836 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 837 | | | | | | | | / 838 +----------+ +----------+ +----------+ +----------+ / 840 Figure 7: Bridges causing uplink loops 842 In Figure 7 we see a loop which is caused by having the downlink 843 interface of router 3 be an attached as an uplink of router 2. This 844 means that Router 2 and Router 4 see two different uplink router; 845 router 1 and router 3. 847 In the IPv4 case, just as above, the default configuration of R1 and 848 R3 might cause IP address conflicts since both might have 849 192.168.1.1/24 as defaults on their downlink ports in which case the 850 network doesn't work at all. Just as above that can be manually 851 corrected by e.g., configuring R3 to have 10.0.0.1/24 on its downlink 852 interface. In that when case R2 and R4 uses DHCPv4 they might pick 853 the DHCP response from either R1 or R3 and configure themselves to 854 either have a 192.168 address and 192.168.1.1 as their default 855 router, or a 10.0 address and 10.0.0.1 as a default router. If R2 856 picks picks the latter (R3), then outbound traffic will loop, since 857 it will be sent to R3 which will NAT and send to R2 which will NAT 858 and send to R3. If R2 picks R1 and R4 picks R3 then traffic from R4 859 to the Internet will merely go through two extra NATs. In general we 860 can't predict which DHCP server R2 and R4 will pick, hence sometimes 861 the network will work and sometimes not. 863 With the proposed prefix delegation scheme and associated 864 bootstrapping for IPv6 things can work a little bit better, since we 865 recommend that a router not enable its PD client on the downlinks 866 until its PD server on the uplink has been delegated a prefix. Thus 867 R1 will be delegated a prefix from the ISP, and then assign a /64 to 868 Network A and enable the PD server. Then R2 and R4 can receive 869 delegations only from R1, since R3 has not yet enabled its PD server. 870 Later when R3 has received a delegation from R2 it will enable the PD 871 server. Note that it isn't much better than for IPv4 since it R4 is 872 powered off and back on or just boots very slowly after a complete 873 power failure it might come up after the R1 -> R2 -> R3 delegation 874 chain has already occurred, in which case R4 might pick R3 as its 875 delegating router. And if R2 crashes and comes back, it might also 876 pick R3 since R2's delegation to R3 will have a non-zero lifetime. 878 [DISCUSSION: It is possible to improve on the above by having the PD 879 client use the delegated prefix-length to determine which DHCP lease 880 to accept; preferring longer prefixes will make it choose a 881 delegating router which is closer to the ISP. In the above example 882 R1 might delegate /59 prefixes while R3 can delegate only /64 883 prefixes. But it isn't clear that such added complexity is worth- 884 while. Note that for that to help we'd also need to pick the 885 delegating router as the default router, instead of building a 886 default router list with all the routers which send RAs. 888 13. Security Considerations 890 No new threats against Neighbor Discovery beyond what is already 891 documented for IPv6 ND [RFC3756] due to IPv6 Address 892 autoconfiguration and Neighbor Discovery at the last hop of Prefix 893 distribution. The recommendations in this document does not prevent 894 using Secure Neighbor Discovery [RFC3971]. 896 The security threats for this solution is believed to be no worse 897 than DHCPv6 Prefix delegation[RFC3633]. See Section 15 of RFC 3633 898 for further information. 900 A malicious host inside the end user network can perform a prefix 901 exhaustion attack on the CER or the IRs. It works as follows; the 902 malicious router keeps on requesting prefixes from the delegating 903 router (DR), which could be the CER or another IR, until all the 904 prefixes have been delegated. At this point a legitimate router that 905 attaches to the delegating router will fail to get a prefix delegated 906 as the DR has no more prefixes available to delegate. This means 907 that the subset of the network behind this newly attaching router 908 will not get any connectivity. This can be avoided by using some 909 form of authorization on the delegating router but the specification 910 of such a mechanism is outside the scope of this document. It might 911 make sense to offer configuration capability so that prefix 912 delegation can be disables on certain links such as a guest network. 914 14. IANA Considerations 916 This document does not require any IANA actions. 918 15. Acknowledgements 920 The authors like to thank David Allan, Joel Halpern, Acee Lindem and 921 Jari Arkko for comments on the proposal of the draft. Alan Kavangh 922 suggested using the default prefix len(/56) as per Broadband Forum's 923 recommendation. We thank Tim Chown for the ASCII-art drawings that 924 we reused and in some cases expanded on it this draft. 926 16. References 928 16.1. Normative References 930 [I-D.chown-homenet-arch] 931 Arkko, J., Chown, T., Weil, J., and O. Troan, "Home 932 Networking Architecture for IPv6", 933 draft-chown-homenet-arch-00 (work in progress), 934 September 2011. 936 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 937 Requirement Levels", BCP 14, RFC 2119, March 1997. 939 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 940 Host Configuration Protocol (DHCP) version 6", RFC 3633, 941 December 2003. 943 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 944 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 945 September 2007. 947 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 948 Address Autoconfiguration", RFC 4862, September 2007. 950 16.2. Informative References 952 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 953 (IPv6) Specification", RFC 2460, December 1998. 955 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 956 and M. Carney, "Dynamic Host Configuration Protocol for 957 IPv6 (DHCPv6)", RFC 3315, July 2003. 959 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 960 Discovery (ND) Trust Models and Threats", RFC 3756, 961 May 2004. 963 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 964 Delegation", RFC 3769, June 2004. 966 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 967 Neighbor Discovery (SEND)", RFC 3971, March 2005. 969 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 970 Addresses", RFC 4193, October 2005. 972 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 973 Translation", RFC 6296, June 2011. 975 Authors' Addresses 977 Erik Nordmark 978 Cisco Systems 979 San Jose, CA 980 USA 982 Email: nordmark@cisco.com 984 Samita Chakrabarti 985 Ericsson 986 San Jose, CA 987 USA 989 Email: samita.chakrabarti@ericsson.com 990 Suresh Krishnan 991 Ericsson 992 Montreal, 993 CANADA 995 Email: suresh.krishnan@ericsson.com 997 Wassim Haddad 998 Ericsson 999 San Jose, CA 1000 USA 1002 Email: wassim.haddad@ericsson.com