idnits 2.17.1 draft-grundemann-homenet-hipnet-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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance 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 == Line 129 has weird spacing: '... Router a nod...' -- The document date (February 25, 2013) is 4077 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'UPNnP-IGD' is mentioned on line 195, but not defined == Unused Reference: 'I-D.cheshire-dnsext-multicastdns' is defined on line 870, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-05) exists of draft-donley-dhc-cer-id-option-01 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-07 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Grundemann 3 Internet-Draft C. Donley 4 Intended status: Informational CableLabs 5 Expires: August 29, 2013 J. Brzozowski 6 Comcast Cable Communications 7 L. Howard 8 Time Warner Cable 9 V. Kuarsingh 10 Rogers Communications 11 February 25, 2013 13 A Near Term Solution for Home IP Networking (HIPnet) 14 draft-grundemann-homenet-hipnet-01 16 Abstract 18 Home networks are becoming more complex. With the launch of new 19 services such as home security, IP video, Smart Grid, etc., many 20 Service Providers are placing additional IPv4/IPv6 routers on the 21 subscriber network. This document describes a self-configuring home 22 router that is capable of operating in such an environment, and that 23 requires no user interaction to configure it. Compliant with 24 draft-ietf-homenet-arch, it uses existing protocols in new ways 25 without the need for a routing protocol. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 29, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Current End-User Network Architecture . . . . . . . . . . 5 72 3.2. HIPNet End-User Network Architecture . . . . . . . . . . . 6 73 4. Network Detection . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1. Edge Detection . . . . . . . . . . . . . . . . . . . . . . 8 75 4.2. Directionless Home Routers . . . . . . . . . . . . . . . . 9 76 5. Routing and Addressing . . . . . . . . . . . . . . . . . . . . 10 77 5.1. Recursive Prefix Delegation . . . . . . . . . . . . . . . 11 78 5.2. Prefix Sub-Delegation Requirements . . . . . . . . . . . . 12 79 5.3. Multiple Address Family Support . . . . . . . . . . . . . 13 80 5.4. Hierarchical Routing . . . . . . . . . . . . . . . . . . . 13 81 6. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . . . 13 82 6.1. Backup Connection . . . . . . . . . . . . . . . . . . . . 14 83 6.2. Multi-homing . . . . . . . . . . . . . . . . . . . . . . . 14 84 6.2.1. Multihoming Requirements . . . . . . . . . . . . . . . 16 85 7. Mulicast Support . . . . . . . . . . . . . . . . . . . . . . . 17 86 7.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 17 87 7.2. Multicast Proxy Support . . . . . . . . . . . . . . . . . 17 88 7.3. Multicast Requirements . . . . . . . . . . . . . . . . . . 17 89 8. Firewall Support . . . . . . . . . . . . . . . . . . . . . . . 18 90 8.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 96 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 100 1. Introduction 102 This document expands upon [I-D.ietf-v6ops-6204bis] to describe IPv6/ 103 IPv4 features for a residential or small-office router, referred to 104 as a HIPnet router. Consistent with [I-D.ietf-homenet-arch], it 105 focuses on network technology evolution to support increasingly large 106 residential/SoHo networks. While the primary focus is on IPv6 107 support, this document also describes how to leverage IPv6 to 108 configure IPv4 in a manner better than nested NATs in operation on 109 many networks today. 111 This document specifies how a HIPnet router automatically detects 112 both the edge of the customer network and its upstream interface, how 113 it subdivides an IPv6 prefix to distribute to downstream routers, and 114 how it leverages IPv6 address assignment to distribute IPv4 115 addresses. It also discusses how such a router can operate with a 116 backup ISP or limited multihoming across two ISPs. 118 1.1. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 2. Terminology 126 End-User Network one or more links attached to the HIPnet 127 router that connect IPv6 and IPv4 hosts. 129 Home IP Network (HIPnet) Router a node intended for home or small- 130 office use that forwards packets not 131 explicitly addressed to itself. 133 Customer Edge Router (CER) a HIPnet router that connects the end- 134 user network to a service provider network. 136 Internal Router an additional HIPnet router deployed in the 137 home or small-office network that is not 138 attached to a service provider network. 139 Note that this is a functional role; it is 140 expected that there will not be a 141 difference in hardware or software between 142 a CER and IR, except in such cases when a 143 CER has a dedicated non-Ethernet WAN 144 interface (e.g. DSL/cable/ LTE modem) that 145 would preclude it from operating as an IR. 147 Down Interface a HIPnet router's attachment to a link in 148 the end-user network on which it 149 distributes addresses and/or prefixes. 150 Examples are Ethernet (simple or bridged), 151 802.11 wireless, or other LAN technologies. 152 A HIPnet router may have one or more 153 network-layer down interfaces. 155 downstream router a router directly connected to a HIPnet 156 router's Down Interface. 158 Service Provider an entity that provides access to the 159 Internet. In this document, a service 160 provider specifically offers Internet 161 access using IPv6, and may also offer IPv4 162 Internet access. The service provider can 163 provide such access over a variety of 164 different transport methods such as DSL, 165 cable, wireless, and others. 167 Up Interface a HIPnet router's attachment to a link 168 where it receives one or more IP addresses 169 and/or prefixes. This is also the link to 170 which the HIPnet router points its default 171 route. 173 depth the number of layers of routers in a 174 network. A single router network would 175 have a depth of 1, while a router behind a 176 router behind a router would have a depth 177 of 3. 179 width The number of routers that can be directly 180 subtended to an upstream router. A network 181 with three directly attached routers behind 182 the CER would have a width of 3. 184 3. Architecture 186 3.1. Current End-User Network Architecture 188 An end-user network will likely support both IPv4 and IPv6. A 189 typical end-user network consists of a "plug and play" router with 190 IPv4 NAT functionality and a single link behind it, connected to the 191 service provider network. 193 A typical IPv4 NAT deployment by default blocks all incoming 194 connections. Opening of ports is typically allowed using a Universal 195 Plug and Play Internet Gateway Device (UPnP IGD) [UPNnP-IGD] or some 196 other firewall control protocol. 198 Rewriting addresses on the edge of the network allows for some 199 rudimentary multihoming, even though using NATs for multihoming does 200 not preserve connections during a fail-over event [RFC4864]. 202 Many existing routers support dynamic routing, and advanced end-users 203 can build arbitrary, complex networks using manual configuration of 204 address prefixes combined with a dynamic routing protocol. 206 3.2. HIPNet End-User Network Architecture 208 The end-user network architecture should provide equivalent or better 209 capabilities and functionality than the current architecture. 210 However, as end-user networks become more complex, the HIPnet 211 architecture needs to support more complicated networks. Figure 1 212 illustrates the model topology for the end-user network. 214 +-------+-------+ \ 215 | Service | \ 216 | Provider | | Service 217 | Router | | Provider 218 +-------+-------+ | network 219 | / 220 | Customer / 221 | Internet connection / 222 | 223 +------+--------+ \ 224 | IPv6 | \ 225 | Customer Edge | \ 226 | Router | / 227 +---+-------+-+-+ / 228 Network A | | Network B | End-User 229 ---+-------------+----+- --+--+-------------+--- | network(s) 230 | | | | \ 231 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 232 | Host | |Internal | | Host| |Internal | / 233 | | | Router | | | | Router | / 234 +----------+ +-----+----+ +----------+ +----------+ / 235 Network C | Network D | | 236 ---+-------------+----+- --+--+-------------+--- | 237 | | | | \ 238 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 239 | Host | | Host | | Host| | Host | / 240 | | | | | | | | / 241 +----------+ +-----+----+ +----------+ +----------+ / 243 Figure 1: Example End-User Network 245 This architecture describes the following: 247 o Prefix subdelegation supporting multiple subnets and routers 249 o Border Detection 251 o Router directionality supporting a hierarchical network 253 o Multicast forwarding rules to support common service discovery 254 protocols 256 While routers described in this document may be manually configured 257 in an arbitrary topology with or without a dynamic routing protocol, 258 this document only addresses automatic provisioning and 259 configuration. 261 4. Network Detection 263 In multirouter home networks, routers have to determine where they 264 fit in the topology - whether they are at the edge or internal, and 265 which interface is up (that is, which interface points out of the 266 network). 268 4.1. Edge Detection 270 Customer Edge Routers (CER) will often be required to behave 271 differently from Internal Routers (IR) in several capacities. Some 272 examples include: Firewall settings, IPv4 NAT, ULA generation (if 273 supported), name services, multicast forwarding differences, and 274 others. This is a functional role, and will not typically be 275 differentiated by hardware/software (i.e. end users will not purchase 276 a specific CER model of router distinct from IR models). 278 There are three methods that a router can use to determine if it is a 279 CER for its given network: 281 "/48 Check" Service providers will provide IPv6 WAN addresses 282 (DHCPv6 IA_NA) and IPv6 prefixes (DHCPv6 IA_PD) from different 283 pools of addresses. The largest IPv6 prefix that we can expect to 284 be delegated to a home router is a /48. Combining these two 285 observations, a home router can compare the WAN address assigned 286 to it with the prefix delegated to it to determine if it is 287 attached directly to a service provider network. If the router is 288 a CER, the WAN address will be from a different /48 than the 289 prefix. If the router is an IR, the WAN address will be from the 290 same /48 as the prefix. In this way, the router can determine if 291 it is recieving an "external" prefix from a service provider or an 292 "internal" prefix from another home router. 294 CER_ID A home router can use the CER_ID DHCPv6 option defined in 295 [I-D.donley-dhc-cer-id-option] to determine if it is a CER or an 296 IR. ISPs will not set the CER_ID option, but the first CPE router 297 sets its address in the option and other routers forward the 298 completed CER_ID to subdelegated routers. 300 Physical Some routers will have a physical differentiator built into 301 them by design that will indicate that they are a CER. Examples 302 include mobile routers, DSL routers, and cable eRouters. In the 303 case of a mobile router, the presence of an active cellular 304 connection indicates that the router is at the customer edge. 305 Likewise, for an eRouter, the presence of an active DOCSIS(R) link 306 tells the router that it is at the customer edge. 308 HIPnet routers can (and likely will) use more than one of the above 309 techniques in combination to determine the edge. For example, an 310 internal router will check for the CER_ID option, but will also use 311 the 48 check in case its upstream router does not support CER_ID. 313 4.2. Directionless Home Routers 315 As home networks grow in complexity and scale, it will become more 316 common for end users to make mistakes with the physical connections 317 between multiple routers in their home or small office. This is 318 liklely to produce loops and improper uplink connections. While we 319 can safely assume that home networks will become more complex over 320 time, we cannot make the same assumption of the users of home 321 networks. Therefor, home routers will need to mitigate these 322 physical topology problems and create a working multi-router home 323 network dynamically, without any end user intervention. 325 Legacy home routers with a physically differentiated uplink port are 326 "directional;" they are pre-set to route from the 'LAN' or Internal 327 ports to a single, pre-defined uplink port labeled "WAN" or 328 "Internet". This means that an end-user can make a cabling mistake 329 which renders the router unusable (e.g. connecting two router's 330 uplink ports together). On the other hand, in enterprise and service 331 provider networks, routers are "directionless;" that is to say they 332 do not have a pre-defined 'uplink' port. While directional routers 333 have a pre-set routing path, directionless routers are required to 334 determine routing paths dynamically. Dynamic routing is often 335 achieved through the implementation of a dynamic routing protocol, 336 which all routers in a given network or network segment must support 337 equally. This section introduces an alternative to dynamic routing 338 protocols (such as OSPF) for creating routing paths on the fly in 339 directionless home routers. 341 Note that some routers (e.g. those with a dedicated wireless/DSL/ 342 DOCSIS WAN interface) may continue to operate as directional routers. 343 The HIPnet mechanism described below is intended for general-purpose 344 routers. 346 The HIPnet mechanism uses address acquisition as described in 347 [I-D.ietf-v6ops-6204bis] and various tiebreakers to determine 348 directionality (up vs. down) and by so doing, creates a logical 349 hierarchy (cf. [I-D.chakrabarti-homenet-prefix-alloc]) from any 350 arbitrary physical topology: 352 1. After powering on, the HIPnet router sends Router Solicitations 353 (RS) ([RFC4861]on all interfaces (except Wi-Fi*) 355 2. Other routers respond with Router Advertisements (RA) 357 3. Router adds any interface on which it receives an RA to the 358 candidate 'up' list 360 4. The router initiates DHCPv6 PD on all candidate 'up' interfaces. 361 If no RAs are received, the router generates a /48 ULA prefix. 363 5. The router evaluates the offers received (in order of preference): 365 a) Valid GUA preferred (preferred/valid lifetimes >0) 367 b) Internal prefix preferred over external (for failover - see 368 Section [6.1]) 370 c) Largest prefix (e.g. /56 preferred to /60) 372 d) Link type/bandwidth (e.g. Ethernet vs. MoCA) 374 e) First response (wait 1 s after first response for additional 375 offers) 377 f) Lowest numerical prefix 379 6. The router chooses the winning offer as its Up Interface. 381 Once directionality is established, the router continues to listen 382 for RAs on all interfaces but doesn't acquire addresses on Down 383 Interfaces. If the router initially receives only a ULA address on 384 its Up Interface and GUA addressing becomes available on one of its 385 Down Interfaces, it restarts the process. If the router stops 386 receiving RAs on its Up Interface, it restarts the process. 388 In all cases, the router's Up Interface becomes its uplink interface; 389 the router acts as a DHCP client on this interface. The router's 390 remaining interfaces are Down Interfaces; it acts as a DHCP server on 391 these interfaces. Also, per [I-D.ietf-v6ops-6204bis], the router 392 only sends RAs on Down Interfaces. 394 *Note: By default, Wi-Fi interfaces are considered to point "down." 395 This requires manual configuration to enable a wireless uplink, which 396 is preferred to avoid accidental or unwanted linking with nearby 397 wireless networks. 399 5. Routing and Addressing 401 HIPnet routers use DHCPv6 prefix sub-delegation ([RFC3633]) to 402 recursively build a hierarchical network 403 ([I-D.chakrabarti-homenet-prefix-alloc]). This approach requires no 404 new protocols to be supported on any home routers. 406 Default router settings: Only CER instantiates guest network. Wifi 407 defaults to 'down' direction, default route uses wired interface. 408 Firewall considers Wifi an inside port. Wi-Fi bridged with first 409 wired Down Interface. 411 5.1. Recursive Prefix Delegation 413 Once directionality is established, the home router will acquire a 414 WAN IPv6 address and an IPv6 prefix per [I-D.ietf-v6ops-6204bis]. As 415 HIPnet routers (other than the CER) do not know their specific 416 location in the hierarchical network, all HIPnet routers use the same 417 generic rules for recursive prefix delegation to facilitate route 418 aggregation, multihoming, and IPv4 support (described below). This 419 methodology expounds upon that previously described in 420 [I-D.chakrabarti-homenet-prefix-alloc]. 422 The process can be illustrated in the following way: 424 1. Per [I-D.ietf-v6ops-6204bis], the HIPnet router assigns a 425 separate /64 from its delegated prefix(es) for each of its Down 426 Interfaces in numerical order, starting from the numerically 427 lowest. 429 2. If the received prefix is too small to number all Down 430 Interfaces, the router collapses them into a single interface, 431 assigns a single /64 to that interface, and logs an error 432 message. 434 3. The HIPnet router subdivides the IPv6 prefix received via DHCPv6 435 ([RFC3315]) into sub-prefixes. To support a suggested depth of 436 three routers, with as large a width as possible, it is 437 recommended to divide the prefix on 2-, 3-, or 4-bit boundaries. 438 If the received prefix is not large enough, it is broken into as 439 many /64 sub-prefixes as possible and logs an error message. By 440 default, this document suggests that the router divide the 441 delegated prefix based on the aggregate prefix size and the 442 HIPnet router's number of physical Down Interfaces. This is to 443 allow for enough prefixes to support a downstream router on each 444 down port. 446 * If the received prefix is smaller than a /56 (e.g. a /60), 448 + 8 or more port routers divide on 3-bit boundaries (e.g. 449 /63). 451 + 7 or fewer port routers divide on 2-bit boundaries (e.g. 452 /62). 454 * If the received prefix is a /56 or larger, 456 + 8 or more port routers divide on 4-bit boundaries (e.g. 457 /60). 459 + 7 or fewer port routers divide on 3-bit boundaries (e.g. 460 /59). 462 4. The HIPnet router delegates remaining prefixes to downstream 463 routers per [RFC3633]in reverse numerical order, starting with 464 the numerically highest. This is to minimize the renumbering 465 impact of enabling an inactive interface. 467 For example, a four port router with two LANs (two Down Interfaces) 468 that receives 2001:db8:0:b0::/60 would start by numbering its two 469 Down Interfaces with 2001:db8:0:b0::/64 and 2001:db8:0:b1::/64 470 respectively, and then begin prefix delegation by giving 2001:db8:0: 471 bc::/62 to the first directly attached downstream router. 473 5.2. Prefix Sub-Delegation Requirements 475 PSD-1: The HIPnet router MUST support [I-D.ietf-v6ops-6204bis] 476 address acquisition and LAN addressing. 478 PSD-2: The HIPnet router MUST support Delegating Router behavior 479 for the IA-PD Option [RFC3633] on all Down Interfaces. 481 PSD-3: HIPnet routers MUST NOT act as both a DHCP client and server 482 on the same link. 484 PSD-4: The HIPnet router MAY support other methods of dividing the 485 received prefix. 487 PSD-5: The HIPnet router MUST delegate prefixes of the same size to 488 downstream routers. 490 PSD-6: Per [I-D.ietf-v6ops-6204bis] L-2, the HIPnet router 491 allocates a /64 to each Down Interface. The HIPnet router 492 SHOULD allocate these /64 interface-prefixes in numerical 493 order, starting with the lowest. 495 PSD-7: If there are insufficient /64s for each Down Interface, the 496 HIPnet router SHOULD assign the lowest numbered /64 for all 497 Down Interfaces and log an error message. 499 PSD-8: The HIPnet router MAY reserve additional /64 interface- 500 prefixes for interfaces that will be enabled in the future. 502 PSD-9: The HIPnet router SHOULD delegate sub-prefixes to downstream 503 routers starting from the numerically highest sub-prefix and 504 working down in reverse numerical order. 506 PSD-10: If there are not enough sub-prefixes remaining to delegate 507 to all downstream routers, the HIPnet router SHOULD log an 508 error message. 510 5.3. Multiple Address Family Support 512 The recursive prefix delegation method described above can be 513 extended to support additional address types such as IPv4, additional 514 GUAs, or ULAs. When the HIPnet router receives its prefix via DHCPv6 515 ([RFC3633]), it computes its 8-bit router ID (bits 56-64) from the 516 received IA_PD. It then prepends additional prefixes received in one 517 or more IPv6 Router Advertisements ([RFC4861]) or from the DHCPv4- 518 assigned ([RFC2131]) IPv4 network address received on the Up 519 Interface. 521 As the network is hierarchical, upstream routers know the router ID 522 for each downstream router, and know the prefix(es) on each LAN 523 segment. Accordingly, HIPnet routers automatically calculate 524 downstream routes to all downstream routers. 526 In networks using this mechanism for IPv4 provisioning, it is 527 suggested that the CER use addresses in the 10.0.0.0/8 ([RFC1918]) 528 range for downstream interface provisioning. 530 5.4. Hierarchical Routing 532 The recursive prefix delegation method described above, coupled with 533 "up detection", enables very simple hierarchical routing. By this we 534 mean that each router installs a single default 'up' route and a more 535 specific 'down' route for each prefix delegated to a downstream IR. 536 Each of these 'down' routes simply points all packets destined to a 537 given prefix to the WAN IP address of the router to which that prefix 538 was delegated. This combination of a default 'up' route and more 539 specific 'down' routes provides complete reachability within the home 540 network with no need for any additional message exchange or routing 541 protocol support. 543 6. Multiple ISPs 545 HIPnet routers can support either active/standby multihoming with 546 multiple ISPs or limited active/active multihoming without a routing 547 protocol. 549 6.1. Backup Connection 551 Using the procedure described above, multi-router home networks with 552 multiple ISP connections can easily operate in an active/standby 553 manner, switching from one Internet connection to the other when the 554 active connection fails. Lacking a default priority, HIPnet routers 555 will have to default to a "first online" method of primary CER 556 selection. In other words, by default, the first CER to come online 557 becomes the primary CER and the second CER to turn on becomes the 558 backup. In this text, the primary ISP is the ISP connected to the 559 primary CER and the backup ISP is simply the ISP atached to the 560 backup CER. 562 In an active/standby multi-ISP scenario, a backup CER sets its Up 563 Interface to point to the primary CER, not the backup ISP. Hence, it 564 does not acquire or advertise the backup ISP prefix. Instead, it 565 discovers the internally advertised GUA prefix being distributed by 566 the currently active primary CER. 568 In the case of a primary ISP failure, per [I-D.ietf-v6ops-6204bis], 569 the CER sends an RA advertising the preferred lifetime as 0 for the 570 ISP-provided prefix, and its router lifetime as 0. The backup CER 571 becomes active when it sees the primary ISP GUA prefix advertised 572 with a preferred lifetime of 0. In the case of CER failure, if the 573 backup CER sees the Primary CER stop sending RAs altogether, the 574 Backup CER becomes active. 576 When the backup CER becomes active, it obtains and advertises its own 577 external GUA. When advertising the GUA delegated by its ISP, the 578 backup CER sets the valid, prefered, and router lifetimes to a value 579 greater than 0. Other routers see this and re-determine the network 580 topology via "up" detection, placing the new CER at the root of the 581 new hiearchical tree. 583 Using this approach, manual intervention may be required to 584 transition back to the primary ISP. This prevents flapping in the 585 event of intermittent network failures. Another alternative is to 586 have a user-defined priority, which would facilitate pre-emption. 588 6.2. Multi-homing 590 The HIPnet algorithm also allows for limited active/active 591 multihoming in two cases: 593 1. When one ISP router is used as the primary connection and the 594 second ISP router is used for limited connectivity e.g. for a 595 home office 597 2. When both ISP routers are connected to the same LAN segment at 598 the top of the tree. 600 In case 1, the subscriber has a primary ISP connection and a 601 secondary connection used for a limited special purpose. (e.g. for 602 work VPN, video network, etc.). Devices connected under the 603 secondary network router access the Internet through the secondary 604 ISP. All devices still have access to all network resources in the 605 home. Devices under the secondary connection can use the primary ISP 606 if the secondary fails, but other devices do not use the secondary 607 ISP. 609 +-------+-------+ \ 610 | Service | \ 611 | Provider | | Service 612 | Router | | Provider 613 +-------+-------+ | network 614 +------------+ | / 615 | ISP 2 | | Customer / 616 +------------+ | Internet connection / 617 | | 618 | +------+--------+ \ 619 | | IPv6 | \ 620 | | Customer Edge | \ 621 | | Router | / 622 | +---+-------+---+ / 623 | Network A | | Network B | End-User 624 | -------+----+- --+--+-------------+--- | network(s) 625 | | | | \ 626 | +-----+----+ +----+-----+ +-----+----+ \ 627 +-----|Secondary | | Host 1| |Internal | / 628 | CER | | | | Router | / 629 +-----+----+ +----------+ +----------+ / 630 Network C | Network D | | 631 ---+-------------+----+- --+--+-------------+--- | 632 | | | | \ 633 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 634 | Host 2| | Host 3 | | Host 4| | Host 5 | / 635 | | | | | | | | / 636 +----------+ +-----+----+ +----------+ +----------+ / 638 Figure 2: An Example of a multihomed End-User Network 640 As described above, the primary CER performs prefix sub-delegation to 641 create the hierarchical tree network. The secondary edge router then 642 obtains a second prefix from ISP2 and advertises the ISP2 prefix as 643 part of its RA. The Secondary CER thus includes sub-prefixes from 644 both ISPs in all IA_PD messages to downstream routers with the same 645 "router id.". In a change from the single-homing (or backup router) 646 case, the secondary CER points its default route to ISP2, and adds an 647 internal /48 route to its upstream internal router (e.g. R1). 648 Devices below the the secondary CER (e.g. Host 2, Host 3) use ISP2, 649 but have full access to all internal devices using the ISP1 prefix 650 (and/or ULAs). If the ISP2 link fails, the secondary CER points its 651 default route 'up' and traffic flows to ISP1. Devices not below the 652 secondary CER (e.g. Hosts 1, 4, 5) use ISP1, but have full access to 653 all internal devices using the ISP1 prefix (or ULAs). 655 In case 2, the secondary CER is installed on the same LAN segment as 656 the primary CER. As above, it acquires a prefix from both the CER 657 and secondary ISP. Since it is on the same LAN segment as the CER, 658 the secondary CER does not delegate prefixes to that interface via 659 DHCP. However, it does generate an RA for the ISP2 prefix on the 660 LAN. 662 As described above, downstream routers receiving the secondary CER RA 663 acquire an address using SLAAC and generate a prefix for sub- 664 delegation by prepending the secondary CER prefix with the router ID 665 generated during the receipt of the prefix from the CER. Such 666 routers then generate their own RAs on downstream interfaces and 667 include the secondary prefix as an IA_PD option in future prefix 668 delegations. 670 6.2.1. Multihoming Requirements 672 MH-1: HIPnet routers configured for active multi-ISP support MUST 673 support DHCP address/prefix acquisition (per 674 [I-D.ietf-v6ops-6204bis] on two interfaces (their WAN and 675 upstream LAN interfaces). 677 MH-2: HIPnet routers configured for active multi-ISP support MAY 678 route packets based on the source IP address of incoming 679 packets using [RFC6724] logic. This allows traffic sourced 680 from the first ISP prefix to be directed to the first ISP, and 681 traffic sourced from the second ISP prefix to be directed to 682 the second ISP. 684 MH-3: HIPnet routers configured for active multi-ISP support MUST 685 advertise RAs for prefixes on all interfaces except the one 686 from which the prefix was acquired or one directly attached to 687 a Service Provider network. 689 7. Mulicast Support 691 7.1. Service Discovery 693 There are several common service discovery protocols such as mDNS 694 [I-D.cheshire-dnsext-multicastdns]/DNS-SD 695 [I-D.cheshire-dnsext-dns-sd] and SSDP [SSDP]. In a multirouter 696 network, service discovery needs to work across the entire home 697 network (e.g. site-scoped rather than link-scoped). This requires 698 that HIPnet routers forward relevant multicast traffic appropriately, 699 to enable service discovery across the home network. 701 7.2. Multicast Proxy Support 703 In addition to multicast support for service discovery, it is 704 recommended that HIPnet routers support external multicast traffic. 706 7.3. Multicast Requirements 708 MULTI-1: A HIPnet router MUST discard IP multicast packets that fail 709 a Reverse Path Forwarding Check (RPFC). 711 MULTI-2: A HIPnet router that determines itself to be at the edge of 712 a home network (e.g. via CER_ID option, /48 verification, 713 or other mechanism) MUST NOT forward IPv4 administratively 714 scoped (239.0.0.0/8) packets onto the WAN interface. 716 MULTI-3: HIPnet Routers MUST forward IPv4 Local Scope multicast 717 packets (239.255.0.0/16) to all LAN interfaces except the 718 one from which they were received. 720 MULTI-4: A HIPnet router that determines itself to be at the edge of 721 a home network (e.g. via CER_ID option, /48 verification, 722 or other mechanism) MUST NOT forward site-scope (FF05::) 723 IPv6 multicast packets onto the WAN interface. 725 MULTI-5: HIPnet routers MUST forward site-scoped (FF05::/16) IPv6 726 multicast packets to all LAN interfaces except the one from 727 which they were received. 729 MULTI-6: A home router MAY discard IP multicast packets sent between 730 Down Interfaces (different VLANs). 732 MULTI-7: HIPnet routers SHOULD support an IGMP/MLD proxy, as 733 described in [RFC4605]. 735 8. Firewall Support 737 In a home network, routers need to be equipped with stateful firewall 738 capabilities. Home routers will need to provide "on by default" 739 security where incoming traffic is limited to return traffic 740 resulting from outgoing packets. They also need to allow users to 741 create inbound 'pinholes' for specific purposes, such as online 742 gaming, manually similar to those described in Simple Security 743 ([RFC6092]). "Advanced Security" [I-D.vyncke-advanced-ipv6-security] 744 features optionally could be added to provide intrusion detection 745 (IDS/IPS) support. 747 Local Network Protection for IPv6 [RFC4864] recommends firewall 748 functions that replace NAT security and calls for simple security. 749 Simple Security [RFC6092] defines firewall filtering rules for IPv6 750 traffic. Advanced Security [I-D.vyncke-advanced-ipv6-security] 751 supports the concept of end-to-end IPv6 reachability and uses 752 adaptive filtering based on Intrusion Prevention System (IPS) 753 functions. 755 It is recommended that the CER enable a stateful [RFC6092] firewall 756 by default. IRs have three options described below: 758 IR Firewall Option 1 - Filtering Disabled: Once a home router 759 determines that it is not the CER, it disables its firewall and 760 allows all traffic to pass. The advantages of this approach are that 761 is is simple and easy to troubleshoot and it facilitates whole-home 762 service discovery and media sharing. The disadvantages are that it 763 does not protect home devices from each other (e.g. infected machines 764 could affect entire home network). 766 IR Firewall Option 2 - Simple Security + PCP: Home routers have a 767 [RFC6092] firewall on by default, regardless of CER/IR status but IRs 768 allow "pin-holing" using PCP [I-D.ietf-pcp-base]. CERs can restrict 769 opening PCP pinholes on the up interface. The advantages of this 770 approach are that it protects the home network from internal threats 771 in other LAN segments and it mirrors legacy IPv4 router behavior. 772 The disadvantages to this approach are that it is less predictable; 773 it relies on application "pin-holing", a "default deny" rule that may 774 interfere with service discovery and/or content sharing, and requires 775 PCP clients (e.g. on PCs and CPE devices). 777 IR Firewall Option 3 - Advanced Security: Once a home router 778 determines that it is not the CER, it disables its [RFC6092] firewall 779 but activates an [I-D.vyncke-advanced-ipv6-security] firewall (IPS). 780 The advantages to this approach are that it protects the home network 781 from internal threats in other segments and is more predictable than 782 Option 2, since internal traffic is allowed by default. The 783 disadvantages are that adaptive filtering is more complex than static 784 filtering and typically requires a "fingerprint" subscription to work 785 well. 787 It is recommended that dual-stack routers configure IPv4 support to 788 mirror IPv6, as described above. 790 While this section describes default router behavior, device 791 manufacturers are encouraged to make router security options user- 792 configurable. 794 8.1. Requirements 796 SEC-1: The CER MUST enable a stateful [RFC6092] firewall by default. 798 SEC-2: HIPnet routers MUST only perform IPv4 NAT when serving as the 799 CER. 801 SEC-3: By default, HIPnet routers SHOULD configure IPv4 firewalling 802 rules to mirror IPv6. 804 SEC-4: HIPnet routers serving as CER SHOULD NOT enable UPnP IGD 805 ([UPnP-IGD]) control by default. 807 9. IANA Considerations 809 This document makes no request of IANA. 811 Note to RFC Editor: this section may be removed on publication as an 812 RFC. 814 10. Security Considerations 816 Security considerations are discussed in the Firewall Support section 817 above. 819 11. Acknowledgements 821 TBD 823 12. References 824 12.1. Normative References 826 [I-D.ietf-v6ops-6204bis] 827 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 828 Requirements for IPv6 Customer Edge Routers", 829 draft-ietf-v6ops-6204bis-12 (work in progress), 830 October 2012. 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, March 1997. 835 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 836 and M. Carney, "Dynamic Host Configuration Protocol for 837 IPv6 (DHCPv6)", RFC 3315, July 2003. 839 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 840 Host Configuration Protocol (DHCP) version 6", RFC 3633, 841 December 2003. 843 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 844 "Internet Group Management Protocol (IGMP) / Multicast 845 Listener Discovery (MLD)-Based Multicast Forwarding 846 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 848 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 849 E. Klein, "Local Network Protection for IPv6", RFC 4864, 850 May 2007. 852 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 853 Customer Premises Equipment (CPE) for Providing 854 Residential IPv6 Internet Service", RFC 6092, 855 January 2011. 857 12.2. Informative References 859 [I-D.chakrabarti-homenet-prefix-alloc] 860 Nordmark, E., Chakrabarti, S., Krishnan, S., and W. 861 Haddad, "Simple Approach to Prefix Distribution in Basic 862 Home Networks", draft-chakrabarti-homenet-prefix-alloc-01 863 (work in progress), October 2011. 865 [I-D.cheshire-dnsext-dns-sd] 866 Cheshire, S. and M. Krochmal, "DNS-Based Service 867 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 868 progress), December 2011. 870 [I-D.cheshire-dnsext-multicastdns] 871 Cheshire, S. and M. Krochmal, "Multicast DNS", 872 draft-cheshire-dnsext-multicastdns-15 (work in progress), 873 December 2011. 875 [I-D.donley-dhc-cer-id-option] 876 Donley, C. and C. Grundemann, "Customer Edge Router 877 Identification Option", draft-donley-dhc-cer-id-option-01 878 (work in progress), September 2012. 880 [I-D.ietf-homenet-arch] 881 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 882 "Home Networking Architecture for IPv6", 883 draft-ietf-homenet-arch-07 (work in progress), 884 February 2013. 886 [I-D.ietf-pcp-base] 887 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 888 Selkirk, "Port Control Protocol (PCP)", 889 draft-ietf-pcp-base-29 (work in progress), November 2012. 891 [I-D.vyncke-advanced-ipv6-security] 892 Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced 893 Security for IPv6 CPE", 894 draft-vyncke-advanced-ipv6-security-03 (work in progress), 895 October 2011. 897 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 898 E. Lear, "Address Allocation for Private Internets", 899 BCP 5, RFC 1918, February 1996. 901 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 902 RFC 2131, March 1997. 904 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 905 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 906 September 2007. 908 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 909 "Default Address Selection for Internet Protocol Version 6 910 (IPv6)", RFC 6724, September 2012. 912 [SSDP] UPnP Forum, "Universal Plug and Play (UPnP) Device 913 Architecture 1.1", October 2008, . 915 [UPnP-IGD] 916 UPnP Forum, "Universal Plug and Play (UPnP) Internet 917 Gateway Device (IGD)", November 2001, 918 . 920 Authors' Addresses 922 Chris Grundemann 923 CableLabs 924 858 Coal Creek Circle 925 Louisville, CO 80027 926 USA 928 Phone: +1-303-351-1539 929 Email: c.grundemann@cablelabs.com 931 Chris Donley 932 CableLabs 933 858 Coal Creek Circle 934 Louisville, CO 80027 935 USA 937 Email: c.donley@cablelabs.com 939 John Jason Brzozowski 940 Comcast Cable Communications 941 1306 Goshen Parkway 942 Chester, PA 19380 943 USA 945 Email: john_brzozowski@cable.comcast.com 947 Lee Howard 948 Time Warner Cable 949 13241 Woodland Park Rd 950 Herndon, VA 20171 951 USA 953 Email: william.howard@twcable.com 955 Victor Kuarsingh 956 Rogers Communications 957 8200 Dixie Road 958 Brampton, ON L6T 0C1 959 Canada 961 Email: victor.kuarsingh@rci.rogers.com