idnits 2.17.1 draft-ietf-homenet-arch-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == 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 -- The document date (January 30, 2012) is 4464 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) == Outdated reference: A later version (-01) exists of draft-baker-homenet-prefix-assignment-00 == Outdated reference: A later version (-04) exists of draft-arkko-homenet-prefix-assignment-01 == Outdated reference: A later version (-03) exists of draft-acee-ospf-ospfv3-autoconfig-00 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-22 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational A. Brandt 5 Expires: August 2, 2012 Sigma Designs 6 T. Chown 7 University of Southampton 8 J. Weil 9 Time Warner Cable 10 O. Troan 11 Cisco Systems, Inc. 12 January 30, 2012 14 Home Networking Architecture for IPv6 15 draft-ietf-homenet-arch-01 17 Abstract 19 This text describes evolving networking technology within small 20 "residential home" networks. The goal of this memo is to define the 21 architecture for IPv6-based home networking and the associated 22 principles, considerations and requirements. The text highlights the 23 impact of IPv6 on home networking, illustrates topology scenarios, 24 and shows how standard IPv6 mechanisms and addressing can be employed 25 in home networking. The architecture describes the need for specific 26 protocol extensions for certain additional functionality. It is 27 assumed that the IPv6 home network is not actively managed, and runs 28 as an IPv6-only or dual-stack network. There are no recommendations 29 in this text for the IPv4 part of the network. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 2, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 5 66 2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . . 5 67 2.1. Multiple subnets and routers . . . . . . . . . . . . . . . 5 68 2.2. Multi-Addressing of devices . . . . . . . . . . . . . . . 6 69 2.3. Unique Local Addresses (ULAs) . . . . . . . . . . . . . . 6 70 2.4. Security, Borders, and the elimination of NAT . . . . . . 7 71 2.5. Naming, and manual configuration of IP addresses . . . . . 9 72 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.1. Network Models . . . . . . . . . . . . . . . . . . . . . . 9 74 3.1.1. A: Single ISP, Single CER, Single subnet . . . . . . . 10 75 3.1.2. B: Single ISP, Single CER, Multiple subnets . . . . . 11 76 3.1.3. C: Single ISP, Single CER, Multiple internal 77 subnets . . . . . . . . . . . . . . . . . . . . . . . 12 78 3.1.4. D: Two ISPs, Two CERs, Shared subnets with 79 multiple internal routers . . . . . . . . . . . . . . 14 80 3.1.5. E: Two ISPs, One CER, Isolated subnets with 81 multiple internal routers . . . . . . . . . . . . . . 15 82 3.1.6. F: Two ISPs, One CER, Shared subnets with multiple 83 internal routers . . . . . . . . . . . . . . . . . . . 16 84 3.2. Determining the Requirements . . . . . . . . . . . . . . . 16 85 3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 17 86 3.3.1. Multihoming . . . . . . . . . . . . . . . . . . . . . 17 87 3.3.2. Quality of Service in multi-service home networks . . 19 88 3.3.3. Privacy considerations . . . . . . . . . . . . . . . . 19 89 3.4. Principles . . . . . . . . . . . . . . . . . . . . . . . . 19 90 3.4.1. Reuse existing protocols . . . . . . . . . . . . . . . 19 91 3.4.2. Dual-stack Operation . . . . . . . . . . . . . . . . . 20 92 3.4.3. Largest Possible Subnets . . . . . . . . . . . . . . . 21 93 3.4.4. Transparent End-to-End Communications . . . . . . . . 21 94 3.4.5. IP Connectivity between All Nodes . . . . . . . . . . 22 95 3.4.6. Routing functionality . . . . . . . . . . . . . . . . 23 96 3.4.7. Self-Organising . . . . . . . . . . . . . . . . . . . 25 97 3.4.8. Fewest Topology Assumptions . . . . . . . . . . . . . 27 98 3.4.9. Naming and Service Discovery . . . . . . . . . . . . . 27 99 3.4.10. Proxy or Extend? . . . . . . . . . . . . . . . . . . . 28 100 3.4.11. Adapt to ISP constraints . . . . . . . . . . . . . . . 28 101 3.5. Summary of Homenet Architecture Recommendations . . . . . 29 102 3.6. Implementing the Architecture on IPv6 . . . . . . . . . . 29 103 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 104 4.1. Normative References . . . . . . . . . . . . . . . . . . . 29 105 4.2. Informative References . . . . . . . . . . . . . . . . . . 30 106 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 33 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 109 1. Introduction 111 This document focuses on evolving networking technology within small 112 "residential home" networks and the associated challenges. For 113 example, a trend in home networking is the proliferation of 114 networking technology in an increasingly broad range of devices and 115 media. This evolution in scale and diversity sets requirements on 116 IETF protocols. Some of these requirements relate to the need for 117 multiple subnets, for example for private and guest networks, the 118 introduction of IPv6, and the introduction of specialized networks 119 for home automation and sensors. 121 While some advanced home networks exist, most operate based on IPv4, 122 employ solutions that we would like to avoid such as (cascaded) 123 network address translation (NAT), or require expert assistance to 124 set up. The assumption of this document is that the homenet is "not 125 actively managed". The architectural constructs in this document are 126 focused on the problems to be solved when introducing IPv6 with an 127 eye towards a better result than what we have today with IPv4, as 128 well as a better result than if the IETF had not given this specific 129 guidance. 131 This architecture document aims to provide the basis and guiding 132 principles for how standard IPv6 mechanisms and addressing [RFC2460] 133 [RFC4291] can be employed in home networking, while coexisting with 134 existing IPv4 mechanisms. In emerging dual-stack home networks it is 135 vital that introducing IPv6 does not adversely affect IPv4 operation. 136 Future deployments, or specific subnets within an otherwise dual- 137 stack home network, may be IPv6-only. 139 [RFC6204] defines basic requirements for customer edge routers 140 (CERs). The scope of this text is the homenet, and thus the internal 141 facing interface described in RFC 6204 as well as other components 142 within the home network. While the network may be dual-stack or 143 IPv6-only, the definition of specific transition tools on the CER are 144 out of scope of this text, as is any advice regarding architecture of 145 the IPv4 part of the network. We assume that IPv4 network 146 architecture in home networks is what it is, and can not be affected 147 by new recommendations. 149 Discussion in the homenet WG has led to a suggestion that there 150 should be a baseline homenet "version 1" architecture, based on 151 protocols and implementations that are as far as possible proven and 152 robust. A future architecture may incorporate more advanced 153 elements. Feedback is sought on what if anything do we want to say 154 about potential homenet versions here. 156 1.1. Terminology and Abbreviations 158 In this section we define terminology and abbreviations used 159 throughout the text. 161 o CER: Customer Edge Router. The border router at the edge of the 162 homenet. 164 o LLN: Low-power and lossy network. 166 o NAT: Network Address Translation. Typically referring to Network 167 Address and Port Translation (NAPT). 169 o NPTv6: Network Prefix Translation for IPv6 [RFC6296]. 171 o PCP: Port Control Protocol [I-D.ietf-pcp-base]. 173 o ULA: Unique Local Addresses [RFC4193]. 175 o uPnP: Universal Plug and Play. 177 o VM: Virtual machine. 179 2. Effects of IPv6 on Home Networking 181 Service providers are deploying IPv6, content is becoming available 182 on IPv6, and support for IPv6 is increasingly available in devices 183 and software used in the home. While IPv6 resembles IPv4 in many 184 ways, it changes address allocation principles, makes multi- 185 addressing the norm, and allows direct IP addressability and routing 186 to devices in the home from the Internet. This section presents an 187 overview of some of the key areas impacted by the introduction of 188 IPv6 into the home network that are both promising and problematic. 190 2.1. Multiple subnets and routers 192 Simple layer 3 topologies involving as few subnets as possible are 193 preferred in home networks for a variety of reasons including simpler 194 management and service discovery. However, the incorporation of 195 dedicated (routed) subnets remains necessary for a variety of 196 reasons. 198 For instance, a common feature in modern home routers is the ability 199 to support both guest and private network subnets. Also, link layer 200 networking technology is poised to become more heterogeneous, as 201 networks begin to employ both traditional Ethernet technology and 202 link layers designed for low-power and lossy networks (LLNs) such as 203 those used for certain types of sensor devices. Similar needs for 204 subnetting may occur in other cases, such as separating building 205 control or corporate extensions from the Internet access network. 206 Also, different subnets may be associated with parts of the homenet 207 that have different routing and security policies. 209 Documents that provide some more specific background and depth on 210 this topic include: [I-D.herbst-v6ops-cpeenhancements], 211 [I-D.baker-fun-multi-router], and [I-D.baker-fun-routing-class]. 213 In addition to routing, rather than NATing, between subnets, there 214 are issues of when and how to extend mechanisms such as service 215 discovery which currently rely on link-local addressing to limit 216 scope. 218 The presence of a multiple subnet, multi-router network implies that 219 there is some kind of automatic routing mechanism in place. In 220 advanced configurations similar to those used in multihomed corporate 221 networks, there may also be a need to discover border router(s) by an 222 appropriate mechanism. 224 2.2. Multi-Addressing of devices 226 In an IPv6 network, devices may acquire multiple addresses, typically 227 at least a link-local address and a globally unique address. Thus it 228 should be considered the norm for devices on IPv6 home networks to be 229 multi-addressed, and to also have an IPv4 address where the network 230 is dual-stack. Default address selection mechanisms 231 [I-D.ietf-6man-rfc3484-revise] allow a node to select appropriate 232 src/dst address pairs for communications, though such selection may 233 face problems in the event of multihoming, where nodes will be 234 configured with one address from each upstream ISP prefix, and the 235 presence of upstream ingress filtering thus requires multi-addressed 236 nodes to select the right source address to be used for the 237 corresponding uplink. 239 2.3. Unique Local Addresses (ULAs) 241 [RFC4193] defines Unique Local Addresses (ULAs) for IPv6 that may be 242 used to address devices within the scope of a single site. Support 243 for ULAs for IPv6 CERs is described in [RFC6204]. A home network 244 running IPv6 may deploy ULAs for communication between devices within 245 the network. ULAs have the potential to be used for stable 246 addressing in a home network where the externally allocated global 247 prefix changes over time (either due to renumbering within the 248 subscriber's ISP or a change of ISP) or where external connectivity 249 is temporarily unavailable. However, it is undesirable to 250 aggressively deprecate global prefixes for temporary loss of 251 connectivity, so for this to matter there would have to be a 252 connection breakage longer than the lease period, and even then, 253 deprecating prefixes when there is no connectivity may not be 254 advisable. However, while setting a network up there may be a period 255 with no connectivity. 257 Another possible reason for using ULAs would be to provide an 258 indication to applications that the traffic is local. This could 259 then be used with security settings to designate where a particular 260 application is allowed to connect to. 262 ULA addresses will allow constrained LLN devices to create permanent 263 relations between IPv6 addresses, e.g. from a wall controller to a 264 lamp. Symbolic host names would require additional non-volatile 265 memory. Updating global prefixes in sleeping LLN devices might also 266 be problematic. 268 Address selection mechanisms should ensure a ULA source address is 269 used to communicate with ULA destination addresses. The use of ULAs 270 does not imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT 271 [RFC6296], rather that external communications should use a node's 272 global IPv6 source address. 274 2.4. Security, Borders, and the elimination of NAT 276 Current IPv4 home networks typically receive a single global IPv4 277 address from their ISP and use NAT with private [RFC1918] addresses 278 for devices within the network. An IPv6 home network removes the 279 need to use NAT given the ISP offers a sufficiently large IPv6 prefix 280 to the homenet, allowing every device on every link to be assigned a 281 globally unique IPv6 address. 283 The end-to-end communication that is potentially enabled with IPv6 is 284 both an incredible opportunity for innovation and simpler network 285 operation, but it is also a concern as it exposes nodes in the 286 internal networks to receipt of otherwise unwanted traffic from the 287 Internet. 289 In IPv4 NAT networks, the NAT provides an implicit firewall function. 290 [RFC4864] suggests that IPv6 networks with global addresses utilise 291 "Simple Security" in border firewalls to restrict incoming 292 connections through a default deny policy. Applications or hosts 293 wanting to accept inbound connections then need to signal that desire 294 through a protocol such as uPNP or PCP [I-D.ietf-pcp-base]. In 295 networks with multiple CERs, PCP will need to handle the cases of 296 flows that may use one or both exit routers. 298 Such an approach would reduce the efficacy of end-to-end connectivity 299 that IPv6 has the potential to restore, since the need for IPv4 NAT 300 traversal is replaced by a need to use a signalling protocol to 301 request a firewall hole be opened. [RFC6092] provides 302 recommendations for an IPv6 firewall that applies "limitations on 303 end-to-end transparency where security considerations are deemed 304 important to promote local and Internet security." The firewall 305 operation is "simple" in that there is an assumption that traffic 306 which is to be blocked by default is defined in the RFC and not 307 expected to be updated by the user or otherwise. The RFC does 308 however state that CERs should have an option to be put into a 309 "transparent mode" of operation. 311 It is important to distinguish between addressability and 312 reachability; i.e. while IPv6 offers global addressability through 313 use of globally unique addresses in the home, whether they are 314 globally reachable or not would depend on firewall or filtering 315 configuration, and not the presence or use of NAT. 317 Advanced Security for IPv6 CPEs [I-D.vyncke-advanced-ipv6-security] 318 takes the approach that in order to provide the greatest end-to-end 319 transparency as well as security, security policies must be updated 320 by a trusted party which can provide intrusion signatures and other 321 "active" information on security threats. This is much like a virus- 322 scanning tool which must receive updates in order to detect and/or 323 neutralize the latest attacks as they arrive. As the name implies 324 "advanced" security requires significantly more resources and 325 infrastructure (including a source for attack signatures) in 326 comparison to "simple" security. 328 In addition to establishing the security mechanisms themselves, it is 329 important to know where to enable them. If there is some indication 330 as to which router is connected to the "outside" of the home network, 331 this is feasible. Otherwise, it can be difficult to know which 332 security policies to apply where. Further, security policies may be 333 different for various address ranges if ULA addressing is setup to 334 only operate within the homenet itself and not be routed to the 335 Internet at large. Finally, such policies must be able to be applied 336 by typical home users, e.g. to give a visitor in a "guest" network 337 access to media services in the home. 339 It may be useful to classify the border of the home network as a 340 unique logical interface separating the home network from service 341 provider network/s. This border interface may be a single physical 342 interface to a single service provider, multiple layer 2 sub- 343 interfaces to a single service provider, or multiple connections to a 344 single or multiple providers. This border is useful for describing 345 edge operations and interface requirements across multiple functional 346 areas including security, routing, service discovery, and router 347 discovery. 349 2.5. Naming, and manual configuration of IP addresses 351 In IPv4, a single subnet NATed home network environment is currently 352 the norm. As a result, it is for example common practice for users 353 to be able to connect to a router for configuration via a literal 354 address such as 192.168.1.1 or some other commonly used RFC 1918 355 address. In IPv6, while ULAs exist and could potentially be used to 356 address internally-reachable services, little deployment experience 357 exists to date. Given a true ULA prefix is effectively a random 48- 358 bit prefix, it is not reasonable to expect users to manually enter 359 such address literals for configuration or other purposes. As such, 360 even for the simplest of functions, naming and the associated 361 discovery of services is imperative for easy administration of the 362 homenet. 364 In a multi-subnet homenet, naming and service discovery should be 365 expected to operate across the scope of the entire home network, and 366 thus be able to cross subnet boundaries. It should be noted that in 367 IPv4, such services do not generally function across home router NAT 368 boundaries, so this is one area where there is scope for an 369 improvement in IPv6. 371 3. Architecture 373 An architecture outlines how to construct home networks involving 374 multiple routers and subnets. In this section, we present a set of 375 typical home network topology models/scenarios, followed by a list of 376 topics that may influence the architecture discussions, and a set of 377 architectural principles that govern how the various nodes should 378 work together. Finally, some guidelines are given for realizing the 379 architecture with the IPv6 addressing, prefix delegation, global and 380 ULA addresses, source address selection rules and other existing 381 components of the IPv6 architecture. The architecture also drives 382 what protocol extensions are necessary, as will be discussed in 383 Section 3.6. 385 3.1. Network Models 387 In this section we list six network models. 389 A) Single ISP, Single CER, Single subnet 390 B) Single ISP, Single CER, Multiple subnets 392 C) Single ISP, Single CER, Multiple internal routers 394 D) Two ISPs, Two CERs, Shared subnets with multiple internal routers 396 E) Two ISPs, One CER, Isolated subnets with multiple internal 397 routers 399 F) Two ISPs, One CER, Shared subnets with multiple internal routers 401 The models are presented to frame the discussion as to which models 402 are in scope for the homenet architecture, and which multi-homing 403 requirements should be met in the architecture. 405 3.1.1. A: Single ISP, Single CER, Single subnet 407 Figure 1 shows the simplest possible home network topology, involving 408 just one router, a local area network, and a set of hosts. Setting 409 up such networks is in principle well understood today [RFC6204]. 411 +-------+-------+ \ 412 | Service | \ 413 | Provider | | Service 414 | Router | | Provider 415 +-------+-------+ | network 416 | / 417 | Customer / 418 demarc #1 --> | Internet connection / 419 | 420 +------+--------+ \ 421 | IPv6 | \ 422 | Customer Edge | \ 423 | Router | / 424 +------+--------+ / 425 | | 426 demarc #2 --> | | End-User 427 | Local network | network(s) 428 ---+-----+-------+--- \ 429 | | \ 430 +----+-----+ +-----+----+ \ 431 |IPv6 Host | |IPv6 Host | / 432 | | | | / 433 +----------+ +-----+----+ / 435 Figure 1 437 Two possible demarcation points are illustrated in Figure 1, which 438 indicate which party is responsible for configuration or 439 autoconfiguration. Demarcation #1 makes the Customer Edge Router the 440 responsibility of the customer. This is only practical if the 441 Customer Edge Router can function with factory defaults installed. 442 The Customer Edge Router may be pre-configured by the ISP, or by the 443 home user by some suitably simple method. Demarcation #2 makes the 444 Customer Edge Router the responsibility of the provider. Both models 445 of operation must be supported in the homenet architecture, including 446 the scenarios below with multiple ISPs and demarcation points. 448 3.1.2. B: Single ISP, Single CER, Multiple subnets 450 Figure 2 shows another network that now introduces multiple local 451 area networks. These may be needed for reasons relating to different 452 link layer technologies in use or for policy reasons. A common 453 arrangement is to have different link types supported on the same 454 router, bridged together. This example however presents two subnets. 455 This could be classic Ethernet in the one subnet and a LLN link layer 456 technology in the other subnet. 458 This topology is also relatively well understood today [RFC6204], 459 though it certainly presents additional demands with regards to 460 suitable firewall policies and limits the operation of certain 461 applications and discovery mechanisms (which may typically today only 462 succeed within a single subnet). 464 +-------+-------+ \ 465 | Service | \ 466 | Provider | | Service 467 | Router | | Provider 468 +------+--------+ | network 469 | / 470 | Customer / 471 | Internet connection / 472 | 473 +------+--------+ \ 474 | IPv6 | \ 475 | Customer Edge | \ 476 | Router | / 477 +----+-------+--+ / 478 Network A | | Network B | End-User 479 ---+-------------+----+- --+--+-------------+--- | network(s) 480 | | | | \ 481 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 482 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 483 | | | | | | | | / 484 +----------+ +----------+ +----------+ +----------+ / 486 Figure 2 488 3.1.3. C: Single ISP, Single CER, Multiple internal subnets 490 Figure 3 shows a little bit more complex network with two routers and 491 eight devices connected to one ISP. This network is similar to the 492 one discussed in [I-D.ietf-v6ops-ipv6-cpe-router-bis]. The main 493 complication in this topology compared to the ones described earlier 494 is that there is no longer a single router that a priori understands 495 the entire topology. The topology itself may also be complex. It 496 may not be possible to assume a pure tree form, for instance. This 497 is a valid consideration as home users may plug routers together to 498 form arbitrary topologies including loops. In the following sections 499 we discuss support for arbitrary topologies. 501 +-------+-------+ \ 502 | Service | \ 503 | Provider | | Service 504 | Router | | Provider 505 +-------+-------+ | network 506 | / 507 | Customer / 508 | Internet connection 509 | 510 +------+--------+ \ 511 | IPv6 | \ 512 | Customer Edge | \ 513 | Router | | 514 +----+-+---+----+ | 515 Network A | | | Network B/E | 516 ----+-------------+----+ | +---+-------------+------+ | 517 | | | | | | | | 518 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | | 519 |IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | | 520 | | | | | | | | | | | 521 +----------+ +----------+ | +----------+ +----------+ | | 522 | | | | | 523 | ---+------+------+-----+ | 524 | | Network B/E | 525 +------+--------+ | | End-User 526 | IPv6 | | | networks 527 | Interior +------+ | 528 | Router | | 529 +---+-------+-+-+ | 530 Network C | | Network D | 531 ----+-------------+---+- --+---+-------------+--- | 532 | | | | | 533 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 534 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 535 | | | | | | | | / 536 +----------+ +----------+ +----------+ +----------+ / 538 Figure 3 540 3.1.4. D: Two ISPs, Two CERs, Shared subnets with multiple internal 541 routers 543 +-------+-------+ +-------+-------+ \ 544 | Service | | Service | \ 545 | Provider A | | Provider B | | Service 546 | Router | | Router | | Provider 547 +------+--------+ +-------+-------+ | network 548 | | / 549 | Customer | / 550 | Internet connections | / 551 | | 552 +------+--------+ +-------+-------+ \ 553 | IPv6 | | IPv6 | \ 554 | Customer Edge | | Customer Edge | \ 555 | Router 1 | | Router 2 | / 556 +------+--------+ +-------+-------+ / 557 | | / 558 | | | End-User 559 ---+---------+---+---------------+--+----------+--- | network(s) 560 | | | | \ 561 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 562 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 563 | | | | | | | | / 564 +----------+ +----------+ +----------+ +----------+ 566 Figure 4 568 Figure 4 illustrates a multihomed home network model, where the 569 customer has connectivity via CER1 to ISP A and via CER2 to ISP B. 570 This example shows one shared subnet where IPv6 nodes would 571 potentially be multihomed and receive multiple IPv6 global addresses, 572 one per ISP. This model may also be combined with that shown in 573 Figure 3 to create a more complex scenario with subnets that my be 574 behind multiple internal routers. 576 3.1.5. E: Two ISPs, One CER, Isolated subnets with multiple internal 577 routers 579 +-------+-------+ +-------+-------+ \ 580 | Service | | Service | \ 581 | Provider A | | Provider B | | Service 582 | Router | | Router | | Provider 583 +-------+-------+ +-------+-------+ | network 584 | | / 585 | Customer | / 586 | Internet | / 587 | connections | | 588 +---------+---------+ \ 589 | IPv6 | \ 590 | Customer Edge | \ 591 | Router 1 | / 592 +---------+---------+ / 593 | | / 594 | | | End-User 595 ---+---------+---+-- --+--+----------+--- | network(s) 596 | | | | \ 597 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 598 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 599 | | | | | | | | / 600 +----------+ +----------+ +----------+ +----------+ 602 Figure 5 604 Figure 5 illustrates a model where a home network may have multiple 605 connections to multiple providers or multiple logical connections to 606 the same provider, but the associated subnet(s) are isolated. Some 607 deployment scenarios may require this model. 609 3.1.6. F: Two ISPs, One CER, Shared subnets with multiple internal 610 routers 612 +-------+-------+ +-------+-------+ \ 613 | Service | | Service | \ 614 | Provider A | | Provider B | | Service 615 | Router | | Router | | Provider 616 +-------+-------+ +-------+-------+ | network 617 | | / 618 | Customer | / 619 | Internet | / 620 | connections | | 621 +---------+---------+ \ 622 | IPv6 | \ 623 | Customer Edge | \ 624 | Router 1 | / 625 +---------+---------+ / 626 | | / 627 | | | End-User 628 ---+------------+-+------------+-+-------------+--- | network(s) 629 | | | | \ 630 +----+-----+ +----+-----+ +----+-----+ +-----+----+ \ 631 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 632 | | | | | | | | / 633 +----------+ +----------+ +----------+ +----------+ 635 Figure 6 637 Figure 6 illustrates a model where a home network may have multiple 638 connections to multiple providers or multiple logical connections to 639 the same provider, with shared internal subnets, that may be multiple 640 layers deep. 642 3.2. Determining the Requirements 644 [RFC6204] defines "basic" requirements for IPv6 Customer Edge 645 Routers, while [I-D.ietf-v6ops-ipv6-cpe-router-bis] describes 646 "advanced" features. In general, home network equipment needs to 647 cope with the different types of network topologies discussed above. 648 Manual configuration is rarely, if at all, possible, given the 649 knowledge level of typical home users. The equipment needs to be 650 prepared to handle at least 652 o Prefix configuration for routers 654 o Managing routing 655 o Name resolution 657 o Service discovery 659 o Network security 661 The remainder of the architecture document is presented as 662 considerations and principles that lead to more specific requirements 663 for the five general areas listed above. 665 3.3. Considerations 667 This section lists some considerations for home networking that may 668 affect the architecture and associated requirements. 670 3.3.1. Multihoming 672 A homenet may be multihomed to multiple providers. This may either 673 take a form where there are multiple isolated networks within the 674 home (see Network Model E above) or a more integrated network where 675 the connectivity selection is dynamic (see Network Model D or F 676 above). Current practice is typically of the former kind, but the 677 latter is expected to become more commonplace. 679 There are some specific multihoming considerations for homenet 680 scenarios. First, it may be the case that multihoming applies due to 681 an ISP migration from a transition method to a native deployment, 682 e.g. a 6rd [RFC5969] sunset scenario. Second, one upstream may be a 683 "walled garden", and thus only appropriate to be used for 684 connectivity to the services of that provider. 686 In an integrated network, specific appliances or applications may use 687 their own external connectivity, or the entire network may change its 688 connectivity based on the status of the different upstream 689 connections. The complexity of the multihoming solution required 690 will depend on the Network Model deployed. For example, Network 691 Models E and F have a single CER and thus could perform source 692 routing at the single network exit point. 694 The general approach for IPv6 multihoming is for a hosts to receive 695 multiple addresses from multiple providers, and to select the 696 appropriate source address to communicate via a given provider. An 697 alternative is to deploy ULAs with a site and then use NPTv6 698 [RFC6296], a prefix translation-based mechanism, at the edge. This 699 obviously comes at some architectural cost, which is why approaches 700 such as [I-D.v6ops-multihoming-without-ipv6nat] have been suggested. 701 There has been much work on multihoming in the IETF, without (yet) 702 widespread deployment of proposed solutions. Host-based methods such 703 as Shim6 [RFC5533] have also been defined, but of course require 704 support in the hosts. 706 If multihoming is supported additional requirements apply. The 707 general multihoming problem is broad, and solutions may include 708 complex architectures for monitoring connectivity, traffic 709 engineering, identifier-locator separation, connection survivability 710 across multihoming events, and so on. This implies that if there is 711 any support for multihoming defined in the homenet architecture it 712 should be limited to a very small subset of the overall problem. 714 The current set of assumptions and requirements proposed by the 715 homenet architecture team is: 717 MH1) The homenet WG should not try to make another attempt at 718 solving complex multihoming; we should prefer to support 719 scenarios for which solutions exist today. 721 MH2) Single CER Network Models E and F are in scope, and may be 722 solved by source routing at the CER. 724 MH3) It is desirable to avoid deployment of NPTv6 at the CER. Hosts 725 should be multi-addressed from each ISP they may communicate 726 with or through. 728 MH4) Solutions that involve host changes should be avoided. 730 MH5) Walled garden multihoming is in scope. 732 MH6) Transition method sunsetting is in scope. The topic of 733 multihoming with specific (6rd) transition coexistence is 734 discussed in [I-D.townsley-troan-ipv6-ce-transitioning]. 736 MH7) "Just" picking the right source address to use to fall foul of 737 ingress filtering on upstream ISP connections (as per Network 738 Model D) is not a trivial task. A solution is highly 739 desirable, but out of scope of homenet. 741 MH8) Source routing throughout the homenet, a la 742 [I-D.baker-fun-multi-router], requires relatively significant 743 routing changes. The network should "guarantee" routing the 744 packet to the correct exit given the source address, but hosts 745 are responsible for anything extra, e.g. detecting failure, or 746 choosing a new src/dst address combination. 748 Feedback is sought on the above points. 750 3.3.2. Quality of Service in multi-service home networks 752 Support for QoS in a multi-service homenet may be a requirement, e.g. 753 for a critical system (perhaps healthcare related), or for 754 differentiation between different types of traffic (file sharing, 755 cloud storage, live streaming, VoIP, etc). Different media types may 756 have different QoS properties or capabilities. 758 However, homenet scenarios should require no new QoS protocols. A 759 DiffServ [RFC2475] approach with a small number of predefined traffic 760 classes should generally be sufficient, though at present there is 761 little experience of QoS deployment in home networks. 763 There may also be complementary mechanisms that could be beneficial 764 in the homenet domain, such as ensuring proper buffering algorithms 765 are used as described in [Gettys11]. 767 3.3.3. Privacy considerations 769 There are no specific privacy concerns for this text. It should be 770 noted that many ISPs are expected to offer relatively stable IPv6 771 prefixes to customers, and thus the network prefix associated with 772 the host addresses they use would not generally change over a 773 reasonable period of time, e.g. between restructuring of an ISPs 774 residential network provision. 776 3.4. Principles 778 There is little that the Internet standards community can do about 779 the physical topologies or the need for some networks to be separated 780 at the network layer for policy or link layer compatibility reasons. 781 However, there is a lot of flexibility in using IP addressing and 782 inter-networking mechanisms. In this section we discuss how this 783 flexibility should be used to provide the best user experience and 784 ensure that the network can evolve with new applications in the 785 future. 787 The following principles should be followed when designing homenet 788 solutions. Where requirements are associated with those principles, 789 they are listed here. There is no implied priority by the order in 790 which the principles themselves are listed. 792 3.4.1. Reuse existing protocols 794 It is desirable to reuse existing protocols where possible, but at 795 the same time to avoid consciously precluding the introduction of new 796 or emerging protocols. 798 A generally conservative approach, giving weight to running code, is 799 preferable. Where new protocols are required, evidence of commitment 800 to implementation by appropriate vendors or development communities 801 is highly desirable. Protocols used should be backwardly compatible. 803 Where possible, changes to hosts should be minimised. Some changes 804 may be unavoidable however, e.g. signalling protocols to punch holes 805 in firewalls where "Simple Security" is deployed in a CER. 807 Changes to routers should also be minimised, e.g. 808 [I-D.baker-fun-routing-class] suggests introducing a routing protocol 809 that may route on both source and destination addresses, which would 810 be a significant change compared to current practices. 812 Liaisons with other appropriate standards groups and related 813 organisations is desirable, e.g. the IEEE and Wi-Fi Alliance. 815 3.4.2. Dual-stack Operation 817 The homenet architecture targets both IPv6-only and dual-stack 818 networks. While the CER requirements in RFC 6204 are aimed at IPv6- 819 only networks, it is likely that dual-stack homenets will be the norm 820 for some period of time. IPv6-only networking may first be deployed 821 in home networks in "greenfield" scenarios, or perhaps as one element 822 of an otherwise dual-stack network. The homenet architecture must 823 operate in the absence of IPv4, and IPv6 must work in the same 824 scenarios as IPv4 today. 826 Running IPv6-only may require documentation of additional 827 considerations such as: 829 Ensuring there is a way to access content in the IPv4 Internet. 830 This can be arranged through incorporating NAT64 [RFC6144] 831 functionality in the home gateway router, for instance. 833 DNS discovery mechanisms are enabled for IPv6. Both stateless 834 DHCPv6 [RFC3736] [RFC3646] and Router Advertisement options 835 [RFC6106] may have to be supported and turned on by default to 836 ensure maximum compatibility with all types of hosts in the 837 network. This requires, however, that a working DNS server is 838 known and addressable via IPv6. 840 All nodes in the home network support operations in IPv6-only 841 mode. Some current devices work well with dual-stack but fail to 842 recognize connectivity when IPv4 DHCP fails, for instance. 844 In dual-stack networks, solutions for IPv6 must not adversely affect 845 IPv4 operation. It is likely that topologies of IPv4 and IPv6 846 networks would be as congruent as possible. 848 Note that specific transition tools, particularly those running on 849 the border CER to support transition tools being used inside the 850 homenet, are out of scope. Use of tools, such as 6rd, on the border 851 CER to support ISP access network transition are to be expected, but 852 not within scope of homenet, which focuses on the internal 853 networking. 855 3.4.3. Largest Possible Subnets 857 Today's IPv4 home networks generally have a single subnet, and early 858 dual-stack deployments have a single congruent IPv6 subnet, possibly 859 with some bridging functionality. 861 Future home networks are highly likely to need multiple subnets, for 862 the reasons described earlier. As part of the self-organisation of 863 the network, the network should subdivide itself to the largest 864 possible subnets that can be constructed within the constraints of 865 link layer mechanisms, bridging, physical connectivity, and policy. 866 For instance, separate subnetworks are necessary where two different 867 link layers cannot be bridged, or when a policy requires the 868 separation of a private and visitor parts of the network. 870 While it may be desirable to maximise the chance of link-local 871 protocols operating across a homenet by maximising the size of a 872 subnet across the homenet, multiple subnet home networks are 873 inevitable, so their support must be included. A general 874 recommendation is to follow the same topology for IPv6 as is used for 875 IPv4, but not to use NAT. Thus there should be routed IPv6 where an 876 IPv4 NAT is used, and where there is no NAT there should be bridging 877 if the link layer allows this. 879 In some cases IPv4 NAT home networks may feature cascaded NATs, e.g. 880 where NAT routers are included within VMs or Internet connection 881 services are used. IPv6 routed versions of such tools will be 882 required. 884 3.4.4. Transparent End-to-End Communications 886 An IPv6-based home network architecture should naturally offer a 887 transparent end-to-end communications model. Each device should be 888 addressable by a unique address. Security perimeters can of course 889 restrict the end-to-end communications, but it is simpler given the 890 availability of globally unique addresses to block certain nodes from 891 communicating by use of an appropriate filtering device than to 892 configure the address translation device to enable appropriate 893 address/port forwarding in the presence of a NAT. 895 As discussed previously, it is important to note the difference 896 between hosts being addressable and reachable. Thus filtering is to 897 be expected, while host-based IPv6 NAT is not. End-to-end 898 communications are important for their robustness against failure of 899 intermediate systems, where in contrast NAT is dependent on state 900 machines which are not self-healing. 902 When configuring filters, protocols for securely associating devices 903 are desirable. In the presence of "Simple Security" the use of 904 signalling protocols such as uPnP or PCP may be expected to punch 905 holes in the firewall (and be able to handle cases where there are 906 multiple CERs/firewall(s). Alternatively, RFC 6092 supports the 907 option for a border CER to run in "transparent mode", in which case a 908 protocol like PCP is not required, but the security model is more 909 open. 911 3.4.5. IP Connectivity between All Nodes 913 A logical consequence of the end-to-end communications model is that 914 the network should by default attempt to provide IP-layer 915 connectivity between all internal parts as well as between the 916 internal parts and the Internet. This connectivity should be 917 established at the link layer, if possible, and using routing at the 918 IP layer otherwise. 920 Local addressing (ULAs) may be used within the scope of a home 921 network. It would be expected that ULAs may be used alongside one or 922 more globally unique ISP-provided addresses/prefixes in a homenet. 923 ULAs may be used for all devices, not just those intended to have 924 internal connectivity only. ULAs may then be used for stable 925 internal communications should the ISP-provided prefix (suddenly) 926 change, or external connectivity be temporarily lost. The use of 927 ULAs should be restricted to the homenet scope through filtering at 928 the border(s) of the homenet; thus "end-to-end" for ULAs is limited 929 to the homenet. 931 In some cases full internal connectivity may not be desirable, e.g. 932 in certain utility networking scenarios, or where filtering is 933 required for policy reasons against guest network subnet(s). Note 934 that certain scenarios may require co-existence of ISP connectivity 935 providing a general Internet service with provider connectivity to a 936 private "walled garden" network. 938 Some home networking scenarios/models may involve isolated subnet(s) 939 with their own CERs. In such cases connectivity would only be 940 expected within each isolated network (though traffic may potentially 941 pass between them via external providers). 943 LLNs provide an example of where there may be secure perimeters 944 inside the homenet. Constrained LLN nodes may implement WPA-style 945 network key security but may depend on access policies enforced by 946 the LLN border router. 948 3.4.6. Routing functionality 950 Routing functionality is required when there are multiple routers in 951 use. This functionality could be as simple as the current "default 952 route is up" model of IPv4 NAT, or it could involve running an 953 appropriate routing protocol. 955 The homenet routing environment may include traditional IP networking 956 where existing link-state or distance-vector protocols may be used, 957 but also new LLN or other "constrained" networks where other 958 protocols may be more appropriate. IPv6 VM solutions may also add 959 additional routing requirements. Current home deployments use 960 largely different mechanisms in sensor and basic Internet 961 connectivity networks. 963 In this section we list the requirements and assumptions for routing 964 functionality within the homenet environment. 966 RT1) The protocol should preferably be an existing deployed 967 protocol that has been proven to be reliable and robust. 969 RT2) It is preferable that the protocol is "lightweight". 971 RT3) The protocol should provide reachability between all nodes in 972 the homement. 974 RT4) In general, LLN or other networks should be able to attach and 975 participate the same way or map/be gatewayed to the main 976 homenet. 978 RT5) Multiple interface PHYs must be accounted for in the homenet 979 routed topology. Technologies such as Ethernet, WiFi, MoCA, 980 etc must be capable of coexisting in the same environment and 981 should be tested as part of any routed deployment. The 982 inclusion of the PHY layer characteristics including 983 bandwidth, loss, and latency in path computation should be 984 considered for optimizing communication in the homenet. 986 RT6) Minimizing convergence time should be a goal in any routed 987 environment, but as a guideline a maximum convergence time of 988 a couple of minutes should be the target. 990 RT7) It is desirable that the routing protocol has knowledge of the 991 homenet topology, which implies a link-state protocol may be 992 preferable. If so, it is also desirable that the 993 announcements and use of LSAs and RAs are appropriately 994 coordinated. 996 RT8) Any routed solution will require a means for determining the 997 boundaries of the homenet. Borders may include but are not 998 limited to the interface to the upstream ISP, a gateway device 999 to a separate home network such as a SmartGrid or similar LLN 1000 network, and in some cases there may be no border such as 1001 before an upstream connection has been established. Devices 1002 in the homenet must be able to find the path to the Internet 1003 as well as other devices on the home intranet. The border 1004 discovery functionality may be integrated into the routing 1005 protocol itself, but may also be imported via a separate 1006 discovery mechanism. 1008 RT9) The routing environment should be self-configuring, as 1009 discussed in the next subsection. An example of how OSPFv3 1010 can be self-configuring in a homenet is described in 1011 [I-D.acee-ospf-ospfv3-autoconfig]. The exception is 1012 configuration of a "secret" for authentication methods. It is 1013 important that self-configuration with "unintended" devices is 1014 avoided. 1016 RT10) The protocol should not require upstream ISP connectivity to 1017 be established to continue routing within the homenet. 1019 RT11) Multiple upstreams should be supported, as described in the 1020 Network Models earlier. 1022 RT12) To support multihoming within a homenet, a routing protocol 1023 that can make routing decisions based on source and 1024 destination addresses is desirable, to avoid upstream ISP 1025 ingress filtering problems. In general the routing protocol 1026 should support multiple ISP uplinks and delegated prefixes in 1027 concurrent use. 1029 RT13) The routing system should support walled garden environments. 1031 RT14) Load-balancing to multiple providers is not a requirement, but 1032 failover from a primary to a backup link when available must 1033 be a requirement. 1035 RT15) It is assumed that the typical router designed for residential 1036 use does not contain the memory or cpu required to process a 1037 full Internet routing table this should not be a requirement 1038 for any homenet device. 1040 A new I-D has been published on homenet routing requirements, see 1041 [I-D.howard-homenet-routing-comparison] and evaluations of common 1042 routing protocols made against those requirements, see 1043 [I-D.howard-homenet-routing-requirements]. The requirements from the 1044 former document have been worked into this architecture text. 1045 Feedback is sought on how these documents move forward. 1047 3.4.7. Self-Organising 1049 A home network architecture should be naturally self-organising and 1050 self-configuring under different circumstances relating to the 1051 connectivity status to the Internet, number of devices, and physical 1052 topology. While the homenet should be self-organising, it should be 1053 possible to manually adjust (override) the current configuration. 1055 The most important function in this respect is prefix delegation and 1056 management. The requirements and assumptions for the prefix 1057 delegation function are summarised as follows: 1059 PD1) From the homenet perspective, a single prefix should be 1060 received on the border CER [RFC3633]. The ISP should only see 1061 that aggregate, and not single /64 prefixes allocated within 1062 the homenet. 1064 PD2) Each link in the homenet should receive a prefix from within 1065 the ISP-provided prefix. 1067 PD3) Delegation should be autonomous, and not assume a flat or 1068 hierarchical model. 1070 PD4) The assignment mechanism should provide reasonable efficiency, 1071 so that typical home network prefix allocation sizes can 1072 accommodate all the necessary /64 allocations in most cases. 1073 A currently typical /60 allocation gives 16 /64 subnets. 1075 PD5) Duplicate assignment of multiple /64s to the same network 1076 should be avoided. 1078 PD6) The network should behave as gracefully as possible in the 1079 event of prefix exhaustion. 1081 PD7) Where multiple CERs exist with multiple ISP prefix pools, it 1082 is expected that routers within the homenet would assign 1083 themselves prefixes from each ISP they communicate with/ 1084 through. 1086 PD8) Where ULAs are used, most likely but not necessarily in 1087 parallel with global prefixes, one router will need to be 1088 elected as the generator of ULA prefixes for the homenet. 1090 PD9) Delegation within the homenet should give each link a prefix 1091 that is persistent across reboots, power outages and similar 1092 short-term outages. 1094 PD10) Addition of a new routing device should not affect existing 1095 persistent prefixes, but persistence may not be expected in 1096 the face of significant "replumbing" of the homenet. 1098 PD11) Persistence should not depend on router boot order. 1100 PD12) Persistent prefixes may imply the need for stable storage on 1101 routing devices, and also a method for a home user to "reset" 1102 the stored prefix should a significant reconfiguration be 1103 required (though ideally the home user should not be involved 1104 at all). 1106 PD13) The delegation method should support "flash" renumbering. 1108 Several proposals have been made for prefix delegation within a 1109 homenet. One group of proposals is based on DHCPv6 PD, as described 1110 in [I-D.baker-homenet-prefix-assignment], 1111 [I-D.chakrabarti-homenet-prefix-alloc], [RFC3315] and [RFC3633]. The 1112 other uses OSPFv3, as described in 1113 [I-D.arkko-homenet-prefix-assignment]. More detailed analysis of 1114 these approaches needs to be made against the requirements/ 1115 assumptions listed above. 1117 Other parameters of the network will need to be self-organising. The 1118 network elements will need to be integrated in a way that takes 1119 account of the various lifetimes on timers that are used on those 1120 different elements, e.g. DHCPv6 PD, router, valid prefix and 1121 preferred prefix timers. 1123 The homenet will have one or more borders, with external connectivity 1124 providers and potentially parts of the internal network (e.g. for 1125 policy-based reasons). It should be possible to automatically 1126 perform border discovery at least for the ISP borders. Such borders 1127 determine for example the scope of ULAs, site scope multicast 1128 boundaries and where firewall policies may be applied. 1130 The network cannot be expected to be completely self-organising, e.g. 1131 some security parameters are likely to need manual configuration, 1132 e.g. WPA2 configuration for wireless access control. Some existing 1133 mechanisms exist to assist home users to associate devices as simply 1134 as possible, e.g. "connect" button support. 1136 3.4.8. Fewest Topology Assumptions 1138 There should ideally be no built-in assumptions about the topology in 1139 home networks, as users are capable of connecting their devices in 1140 ingenious ways. Thus arbitrary topologies will need to be supported. 1142 It is important not to introduce new IPv6 scenarios that would break 1143 with IPv4+NAT, given that dual-stack homenets will be commonplace for 1144 some time. There may be IPv6-only topologies that work where IPv4 is 1145 not used or required. 1147 3.4.9. Naming and Service Discovery 1149 The most natural way to think about naming and service discovery 1150 within a homenet is to enable it to work across the entire residence, 1151 disregarding technical borders such as subnets but respecting policy 1152 borders such as those between visitor and internal networks. 1154 Homenet naming systems will be required that work internally or 1155 externally, though the domains used may be different from those 1156 different perspectives. 1158 A desirable target may be a fully functional self-configuring secure 1159 local DNS service so that all devices are referred to by name, and 1160 these FQDNs are resolved locally. This would make clean use of ULAs 1161 and multiple ISP-provided prefixes much easier. The local DNS 1162 service should be (by default) authoritative for the local name space 1163 in both IPv4 and IPv6. A dual-stack residential gateway should 1164 include a dual-stack DNS server. 1166 Consideration will also need to be given for existing protocols that 1167 may be used within a network, e.g. mDNS, and how these interact with 1168 unicast-based DNS services. 1170 With the introduction of new top level domains, there is potential 1171 for ambiguity between for example a local host called apple and (if 1172 it is registered) an apple gTLD, so some local name space is probably 1173 required, which should also be configurable to something else by a 1174 home user, e.g. ".home", if desired. 1176 It is also important to note here that there is also potential 1177 ambiguity if a mobile device should move between two local name 1178 spaces called ".home", for example. 1180 For service discovery, support may be required for IPv6 multicast 1181 across the scope of the home network, and thus at least all routing 1182 devices in the network. 1184 3.4.10. Proxy or Extend? 1186 Related to the above, we believe that general existing discovery 1187 protocols that are designed to only work within a subnet should be 1188 modified/extended to work across subnets, rather than defining proxy 1189 capabilities for each of those functions. 1191 Feedback is desirable on which other functions/protocols assume 1192 subnet-only operation, in the context of existing home networks. 1193 Some experience from enterprises may be relevant here. 1195 3.4.11. Adapt to ISP constraints 1197 The home network may receive an arbitrary length IPv6 prefix from its 1198 provider, e.g. /60 or /56. The offered prefix may be stable over 1199 time or change frequently. The home network needs to be adaptable to 1200 such ISP policies, e.g. on constraints placed by the size of prefix 1201 offered by the ISP. The ISP may use [I-D.ietf-dhc-pd-exclude] for 1202 example. 1204 The internal operation of the home network should also not depend on 1205 the availability of the ISP network at any given time, other than for 1206 connectivity to services or systems off the home network. This 1207 implies the use of ULAs as supported in RFC6204. If used, ULA 1208 addresses should be stable so that they can always be used 1209 internally, independent of the link to the ISP. 1211 It is expected that ISPs will deliver a relatively stable home prefix 1212 to customers. The norm for residential customers of large ISPs may 1213 similar to their single IPv4 address provision; by default it is 1214 likely to remain persistent for some time, but changes in the ISP's 1215 own provisioning systems may lead to the customer's IP (and in the 1216 IPv6 case their prefix pool) changing. 1218 When an ISP needs to restructure and in doing so renumber its 1219 customer homenets, "flash" renumbering is likely to be imposed. This 1220 implies a need for the homenet to be able to handle a sudden 1221 renumbering event which, unlike the process described in [RFC4192], 1222 would be without a "flag day". The customer may of course also 1223 choose to move to a new ISP, and thus begin using a new prefix. Thus 1224 it's desirable that homenet protocols or operational processes don't 1225 add unnecessary complexity for renumbering. 1227 The 6renum WG is studying IPv6 renumbering for enterprise networks. 1228 It is not currently targetting homenets, but may produce outputs that 1229 are relevant. 1231 3.5. Summary of Homenet Architecture Recommendations 1233 Feedback sought on whether a summary section would be useful. 1235 3.6. Implementing the Architecture on IPv6 1237 The necessary mechanisms are largely already part of the IPv6 1238 protocol set and common implementations, though there are some 1239 exceptions. For automatic routing, it is expected that existing 1240 routing protocols can be used as is. However, a new mechanism may be 1241 needed in order to turn a selected protocol on by default. Support 1242 for multiple exit routers and multi-homing would also require 1243 extensions, even if focused on the problem of multi-addressed hosts 1244 selecting the right source address to avoid falling foul of ingress 1245 filtering on upstream ISP connections. 1247 For name resolution and service discovery, extensions to existing 1248 multicast-based name resolution protocols are needed to enable them 1249 to work across subnets, within the scope of the home network. 1251 The hardest problems in developing solutions for home networking IPv6 1252 architectures include discovering the right borders where the domain 1253 "home" ends and the service provider domain begins, deciding whether 1254 some of necessary discovery mechanism extensions should affect only 1255 the network infrastructure or also hosts, and the ability to turn on 1256 routing, prefix delegation and other functions in a backwards 1257 compatible manner. 1259 4. References 1261 4.1. Normative References 1263 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1264 E. Lear, "Address Allocation for Private Internets", 1265 BCP 5, RFC 1918, February 1996. 1267 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1268 (IPv6) Specification", RFC 2460, December 1998. 1270 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1271 and W. Weiss, "An Architecture for Differentiated 1272 Services", RFC 2475, December 1998. 1274 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1275 and M. Carney, "Dynamic Host Configuration Protocol for 1276 IPv6 (DHCPv6)", RFC 3315, July 2003. 1278 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1279 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1280 December 2003. 1282 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1283 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1284 September 2005. 1286 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1287 Addresses", RFC 4193, October 2005. 1289 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1290 Architecture", RFC 4291, February 2006. 1292 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1293 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1294 May 2007. 1296 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1297 Shim Protocol for IPv6", RFC 5533, June 2009. 1299 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1300 Infrastructures (6rd) -- Protocol Specification", 1301 RFC 5969, August 2010. 1303 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1304 Customer Premises Equipment (CPE) for Providing 1305 Residential IPv6 Internet Service", RFC 6092, 1306 January 2011. 1308 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1309 Troan, "Basic Requirements for IPv6 Customer Edge 1310 Routers", RFC 6204, April 2011. 1312 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1313 Translation", RFC 6296, June 2011. 1315 4.2. Informative References 1317 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1318 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1319 December 2003. 1321 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1322 (DHCP) Service for IPv6", RFC 3736, April 2004. 1324 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1325 "IPv6 Router Advertisement Options for DNS Configuration", 1326 RFC 6106, November 2010. 1328 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1329 IPv4/IPv6 Translation", RFC 6144, April 2011. 1331 [I-D.baker-fun-multi-router] 1332 Baker, F., "Exploring the multi-router SOHO network", 1333 draft-baker-fun-multi-router-00 (work in progress), 1334 July 2011. 1336 [I-D.townsley-troan-ipv6-ce-transitioning] 1337 Townsley, M. and O. Troan, "Basic Requirements for 1338 Customer Edge Routers - multihoming and transition", 1339 draft-townsley-troan-ipv6-ce-transitioning-02 (work in 1340 progress), December 2011. 1342 [I-D.baker-fun-routing-class] 1343 Baker, F., "Routing a Traffic Class", 1344 draft-baker-fun-routing-class-00 (work in progress), 1345 July 2011. 1347 [I-D.howard-homenet-routing-comparison] 1348 Howard, L., "Evaluation of Proposed Homenet Routing 1349 Solutions", draft-howard-homenet-routing-comparison-00 1350 (work in progress), December 2011. 1352 [I-D.howard-homenet-routing-requirements] 1353 Howard, L., "Homenet Routing Requirements", 1354 draft-howard-homenet-routing-requirements-00 (work in 1355 progress), December 2011. 1357 [I-D.herbst-v6ops-cpeenhancements] 1358 Herbst, T. and D. Sturek, "CPE Considerations in IPv6 1359 Deployments", draft-herbst-v6ops-cpeenhancements-00 (work 1360 in progress), October 2010. 1362 [I-D.vyncke-advanced-ipv6-security] 1363 Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced 1364 Security for IPv6 CPE", 1365 draft-vyncke-advanced-ipv6-security-03 (work in progress), 1366 October 2011. 1368 [I-D.ietf-v6ops-ipv6-cpe-router-bis] 1369 Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1371 Troan, "Advanced Requirements for IPv6 Customer Edge 1372 Routers", draft-ietf-v6ops-ipv6-cpe-router-bis-01 (work in 1373 progress), July 2011. 1375 [I-D.ietf-6man-rfc3484-revise] 1376 Matsumoto, A., Kato, J., Fujisaki, T., and T. Chown, 1377 "Update to RFC 3484 Default Address Selection for IPv6", 1378 draft-ietf-6man-rfc3484-revise-05 (work in progress), 1379 October 2011. 1381 [I-D.ietf-dhc-pd-exclude] 1382 Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1383 "Prefix Exclude Option for DHCPv6-based Prefix 1384 Delegation", draft-ietf-dhc-pd-exclude-04 (work in 1385 progress), December 2011. 1387 [I-D.v6ops-multihoming-without-ipv6nat] 1388 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 1389 Wing, "IPv6 Multihoming without Network Address 1390 Translation", draft-v6ops-multihoming-without-ipv6nat-00 1391 (work in progress), March 2011. 1393 [I-D.baker-homenet-prefix-assignment] 1394 Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small 1395 Networks", draft-baker-homenet-prefix-assignment-00 (work 1396 in progress), October 2011. 1398 [I-D.arkko-homenet-prefix-assignment] 1399 Arkko, J. and A. Lindem, "Prefix Assignment in a Home 1400 Network", draft-arkko-homenet-prefix-assignment-01 (work 1401 in progress), October 2011. 1403 [I-D.acee-ospf-ospfv3-autoconfig] 1404 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 1405 draft-acee-ospf-ospfv3-autoconfig-00 (work in progress), 1406 October 2011. 1408 [I-D.ietf-pcp-base] 1409 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1410 Selkirk, "Port Control Protocol (PCP)", 1411 draft-ietf-pcp-base-22 (work in progress), January 2012. 1413 [I-D.chakrabarti-homenet-prefix-alloc] 1414 Nordmark, E., Chakrabarti, S., Krishnan, S., and W. 1415 Haddad, "Simple Approach to Prefix Distribution in Basic 1416 Home Networks", draft-chakrabarti-homenet-prefix-alloc-01 1417 (work in progress), October 2011. 1419 [Gettys11] 1420 Gettys, J., "Bufferbloat: Dark Buffers in the Internet", 1421 March 2011, 1422 . 1424 Appendix A. Acknowledgments 1426 The authors would like to thank Brian Carpenter, Mark Andrews, Fred 1427 Baker, Ray Bellis, Cameron Byrne, Stuart Cheshire, Lorenzo Colitti, 1428 Ralph Droms, Lars Eggert, Jim Gettys, Wassim Haddad, Joel M. Halpern, 1429 David Harrington, Lee Howard, Ray Hunter, Joel Jaeggli, Heather 1430 Kirksey, Ted Lemon, Erik Nordmark, Michael Richardson, Barbara Stark, 1431 Sander Steffann, Dave Thaler, JP Vasseur, Curtis Villamizar, Russ 1432 White, and James Woodyatt for their contributions within homenet WG 1433 meetings and the mailing list, and Mark Townsley for being an initial 1434 editor/author of this text before taking his position as homenet WG 1435 co-chair. 1437 Authors' Addresses 1439 Jari Arkko 1440 Ericsson 1441 Jorvas 02420 1442 Finland 1444 Email: jari.arkko@piuha.net 1446 Anders Brandt 1447 Sigma Designs 1448 Emdrupvej 26A, 1 1449 Copenhagen DK-2100 1450 Denmark 1452 Email: abr@sdesigns.dk 1454 Tim Chown 1455 University of Southampton 1456 Highfield 1457 Southampton, Hampshire SO17 1BJ 1458 United Kingdom 1460 Email: tjc@ecs.soton.ac.uk 1461 Jason Weil 1462 Time Warner Cable 1463 13820 Sunrise Valley Drive 1464 Herndon, VA 20171 1465 USA 1467 Email: jason.weil@twcable.com 1469 Ole Troan 1470 Cisco Systems, Inc. 1471 Drammensveien 145A 1472 Oslo N-0212 1473 Norway 1475 Email: ot@cisco.com