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