idnits 2.17.00 (12 Aug 2021) /tmp/idnits48405/draft-ietf-homenet-arch-06.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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 3498 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 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) == Outdated reference: A later version (-04) exists of draft-mglt-homenet-front-end-naming-delegation-00 == Outdated reference: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat has been published as RFC 7157 == Outdated reference: A later version (-04) exists of draft-arkko-homenet-prefix-assignment-02 == Outdated reference: draft-ietf-pcp-base has been published as RFC 6887 == Outdated reference: A later version (-01) exists of draft-kline-default-perimeter-00 == Outdated reference: draft-ietf-v6ops-6204bis has been published as RFC 7084 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Chown, Ed. 3 Internet-Draft University of Southampton 4 Intended status: Informational J. Arkko 5 Expires: April 25, 2013 Ericsson 6 A. Brandt 7 Sigma Designs 8 O. Troan 9 Cisco Systems, Inc. 10 J. Weil 11 Time Warner Cable 12 October 22, 2012 14 Home Networking Architecture for IPv6 15 draft-ietf-homenet-arch-06 17 Abstract 19 This text describes evolving networking technology within 20 increasingly large residential home networks. The goal of this 21 document is to define an architecture for IPv6-based home networking, 22 while describing the associated principles, considerations and 23 requirements. The text briefly highlights the specific implications 24 of the introduction of IPv6 for home networking, discusses the 25 elements of the architecture, and suggests how standard IPv6 26 mechanisms and addressing can be employed in home networking. The 27 architecture describes the need for specific protocol extensions for 28 certain additional functionality. It is assumed that the IPv6 home 29 network is not actively managed, and runs as an IPv6-only or dual- 30 stack network. There are no recommendations in this text for the 31 IPv4 part of the network. 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 April 25, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 5 69 2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . . 6 70 2.1. Multiple subnets and routers . . . . . . . . . . . . . . . 6 71 2.2. Global addressability and elimination of NAT . . . . . . . 7 72 2.3. Multi-Addressing of devices . . . . . . . . . . . . . . . 8 73 2.4. Unique Local Addresses (ULAs) . . . . . . . . . . . . . . 8 74 2.5. Naming, and manual configuration of IP addresses . . . . . 9 75 2.6. IPv6-only operation . . . . . . . . . . . . . . . . . . . 9 76 3. Homenet Architecture . . . . . . . . . . . . . . . . . . . . . 10 77 3.1. General Principles . . . . . . . . . . . . . . . . . . . . 11 78 3.1.1. Reuse existing protocols . . . . . . . . . . . . . . . 11 79 3.1.2. Minimise changes to hosts and routers . . . . . . . . 11 80 3.2. Homenet Topology . . . . . . . . . . . . . . . . . . . . . 11 81 3.2.1. Supporting arbitrary topologies . . . . . . . . . . . 11 82 3.2.2. Network topology models . . . . . . . . . . . . . . . 12 83 3.2.3. Dual-stack topologies . . . . . . . . . . . . . . . . 16 84 3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 17 85 3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 18 86 3.3.1. Homenet realms and borders . . . . . . . . . . . . . . 19 87 3.3.2. Largest practical subnets . . . . . . . . . . . . . . 20 88 3.3.3. Handling multiple homenets . . . . . . . . . . . . . . 20 89 3.3.4. Coordination of configuration information . . . . . . 20 90 3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . . 21 91 3.4.1. Use of ISP-delegated IPv6 prefixes . . . . . . . . . . 21 92 3.4.2. Stable internal IP addresses . . . . . . . . . . . . . 22 93 3.4.3. Internal prefix delegation . . . . . . . . . . . . . . 23 94 3.4.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . 24 95 3.5. Routing functionality . . . . . . . . . . . . . . . . . . 25 96 3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 26 98 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 3.6.1. Addressability vs reachability . . . . . . . . . . . . 27 100 3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 28 101 3.6.3. Marginal Effectiveness of NAT and Firewalls . . . . . 28 102 3.6.4. Device capabilities . . . . . . . . . . . . . . . . . 29 103 3.6.5. ULAs as a hint of connection origin . . . . . . . . . 29 104 3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 29 105 3.7.1. Discovering services . . . . . . . . . . . . . . . . . 29 106 3.7.2. Assigning names to devices . . . . . . . . . . . . . . 30 107 3.7.3. Name spaces . . . . . . . . . . . . . . . . . . . . . 30 108 3.7.4. The homenet name service . . . . . . . . . . . . . . . 32 109 3.7.5. Independent operation . . . . . . . . . . . . . . . . 33 110 3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 33 111 3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 34 112 3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 34 113 3.8.1. Proxy or Extend? . . . . . . . . . . . . . . . . . . . 34 114 3.8.2. Quality of Service . . . . . . . . . . . . . . . . . . 35 115 3.8.3. Operations and Management . . . . . . . . . . . . . . 35 116 3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 35 117 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 36 118 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 119 5.1. Normative References . . . . . . . . . . . . . . . . . . . 36 120 5.2. Informative References . . . . . . . . . . . . . . . . . . 37 121 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 40 122 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 40 123 B.1. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 41 124 B.2. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 41 125 B.3. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 41 126 B.4. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 41 127 B.5. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 43 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 130 1. Introduction 132 This document focuses on evolving networking technology within 133 increasingly large residential home networks and the associated 134 challenges with their deployment and operation. There is a growing 135 trend in home networking for the proliferation of networking 136 technology in an increasingly broad range of devices and media. This 137 evolution in scale and diversity sets requirements on IETF protocols. 138 Some of these requirements relate to the introduction of IPv6, others 139 to the introduction of specialised networks for home automation and 140 sensors. 142 While at the time of writing some complex home network topologies 143 exist, most operate based on IPv4, employ solutions that we would 144 like to avoid such as (cascaded) network address translation (NAT), 145 or require expert assistance to set up. In IPv6 home networks, there 146 are likely to be scenarios where internal routing is required, for 147 example to support private and guest networks, in which case such 148 networks may use increasing numbers of subnets, and require methods 149 for IPv6 prefixes to be delegated to those subnets. The assumption 150 of this document is that the homenet is as far as possible self- 151 organising and self-configuring, and thus need not be pro-actively 152 managed by the residential user. 154 The architectural constructs in this document are focused on the 155 problems to be solved when introducing IPv6 with an eye towards a 156 better result than what we have today with IPv4, as well as a better 157 result than if the IETF had not given this specific guidance. The 158 document aims to provide the basis and guiding principles for how 159 standard IPv6 mechanisms and addressing [RFC2460] [RFC4291] can be 160 employed in home networking, while coexisting with existing IPv4 161 mechanisms. In emerging dual-stack home networks it is vital that 162 introducing IPv6 does not adversely affect IPv4 operation. We assume 163 that the IPv4 network architecture in home networks is what it is, 164 and can not be affected by new recommendations. It should not be 165 assumed that any future new functionality created with IPv6 in mind 166 will be backward-compatible to include IPv4 support. Further, future 167 deployments, or specific subnets within an otherwise dual-stack home 168 network, may be IPv6-only, in which case considerations for IPv4 169 impact would not apply. 171 This architecture document proposes a baseline homenet architecture, 172 based on protocols and implementations that are as far as possible 173 proven and robust. The scope of the document is primarily the 174 network layer technologies that provide the basic functionality to 175 enable addressing, connectivity, routing, naming and service 176 discovery. While it may, for example, state that homenet components 177 must be simple to deploy and use, it does not discuss specific user 178 interfaces, nor does it discuss specific physical, wireless or data- 179 link layer considerations. 181 [RFC6204] defines basic requirements for customer edge routers 182 (CERs). The scope of this text is the internal homenet, and thus 183 specific features on the CER are out of scope for this text. While 184 the network may be dual-stack or IPv6-only, the definition of 185 specific transition tools on the CER, as introduced in RFC 6204-bis 186 [I-D.ietf-v6ops-6204bis] with DS-Lite [RFC6333] and 6rd [RFC5969], 187 are considered issues for that RFC, and are thus also out of scope of 188 this text. 190 1.1. Terminology and Abbreviations 192 In this section we define terminology and abbreviations used 193 throughout the text. 195 o "Advanced Security". Describes advanced security functions for a 196 CER, as defined in [I-D.vyncke-advanced-ipv6-security], where the 197 default inbound connection policy is generally "default allow". 199 o ALQDN: Ambiguous Locally Qualified Domain Name. An example would 200 be .sitelocal. 202 o CER: Customer Edge Router. A border router at the edge of the 203 homenet. 205 o FQDN: Fully Qualified Domain Name. A globally unique name space. 207 o LLN: Low-power and lossy network. 209 o LQDN: Locally Qualified Domain Name. A name space local to the 210 homenet. 212 o NAT: Network Address Translation. Typically referring to IPv4 213 Network Address and Port Translation (NAPT) [RFC3022]. 215 o NPTv6: Network Prefix Translation for IPv6 [RFC6296]. 217 o PCP: Port Control Protocol [I-D.ietf-pcp-base]. 219 o "Simple Security". Defined in [RFC4864] and expanded further in 220 [RFC6092]; describes recommended perimeter security capabilities 221 for IPv6 networks. 223 o ULA: IPv6 Unique Local Addresses [RFC4193]. 225 o ULQDN: Unique Locally Qualified Domain Name. An example might be 226 ..sitelocal. 228 o UPnP: Universal Plug and Play. Includes the Internet Gateway 229 Device (IGD) function, which for IPv6 is UPnP IGD Version 2 230 [IGD-2]. 232 o VM: Virtual machine. 234 o WPA2: Wi-Fi Protected Access, as defined by the Wi-Fi Alliance. 236 2. Effects of IPv6 on Home Networking 238 While IPv6 resembles IPv4 in many ways, it changes address allocation 239 principles, making multi-addressing the norm, and allowing direct IP 240 addressability of home networking devices from the Internet. This 241 section presents an overview of some of the key implications of the 242 introduction of IPv6 for home networking, that are simultaneously 243 both promising and problematic. 245 2.1. Multiple subnets and routers 247 The introduction of IPv6 for home networking enables the potential 248 for every home network to be delegated enough address space to 249 provision globally unique prefixes for each subnet in the home. Such 250 subnetting is not common practice in existing IPv4 homenets, but is 251 very likely to become increasingly standard in future IPv6 homenets. 253 While simple layer 3 topologies involving as few subnets as possible 254 are preferred in home networks, the incorporation of dedicated 255 (routed) subnets remains necessary for a variety of reasons. For 256 instance, an increasingly common feature in modern home routers is 257 the ability to support both guest and private network subnets. 258 Likewise, there may be a need to separate building control or 259 corporate extensions from the main Internet access network, or 260 different subnets may in general be associated with parts of the 261 homenet that have different routing and security policies. Further, 262 link layer networking technology is poised to become more 263 heterogeneous, as networks begin to employ both traditional Ethernet 264 technology and link layers designed for low-power and lossy networks 265 (LLNs), such as those used for certain types of sensor devices. 266 Constraining the flow of certain traffic from Ethernet links to much 267 lower capacity links thus becomes an important topic. 269 The addition of routing between subnets raises the issue of how to 270 extend mechanisms such as service discovery which currently rely on 271 link-local addressing to limit scope. There are two broad choices; 272 extend existing protocols to work across the scope of the homenet, or 273 introduce proxies for existing link layer protocols. This topic is 274 discussed later in the document. It may also be more appropriate to 275 use a different protocol instead, in which case it should preferably 276 be a proven, existing protocol. 278 There will also be the need to discover which routers in the homenet 279 are the border router(s) by an appropriate mechanism. Here, there 280 are a number of choices, including the use of an appropriate service 281 discovery protocol. Whatever method is chosen would likely have to 282 deal with handling more than one router responding in multihomed 283 environments. 285 2.2. Global addressability and elimination of NAT 287 Current IPv4 home networks typically receive a single global IPv4 288 address from their ISP and use NAT with private [RFC1918] addresses 289 for devices within the network. An IPv6 home network removes the 290 need to use NAT given the ISP offers a sufficiently large globally 291 unique IPv6 prefix to the homenet, allowing every device on every 292 subnet to be assigned a globally unique IPv6 address. 294 The end-to-end communication that is potentially enabled with IPv6 is 295 on the one hand an incredible opportunity for innovation and simpler 296 network operation, but it is also a concern as it exposes nodes in 297 the internal networks to receipt of otherwise unwanted traffic from 298 the Internet. While devices and applications can potentially talk 299 directly to each other when all devices have globally unique 300 addresses, there may be an expectation of improved host security to 301 compensate for this. It should be noted that many devices may (for 302 example) ship with default settings that make them readily vulnerable 303 to compromise by external attackers if globally accessible, or may 304 simply not have robustness designed-in because it was either assumed 305 such devices would only be used on private networks or the device 306 itself doesn't have the computing power to apply the necessary 307 security methods. 309 IPv6 networks may or may not have filters applied at their borders, 310 i.e. at the homenet CER. [RFC4864], [RFC6092] and 311 [I-D.vyncke-advanced-ipv6-security] discuss such filtering, and the 312 merits of "default allow" against "default deny" policies for 313 external traffic initiated into a homenet. It is important to 314 distinguish between addressability and reachability. While IPv6 315 offers global addressability through use of globally unique addresses 316 in the home, whether they are globally reachable or not would depend 317 on the firewall or filtering configuration, and not, as is commonly 318 the case with IPv4, the presence or use of NAT. 320 2.3. Multi-Addressing of devices 322 In an IPv6 network, devices may acquire multiple addresses, typically 323 at least a link-local address and one or more globally unique 324 addresses. They may also have an IPv4 address if the network is 325 dual-stack, a Unique Local Address (ULA) [RFC4193] (see below), and 326 one or more IPv6 Privacy Addresses [RFC4941]. 328 Thus it should be considered the norm for devices on IPv6 home 329 networks to be multi-addressed, and to need to make appropriate 330 address selection decisions for the candidate source and destination 331 address pairs. Default Address Selection for IPv6 [RFC6724] provides 332 a solution for this, though it may face problems in the event of 333 multihoming, where nodes will be configured with one address from 334 each upstream ISP prefix. In such cases the presence of upstream 335 ingress filtering requires multi-addressed nodes to select the 336 correct source address to be used for the corresponding uplink, to 337 avoid ISP BCP 38 ingress filtering, but the node may not have the 338 information it needs to make that decision based on addresses alone. 339 We discuss such challenges in the multihoming section later in this 340 document. 342 2.4. Unique Local Addresses (ULAs) 344 [RFC4193] defines Unique Local Addresses (ULAs) for IPv6 that may be 345 used to address devices within the scope of a single site. Support 346 for ULAs for IPv6 CERs is described in [RFC6204]. A home network 347 running IPv6 may deploy ULAs for stable communication between devices 348 (on different subnets) within the network where the externally 349 allocated global prefix changes over time (e.g. due to renumbering 350 within the subscriber's ISP) or where external connectivity is 351 temporarily unavailable. In the case where multiple routers exist in 352 the homenet, a mechanism for the creation of a single overlapping /48 353 ULA prefix is desirable for addressing consistency and policy 354 enforcement. 356 A counter-argument to using ULAs is that it is undesirable to 357 aggressively deprecate global prefixes for temporary loss of 358 connectivity, so for a host to lose its global address there would 359 have to be a connection breakage longer than the lease period, and 360 even then, deprecating prefixes when there is no connectivity may not 361 be advisable. It should also be noted that there may be timers on 362 the prefix lease to the homenet, on the internal prefix delegations, 363 and on the Router Advertisements to the hosts. Despite this counter- 364 argument, while setting a network up there may be a period with no 365 connectivity, in which case ULAs would be required for inter-subnet 366 communication. In the case where LLNs are being set up in a new 367 home/deployment, individual LLNs may, at least initially, each use 368 their own /48 ULA prefix. 370 Default address selection mechanisms should ensure a ULA source 371 address is used to communicate with ULA destination addresses when 372 appropriate, in particular when the ULA destination lies within a /48 373 ULA prefix known to be used within the same homenet. Note that 374 unlike the IPv4 private RFC 1918 space, the use of ULAs does not 375 imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT 376 [RFC6296], rather that external communications should use a node's 377 additional globally unique IPv6 source address. 379 2.5. Naming, and manual configuration of IP addresses 381 Some IPv4 home networking devices expose IPv4 addresses to users, 382 e.g. the IPv4 address of a home IPv4 CER that may be configured via a 383 web interface. Users should not be expected to enter IPv6 literal 384 addresses in homenet devices or applications, given their much 385 greater length and apparent randomness to a typical home user. While 386 shorter addresses, perhaps ones registered with IANA from ULA-C space 387 [I-D.hain-ipv6-ulac], could be used for specific devices/services, in 388 general it is better not to expose users to real IPv6 addresses. 389 Thus, even for the simplest of functions, simple naming and the 390 associated (minimal, and ideally zero configuration) discovery of 391 services is imperative for the easy deployment and use of homenet 392 devices and applications. 394 In a multi-subnet homenet, naming and service discovery should be 395 expected to be capable of operating across the scope of the entire 396 home network, and thus be able to cross subnet boundaries. It should 397 be noted that in IPv4, such services do not generally function across 398 home router NAT boundaries, so this is one area where there is room 399 for improvement in IPv6. 401 2.6. IPv6-only operation 403 It is likely that IPv6-only networking will be deployed first in 404 "greenfield" homenet scenarios, or perhaps as one element of an 405 otherwise dual-stack network. Running IPv6-only adds additional 406 requirements, e.g. for devices to get configuration information via 407 IPv6 transport (not relying on an IPv4 protocol such as IPv4 DHCP), 408 and for devices to be able to initiate communications to external 409 devices that are IPv4-only. Thus, for example, the following 410 requirements are amongst those that should be considered in IPv6-only 411 environments: 413 o Ensuring there is a way to access content in the IPv4 Internet. 414 This can be arranged through appropriate use of NAT64 [RFC6144] 415 and DNS64 [RFC6145], for example, or via a node-based DS-Lite 417 [RFC6333] approach. 419 o DNS discovery mechanisms are enabled for IPv6. Both stateless 420 DHCPv6 [RFC3736] [RFC3646] and Router Advertisement options 421 [RFC6106] may have to be supported and turned on by default to 422 ensure maximum compatibility with all types of hosts in the 423 network. This requires, however, that a working DNS server is 424 known and addressable via IPv6, and that the automatic discovery 425 of such a server is possible through multiple routers in the 426 homenet. 428 o All nodes in the home network support operations in IPv6-only 429 mode. Some current devices work well with dual-stack but fail to 430 recognise connectivity when IPv4 DHCP fails, for instance. 432 The widespread availability of robust solutions to these types of 433 requirements will help accelerate the uptake of IPv6-only homenets. 434 The specifics of these are however beyond the scope of this document, 435 especially those functions that reside on the CER. 437 3. Homenet Architecture 439 The aim of this architecture text is to outline how to construct 440 advanced IPv6-based home networks involving multiple routers and 441 subnets using standard IPv6 protocols and addressing [RFC2460] 442 [RFC4291]. In this section, we present the elements of such a home 443 networking architecture, with discussion of the associated design 444 principles. 446 Existing IETF work [RFC6204] defines the "basic" requirements for 447 Customer Edge Routers, while [I-D.ietf-v6ops-6204bis] extends RFC 448 6204 to describe additional features. The homenet architecture is 449 focused on the internal homenet, rather than the CER(s). In general, 450 home network equipment needs to be able to operate in networks with a 451 range of different properties and topologies, where home users may 452 plug components together in arbitrary ways and expect the resulting 453 network to operate. Significant manual configuration is rarely, if 454 at all, possible, given the knowledge level of typical home users. 455 Thus the network should, as far as possible, be self-configuring. 457 The equipment also needs to be prepared to handle at least 459 o Routing 461 o Prefix configuration for routers 462 o Name resolution 464 o Service discovery 466 o Network security 468 The remainder of this document describes the principles by which a 469 homenet architecture may deliver these properties. 471 3.1. General Principles 473 There is little that the Internet standards community can do about 474 the physical topologies or the need for some networks to be separated 475 at the network layer for policy or link layer compatibility reasons. 476 However, there is a lot of flexibility in using IP addressing and 477 inter-networking mechanisms. This architecture text discusses how 478 this flexibility should be used to provide the best user experience 479 and ensure that the network can evolve with new applications in the 480 future. The principles described in this text should be followed 481 when designing homenet solutions. 483 3.1.1. Reuse existing protocols 485 It is desirable to reuse existing protocols where possible, but at 486 the same time to avoid consciously precluding the introduction of new 487 or emerging protocols. A generally conservative approach, giving 488 weight to running code, is preferable. Where new protocols are 489 required, evidence of commitment to implementation by appropriate 490 vendors or development communities is highly desirable. Protocols 491 used should be backwardly compatible, and forward compatible where 492 changes are made. 494 3.1.2. Minimise changes to hosts and routers 496 Where possible, any requirement for changes to hosts and routers 497 should be minimised, though solutions which, for example, 498 incrementally improve with host or router changes may be acceptable. 500 3.2. Homenet Topology 502 This section considers homenet topologies, and the principles that 503 may be applied in designing an architecture to support as wide a 504 range as possible of such topologies. 506 3.2.1. Supporting arbitrary topologies 508 There should ideally be no built-in assumptions about the topology in 509 home networks, as users are capable of connecting their devices in 510 "ingenious" ways. Thus arbitrary topologies and arbitrary routing 511 will need to be supported, or at least the failure mode for when the 512 user makes a mistake should be as robust as possible, e.g. de- 513 activating a certain part of the infrastructure to allow the rest to 514 operate. In such cases, the user should ideally have some useful 515 indication of the failure mode encountered. 517 There are no topology scenarios which could cause loss of 518 connectivity, except when the user creates a physical island within 519 the topology. Some potentially pathological cases that can be 520 created include bridging ports of a router together, however this 521 case can be detected and dealt with by the router. Loops within a 522 routed topology are in a sense good in that they offer redundancy. 523 Bridging loops can be dangerous but are also detectable when a switch 524 learns the MAC of one of its interfaces on another or runs a spanning 525 tree or link state protocol. It is only loops using simple repeaters 526 that are truly pathological. 528 3.2.2. Network topology models 530 Most IPv4 home network models at the time of writing tend to be 531 relatively simple, typically a single NAT router to the ISP and a 532 single internal subnet but, as discussed earlier, evolution in 533 network architectures is driving more complex topologies, such as the 534 separation of guest and private networks. There may also be some 535 cascaded IPv4 NAT scenarios, which we mention in the next section. 537 In general, the models described in [RFC6204] and its successor RFC 538 6204-bis [I-D.ietf-v6ops-6204bis] should be supported by the IPv6 539 home networking architecture. The functions resident on the CER 540 itself are, as stated previously, out of scope of this text. 542 There are a number of properties or attributes of a home network that 543 we can use to describe its topology and operation. The following 544 properties apply to any IPv6 home network: 546 o Presence of internal routers. The homenet may have one or more 547 internal routers, or may only provide subnetting from interfaces 548 on the CER. 550 o Presence of isolated internal subnets. There may be isolated 551 internal subnets, with no direct connectivity between them within 552 the homenet. Isolation may be physical, or implemented via IEEE 553 802.1q VLANs. The latter is however not something a typical user 554 would be expected to configure. 556 o Demarcation of the CER. The CER(s) may or may not be managed by 557 the ISP. If the demarcation point is such that the customer can 558 provide or manage the CER, its configuration must be simple. Both 559 models must be supported. 561 Various forms of multihoming are likely to be more prevalent with 562 IPv6 home networks, as discussed further below. Thus the following 563 properties should also be considered for such networks: 565 o Number of upstream providers. The majority of home networks today 566 consist of a single upstream ISP, but it may become more common in 567 the future for there to be multiple ISPs, whether for resilience 568 or provision of additional services. Each would offer its own 569 prefix. Some may or may not provide a default route to the public 570 Internet. 572 o Number of CERs. The homenet may have a single CER, which might be 573 used for one or more providers, or multiple CERs. The presence of 574 multiple CERs adds additional complexity for multihoming 575 scenarios, and protocols like PCP that need to manage connection- 576 oriented state mappings. 578 In the following sections we give some examples of the types of 579 homenet topologies we may see in the future. This is not intended to 580 be an exhaustive or complete list, rather an indicative one to 581 facilitate the discussion in this text. 583 3.2.2.1. A: Single ISP, Single CER, Internal routers 585 Figure 1 shows a network with multiple local area networks. These 586 may be needed for reasons relating to different link layer 587 technologies in use or for policy reasons, e.g. classic Ethernet in 588 one subnet and a LLN link layer technology in another. In this 589 example there is no single router that a priori understands the 590 entire topology. The topology itself may also be complex, and it may 591 not be possible to assume a pure tree form, for instance (home users 592 may plug routers together to form arbitrary topologies including 593 loops). 595 +-------+-------+ \ 596 | Service | \ 597 | Provider | | Service 598 | Router | | Provider 599 +-------+-------+ | network 600 | / 601 | Customer / 602 | Internet connection 603 | 604 +------+--------+ \ 605 | IPv6 | \ 606 | Customer Edge | \ 607 | Router | | 608 +----+-+---+----+ | 609 Network A | | | Network B(E) | 610 ----+-------------+----+ | +---+-------------+------+ | 611 | | | | | | | 612 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | | 613 |IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | | 614 | H1 | | H2 | | | H3 | | H4 | | | 615 +----------+ +----------+ | +----------+ +----------+ | | 616 | | | | | 617 Link F | ---+------+------+-----+ | 618 | | Network E(B) | 619 +------+--------+ | | End-User 620 | IPv6 | | | networks 621 | Interior +------+ | 622 | Router | | 623 +---+-------+-+-+ | 624 Network C | | Network D | 625 ----+-------------+---+ +---+-------------+--- | 626 | | | | | 627 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 628 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 629 | H5 | | H6 | | H7 | | H8 | / 630 +----------+ +----------+ +----------+ +----------+ / 632 Figure 1 634 In this diagram there is one CER. It has a single uplink interface. 635 It has three additional interfaces connected to Network A, Link F, 636 and Network B. IPv6 Internal Router (IR) has four interfaces 637 connected to Link F, Network C, Network D and Network E. Network B 638 and Network E have been bridged, likely inadvertently. This could be 639 as a result of connecting a wire between a switch for Network B and a 640 switch for Network E. 642 Any of logical Networks A through F might be wired or wireless. 644 Where multiple hosts are shown, this might be through one or more 645 physical ports on the CER or IPv6 (IR), wireless networks, or through 646 one or more layer-2 only Ethernet switches. 648 3.2.2.2. B: Two ISPs, Two CERs, Shared subnet 650 +-------+-------+ +-------+-------+ \ 651 | Service | | Service | \ 652 | Provider A | | Provider B | | Service 653 | Router | | Router | | Provider 654 +------+--------+ +-------+-------+ | network 655 | | / 656 | Customer | / 657 | Internet connections | / 658 | | 659 +------+--------+ +-------+-------+ \ 660 | IPv6 | | IPv6 | \ 661 | Customer Edge | | Customer Edge | \ 662 | Router 1 | | Router 2 | / 663 +------+--------+ +-------+-------+ / 664 | | / 665 | | | End-User 666 ---+---------+---+---------------+--+----------+--- | network(s) 667 | | | | \ 668 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 669 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 670 | H1 | | H2 | | H3 | | H4 | / 671 +----------+ +----------+ +----------+ +----------+ 673 Figure 2 675 Figure 2 illustrates a multihomed homenet model, where the customer 676 has connectivity via CER1 to ISP A and via CER2 to ISP B. This 677 example shows one shared subnet where IPv6 nodes would potentially be 678 multihomed and receive multiple IPv6 global addresses, one per ISP. 679 This model may also be combined with that shown in Figure 1 to create 680 a more complex scenario with multiple internal routers. Or the above 681 shared subnet may be split in two, such that each CER serves a 682 separate isolated subnet, which is a scenario seen with some IPv4 683 networks today. 685 3.2.2.3. C: Two ISPs, One CER, Shared subnet 687 +-------+-------+ +-------+-------+ \ 688 | Service | | Service | \ 689 | Provider A | | Provider B | | Service 690 | Router | | Router | | Provider 691 +-------+-------+ +-------+-------+ | network 692 | | / 693 | Customer | / 694 | Internet | / 695 | connections | | 696 +---------+---------+ \ 697 | IPv6 | \ 698 | Customer Edge | \ 699 | Router | / 700 +---------+---------+ / 701 | / 702 | | End-User 703 ---+------------+-------+--------+-------------+--- | network(s) 704 | | | | \ 705 +----+-----+ +----+-----+ +----+-----+ +-----+----+ \ 706 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 707 | H1 | | H2 | | H3 | | H4 | / 708 +----------+ +----------+ +----------+ +----------+ 710 Figure 3 712 Figure 3 illustrates a model where a home network may have multiple 713 connections to multiple providers or multiple logical connections to 714 the same provider, with shared internal subnets. 716 In general, while the architecture may focus on likely common 717 topologies, it should not preclude any arbitrary topology from being 718 constructed. 720 3.2.3. Dual-stack topologies 722 It is expected that most homenet deployments will for the immediate 723 future be dual-stack IPv4/IPv6. In such networks it is important not 724 to introduce new IPv6 capabilities that would cause a failure if used 725 alongside IPv4+NAT, given that such dual-stack homenets will be 726 commonplace for some time. That said, it is desirable that IPv6 727 works better than IPv4 in as many scenarios as possible. Further, 728 the homenet architecture must operate in the absence of IPv4. 730 A general recommendation is to follow the same topology for IPv6 as 731 is used for IPv4, but not to use NAT. Thus there should be routed 732 IPv6 where an IPv4 NAT is used, and where there is no NAT routing or 733 bridging may be used. Routing may have advantages when compared to 734 bridging together high speed and lower speed shared media, and in 735 addition bridging may not be suitable for some media, such as ad-hoc 736 mobile networks. 738 In some cases IPv4 NAT home networks may feature cascaded NATs, which 739 may include cases where NAT routers are included within VMs, or where 740 Internet connection sharing services are used. IPv6 routed versions 741 of such cases will be required. We should thus note that routers in 742 the homenet may not be separate physical devices; they may be 743 embedded within other devices. 745 3.2.4. Multihoming 747 A homenet may be multihomed to multiple providers, as the network 748 models above illustrate. This may either take a form where there are 749 multiple isolated networks within the home or a more integrated 750 network where the connectivity selection needs to be dynamic. 751 Current practice is typically of the former kind, but the latter is 752 expected to become more commonplace. 754 The general multihoming problem is broad, and solutions suggested to 755 date within the IETF may include complex architectures for monitoring 756 connectivity, traffic engineering, identifier-locator separation, 757 connection survivability across multihoming events, and so on. It is 758 thus important that the homenet architecture should as far as 759 possible minimise the complexity of any multihoming support. So we 760 should limit the support to the smallest subset of the overall 761 problem to meet the requirements of the topologies described above. 762 This means that the homenet architecture should not try to make 763 another attempt at solving complex multihoming, and we should prefer 764 to support scenarios for which solutions exist today. 766 In the general homenet architecture, hosts should be multi-addressed 767 with globally unique prefixes from each ISP they may communicate with 768 or through. An alternative for a homenet would be to deploy NPTv6 769 [RFC6296] at the CER, with ULAs then typically used internally, but 770 this mode is not considered by this text. If NPTv6 is used, the 771 internal part of the homenet (which is the scope of this text) simply 772 sees only the one (ULA) prefix in use. It should be noted that 773 running NPTv6 has an architectural cost, due to the prefix 774 translation used. 776 When multi-addressing is in use, hosts need some way to pick source 777 and destination address pairs for connections. A host may choose a 778 source address to use by various methods, which would typically 779 include [RFC6724]. Applications may of course do different things, 780 and this should not be precluded. 782 For the single CER Network Model C, multihoming may be offered by 783 source routing at the CER. With multiple exit routers, the 784 complexity rises. Given a packet with a source address on the 785 network, the packet must be routed to the proper egress to avoid BCP 786 38 [RFC2827] filtering at an ISP that did not delegate the prefix the 787 address is chosen from. While the packet might not take an optimal 788 path to the correct exit CER, the minimum requirement is that the 789 packet is not dropped. It is of course highly desirable that the 790 packet is routed in the most efficient manner to the correct exit. 792 There are various potential approaches to this problem, one example 793 being described in [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. 794 Another is discussed in [I-D.baker-fun-multi-router], which explores 795 support for source routing throughout the homenet. This approach 796 would however likely require relatively significant routing changes 797 to route the packet to the correct exit given the source address. 798 Such changes should preferably be minimised. 800 There are some other multihoming considerations for homenet 801 scenarios. First, it may be the case that multihoming applies due to 802 an ISP migration from a transition method to a native deployment, 803 e.g. a 6rd [RFC5969] sunset scenario. Second, one upstream may be a 804 "walled garden", and thus only appropriate to be used for 805 connectivity to the services of that provider; an example may be a 806 VPN service that only routes back to the enterprise business network 807 of a user in the homenet. While we should not specifically target 808 walled garden multihoming as a principal goal, it should not be 809 precluded. 811 Host-based methods such as Shim6 [RFC5533] have been defined, but of 812 course require support in the hosts. There are also application- 813 oriented approaches such as Happy Eyeballs [RFC6555]; simplified 814 versions of this are for example already implemented in some 815 commonly-used web browsers. The homenet architecture should not 816 preclude use of such tools should hosts include their support. 818 3.3. A Self-Organising Network 820 A home network architecture should be naturally self-organising and 821 self-configuring under different circumstances relating to the 822 connectivity status to the Internet, number of devices, and physical 823 topology. While the homenet should be self-organising, it should be 824 possible to manually adjust (override) the current configuration. 826 While a goal of the homenet architecture is for the network to be as 827 self-organising as possible, there may be instances where some manual 828 configuration is required, e.g. the entry of a WPA2 key to apply 829 wireless security, or to configure a shared routing secret. The 830 latter may be relevant when considering how to bootstrap a routing 831 configuration. It is highly desirable that only one such key is 832 needed for any set of functions, to increase usability for the 833 homenet user. 835 3.3.1. Homenet realms and borders 837 The homenet will need to be aware of the extent of its own "site", 838 which will define the borders for ULAs, site scope multicast, service 839 discovery and security policies. The homenet will have one or more 840 borders with external connectivity providers and potentially also 841 have borders within the internal network (e.g. for policy-based 842 reasons). It should be possible to automatically perform border 843 discovery for the different borders. Such borders determine for 844 example the scope of where prefixes, routing information, network 845 traffic, service discovery and naming may be shared. The default 846 mode internally should be to share everything. 848 It is expected that a realm would span at least an entire subnet, and 849 thus be associated to one delegated prefix within the homenet. It is 850 also desirable for a richer security model that hosts, which may be 851 running in a transparent communication mode, are able to make 852 decisions based on available realm and associated prefix information 853 in the same way that routers at realm borders can. 855 A simple homenet model may just consider three types of realm and the 856 borders between them. For example if the realms are the homenet, the 857 ISP and the guest network, then the borders will include that from 858 the homenet to the ISP, that from the guest network to the ISP, and 859 that from the homenet to the guest network. Regardless, it should be 860 possible for additional types of realms and borders to be defined, 861 e.g. for some specific Grid or LLN-based network, and for these to be 862 detected automatically, and for an appropriate default policy to be 863 applied as to what type of traffic/data can flow across such borders. 865 It is desirable to classify the external border of the home network 866 as a unique logical interface separating the home network from 867 service provider network/s. This border interface may be a single 868 physical interface to a single service provider, multiple layer 2 869 sub-interfaces to a single service provider, or multiple connections 870 to a single or multiple providers. This border makes it possible to 871 describe edge operations and interface requirements across multiple 872 functional areas including security, routing, service discovery, and 873 router discovery. 875 It should be possible for the homenet user to override any 876 automatically determined borders and the default policies applied 877 between them. 879 Some initial proposals towards border discovery are presented in 880 [I-D.kline-default-perimeter]. 882 3.3.2. Largest practical subnets 884 Today's IPv4 home networks generally have a single subnet, and early 885 dual-stack deployments have a single congruent IPv6 subnet, possibly 886 with some bridging functionality. More recently, some vendors have 887 started to introduce "home" and "guest" functions, which in IPv6 888 would be implemented as two subnets. 890 Future home networks are highly likely to have one or more internal 891 routers and thus need multiple subnets, for the reasons described 892 earlier. As part of the self-organisation of the network, the 893 homenet should subdivide itself to the largest practical subnets that 894 can be constructed within the constraints of link layer mechanisms, 895 bridging, physical connectivity, and policy, and where applicable 896 performance or other criteria. For example, bridging a busy Gigabit 897 Ethernet subnet and a wireless subnet together may impact wireless 898 performance. 900 While it may be desirable to maximise the chance of link-local 901 protocols operating across a homenet by maximising the size of a 902 subnet, multi-subnet home networks are inevitable, so their support 903 must be included. 905 3.3.3. Handling multiple homenets 907 It is important that self-configuration with "unintended" devices is 908 avoided. Methods are needed for devices to know whether they are 909 intended to be part of the same homenet site or not. Thus methods to 910 ensure separation between neighbouring homenets are required. This 911 may require use of some unique "secret" for devices/protocols in each 912 homenet. Some existing mechanisms exist to assist home users to 913 associate devices as simply as possible, e.g. "connect" button 914 support. 916 3.3.4. Coordination of configuration information 918 The network elements will need to be integrated in a way that takes 919 account of the various lifetimes on timers that are used on different 920 elements, e.g. DHCPv6 PD, router, valid prefix and preferred prefix 921 timers. 923 3.4. Homenet Addressing 925 The IPv6 addressing scheme used within a homenet must conform to the 926 IPv6 addressing architecture [RFC4291]. The homenet will need to 927 adapt to the prefixes made available to it through the prefix 928 delegation method used by its upstream ISP. 930 3.4.1. Use of ISP-delegated IPv6 prefixes 932 A homenet may receive an arbitrary length IPv6 prefix from its 933 provider, e.g. /60, /56 or /48. The offered prefix may be stable or 934 change from time to time. Some ISPs may offer relatively stable 935 prefixes, while others may change the prefix whenever the CER is 936 reset. Some discussion of IPv6 prefix allocation policies is 937 included in [RFC6177] which discusses why, for example, a one-size- 938 fits-all /48 allocation is not desirable. 940 The home network needs to be adaptable to such ISP policies, and thus 941 make no assumptions about the stability of the prefix received from 942 an ISP, or the length of the prefix that may be offered. However, if 943 only a /64 is offered by the ISP, the homenet may be severely 944 constrained (with IPv6 not reaching all devices in the home, or use 945 of some form of IPv6 NAT being forced), or even unable to function. 946 While it may be possible to operate a DHCPv6-only network with 947 prefixes longer than /64, doing so would break SLAAC, and is thus not 948 recommended. 950 A DHCPv6-PD capable router should "hint" that it would like a /48 951 prefix from its ISP, i.e. the CER asks the ISP for the maximum size 952 prefix it might expect to be offered, but in practice it may 953 typically only be offered a /56 or /60. 955 The internal operation of the home network should also not depend on 956 the availability of the ISP network at any given time, other than for 957 connectivity to services or systems off the home network. This 958 implies the use of ULAs for stable internal communication, as 959 described in the next section. 961 In practice, it is expected that ISPs will deliver a relatively 962 stable home prefix to customers. The norm for residential customers 963 of large ISPs may be similar to their single IPv4 address provision; 964 by default it is likely to remain persistent for some time, but 965 changes in the ISP's own provisioning systems may lead to the 966 customer's IP (and in the IPv6 case their prefix pool) changing. It 967 is not expected that ISPs will support Provider Independent (PI) 968 addressing for general residential homenets. 970 When an ISP needs to restructure and in doing so renumber its 971 customer homenets, "flash" renumbering is likely to be imposed. This 972 implies a need for the homenet to be able to handle a sudden 973 renumbering event which, unlike the process described in [RFC4192], 974 would be a "flag day" event, which means that a graceful renumbering 975 process moving through a state with two active prefixes in use would 976 not be possible. While renumbering is an extended version of an 977 initial numbering process, the difference between flash renumbering 978 and an initial "cold start" is the need to provide service 979 continuity. The deprecated addresses may remain usable for a short 980 period of time within the homenet. 982 There may be cases where local law means some ISPs are required to 983 change IPv6 prefixes (current IPv4 addresses) for privacy reasons for 984 their customers. In such cases it may be possible to avoid an 985 instant "flash" renumbering and plan a non-flag day renumbering as 986 per RFC 4192. 988 The customer may of course also choose to move to a new ISP, and thus 989 begin using a new prefix. In such cases the customer should expect a 990 discontinuity, and not only may the prefix change, but potentially 991 also the prefix length, if the new ISP offers a different default 992 size prefix, e.g. a /60 rather than a /56. Regardless, it's 993 desirable that homenet protocols support rapid renumbering and that 994 operational processes don't add unnecessary complexity for the 995 renumbering process. 997 The 6renum WG has studied IPv6 renumbering for enterprise networks. 998 It has not as yet targeted homenets, but may produce outputs that are 999 relevant. The introduction of any new homenet protocols should not 1000 make any form of renumbering any more complex than it already is. 1002 3.4.2. Stable internal IP addresses 1004 The network should by default attempt to provide IP-layer 1005 connectivity between all internal parts of the homenet as well as to 1006 and from the external Internet, subject to the filtering policies or 1007 other policy constraints discussed later in the security section. 1009 ULAs should be used within the scope of a homenet to support routing 1010 between subnets regardless of whether a globally unique ISP-provided 1011 prefix is available. It would be expected that ULAs would be used 1012 alongside one or more such global prefixes in a homenet, such that 1013 hosts become multi-addressed with both globally unique and ULA 1014 prefixes. Default address selection would then enable ULAs to be 1015 preferred for internal communications between devices that are using 1016 ULA prefixes generated within the same homenet. 1018 ULA addresses will allow constrained LLN devices to create permanent 1019 relationships between IPv6 addresses, e.g. from a wall controller to 1020 a lamp. Symbolic host names would require additional non-volatile 1021 memory. Updating global prefixes in sleeping LLN devices might also 1022 be problematic. 1024 ULAs may be used for all devices, not just those intended to only 1025 have internal connectivity. ULAs used in this way provide stable 1026 internal communications should the ISP-provided prefix (suddenly) 1027 change, or external connectivity be temporarily lost. The use of 1028 ULAs should be restricted to the homenet scope through filtering at 1029 the border(s) of the homenet, as described in RFC 6092. 1031 Note that it is possible that in some cases multiple /48 ULA prefixes 1032 may be in use within the same homenet, e.g. when the network is being 1033 deployed, perhaps also without external connectivity. It is expect 1034 that routers in the homenet would somehow elect a 'master' that would 1035 be responsible for delegating /64 prefixes to internal requesting 1036 routers, much as routers obtain /64 global prefixes from the prefix 1037 pool delegated by the ISP to the CER. In cases where multiple ULA 1038 /48's are in use, hosts need to know that each /48 is local to the 1039 homenet, e.g. by inclusion in their local address selection policy 1040 table. 1042 3.4.3. Internal prefix delegation 1044 As mentioned above, there are various sources of prefixes, e.g. they 1045 may be globally unique prefixes originating from ISP(s), they may be 1046 globally unique or ULA prefixes allocated by "master" router(s) in 1047 the homenet, or they may be ULAs allocated by LLN gateways. There 1048 may also be a prefix associated with NAT64, if in use in the homenet. 1050 From the homenet perspective, a single prefix from each ISP should be 1051 received on the border CER [RFC3633]. Then each subnet in the 1052 homenet should receive a prefix from within the ISP-provided 1053 prefix(es). 1055 The delegation of a prefix pool to the homenet should allow 1056 subsequent internal autonomous delegation of prefixes within the 1057 homenet, which should not assume a flat or hierarchical model. This 1058 text also makes no assumption about whether the delegation of 1059 prefixes is distributed or centralised. The assignment mechanism 1060 should provide reasonable efficiency, so that typical home network 1061 prefix allocation sizes can accommodate all the necessary /64 1062 allocations in most cases, and not waste prefixes. A currently 1063 typical /60 allocation gives 16 /64 subnets. Duplicate assignment of 1064 multiple /64s to the same network should be avoided. The network 1065 should behave as gracefully as possible in the event of prefix 1066 exhaustion, though the options in such cases may be limited. 1068 Where multiple CERs exist with multiple ISP prefix pools, it is 1069 expected that routers within the homenet would assign themselves 1070 prefixes from each ISP they communicate with/through. 1072 Where ULAs are used, most likely but not necessarily in parallel with 1073 global prefixes, one router should be elected to offer ULA prefixes 1074 for the homenet. The router should generate a /48 ULA for the site, 1075 and then delegate /64's from that ULA prefix to subnets. In the 1076 normal state, a single /48 ULA should be used within the homenet. In 1077 cases where two /48 ULAs are generated within a homenet, the network 1078 should still continue to function, meaning that hosts will need to 1079 determine that each ULA is local to the homenet. 1081 Delegation within the homenet should give each subnet a prefix that 1082 is persistent across reboots, power outages and similar short-term 1083 outages. Addition of a new routing device should not affect existing 1084 persistent prefixes, but persistence may not be expected in the face 1085 of significant "replumbing" of the homenet. Persistent prefixes 1086 should not depend on router boot order. Such persistent prefixes may 1087 imply the need for stable storage on routing devices, and also a 1088 method for a home user to "reset" the stored prefix should a 1089 significant reconfiguration be required (though ideally the home user 1090 should not be involved at all). 1092 The delegation method should support renumbering, which would 1093 typically be "flash" renumbering in that the homenet would not have 1094 advance notice of the event or thus be able to apply the types of 1095 approach described in [RFC4192]. As a minimum, delegated ULA 1096 prefixes within the homenet should remain persistent through an ISP- 1097 driven renumbering event. 1099 Several proposals have been made for prefix delegation within a 1100 homenet. One group of proposals is based on DHCPv6 PD, as described 1101 in [I-D.baker-homenet-prefix-assignment], 1102 [I-D.chakrabarti-homenet-prefix-alloc], [RFC3315] and [RFC3633]. The 1103 other uses OSPFv3, as described in 1104 [I-D.arkko-homenet-prefix-assignment]. More detailed analysis of 1105 these approaches needs to be made against the requirements/principles 1106 described above. For example, DHCPv6 solutions may have problems in 1107 multihomed scenarios with loops in the topology. 1109 3.4.4. Privacy 1111 There are no specific privacy concerns discussed in this text. It 1112 should be noted as above that many ISPs are expected to offer 1113 relatively stable IPv6 prefixes to customers, and thus the network 1114 prefix associated with the host addresses they use may not change 1115 over a reasonably long period of time. This exposure is similar to 1116 IPv4 networks that expose the same IPv4 global address via use of 1117 NAT, where the IPv4 address received from the ISP may change over 1118 time, but not necessarily that frequently. 1120 Hosts inside an IPv6 homenet may get new IPv6 addresses over time 1121 regardless, e.g. through Privacy Addresses [RFC4941]. 1123 3.5. Routing functionality 1125 Routing functionality is required when there are multiple routers 1126 deployed within the internal home network. This functionality could 1127 be as simple as the current "default route is up" model of IPv4 NAT, 1128 or, more likely, it would involve running an appropriate routing 1129 protocol. 1131 The homenet unicast routing protocol should preferably be an existing 1132 deployed protocol that has been shown to be reliable and robust, and 1133 it is preferable that the protocol is "lightweight". It is desirable 1134 that the routing protocol has knowledge of the homenet topology, 1135 which implies a link-state protocol is preferable. If so, it is also 1136 desirable that the announcements and use of LSAs and RAs are 1137 appropriately coordinated. This would mean the routing protocol 1138 gives a consistent view of the network, and that it can pass around 1139 more than just routing information. 1141 Multiple interface PHYs must be accounted for in the homenet routed 1142 topology. Technologies such as Ethernet, WiFi, MoCA, etc must be 1143 capable of coexisting in the same environment and should be treated 1144 as part of any routed deployment. The inclusion of the PHY layer 1145 characteristics including bandwidth, loss, and latency in path 1146 computation should be considered for optimising communication in the 1147 homenet. Multiple upstreams should be supported, as described in the 1148 multihoming section earlier. This should include load-balancing to 1149 multiple providers, and failover from a primary to a backup link when 1150 available. The protocol however should not require upstream ISP 1151 connectivity to be established to continue routing within the 1152 homenet. 1154 To support multihoming within a homenet, a routing protocol that can 1155 make routing decisions based on source and destination addresses is 1156 desirable, to avoid upstream ISP ingress filtering problems. In 1157 general the routing protocol should support multiple ISP uplinks and 1158 delegated prefixes in concurrent use. 1160 The routing environment should be self-configuring, as discussed 1161 previously. An example of how OSPFv3 can be self-configuring in a 1162 homenet is described in [I-D.acee-ospf-ospfv3-autoconfig]. 1163 Minimising convergence time should be a goal in any routed 1164 environment, but as a guideline a maximum convergence time of around 1165 30 seconds should be the target. 1167 Any routed solution will require a means for determining the 1168 boundaries of the homenet. Borders may include but are not limited 1169 to the interface to the upstream ISP, or a gateway device to a 1170 separate home network such as a LLN network. In some cases there may 1171 be no border present, which may for example occur before an upstream 1172 connection has been established. The border discovery functionality 1173 may be integrated into the routing protocol itself, but may also be 1174 imported via a separate discovery mechanism. 1176 In general, LLN or other networks should be able to attach and 1177 participate the same way as the main homenet, or alternatively map/be 1178 gatewayed to the main homenet. Current home deployments use largely 1179 different mechanisms in sensor and basic Internet connectivity 1180 networks. IPv6 VM solutions may also add additional routing 1181 requirements. 1183 3.5.1. Multicast support 1185 It is desirable that, subject to the capacities of devices on certain 1186 media types, multicast routing is supported across the homenet. The 1187 natural scopes for multicast would be link-local or site-local, with 1188 the latter constrained within the homenet, but other policy borders, 1189 e.g. to a guest subnet, or to certain media types, may also affect 1190 where specific multicast traffic is routed. 1192 There may be different drivers for multicast to be supported across 1193 the homenet, e.g. for service discovery should a proposal such as 1194 xmDNS [I-D.lynn-homenet-site-mdns] be deployed, or potentially for 1195 novel streaming or filesharing applications. Where multicast is 1196 routed across a homenet an appropriate multicast routing protocol is 1197 required, one that as per the unicast routing protocol should be 1198 self-configuring. It must be possible to scope or filter multicast 1199 traffic to avoid it being flooded to network media where devices 1200 cannot reasonably support it. 1202 The multicast environment should support the ability for applications 1203 to pick a unique multicast group to use. 1205 3.6. Security 1207 The security of an IPv6 homenet is an important consideration. The 1208 most notable difference to the IPv4 operational model is the removal 1209 of NAT, the introduction of global addressability of devices, and 1210 thus a need to consider whether devices should have global 1211 reachability. However, there are other challenges introduced, e.g. 1213 default filtering policies at the borders between other homenet 1214 realms. 1216 There is no defined "threat model" as such for the type of IPv6 1217 homenet described in this text. Such a document may be very useful. 1218 It may include a variety of perspectives, from probing for specific 1219 types of home appliance being present, to potential denial of service 1220 attacks. Hosts need to be able to operate securely, end-to-end where 1221 required, but also be robust against malicious traffic direct towards 1222 them. We simply note at this point that software on home devices are 1223 likely to have an increase in security if it allows its software to 1224 be updated regularly. 1226 3.6.1. Addressability vs reachability 1228 An IPv6-based home network architecture should embrace and naturally 1229 offer a transparent end-to-end communications model as described in 1230 [RFC2775]. Each device should be addressable by a globally unique 1231 address, and those addresses must not be altered in transit. 1232 Security perimeters can (via policy) restrict end-to-end 1233 communications, and thus while a host may be globally addressable it 1234 may not be globally reachable. 1236 In IPv4 NAT networks, the NAT provides an implicit firewall function. 1237 [RFC4864] describes a "Simple Security" model for IPv6 networks, 1238 whereby stateful perimeter filtering can be applied instead where 1239 global addresses are used. RFC 4864 implies an IPv6 "default deny" 1240 policy for inbound connections be used for similar functionality to 1241 IPv4 NAT. It should be noted that such a "default deny" approach 1242 would effectively replace the need for IPv4 NAT traversal protocols 1243 with a need to use a signalling protocol to request a firewall hole 1244 be opened. Thus to support applications wanting to accept 1245 connections initiated into home networks where a "default deny" 1246 policy is in place support for a signalling protocol such as UPnP or 1247 PCP [I-D.ietf-pcp-base] is required. In networks with multiple CERs, 1248 the signalling would need to handle the cases of flows that may use 1249 one or more exit routers. CERs would need to be able to advertise 1250 their existence for such protocols. 1252 [RFC6092] expands on RFC 4864, giving a more detailed discussion of 1253 IPv6 perimeter security recommendations, without mandating a "default 1254 deny" approach. Indeed, RFC 6092 does not prescribe a particular 1255 mode of operation, instead stating that CERs must provide an easily 1256 selected configuration option that permits a "transparent" mode of 1257 operation, thus ensuring a "default allow" model is available. The 1258 homenet architecture text makes no recommendation on the default 1259 setting, and refers the reader to RFC 6092. 1261 Advanced Security for IPv6 CPEs [I-D.vyncke-advanced-ipv6-security] 1262 takes the approach that in order to provide the greatest end-to-end 1263 transparency as well as security, security policies must be updated 1264 by a trusted party which can provide intrusion signatures and other 1265 "active" information on security threats. This might for example 1266 allow different malware detection profiles to be configured on a CER. 1267 Such methods should be able to be automatically updating. 1269 3.6.2. Filtering at borders 1271 It is desirable that there are mechanisms to detect different types 1272 of borders within the homenet, as discussed previously, and then the 1273 means to apply different types of filtering policies at those 1274 borders, e.g. whether naming and service discovery should pass a 1275 given border. Any such policies should be able to be easily applied 1276 by typical home users, e.g. to give a user in a guest network access 1277 to media services in the home, or access to a printer. Simple 1278 mechanisms to apply policy changes, or associations between devices, 1279 will be required. 1281 There are cases where full internal connectivity may not be 1282 desirable, e.g. in certain utility networking scenarios, or where 1283 filtering is required for policy reasons against guest network 1284 subnet(s). Some scenarios/models may as a result involve running 1285 isolated subnet(s) with their own CERs. In such cases connectivity 1286 would only be expected within each isolated network (though traffic 1287 may potentially pass between them via external providers). 1289 LLNs provide an another example of where there may be secure 1290 perimeters inside the homenet. Constrained LLN nodes may implement 1291 WPA2-style network key security but may depend on access policies 1292 enforced by the LLN border router. 1294 3.6.3. Marginal Effectiveness of NAT and Firewalls 1296 Security by way of obscurity (address translation) or through 1297 firewalls (filtering) is at best marginally effective. The very poor 1298 security track record of home computer, home networking and business 1299 PC computers and networking is testimony to its ineffectiveness. A 1300 compromise behind the firewall of any device exposes all others, 1301 making an entire network that relies on obscurity or a firewall as 1302 vulnerable as the most insecure device on the private side of the 1303 network. 1305 However, given home network products with very poor security, putting 1306 a firewall in place does provide some protection, even if only 1307 marginally effective. IPv6 global reachability may increase the need 1308 to solve the underlying problem of certain insecure home and business 1309 computer and network products. The use of firewalls today, whether a 1310 good practice or not, is common practice and whatever protection 1311 afforded, even if marginally effective, must not be lost. 1313 3.6.4. Device capabilities 1315 In terms of the devices, homenet hosts should implement their own 1316 security policies in accordance to their computing capabilities. 1317 They should have the means to request transparent communications to 1318 be initiated to them, either for all ports or for specific services. 1319 Users should have simple methods to associate devices to services 1320 that they wish to operate transparently through (CER) borders. 1322 3.6.5. ULAs as a hint of connection origin 1324 It has been suggested that using ULAs would provide an indication to 1325 applications that received traffic is locally sourced. This could 1326 then be used with security settings to designate between which nodes 1327 a particular application is allowed to communicate, provided ULA 1328 address space is filtered appropriately at the boundary of the realm. 1330 3.7. Naming and Service Discovery 1332 Naming and service discovery must be supported in the homenet, and 1333 the service(s) providing this function must as far as possible 1334 support unmanaged operation. 1336 The naming system will be required to work internally or externally, 1337 be the user within the homenet or outside it. The most natural way 1338 to think about such naming and service discovery is to enable it to 1339 work across the entire homenet residence (site), disregarding 1340 technical borders such as subnets but respecting policy borders such 1341 as those between guest and other internal network realms. 1343 3.7.1. Discovering services 1345 Users will typically perform service discovery through GUI interfaces 1346 that allow them to browse services on their network in an appropriate 1347 and intuitive way. Such interfaces are beyond the scope of this 1348 document, but the interface should have an appropriate API for the 1349 discovery to be performed. 1351 Such interfaces may also typically hide the local domain name element 1352 from users, especially where only one name space is available. As we 1353 discuss below, in some cases the ability to discover available 1354 domains may be useful. 1356 We note that current service discovery protocols are generally aimed 1357 at single subnets. There is thus a choice to make for multi-subnet 1358 homenets as to whether such protocols should be proxied or extended 1359 to operate across a whole homenet. This issue is discussed in more 1360 detail in a later section of this text. In general we should prefer 1361 approaches that are backwardly compatible, and allow current 1362 implementations to continue to be used. 1364 One of the primary challenges facing service discovery today is lack 1365 of interoperability due to the ever increasing number of service 1366 discovery protocols available. While it is conceivable for consumer 1367 devices to support multiple discovery protocols, this is clearly not 1368 the most efficient use of network and computational resources. One 1369 goal of the homenet architecture should be a path to service 1370 discovery protocol interoperability either through a standards based 1371 translation scheme, hooks into current protocols to allow some for of 1372 communication among discovery protocols, extensions to support a 1373 central service repository in the homenet, or convergence towards a 1374 unified protocol suite. 1376 3.7.2. Assigning names to devices 1378 Given the large number of devices that may be networked in the 1379 future, devices should have a means to generate their own unique 1380 names within a homenet, and to detect clashes should they arise, e.g. 1381 where two devices of the same type are deployed with the same default 1382 name, or where two running network elements are suddenly joined. 1384 Users will also want simple ways to (re)name devices, again most 1385 likely through an appropriate and intuitive interface that is beyond 1386 the scope of this document. Note the name a user assigns to a device 1387 may be a label that is stored on the device as an attribute of the 1388 device, and may be distinct from the name used in a name service, 1389 e.g. 'Laser Printer in the Study Room' as opposed to 1390 printer2.sitelocal. 1392 3.7.3. Name spaces 1394 It is desirable that only one name space is in use in the homenet, 1395 and that this name space is served authoritatively by a server in the 1396 homenet, most likely resident on the CER. 1398 If a user wishes to access their home devices remotely from elsewhere 1399 on the Internet a globally unique name space is required. This may 1400 be acquired by the user or provided/generated by their ISP. It is 1401 expected that the default case is that a homenet will use a global 1402 domain provided by the ISP, but users wishing to use a name space 1403 that is independent of their provider in the longer term may seek 1404 their own domain name. Examples of provider name space delegation 1405 approaches are described in [I-D.mglt-homenet-naming-delegation] and 1406 [I-D.mglt-homenet-front-end-naming-delegation]. For users wanting to 1407 use their own independent domain names, such services are already 1408 available. 1410 If however a global name space is not available, the homenet will 1411 need to pick and use a local name space, which would only have 1412 meaning within the local homenet (i.e. it would not be used for 1413 remote access to the homenet). The .local name space has a special 1414 meaning for certain existing protocols which have link-local scope, 1415 and is thus not appropriate for multi-subnet home networks. A 1416 differently named name space is thus required for the homenet. 1418 One approach for picking a local name space is to use an Ambiguous 1419 Local Qualified Domain Name (ALQDN) space, such as .sitelocal (or an 1420 appropriate name reserved for the purpose). While this is a simple 1421 approach, there is the potential for devices that are bookmarked 1422 somehow by an application in one homenet to be confused with a device 1423 with the same name in another homenet. 1425 An alternative approach for local name space would be to use a Unique 1426 Locally Qualified Domain Name (ULQDN) space such as 1427 ..sitelocal. The could be generated in 1428 a variety of ways, one potentially being based on the local ULA 1429 prefix across the homenet. Such a should survive a 1430 cold start, or if an existing value is not set on startup, the CER or 1431 device running the name service should generate a default value. It 1432 could be desirable for the homenet user to be able to override the 1433 with a value of their choice, but that would increase 1434 the likelihood of a name conflict. 1436 Whichever approach is used, the intent is to disambiguate the name 1437 space across different homenets, not to create a new IANA name space 1438 for such networks. If remote access to the homenet is required, a 1439 global domain is required. 1441 With the introduction of new "dotless" top level domains, there is 1442 potential for ambiguity between for example a local host called 1443 "computer" and (if it is registered) a .computer gTLD. Thus 1444 qualified names should always be used, whether these are exposed to 1445 the user or not. 1447 There may be use cases where segmentation of the name space is 1448 desirable, e.g. for use in different realms within the homenet. Thus 1449 hierarchical name space management is likely to be required. 1451 Where a user may be in a remote network wishing to access devices in 1452 their home network, there may be a requirement to consider the domain 1453 search order presented where two name spaces exist. In such cases, a 1454 GUI may present the user a choice of domains to use, where the name 1455 of their devices is thus relative to that domain. This implies that 1456 a domain discovery function is desirable. 1458 It may be the case that not all devices in the homenet are made 1459 available by name via an Internet name space, and that a 'split view' 1460 is preferred for certain devices. 1462 This document makes no assumption about the presence or omission of a 1463 reverse lookup service. There is an argument that it may be useful 1464 for presenting logging information to users with meaningful device 1465 names rather than literal addresses. 1467 3.7.4. The homenet name service 1469 The homenet name service should support both lookups and discovery. 1470 A lookup would operate via a direct query to a known service, while 1471 discovery may use multicast messages or a service where applications 1472 register in order to be found. 1474 It is highly desirable that the homenet name service must at the very 1475 least co-exist with the Internet name service. There should also be 1476 a bias towards proven, existing solutions. The strong implication is 1477 thus that the homenet service is DNS-based, or DNS-compatible. There 1478 are naming protocols that are designed to be configured and operate 1479 Internet-wide, like unicast-based DNS, but also protocols that are 1480 designed for zero-configuration local environments, like mDNS. 1482 As described in [I-D.mglt-homenet-naming-delegation], one approach is 1483 to run an authoritative name service in the homenet, most likely on 1484 the CER, which caches results, and to have the homenet's ISP provide 1485 a secondary name service. 1487 For a service such as mDNS to coexist with an Internet name service, 1488 where the homenet is preferably using a global domain name, it is 1489 desirable that the zeroconf devices have a way to add their names to 1490 the global name space in use. Zeroconf protocols could be used to 1491 indicate global FQDNs, e.g. an mDNS service could return a FQDN in a 1492 SRV record. 1494 Regardless, a method for local name service entries to be populated 1495 automatically by devices is desirable. Interfaces to devices might 1496 choose to give users the option as to whether the device should 1497 register itself in the global name space. There should also be a 1498 defined mechanism for device entries to be removed or expired from 1499 the global name space. 1501 It has been suggested for example that Dynamic DNS could be made to 1502 operate in a zero-configuration mode using a locally significant root 1503 domain and with minimal configuration or using a DHCPv6 based 1504 (details to-be-defined) means of automated delegation populate a 1505 global DNS zone. 1507 To protect against attacks such as cache poisoning, it is desirable 1508 to support appropriate name service security methods, including 1509 DNSSEC. 1511 The impact of a change in CER must be considered. It would be 1512 desirable to retain any relevant state (configuration) that was held 1513 in the old CER. This might imply that state information should be 1514 distributed in the homenet, to be recoverable by/to the new CER, or 1515 to the homenet's ISP or a third party service by some means. 1517 3.7.5. Independent operation 1519 Name resolution and service discovery for reachable devices must 1520 continue to function if the local network is disconnected from the 1521 global Internet, e.g. a local media server should still be available 1522 even if the Internet link is down for an extended period. This 1523 implies the local network should also be able to perform a complete 1524 restart in the absence of external connectivity, and have local 1525 naming and service discovery operate correctly. 1527 The approach described above of a local authoritative name service 1528 with a cache would allow local operation for sustained ISP outages. 1530 Having an independent local trust anchor is desirable, to support 1531 secure exchanges should external connectivity be unavailable. 1533 A change in ISP should not affect local naming and service discovery. 1534 However, if the homenet uses a global name space provided by the ISP, 1535 then this will obviously have an impact if the user changes their 1536 network provider. 1538 3.7.6. Considerations for LLNs 1540 In some parts of the homenet, in particular LLNs, devices may be 1541 sleeping, in which case a proxy for such nodes may be required, that 1542 can respond (for example) to multicast service discovery requests. 1543 Those same parts of the network may have less capacity for multicast 1544 traffic that may be flooded from other parts of the network. In 1545 general, message utilisation should be efficient considering the 1546 network technologies the service may need to operate over. 1548 There are efforts underway to determine naming and discovery 1549 solutions for use by the Constrained Application Protocol (CoAP) in 1550 LLN networks. These are outside the scope of this document. 1552 3.7.7. DNS resolver discovery 1554 Automatic discovery of a name service to allow client devices in the 1555 homenet to resolve external domains on the Internet is required, and 1556 such discovery must support clients that may be a number of router 1557 hops away from the name service. Similarly the search domains for 1558 local FQDN-derived zones should be included. 1560 3.8. Other Considerations 1562 This section discusses some other considerations for home networking 1563 that may affect the architecture. 1565 3.8.1. Proxy or Extend? 1567 There are two broad choices for allowing services that would 1568 otherwise be link-local to work across a homenet site, i.e. to extend 1569 the protocol to work across the scope of a subnet directly, or to 1570 proxy the link-local protocol between subnets. It may also in some 1571 cases be appropriate to use a different protocol instead, in which 1572 case that protocol should preferably be a proven, existing protocol. 1574 In the example of service discovery, one option is to take protocols 1575 like mDNS and have them run over site multicast within the homenet, 1576 as described in the Extended mDNS proposal (xmDNS) 1577 [I-D.lynn-homenet-site-mdns]. This is fine if all hosts support the 1578 extension, and the scope within any internal borders is well- 1579 understood. But it's not backwards-compatible with existing link- 1580 local protocols. An alternative is to proxy service discovery across 1581 subnets to propagate it. This is more complex, but is backwards- 1582 compatible. It would need to work with IPv6, and dual-stack. 1584 The homenet architecture proposes that any existing protocols that 1585 are designed to only work within a subnet should be extended to work 1586 across subnets, rather than defining proxy capabilities for each of 1587 those functions. However, while it is desirable to extend protocols 1588 to site scope operation rather than providing proxy functions on 1589 subnet boundaries, the reality is that until all hosts can use site- 1590 scope discovery protocols, existing link-local protocols would need 1591 to be proxied anyway. 1593 Some protocols already have proxy functions defined and in use, e.g. 1594 DHCPv6 relays, in which case those protocols would be expected to 1595 continue to operate that way. 1597 3.8.2. Quality of Service 1599 Support for QoS in a multi-service homenet may be a requirement, e.g. 1600 for a critical system (perhaps healthcare related), or for 1601 differentiation between different types of traffic (file sharing, 1602 cloud storage, live streaming, VoIP, etc). Different media types may 1603 have different such properties or capabilities. 1605 However, homenet scenarios should require no new QoS protocols. A 1606 DiffServ [RFC2475] approach with a small number of predefined traffic 1607 classes should generally be sufficient, though at present there is 1608 little experience of QoS deployment in home networks. It is likely 1609 that QoS, or traffic prioritisation, methods will be required at the 1610 CER, and potentially around boundaries between different media types 1611 (where for example some traffic may simply not be appropriate for 1612 some media, and need to be dropped to avoid drowning the constrained 1613 media). 1615 There may also be complementary mechanisms that could be beneficial 1616 to application performance and behaviour in the homenet domain, such 1617 as ensuring proper buffering algorithms are used as described in 1618 [Gettys11]. 1620 3.8.3. Operations and Management 1622 The homenet should be self-organising and configuring as far as 1623 possible, and thus not be pro-actively managed by the home user. 1624 Thus protocols to manage the network are not discussed in this 1625 architecture text. 1627 However, users may be interested in the status of their networks and 1628 devices on the network, in which case simplified monitoring 1629 mechanisms may be desirable. It may also be the case that an ISP, or 1630 a third party, might offer management of the homenet on behalf of a 1631 user, in which case management protocols would be required. How such 1632 management is done is out of scope of this document; many solutions 1633 exist. 1635 3.9. Implementing the Architecture on IPv6 1637 This architecture text encourages re-use of existing protocols. Thus 1638 the necessary mechanisms are largely already part of the IPv6 1639 protocol set and common implementations. There are though some 1640 exceptions. For automatic routing, it is expected that existing 1641 routing protocols can be used as is. However, a new mechanism may be 1642 needed in order to turn a selected protocol on by default. 1644 Some functionality, if required by the architecture, would add 1645 significant changes or require development of new protocols, e.g. 1646 support for multihoming with multiple exit routers would likely 1647 require extensions to support source and destination address based 1648 routing within the homenet. 1650 Some protocol changes are however required in the architecture, e.g. 1651 for name resolution and service discovery, extensions to existing 1652 multicast-based name resolution protocols are needed to enable them 1653 to work across subnets, within the scope of the home network site. 1655 Some of the hardest problems in developing solutions for home 1656 networking IPv6 architectures include discovering the right borders 1657 where the "home" domain ends and the service provider domain begins, 1658 deciding whether some of the necessary discovery mechanism extensions 1659 should affect only the network infrastructure or also hosts, and the 1660 ability to turn on routing, prefix delegation and other functions in 1661 a backwards compatible manner. 1663 4. Conclusions 1665 This text defines principles and requirements for a homenet 1666 architecture. The principles and requirements documented here should 1667 be observed by any future texts describing homenet protocols for 1668 routing, prefix management, security, naming or service discovery. 1670 5. References 1672 5.1. Normative References 1674 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1675 (IPv6) Specification", RFC 2460, December 1998. 1677 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1678 and M. Carney, "Dynamic Host Configuration Protocol for 1679 IPv6 (DHCPv6)", RFC 3315, July 2003. 1681 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1682 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1683 December 2003. 1685 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1686 (DHCP) Service for IPv6", RFC 3736, April 2004. 1688 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1689 Addresses", RFC 4193, October 2005. 1691 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1692 Architecture", RFC 4291, February 2006. 1694 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1695 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1696 May 2007. 1698 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1699 Extensions for Stateless Address Autoconfiguration in 1700 IPv6", RFC 4941, September 2007. 1702 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1703 Customer Premises Equipment (CPE) for Providing 1704 Residential IPv6 Internet Service", RFC 6092, 1705 January 2011. 1707 5.2. Informative References 1709 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1710 E. Lear, "Address Allocation for Private Internets", 1711 BCP 5, RFC 1918, February 1996. 1713 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1714 and W. Weiss, "An Architecture for Differentiated 1715 Services", RFC 2475, December 1998. 1717 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1718 February 2000. 1720 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1721 Defeating Denial of Service Attacks which employ IP Source 1722 Address Spoofing", BCP 38, RFC 2827, May 2000. 1724 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1725 Address Translator (Traditional NAT)", RFC 3022, 1726 January 2001. 1728 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1729 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1730 December 2003. 1732 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1733 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1734 September 2005. 1736 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1737 Shim Protocol for IPv6", RFC 5533, June 2009. 1739 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1740 Infrastructures (6rd) -- Protocol Specification", 1741 RFC 5969, August 2010. 1743 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1744 "IPv6 Router Advertisement Options for DNS Configuration", 1745 RFC 6106, November 2010. 1747 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1748 IPv4/IPv6 Translation", RFC 6144, April 2011. 1750 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1751 Algorithm", RFC 6145, April 2011. 1753 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1754 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 1756 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1757 Troan, "Basic Requirements for IPv6 Customer Edge 1758 Routers", RFC 6204, April 2011. 1760 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1761 Translation", RFC 6296, June 2011. 1763 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1764 Stack Lite Broadband Deployments Following IPv4 1765 Exhaustion", RFC 6333, August 2011. 1767 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1768 Dual-Stack Hosts", RFC 6555, April 2012. 1770 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 1771 "Default Address Selection for Internet Protocol Version 6 1772 (IPv6)", RFC 6724, September 2012. 1774 [I-D.mglt-homenet-front-end-naming-delegation] 1775 Cloetens, W., Lemordant, P., and D. Migault, "IPv6 Home 1776 Network Front End Naming Delegation", 1777 draft-mglt-homenet-front-end-naming-delegation-00 (work in 1778 progress), July 2012. 1780 [I-D.mglt-homenet-naming-delegation] 1781 Cloetens, W., Lemordant, P., and D. Migault, "IPv6 Home 1782 Network Naming Delegation Architecture", 1783 draft-mglt-homenet-naming-delegation-00 (work in 1784 progress), July 2012. 1786 [I-D.baker-fun-multi-router] 1787 Baker, F., "Exploring the multi-router SOHO network", 1788 draft-baker-fun-multi-router-00 (work in progress), 1789 July 2011. 1791 [I-D.lynn-homenet-site-mdns] 1792 Lynn, K. and D. Sturek, "Extended Multicast DNS", 1793 draft-lynn-homenet-site-mdns-01 (work in progress), 1794 September 2012. 1796 [I-D.vyncke-advanced-ipv6-security] 1797 Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced 1798 Security for IPv6 CPE", 1799 draft-vyncke-advanced-ipv6-security-03 (work in progress), 1800 October 2011. 1802 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] 1803 Matsushima, S., Okimoto, T., Troan, O., Miles, D., and D. 1804 Wing, "IPv6 Multihoming without Network Address 1805 Translation", 1806 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 (work 1807 in progress), February 2012. 1809 [I-D.baker-homenet-prefix-assignment] 1810 Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small 1811 Networks", draft-baker-homenet-prefix-assignment-01 (work 1812 in progress), March 2012. 1814 [I-D.arkko-homenet-prefix-assignment] 1815 Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment 1816 in a Home Network", 1817 draft-arkko-homenet-prefix-assignment-02 (work in 1818 progress), July 2012. 1820 [I-D.acee-ospf-ospfv3-autoconfig] 1821 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 1822 draft-acee-ospf-ospfv3-autoconfig-03 (work in progress), 1823 July 2012. 1825 [I-D.ietf-pcp-base] 1826 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1827 Selkirk, "Port Control Protocol (PCP)", 1828 draft-ietf-pcp-base-28 (work in progress), October 2012. 1830 [I-D.kline-default-perimeter] 1831 Kline, E., "Default Perimeter Identification", 1832 draft-kline-default-perimeter-00 (work in progress), 1833 July 2012. 1835 [I-D.hain-ipv6-ulac] 1836 Hain, T., Hinden, R., and G. Huston, "Centrally Assigned 1837 IPv6 Unicast Unique Local Address Prefixes", 1838 draft-hain-ipv6-ulac-02 (work in progress), July 2010. 1840 [I-D.chakrabarti-homenet-prefix-alloc] 1841 Nordmark, E., Chakrabarti, S., Krishnan, S., and W. 1842 Haddad, "Simple Approach to Prefix Distribution in Basic 1843 Home Networks", draft-chakrabarti-homenet-prefix-alloc-01 1844 (work in progress), October 2011. 1846 [I-D.ietf-v6ops-6204bis] 1847 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1848 Requirements for IPv6 Customer Edge Routers", 1849 draft-ietf-v6ops-6204bis-11 (work in progress), 1850 September 2012. 1852 [Gettys11] 1853 Gettys, J., "Bufferbloat: Dark Buffers in the Internet", 1854 March 2011, 1855 . 1857 [IGD-2] UPnP Gateway Committee, "Internet Gateway Device (IGD) V 1858 2.0", September 2010, . 1861 Appendix A. Acknowledgments 1863 The authors would like to thank Aamer Akhter, Mark Andrews, Dmitry 1864 Anipko, Fred Baker, Ray Bellis, Cameron Byrne, Brian Carpenter, 1865 Stuart Cheshire, Lorenzo Colitti, Robert Cragie, Ralph Droms, Lars 1866 Eggert, Jim Gettys, olafur Gudmundsson, Wassim Haddad, Joel M. 1867 Halpern, David Harrington, Lee Howard, Ray Hunter, Joel Jaeggli, 1868 Heather Kirksey, Ted Lemon, Acee Lindem, Kerry Lynn, Erik Nordmark, 1869 Michael Richardson, Barbara Stark, Sander Steffann, Don Sturek, Dave 1870 Taht, Dave Thaler, Michael Thomas, Mark Townsley, JP Vasseur, Curtis 1871 Villamizar, Dan Wing, Russ White, and James Woodyatt for their 1872 comments and contributions within homenet WG meetings and on the WG 1873 mailing list. 1875 Appendix B. Changes 1877 This section will be removed in the final version of the text. 1879 B.1. Version 06 1881 Changes made include: 1883 o Stated that unmanaged goal is 'as far as possible'. 1885 o Added note about multiple /48 ULAs potentially being in use. 1887 o Minor edits from list feedback. 1889 B.2. Version 05 1891 Changes made include: 1893 o Some significant changes to naming and SD section. 1895 o Removed some expired drafts. 1897 o Added notes about issues caused by ISP only delegating a /64. 1899 o Recommended against using prefixes longer than /64. 1901 o Suggested CER asks for /48 by DHCP-PD, even if it only receives 1902 less. 1904 o Added note about DS-Lite but emphasised transition is out of 1905 scope. 1907 o Added text about multicast routing. 1909 B.3. Version 04 1911 Changes made include: 1913 o Moved border section from IPv6 differences to principles section. 1915 o Restructured principles into areas. 1917 o Added summary of naming and service discovery discussion from WG 1918 list. 1920 B.4. Version 03 1922 Changes made include: 1924 o Various improvements to the readability. 1926 o Removed bullet lists of requirements, as requested by chair. 1928 o Noted 6204bis has replaced advanced-cpe draft. 1930 o Clarified the topology examples are just that. 1932 o Emphasised we are not targetting walled gardens, but they should 1933 not be precluded. 1935 o Also changed text about requiring support for walled gardens. 1937 o Noted that avoiding falling foul of ingress filtering when 1938 multihomed is desirable. 1940 o Improved text about realms, detecting borders and policies at 1941 borders. 1943 o Stated this text makes no recommendation about default security 1944 model. 1946 o Added some text about failure modes for users plugging things 1947 arbitrarily. 1949 o Expanded naming and service discovery text. 1951 o Added more text about ULAs. 1953 o Removed reference to version 1 on chair feedback. 1955 o Stated that NPTv6 adds architectural cost but is not a homenet 1956 matter if deployed at the CER. This text only considers the 1957 internal homenet. 1959 o Noted multihoming is supported. 1961 o Noted routers may not by separate devices, they may be embedded in 1962 devices. 1964 o Clarified simple and advanced security some more, and RFC 4864 and 1965 6092. 1967 o Stated that there should be just one secret key, if any are used 1968 at all. 1970 o For multihoming, support multiple CERs but note that routing to 1971 the correct CER to avoid ISP filtering may not be optimal within 1972 the homenet. 1974 o Added some ISPs renumber due to privacy laws. 1976 o Removed extra repeated references to Simple Security. 1978 o Removed some solution creep on RIOs/RAs. 1980 o Load-balancing scenario added as to be supported. 1982 B.5. Version 02 1984 Changes made include: 1986 o Made the IPv6 implications section briefer. 1988 o Changed Network Models section to describe properties of the 1989 homenet with illustrative examples, rather than implying the 1990 number of models was fixed to the six shown in 01. 1992 o Text to state multihoming support focused on single CER model. 1993 Multiple CER support is desirable, but not required. 1995 o Stated that NPTv6 not supported. 1997 o Added considerations section for operations and management. 1999 o Added bullet point principles/requirements to Section 3.4. 2001 o Changed IPv6 solutions must not adversely affect IPv4 to should 2002 not. 2004 o End-to-end section expanded to talk about "Simple Security" and 2005 borders. 2007 o Extended text on naming and service discovery. 2009 o Added reference to RFC 2775, RFC 6177. 2011 o Added reference to the new xmDNS draft. 2013 o Added naming/SD requirements from Ralph Droms. 2015 Authors' Addresses 2017 Tim Chown (editor) 2018 University of Southampton 2019 Highfield 2020 Southampton, Hampshire SO17 1BJ 2021 United Kingdom 2023 Email: tjc@ecs.soton.ac.uk 2025 Jari Arkko 2026 Ericsson 2027 Jorvas 02420 2028 Finland 2030 Email: jari.arkko@piuha.net 2032 Anders Brandt 2033 Sigma Designs 2034 Emdrupvej 26A, 1 2035 Copenhagen DK-2100 2036 Denmark 2038 Email: abr@sdesigns.dk 2040 Ole Troan 2041 Cisco Systems, Inc. 2042 Drammensveien 145A 2043 Oslo N-0212 2044 Norway 2046 Email: ot@cisco.com 2048 Jason Weil 2049 Time Warner Cable 2050 13820 Sunrise Valley Drive 2051 Herndon, VA 20171 2052 USA 2054 Email: jason.weil@twcable.com