idnits 2.17.1 draft-grundemann-homenet-hipnet-00.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 15, 2013) is 4089 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'UPNnP-IGD' is mentioned on line 192, but not defined == Unused Reference: 'I-D.cheshire-dnsext-multicastdns' is defined on line 860, 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-06 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 9, 2013 J. Brzozowski 6 Comcast Cable Communications 7 L. Howard 8 Time Warner Cable 9 V. Kuarsingh 10 Rogers Communications 11 February 15, 2013 13 A Near Term Solution for Home IP Networking (HIPnet) 14 draft-grundemann-homenet-hipnet-00 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 9, 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 . . . . . . . . . . . . . . . . . . . . . . 7 74 4.1. Edge Detection . . . . . . . . . . . . . . . . . . . . . . 7 75 4.2. Directionless Home Routers . . . . . . . . . . . . . . . . 8 76 5. Routing and Addressing . . . . . . . . . . . . . . . . . . . . 10 77 5.1. Recursive Prefix Delegation . . . . . . . . . . . . . . . 10 78 5.2. Prefix Sub-Delegation Requirements . . . . . . . . . . . . 11 79 5.3. Multiple Address Family Support . . . . . . . . . . . . . 12 80 5.4. Hierarchical Routing . . . . . . . . . . . . . . . . . . . 13 81 6. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . . . 13 82 6.1. Backup Connection . . . . . . . . . . . . . . . . . . . . 13 83 6.2. Multi-homing . . . . . . . . . . . . . . . . . . . . . . . 14 84 6.2.1. Multihoming Requirements . . . . . . . . . . . . . . . 16 85 7. Mulicast Support . . . . . . . . . . . . . . . . . . . . . . . 16 86 7.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 16 87 7.2. Multicast Proxy Support . . . . . . . . . . . . . . . . . 16 88 7.3. Multicast Requirements . . . . . . . . . . . . . . . . . . 17 89 8. Firewall Support . . . . . . . . . . . . . . . . . . . . . . . 17 90 8.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 96 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 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 subtended 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 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 a HIPnet router that connects the end-user 134 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 Service Provider an entity that provides access to the 156 Internet. In this document, a service 157 provider specifically offers Internet 158 access using IPv6, and may also offer IPv4 159 Internet access. The service provider can 160 provide such access over a variety of 161 different transport methods such as DSL, 162 cable, wireless, and others. 164 Up Interface a HIPnet router's attachment to a link 165 where it receives one or more IP addresses 166 and/or prefixes. This is also the link to 167 which the HIPnet router points its default 168 route. 170 depth the number of layers of routers in a 171 network. A single router network would 172 have a depth of 1, while a router behind a 173 router behind a router would have a depth 174 of 3. 176 width The number of routers that can be directly 177 subtended to an upstream router. A network 178 with three directly attached routers behind 179 the CER would have a width of 3. 181 3. Architecture 183 3.1. Current End-User Network Architecture 185 An end-user network will likely support both IPv4 and IPv6. A 186 typical end-user network consists of a "plug and play" router with 187 IPv4 NAT functionality and a single link behind it, connected to the 188 service provider network. 190 A typical IPv4 NAT deployment by default blocks all incoming 191 connections. Opening of ports is typically allowed using a Universal 192 Plug and Play Internet Gateway Device (UPnP IGD) [UPNnP-IGD] or some 193 other firewall control protocol. 195 Rewriting addresses on the edge of the network allows for some 196 rudimentary multihoming, even though using NATs for multihoming does 197 not preserve connections during a fail-over event [RFC4864]. 199 Many existing routers support dynamic routing, and advanced end-users 200 can build arbitrary, complex networks using manual configuration of 201 address prefixes combined with a dynamic routing protocol. 203 3.2. HIPNet End-User Network Architecture 205 The end-user network architecture should provide equivalent or better 206 capabilities and functionality than the current architecture. 207 However, as end-user networks become more complex, the HIPnet 208 architecture needs to support more complicated networks. Figure 1 209 illustrates the model topology for the end-user network. 211 +-------+-------+ \ 212 | Service | \ 213 | Provider | | Service 214 | Router | | Provider 215 +-------+-------+ | network 216 | / 217 | Customer / 218 | Internet connection / 219 | 220 +------+--------+ \ 221 | IPv6 | \ 222 | Customer Edge | \ 223 | Router | / 224 +---+-------+-+-+ / 225 Network A | | Network B | End-User 226 ---+-------------+----+- --+--+-------------+--- | network(s) 227 | | | | \ 228 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 229 | Host | |Internal | | Host| |Internal | / 230 | | | Router | | | | Router | / 231 +----------+ +-----+----+ +----------+ +----------+ / 232 Network C | Network D | | 233 ---+-------------+----+- --+--+-------------+--- | 234 | | | | \ 235 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 236 | Host | | Host | | Host| | Host | / 237 | | | | | | | | / 238 +----------+ +-----+----+ +----------+ +----------+ / 240 Figure 1: An Example of a Typical End-User Network 242 This architecture describes the following: 244 o Prefix subdelegation supporting multiple subnets and routers 246 o Border Detection 248 o Router directionality supporting a hierarchical network 250 o Multicast forwarding rules to support common service discovery 251 protocols 253 While routers described in this document may be manually configured 254 in an arbitrary topology with or without a dynamic routing protocol, 255 this document only addresses automatic provisioning and 256 configuration. 258 4. Network Detection 260 In multirouter home networks, routers have to determine where they 261 fit in the topology - whether they are at the edge or internal, and 262 which interface is up (that is, which interface points out of the 263 network). 265 4.1. Edge Detection 267 Customer Edge Routers (CER) will often be required to behave 268 differently from Internal Routers (IR) in several capacities. Some 269 examples include: Firewall settings, IPv4 NAT, ULA generation (if 270 supported), name services, multicast forwarding differences, and 271 others. This is a functional role, and will not typically be 272 differentiated by hardware/software (i.e. end users will not purchase 273 a specific CER model of router distinct from IR models). 275 There are three methods that a router can use to determine if it is a 276 CER for its given network: 278 "/48 Check" Service providers will provide IPv6 WAN addresses 279 (DHCPv6 IA_NA) and IPv6 prefixes (DHCPv6 IA_PD) from distinct 280 pools of addresses. The largest IPv6 prefix that we can expect to 281 be delegated to a home router is a /48. Combining these two 282 observations, a home router can compare the WAN address assigned 283 to it with the prefix delegated to it to determine if it is 284 attached directly to a service provider network. If the router is 285 a CER, the WAN address will be from a distinct /48 than the 286 prefix. If the router is an IR, the WAN address will be from the 287 same /48 as the prefix. In this way, the router can determine if 288 it is recieving an "external" prefix from a service provider or an 289 "internal" prefix from another home router. 291 CER_ID A home router can use the CER_ID DHCPv6 option defined in 292 [I-D.donley-dhc-cer-id-option] to determine if it is a CER or an 293 IR. ISPs will not set the CER_ID option, but the first CPE router 294 sets its address in the option and other routers forward the 295 completed CER_ID to subdelegated routers. 297 Physical Some routers will have a physical differentiator built into 298 them by design that will indicate that they are a CER. Examples 299 include mobile routers, DSL routers, and cable eRouters. In the 300 case of a mobile router, the presence of an active cellular 301 connection indicates that the router is at the customer edge. 302 Likewise, for an eRouter, the presence of an active DOCSIS(R) link 303 tells the router that it is at the customer edge. 305 HIPnet routers can (and likely will) use more than one of the above 306 techniques in combination to determine the edge. For example, an 307 internal router will check for the CER_ID option, but will also use 308 the 48 check in case its upstream router does not support CER_ID. 310 4.2. Directionless Home Routers 312 As home networks grow in complexity and scale, it will become more 313 common for end users to make mistakes with the physical connections 314 between multiple routers in their home or small office. This is 315 liklely to produce loops and improper uplink connections. While we 316 can safely assume that home networks will become more complex over 317 time, we cannot make the same assumption of the users of home 318 networks. Therefor, home routers will need to mitigate these 319 physical topology problems and create a working multi-router home 320 network dynamically, without any end user intervention. 322 Legacy home routers with a physically differentiated uplink port are 323 "directional;" they are pre-set to route from the 'LAN' or Internal 324 ports to a single, pre-defined uplink port labeled "WAN" or 325 "Internet". This means that an end-user can make a cabling mistake 326 which renders the router unusable (e.g. connecting two router's 327 uplink ports together). On the other hand, in enterprise and service 328 provider networks, routers are "directionless;" that is to say they 329 do not have a pre-defined 'uplink' port. While directional routers 330 have a pre-set routing path, directionless routers are required to 331 determine routing paths dynamically. Dynamic routing is often 332 achieved through the implementation of a dynamic routing protocol, 333 which all routers in a given network or network segment must support 334 equally. This section introduces an alternative to dynamic routing 335 protocols for creating routing paths on the fly in directionless home 336 routers. 338 Note that some routers (e.g. those with a dedicated wireless/DSL/ 339 DOCSIS WAN interface) may continue to operate as directional routers. 340 The HIPnet mechanism described below is intended for general-purpose 341 routers. 343 The HIPnet mechanism uses address acquisition as described in 344 [I-D.ietf-v6ops-6204bis] and various tiebreakers to determine 345 directionality (up vs. down) and by so doing, creates a logical 346 hierarchy (cf. [I-D.chakrabarti-homenet-prefix-alloc]) from any 347 arbitrary physical topology: 349 1. After powering on, the HIPnet router sends Router Solicitations 350 (RS) ([RFC4861]on all interfaces (except wifi*) 352 2. Other routers respond with Router Advertisements (RA) 354 3. Router adds any interface on which it receives an RA to the 355 candidate 'up' list 357 4. The router initiates DHCPv6 PD on all candidate 'up' interfaces. 358 If no RAs are received, the router generates a /48 ULA prefix. 360 5. The router evaluates the offers received (in order of preference): 362 a) Valid GUA preferred (preferred/valid lifetimes >0) 364 b) Internal prefix preferred over external (for failover - see 365 Section [[anchor10: 4.3.1]]) 367 c) Largest prefix (e.g. /56 preferred to /60) 369 d) Link type/bandwidth (e.g. Ethernet vs. MoCA) 371 e) First response (wait 1 s after first response for additional 372 offers) 374 f) Lowest numerical prefix 376 6. The router chooses the winning offer as its 'up' interface. 378 Once directionality is established, the router continues to listen 379 for RAs on all interfaces but doesn't acquire addresses on 'down' 380 interfaces. If the router initially receives only a ULA address on 381 its 'up' interface and GUA addressing becomes available on one of its 382 'down' interfaces, it restarts the process. If the router stops 383 receiving RAs on its 'up' interface, it restarts the process. 385 In all cases, the router's 'up' interface becomes its uplink 386 interface; the router acts as a DHCP client on this interface. The 387 router's remaining interfaces are 'down' interfaces; it acts as a 388 DHCP server on these interfaces. Also, per [I-D.ietf-v6ops-6204bis], 389 the router only sends RAs on 'down' interfaces. 391 *Note: By default, wifi interfaces are considered to point "down." 392 This requires manual configuration to enable a wireless uplink, which 393 is preferred to avoid accidental or unwanted linking with nearby 394 wireless networks. 396 5. Routing and Addressing 398 HIPnet routers use DHCPv6 prefix sub-delegation ([RFC3633]) to 399 recursively build a hierarchical network 400 ([I-D.chakrabarti-homenet-prefix-alloc]). This approach requires no 401 new protocols to be supported on any home routers. 403 Default router settings: Only CER instantiates guest network. Wifi 404 defaults to 'down' direction, default route uses wired interface. 405 Firewall considers Wifi an inside port. Wifi bridged with first 406 downstream LAN. 408 5.1. Recursive Prefix Delegation 410 Once directionality is established, the home router will acquire a 411 WAN IPv6 address and an IPv6 prefix per [I-D.ietf-v6ops-6204bis]. As 412 HIPnet routers (other than the CER) do not know their specific 413 location in the hierarchical network, all HIPnet routers use the same 414 generic rules for recursive prefix delegation to facilitate route 415 aggregation, multihoming, and IPv4 support (described below). This 416 methodology expounds upon that previously described in 417 [I-D.chakrabarti-homenet-prefix-alloc]. 419 The process can be illustrated in the following way: 421 1. Per [I-D.ietf-v6ops-6204bis], the HIPnet router assigns a 422 separate /64 from its delegated prefix(es) for each of its LAN 423 interfaces in numerical order, starting from the numerically 424 lowest. 426 2. If the received prefix is too small to number all 'down' 427 interfaces, the router collapses them into a single interface, 428 assigns a single /64 to that interface, and logs an error 429 message. 431 3. The HIPnet router subdivides the IPv6 prefix received via DHCPv6 432 ([RFC3315]) into sub-prefixes. To support a suggested depth of 433 three routers, with as large a width as possible, it is 434 recommended to divide the prefix on 2-, 3-, or 4-bit boundaries. 435 If the received prefix is not large enough, it is broken into as 436 many /64 sub-prefixes as possible and logs an error message. By 437 default, this document suggests that the router divide the 438 delegated prefix based on the aggregate prefix size and the 439 HIPnet router's number of physical 'down' interfaces. This is to 440 allow for enough prefixes to support a subtended router on each 441 down port. 443 * If the received prefix is smaller than a /56 (e.g. a /60), 445 + 8 or more port routers divide on 3-bit boundaries (e.g. 446 /63). 448 + 7 or fewer port routers divide on 2-bit boundaries (e.g. 449 /62). 451 * If the received prefix is a /56 or larger, 453 + 8 or more port routers divide on 4-bit boundaries (e.g. 454 /60). 456 + 7 or fewer port routers divide on 3-bit boundaries (e.g. 457 /59). 459 4. The HIPnet router delegates remaining prefixes to subtended 460 routers per [RFC3633]in reverse numerical order, starting with 461 the numerically highest. This is to minimize the renumbering 462 impact of enabling an inactive interface. 464 For example, a four port router with two LANs that receives 2001:db8: 465 0:b0::/60 would start by numbering its two 'down' IP interfaces with 466 2001:db8:0:b0::/64 and 2001:db8:0:b1::/64 respectively, and then 467 begin prefix delegation by giving 2001:db8:0:bc::/62 to the first 468 directly attached downstream router. 470 5.2. Prefix Sub-Delegation Requirements 472 PSD-1: The HIPnet router MUST support [I-D.ietf-v6ops-6204bis] 473 address acquisition and LAN addressing. 475 PSD-2: The HIPnet router MUST support Delegating Router behavior 476 for the IA-PD Option [RFC3633] on all 'down' interfaces. 478 PSD-3: HIPnet routers MUST NOT act as both a DHCP client and server 479 on the same link. 481 PSD-4: The HIPnet router MAY support other methods of dividing the 482 received prefix. 484 PSD-5: The HIPnet router MUST delegate prefixes of the same size to 485 subtended routers. 487 PSD-6: Per [I-D.ietf-v6ops-6204bis] L-2, the HIPnet router 488 allocates a /64 to each 'down' interface. The HIPnet router 489 SHOULD allocate these /64 interface-prefixes in numerical 490 order, starting with the lowest. 492 PSD-7: If there are insufficient /64s for each 'down' interface, 493 the HIPnet router SHOULD assign a single /64 for all 'down' 494 IP interfaces and log an error message. 496 PSD-8: The HIPnet router MAY reserve additional /64 interface- 497 prefixes for interfaces that will be enabled in the future. 499 PSD-9: The HIPnet router SHOULD delegate sub-prefixes to subtended 500 routers starting from the numerically highest sub-prefix and 501 working down in reverse numerical order. 503 PSD-10: If there are not enough sub-prefixes remaining to delegate 504 to all downstream routers, the HIPnet router SHOULD log an 505 error message. 507 5.3. Multiple Address Family Support 509 The recursive prefix delegation method described above can be 510 extended to support additional address types such as IPv4, additional 511 GUAs, or ULAs. When the HIPnet router receives its prefix via DHCPv6 512 ([RFC3633]), it computes its 8-bit router ID (bits 56-64) from the 513 received IA_PD. It then prepends additional prefixes received in one 514 or more IPv6 Router Advertisements ([RFC4861]) or from the DHCPv4- 515 assigned ([RFC2131]) IPv4 network address received on the 'up' 516 interface. 518 As the network is hierarchical, upstream routers know the router ID 519 for each downstream router, and know the prefix(es) on each LAN 520 segment. Accordingly, HIPnet routers automatically calculate 521 downstream routes to all subtended routers. 523 In networks using this mechanism for IPv4 provisioning, it is 524 suggested that the CER use addresses in the 10.0.0.0/8 ([RFC1918]) 525 range for downstream interface provisioning. 527 5.4. Hierarchical Routing 529 The recursive prefix delegation method described above, coupled with 530 "up detection", enables very simple hierarchical routing. By this we 531 mean that each router installs a single default 'up' route and a more 532 specific 'down' route for each prefix delegated to a downstream IR. 533 Each of these 'down' routes simply points all packets destined to a 534 given prefix to the WAN IP address of the router to which that prefix 535 was delegated. This combination of a default 'up' route and more 536 specific 'down' routes provides complete reachability within the home 537 network with no need for any additional message exchange or routing 538 protocol support. 540 6. Multiple ISPs 542 HIPnet routers can support either active/standby multihoming with 543 multiple ISPs or limited active/active multihoming without a routing 544 protocol. 546 6.1. Backup Connection 548 Using the procedure described above, multi-router home networks with 549 multiple ISP connections can easily operate in an active/standby 550 manner, switching from one Internet connection to the other when the 551 active connection fails. 553 In an active/standby multi-ISP scenario, a backup CER sets its 'up' 554 interface to point to the primary CER, not the backup ISP. Hence, it 555 does not acquire or advertise the Backup ISP prefix. Instead, it 556 discovers the internally advertised GUA prefix being distributed by 557 the currently active primary CER. 559 In the case of a primary ISP failure, per [I-D.ietf-v6ops-6204bis], 560 the CER sends an RA advertising the preferred lifetime as 0 for the 561 ISP-provided prefix, and its router lifetime as 0. The Backup CER 562 becomes active when it sees the primary ISP GUA prefix advertised 563 with a preferred lifetime of 0. In the case of CER failure, if the 564 Backup CER sees the Primary CER stop sending RAs altogether, the 565 Backup CER becomes active. 567 When the Backup CER becomes active, it obtains and advertises its own 568 external GUA. When advertising the GUA delegated by its ISP, the 569 Backup CER sets the valid, prefered, and router lifetimes to a value 570 greater than 0. Other routers see this and re-determine the network 571 topology via "up" detection, placing the new CER at the root of the 572 new hiearchical tree. 574 Using this approach, manual intervention may be required to 575 transition back to the primary ISP. This prevents flapping in the 576 event of intermittent network failures. 578 6.2. Multi-homing 580 The HIPnet algorithm also allows for limited active/active 581 multihoming in two cases: 583 1. When one ISP router is used as the primary connection and the 584 second ISP router is used for limited connectivity e.g. for a 585 home office 587 2. When both ISP routers are connected to the same LAN segment at 588 the top of the tree. 590 In case 1, the subscriber has a primary ISP connection and a 591 secondary connection used for a limited special purpose. (e.g. for 592 work VPN, video network, etc.). Devices connected under the 593 secondary network router access the Internet through the secondary 594 ISP. All devices still have access to all network resources in the 595 home. Devices under the secondary connection can use the primary ISP 596 if the secondary fails, but other devices do not use the secondary 597 ISP. 599 +-------+-------+ \ 600 | Service | \ 601 | Provider | | Service 602 | Router | | Provider 603 +-------+-------+ | network 604 +------------+ | / 605 | ISP 2 | | Customer / 606 +------------+ | Internet connection / 607 | | 608 | +------+--------+ \ 609 | | IPv6 | \ 610 | | Customer Edge | \ 611 | | Router | / 612 | +---+-------+---+ / 613 | Network A | | Network B | End-User 614 | -------+----+- --+--+-------------+--- | network(s) 615 | | | | \ 616 | +-----+----+ +----+-----+ +-----+----+ \ 617 +-----|Secondary | | Host 1| |Internal | / 618 | CER | | | | Router | / 619 +-----+----+ +----------+ +----------+ / 620 Network C | Network D | | 621 ---+-------------+----+- --+--+-------------+--- | 622 | | | | \ 623 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 624 | Host 2| | Host 3 | | Host 4| | Host 5 | / 625 | | | | | | | | / 626 +----------+ +-----+----+ +----------+ +----------+ / 628 Figure 2: An Example of a multihomed End-User Network 630 As described above, the primary CER performs prefix sub-delegation to 631 create the hierarchical tree network. The secondary edge router then 632 obtains a second prefix from ISP2 and advertises the ISP2 prefix as 633 part of its RA. The Secondary CER thus includes sub-prefixes from 634 both ISPs in all IA_PD messages to downstream routers with the same 635 "router id.". In a change from the single-homing (or backup router) 636 case, the secondary CER points its default route to ISP2, and adds an 637 internal /48 route to its upstream internal router (e.g. R1). 638 Devices below the the secondary CER (e.g. Host 2, Host 3) use ISP2, 639 but have full access to all internal devices using the ISP1 prefix 640 (and/or ULAs). If the ISP2 link fails, the secondary CER points its 641 default route 'up' and traffic flows to ISP1. Devices not below the 642 secondary CER (e.g. Hosts 1, 4, 5) use ISP1, but have full access to 643 all internal devices using the ISP1 prefix (or ULAs). 645 In case 2, the secondary CER is installed on the same LAN segment as 646 the primary CER. As above, it acquires a prefix from both the CER 647 and secondary ISP. Since it is on the same LAN segment as the CER, 648 the secondary CER does not delegate prefixes to that interface via 649 DHCP. However, it does generate an RA for the ISP2 prefix on the 650 LAN. 652 As described above, downstream routers receiving the secondary CER RA 653 acquire an address using SLAAC and generate a prefix for sub- 654 delegation by prepending the secondary CER prefix with the router ID 655 generated during the receipt of the prefix from the CER. Such 656 routers then generate their own RAs on downstream interfaces and 657 include the secondary prefix as an IA_PD option in future prefix 658 delegations. 660 6.2.1. Multihoming Requirements 662 MH-1: HIPnet routers configured for active multi-ISP support MUST 663 support DHCP address/prefix acquisition (per 664 [I-D.ietf-v6ops-6204bis] on two interfaces (their WAN and 665 upstream LAN interfaces). 667 MH-2: HIPnet routers configured for active multi-ISP support MAY 668 route packets based on the source IP address of incoming 669 packets using [RFC6724] logic. This allows traffic sourced 670 from the first ISP prefix to be directed to the first ISP, and 671 traffic sourced from the second ISP prefix to be directed to 672 the second ISP. 674 MH-3: HIPnet routers configured for active multi-ISP support MUST 675 advertise RAs for prefixes on all interfaces except the one 676 from which the prefix was acquired or one directly attached to 677 a Service Provider network. 679 7. Mulicast Support 681 7.1. Service Discovery 683 There are several common service discovery protocols such as mDNS 684 [I-D.cheshire-dnsext-multicastdns]/DNS-SD 685 [I-D.cheshire-dnsext-dns-sd] and SSDP [SSDP]. In a multirouter 686 network, service discovery needs to work across the entire home 687 network (e.g. site-scoped rather than link-scoped). 689 7.2. Multicast Proxy Support 691 In addition to multicast support for service discovery, it is 692 recommended that HIPnet routers support external multicast traffic. 694 7.3. Multicast Requirements 696 MULTI-1: A HIPnet router MUST discard IP multicast packets that fail 697 a Reverse Path Forwarding Check (RPFC). 699 MULTI-2: A home router MAY discard IP multicast packets sent between 700 'guest' and 'internal' networks. 702 MULTI-3: A HIPnet router that determines itself to be at the edge of 703 a home network (e.g. via CER_ID option, /48 verification, 704 or other mechanism) MUST NOT forward IPv4 administratively 705 scoped (239.0.0.0/8) packets onto the WAN interface. 707 MULTI-4: HIPnet Routers MUST forward IPv4 Local Scope multicast 708 packets (239.255.0.0/16) to all LAN interfaces except the 709 one from which they were received. 711 MULTI-5: 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 link-scope (FF02::) or 714 site-scope (FF05::) IPv6 multicast packets onto the WAN 715 interface. 717 MULTI-6: HIPnet routers MUST forward site-scoped (FF05::/16) IPv6 718 multicast packets to all LAN interfaces except the one from 719 which they were received. 721 MULTI-7: HIPnet routers SHOULD support an IGNMP/MLD proxy, as 722 described in [RFC4605]. 724 8. Firewall Support 726 In a home network, routers need to be equipped with stateful firewall 727 capabilities. Home routers will need to provide "on by default" 728 security where incoming traffic is limited to return traffic 729 resulting from outgoing packets. They also need to allow users to 730 create inbound 'pinholes' for specific purposes, such as online 731 gaming, manually similar to those described in Simple Security 732 ([RFC6092]). "Advanced Security" [I-D.vyncke-advanced-ipv6-security] 733 features optionally could be added to provide intrusion detection 734 (IDS/IPS) support. 736 Local Network Protection for IPv6 [RFC4864] recommends firewall 737 functions that replace NAT security and calls for simple security. 738 Simple Security [RFC6092] defines firewall filtering rules for IPv6 739 traffic. Advanced Security [I-D.vyncke-advanced-ipv6-security] 740 supports the concept of end-to-end IPv6 reachability and uses 741 adaptive filtering based on Intrusion Prevention System (IPS) 742 functions. 744 It is recommended that the CER enable a stateful [RFC6092] firewall 745 by default. IRs have three options described below: 747 IR Firewall Option 1 - Filtering Disabled: Once a home router 748 determines that it is not the CER, it disables its firewall and 749 allows all traffic to pass. The advantages of this approach are that 750 is is simple and easy to troubleshoot and it facilitates whole-home 751 service discovery and media sharing. The disadvantages are that it 752 does not protect home devices from each other (e.g. infected machines 753 could affect entire home network). 755 IR Firewall Option 2 - Simple Security + PCP: Home routers have a 756 [RFC6092] firewall on by default, regardless of CER/IR status but IRs 757 allow "pin-holing" using PCP [I-D.ietf-pcp-base]. CERs can restrict 758 opening PCP pinholes on the up interface. The advantages of this 759 approach are that it protects the home network from internal threats 760 in other LAN segments and it mirrors legacy IPv4 router behavior. 761 The disadvantages to this approach are that it is less predictable; 762 it relies on application "pin-holing", a "default deny" rule that may 763 interfere with service discovery and/or content sharing, and requires 764 PCP clients (e.g. on PCs and CPE devices). 766 IR Firewall Option 3 - Advanced Security: Once a home router 767 determines that it is not the CER, it disables its [RFC6092] firewall 768 but activates an [I-D.vyncke-advanced-ipv6-security] firewall (IPS). 769 The advantages to this approach are that it protects the home network 770 from internal threats in other segments and is more predictable than 771 Option 2, since internal traffic is allowed by default. The 772 disadvantages are that adaptive filtering is more complex than static 773 filtering and typically requires a "fingerprint" subscription to work 774 well. 776 It is recommended that dual-stack routers configure IPv4 support to 777 mirror IPv6, as described above. 779 While this section describes default router behavior, device 780 manufacturers are encouraged to make router security options user- 781 configurable. 783 8.1. Requirements 784 SEC-1: The CER SHOULD enable a stateful [RFC6092] firewall by 785 default. 787 SEC-2: HIPnet routers SHOULD only perform IPv4 NAT when serving as 788 the CER. 790 SEC-3: By default, HIPnet routers SHOULD configure IPv4 firewalling 791 rules to mirror IPv6. 793 SEC-4: HIPnet routers serving as CER SHOULD NOT enable UPnP IGD 794 ([UPnP-IGD]) control by default. 796 9. IANA Considerations 798 This document makes no request of IANA. 800 Note to RFC Editor: this section may be removed on publication as an 801 RFC. 803 10. Security Considerations 805 Security considerations are discussed in the Firewall Support section 806 above. 808 11. Acknowledgements 810 TBD 812 12. References 814 12.1. Normative References 816 [I-D.ietf-v6ops-6204bis] 817 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 818 Requirements for IPv6 Customer Edge Routers", 819 draft-ietf-v6ops-6204bis-12 (work in progress), 820 October 2012. 822 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 823 Requirement Levels", BCP 14, RFC 2119, March 1997. 825 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 826 and M. Carney, "Dynamic Host Configuration Protocol for 827 IPv6 (DHCPv6)", RFC 3315, July 2003. 829 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 830 Host Configuration Protocol (DHCP) version 6", RFC 3633, 831 December 2003. 833 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 834 "Internet Group Management Protocol (IGMP) / Multicast 835 Listener Discovery (MLD)-Based Multicast Forwarding 836 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 838 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 839 E. Klein, "Local Network Protection for IPv6", RFC 4864, 840 May 2007. 842 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 843 Customer Premises Equipment (CPE) for Providing 844 Residential IPv6 Internet Service", RFC 6092, 845 January 2011. 847 12.2. Informative References 849 [I-D.chakrabarti-homenet-prefix-alloc] 850 Nordmark, E., Chakrabarti, S., Krishnan, S., and W. 851 Haddad, "Simple Approach to Prefix Distribution in Basic 852 Home Networks", draft-chakrabarti-homenet-prefix-alloc-01 853 (work in progress), October 2011. 855 [I-D.cheshire-dnsext-dns-sd] 856 Cheshire, S. and M. Krochmal, "DNS-Based Service 857 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 858 progress), December 2011. 860 [I-D.cheshire-dnsext-multicastdns] 861 Cheshire, S. and M. Krochmal, "Multicast DNS", 862 draft-cheshire-dnsext-multicastdns-15 (work in progress), 863 December 2011. 865 [I-D.donley-dhc-cer-id-option] 866 Donley, C. and C. Grundemann, "Customer Edge Router 867 Identification Option", draft-donley-dhc-cer-id-option-01 868 (work in progress), September 2012. 870 [I-D.ietf-homenet-arch] 871 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 872 "Home Networking Architecture for IPv6", 873 draft-ietf-homenet-arch-06 (work in progress), 874 October 2012. 876 [I-D.ietf-pcp-base] 877 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 878 Selkirk, "Port Control Protocol (PCP)", 879 draft-ietf-pcp-base-29 (work in progress), November 2012. 881 [I-D.vyncke-advanced-ipv6-security] 882 Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced 883 Security for IPv6 CPE", 884 draft-vyncke-advanced-ipv6-security-03 (work in progress), 885 October 2011. 887 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 888 E. Lear, "Address Allocation for Private Internets", 889 BCP 5, RFC 1918, February 1996. 891 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 892 RFC 2131, March 1997. 894 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 895 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 896 September 2007. 898 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 899 "Default Address Selection for Internet Protocol Version 6 900 (IPv6)", RFC 6724, September 2012. 902 [SSDP] UPnP Forum, "Universal Plug and Play (UPnP) Device 903 Architecture 1.1", October 2008, . 905 [UPnP-IGD] 906 UPnP Forum, "Universal Plug and Play (UPnP) Internet 907 Gateway Device (IGD)", November 2001, 908 . 910 Authors' Addresses 912 Chris Grundemann 913 CableLabs 914 858 Coal Creek Circle 915 Louisville, CO 80027 916 USA 918 Phone: +1-303-351-1539 919 Email: c.grundemann@cablelabs.com 920 Chris Donley 921 CableLabs 922 858 Coal Creek Circle 923 Louisville, CO 80027 924 USA 926 Email: c.donley@cablelabs.com 928 John Jason Brzozowski 929 Comcast Cable Communications 930 1306 Goshen Parkway 931 Chester, PA 19380 932 USA 934 Email: john_brzozowski@cable.comcast.com 936 Lee Howard 937 Time Warner Cable 938 13241 Woodland Park Rd 939 Herndon, VA 20171 940 USA 942 Email: william.howard@twcable.com 944 Victor Kuarsingh 945 Rogers Communications 946 8200 Dixie Road 947 Brampton, ON L6T 0C1 948 Canada 950 Email: victor.kuarsingh@rci.rogers.com