idnits 2.17.1 draft-ietf-homenet-arch-08.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 (May 21, 2013) is 3993 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 informational reference (is this intentional?): 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) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05 == Outdated reference: A later version (-04) exists of draft-arkko-homenet-prefix-assignment-03 == Outdated reference: A later version (-15) exists of draft-ietf-ospf-ospfv3-autoconfig-02 == Outdated reference: A later version (-02) exists of draft-behringer-homenet-trust-bootstrap-00 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 7 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: November 22, 2013 Ericsson 6 A. Brandt 7 Sigma Designs 8 O. Troan 9 Cisco Systems, Inc. 10 J. Weil 11 Time Warner Cable 12 May 21, 2013 14 Home Networking Architecture for IPv6 15 draft-ietf-homenet-arch-08 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 a general architecture for IPv6-based home 22 networking, describing the associated principles, considerations and 23 requirements. The text briefly highlights specific implications of 24 the introduction of IPv6 for home networking, discusses the elements 25 of the architecture, and suggests how standard IPv6 mechanisms and 26 addressing can be employed in home networking. The architecture 27 describes the need for specific protocol extensions for certain 28 additional functionality. It is assumed that the IPv6 home network 29 is not actively managed, and runs as an IPv6-only or dual-stack 30 network. There are no recommendations in this text for the IPv4 part 31 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 November 22, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 5 69 2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . . 6 70 2.1. Multiple subnets and routers . . . . . . . . . . . . . . . 7 71 2.2. Global addressability and elimination of NAT . . . . . . . 8 72 2.3. Multi-Addressing of devices . . . . . . . . . . . . . . . 8 73 2.4. Unique Local Addresses (ULAs) . . . . . . . . . . . . . . 9 74 2.5. Avoiding manual configuration of IP addresses . . . . . . 10 75 2.6. IPv6-only operation . . . . . . . . . . . . . . . . . . . 10 76 3. Homenet Architecture . . . . . . . . . . . . . . . . . . . . . 11 77 3.1. General Principles . . . . . . . . . . . . . . . . . . . . 12 78 3.1.1. Reuse existing protocols . . . . . . . . . . . . . . . 12 79 3.1.2. Minimise changes to hosts and routers . . . . . . . . 12 80 3.2. Homenet Topology . . . . . . . . . . . . . . . . . . . . . 12 81 3.2.1. Supporting arbitrary topologies . . . . . . . . . . . 13 82 3.2.2. Network topology models . . . . . . . . . . . . . . . 13 83 3.2.3. Dual-stack topologies . . . . . . . . . . . . . . . . 17 84 3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 18 85 3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 19 86 3.3.1. Differentiating neighbouring homenets . . . . . . . . 20 87 3.3.2. Largest practical subnets . . . . . . . . . . . . . . 20 88 3.3.3. Homenet realms and borders . . . . . . . . . . . . . . 20 89 3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . . 21 90 3.4.1. Use of ISP-delegated IPv6 prefixes . . . . . . . . . . 22 91 3.4.2. Stable internal IP addresses . . . . . . . . . . . . . 24 92 3.4.3. Internal prefix delegation . . . . . . . . . . . . . . 25 93 3.4.4. Coordination of configuration information . . . . . . 26 94 3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 26 95 3.5. Routing functionality . . . . . . . . . . . . . . . . . . 27 96 3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 28 98 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 28 99 3.6.1. Addressability vs reachability . . . . . . . . . . . . 29 100 3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 29 101 3.6.3. Marginal Effectiveness of NAT and Firewalls . . . . . 30 102 3.6.4. Device capabilities . . . . . . . . . . . . . . . . . 30 103 3.6.5. ULAs as a hint of connection origin . . . . . . . . . 30 104 3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 31 105 3.7.1. Discovering services . . . . . . . . . . . . . . . . . 31 106 3.7.2. Assigning names to devices . . . . . . . . . . . . . . 32 107 3.7.3. Name spaces . . . . . . . . . . . . . . . . . . . . . 32 108 3.7.4. The homenet name service . . . . . . . . . . . . . . . 34 109 3.7.5. Independent operation . . . . . . . . . . . . . . . . 35 110 3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 35 111 3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 36 112 3.7.8. Devices roaming from the homenet . . . . . . . . . . . 36 113 3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 36 114 3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 36 115 3.8.2. Operations and Management . . . . . . . . . . . . . . 37 116 3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 37 117 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 38 118 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 119 5.1. Normative References . . . . . . . . . . . . . . . . . . . 38 120 5.2. Informative References . . . . . . . . . . . . . . . . . . 39 121 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 42 122 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 42 123 B.1. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 42 124 B.2. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 43 125 B.3. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 43 126 B.4. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 44 127 B.5. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 44 128 B.6. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 44 129 B.7. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 46 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 132 1. Introduction 134 This document focuses on evolving networking technology within 135 increasingly large residential home networks and the associated 136 challenges with their deployment and operation. There is a growing 137 trend in home networking for the proliferation of networking 138 technology through an increasingly broad range of devices and media. 139 This evolution in scale and diversity sets requirements on IETF 140 protocols. Some of these requirements relate to the introduction of 141 IPv6, others to the introduction of specialised networks for home 142 automation and sensors. 144 While at the time of writing some complex home network topologies 145 exist, most are relatively simple single subnet networks, and 146 ostensibly operate using just IPv4. While there may be IPv6 traffic 147 within the network, e.g. for service discovery, the homenet is 148 provisioned by the ISP as an IPv4 network. Such networks also 149 typically employ solutions that we would like to avoid, such as 150 private [RFC1918] addressing with (cascaded) network address 151 translation (NAT)[RFC3022], or they may require expert assistance to 152 set up. 154 In contrast, emerging IPv6-capable home networks are very likely to 155 have multiple internal subnets, e.g. to facilitate private and guest 156 networks, heterogeneous link layers, and smart grid components, and 157 enough address space available to allow every device to have a 158 globally unique address. This implies that internal routing 159 functionality is required, and that the homenet's ISP both provides a 160 large enough prefix to allocate a prefix to each subnet, and that a 161 method is supported for such prefixes to be delegated efficiently to 162 those subnets. 164 It is not practical to expect home users to configure their networks. 165 Thus the assumption of this document is that the homenet is as far as 166 possible self-organising and self-configuring, i.e. it should 167 function without pro-active management by the residential user. 169 The architectural constructs in this document are focused on the 170 problems to be solved when introducing IPv6, with an eye towards a 171 better result than what we have today with IPv4, as well as a better 172 result than if the IETF had not given this specific guidance. The 173 document aims to provide the basis and guiding principles for how 174 standard IPv6 mechanisms and addressing [RFC2460] [RFC4291] can be 175 employed in home networking, while coexisting with existing IPv4 176 mechanisms. In emerging dual-stack home networks it is vital that 177 introducing IPv6 does not adversely affect IPv4 operation. We assume 178 that the IPv4 network architecture in home networks is what it is, 179 and can not be modified by new recommendations. This document does 180 not discuss how IPv4 home networks provision or deliver support for 181 multiple subnets. It should not be assumed that any future new 182 functionality created with IPv6 in mind will be backward-compatible 183 to include IPv4 support. Further, future deployments, or specific 184 subnets within an otherwise dual-stack home network, may be IPv6- 185 only, in which case considerations for IPv4 impact would not apply. 187 This document proposes a baseline homenet architecture, using 188 protocols and implementations that are as far as possible proven and 189 robust. The scope of the document is primarily the network layer 190 technologies that provide the basic functionality to enable 191 addressing, connectivity, routing, naming and service discovery. 192 While it may, for example, state that homenet components must be 193 simple to deploy and use, it does not discuss specific user 194 interfaces, nor does it discuss specific physical, wireless or data- 195 link layer considerations. 197 [RFC6204] defines basic requirements for customer edge routers 198 (CERs). This document has recently been updated with the definition 199 of requirements for specific transition tools on the CER in 200 [I-D.ietf-v6ops-6204bis], specifically DS-Lite [RFC6333] and 6rd 201 [RFC5969]. Such detailed specification of CER devices is considered 202 out of scope of this architecture document, and we assume that any 203 required update of the CER device specification as a result of 204 adopting this architecture will be handled as separate and specific 205 updates to these existing documents. Further, the scope of this text 206 is the internal homenet, and thus specific features on the WAN side 207 of the CER are out of scope for this text. 209 1.1. Terminology and Abbreviations 211 In this section we define terminology and abbreviations used 212 throughout the text. 214 o ALQDN: Ambiguous Locally Qualified Domain Name. An example would 215 be .sitelocal. 217 o Border: a point, typically resident on a router, between two 218 networks, e.g. between the main internal homenet and a guest 219 network. This defines point(s) at which filtering and forwarding 220 policies for different types of traffic may be applied. 222 o CER: Customer Edge Router: A border router intended for use in a 223 homenet, which connects the homenet to a service provider network. 225 o FQDN: Fully Qualified Domain Name. A globally unique name space. 227 o Homenet: A home network, comprising host and router equipment, 228 with one or more CERs providing connectivity to service provider 229 network(s). 231 o Internet Service Provider (ISP): an entity that provides access to 232 the Internet. In this document, a service provider specifically 233 offers Internet access using IPv6, and may also offer IPv4 234 Internet access. The service provider can provide such access 235 over a variety of different transport methods such as DSL, cable, 236 wireless, and others. 238 o LLN: Low-power and lossy network. 240 o LQDN: Locally Qualified Domain Name. A name space local to the 241 homenet. 243 o NAT: Network Address Translation. Typically referring to IPv4 244 Network Address and Port Translation (NAPT) [RFC3022]. 246 o NPTv6: Network Prefix Translation for IPv6 [RFC6296]. 248 o PCP: Port Control Protocol [I-D.ietf-pcp-base]. 250 o Realm: a network delimited by a defined border. A guest network 251 within a homenet may form one realm. 253 o 'Simple Security'. Defined in [RFC4864] and expanded further in 254 [RFC6092]; describes recommended perimeter security capabilities 255 for IPv6 networks. 257 o ULA: IPv6 Unique Local Addresses [RFC4193]. 259 o ULQDN: Unique Locally Qualified Domain Name. An example might be 260 ..sitelocal. 262 o UPnP: Universal Plug and Play. Includes the Internet Gateway 263 Device (IGD) function, which for IPv6 is UPnP IGD Version 2 264 [IGD-2]. 266 o VM: Virtual machine. 268 o WPA2: Wi-Fi Protected Access, as defined by the Wi-Fi Alliance. 270 2. Effects of IPv6 on Home Networking 272 While IPv6 resembles IPv4 in many ways, there are some notable 273 differences in the way it may typically be deployed. It changes 274 address allocation principles, making multi-addressing the norm, and, 275 through the vastly increased address space, allows globally unique IP 276 addresses to be used for all devices in a home network. This section 277 presents an overview of some of the key implications of the 278 introduction of IPv6 for home networking, that are simultaneously 279 both promising and problematic. 281 2.1. Multiple subnets and routers 283 While simple layer 3 topologies involving as few subnets as possible 284 are preferred in home networks, the incorporation of dedicated 285 (routed) subnets remains necessary for a variety of reasons. For 286 instance, an increasingly common feature in modern home routers is 287 the ability to support both guest and private network subnets. 288 Likewise, there may be a need to separate building control or 289 corporate extensions from the main Internet access network, or 290 different subnets may in general be associated with parts of the 291 homenet that have different routing and security policies. Further, 292 link layer networking technology is poised to become more 293 heterogeneous, as networks begin to employ both traditional Ethernet 294 technology and link layers designed for low-power and lossy networks 295 (LLNs), such as those used for certain types of sensor devices. 296 Constraining the flow of certain traffic from Ethernet links to much 297 lower capacity links thus becomes an important topic. 299 The introduction of IPv6 for home networking enables the potential 300 for every home network to be delegated enough address space from its 301 ISP to provision globally unique prefixes for each such subnet in the 302 home. While the number of addresses in a standard /64 IPv6 prefix is 303 practically infinite, the number of prefixes available for assignment 304 to the home network is not. As a result the growth inhibitor for the 305 home network shifts from the number of addresses to the number of 306 prefixes offered by the provider; this topic is discussed in 307 [RFC6177] (BCP 157), which recommends that "end sites always be able 308 to obtain a reasonable amount of address space for their actual and 309 planned usage". 311 The addition of routing between subnets raises a number of issues. 312 One is a method by which prefixes can be efficiently allocated to 313 each subnet, without user intervention. Another is the issue of how 314 to extend mechanisms such as service discovery which currently only 315 operate within a single subnet using link-local traffic. In a 316 typical IPv4 home network, there is only one subnet, so such 317 mechanisms would normally operate as expected. For multi-subnet IPv6 318 home networks there are two broad choices to enable such protocols to 319 work across the scope of the entire homenet; extend existing 320 protocols to work across that scope, or introduce proxies for 321 existing link layer protocols. This topic is discussed in 322 Section 3.7. 324 2.2. Global addressability and elimination of NAT 326 The possibility for direct end-to-end communication on the Internet 327 that will be restored by the introduction of IPv6 is on the one hand 328 an incredible opportunity for innovation and simpler network 329 operation, but it is also a concern as it potentially exposes nodes 330 in the internal networks to receipt of unwanted traffic from the 331 Internet. 333 With devices and applications able to talk directly to each other 334 when they have globally unique addresses, there may be an expectation 335 of improved host security to compensate for this. It should be noted 336 that many devices may (for example) ship with default settings that 337 make them readily vulnerable to compromise by external attackers if 338 globally accessible, or may simply not have robustness designed-in 339 because it was either assumed such devices would only be used on 340 private networks or the device itself doesn't have the computing 341 power to apply the necessary security methods. In addition, the 342 upgrade cycle for devices (or their firmware) may be slow, and/or 343 lack auto-update mechanisms. 345 It is thus important to distinguish between addressability and 346 reachability. While IPv6 offers global addressability through use of 347 globally unique addresses in the home, whether devices are globally 348 reachable or not would depend on any firewall or filtering 349 configuration, and not, as is commonly the case with IPv4, the 350 presence or use of NAT. In this respect, IPv6 networks may or may 351 not have filters applied at their borders to control such traffic, 352 i.e. at the homenet CER. [RFC4864] and [RFC6092] discuss such 353 filtering, and the merits of 'default allow' against 'default deny' 354 policies for external traffic initiated into a homenet. This 355 document takes no position on which mode is the default, but assumes 356 the choice to for the homenet to use either mode would be available. 358 2.3. Multi-Addressing of devices 360 In an IPv6 network, devices will often acquire multiple addresses, 361 typically at least a link-local address and one or more globally 362 unique addresses. Where a homenet is multihomed, a device would 363 typically receive a globally unique address (GUA) from within the 364 delegated prefix from each upstream ISP. Devices may also have an 365 IPv4 address if the network is dual-stack, an IPv6 Unique Local 366 Address (ULA) [RFC4193] (see below), and one or more IPv6 Privacy 367 Addresses [RFC4941]. 369 It should thus be considered the norm for devices on IPv6 home 370 networks to be multi-addressed, and to need to make appropriate 371 address selection decisions for the candidate source and destination 372 address pairs for any given connection. Default Address Selection 373 for IPv6 [RFC6724] provides a solution for this, though it may face 374 problems in the event of multihoming where, as described above, nodes 375 will be configured with one address from each upstream ISP prefix. 376 In such cases the presence of upstream BCP 38 [RFC2827] ingress 377 filtering requires multi-addressed nodes to select the correct source 378 address to be used for the corresponding uplink. A challenge here is 379 that the node may not have the information it needs to make that 380 decision based on addresses alone. We discuss this challenge in 381 Section 3.2.4. 383 2.4. Unique Local Addresses (ULAs) 385 [RFC4193] defines Unique Local Addresses (ULAs) for IPv6 that may be 386 used to address devices within the scope of a single site. Support 387 for ULAs for IPv6 CERs is described in [RFC6204]. A home network 388 running IPv6 should deploy ULAs alongside its globally unique 389 prefix(es) to allow stable communication between devices (on 390 different subnets) within the homenet where that externally allocated 391 globally unique prefix may change over time (e.g. due to renumbering 392 within the subscriber's ISP) or where external connectivity may be 393 temporarily unavailable. 395 While setting up a network there may be a period where it has no 396 external connectivity, in which case ULAs would be required for 397 inter-subnet communication. In the case where LLNs are being set up 398 in a new home/deployment (as early as during construction of the 399 home), LLNs will likely need to use their own /48 ULA prefix. 400 Depending upon circumstances beyond the scope of homenet, it may be 401 impossible to renumber the ULA used by the LLN so routing between ULA 402 /48s may be required. Also, some devices, particularly constrained 403 devices, may have only a ULA (in addition to a link-local), while 404 others may have both a GUA and a ULA. 406 Note that unlike private IPv4 RFC 1918 space, the use of ULAs does 407 not imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT 408 [RFC6296], rather that in an IPv6 homenet a node should use its ULA 409 address internally, and its additional globally unique IPv6 address 410 as a source address for external communications. By using such 411 globally unique addresses between hosts and devices in remote 412 networks, the architectural cost and complexity, particularly to 413 applications, of NAT or NPTv6 translation is avoided. As such, 414 neither IPv6 NAT or NPTv6 is recommended for use in the homenet 415 architecture. 417 Where both a ULA and a global prefix are in use, the ULA source 418 address is used to communicate with ULA destination addresses when 419 appropriate, i.e. when the ULA source and destination lie within the 420 /48 ULA prefix(es) known to be used within the same homenet. In 421 cases where multiple /48 ULA prefixes are in use within a single 422 homenet (perhaps because multiple homenet routers each independently 423 auto-generate a /48 ULA prefix and then share prefix/routing 424 information), utilising a ULA source address and a ULA destination 425 address from two disjoint internal ULA prefixes is preferable to 426 using GUAs. 428 While a homenet should operate correctly with two or more /48 ULAs 429 enabled, a mechanism for the creation and use of a single /48 ULA 430 prefix is desirable for addressing consistency and policy 431 enforcement. It may thus be expected that one router in the homenet 432 be elected a 'master' to delegate ULA prefixes to subnets from a 433 single /48 ULA prefix. 435 A counter-argument to using ULAs is that it is undesirable to 436 aggressively deprecate global prefixes for temporary loss of 437 connectivity, so for a host to lose its global address there would 438 have to be a connection breakage longer than the lease period, and 439 even then, deprecating prefixes when there is no connectivity may not 440 be advisable. However, it is assumed in this architecture that 441 homenets should support and use ULAs. 443 2.5. Avoiding manual configuration of IP addresses 445 Some IPv4 home networking devices expose IPv4 addresses to users, 446 e.g. the IPv4 address of a home IPv4 CER that may be configured via a 447 web interface. In potentially complex future IPv6 homenets, users 448 should not be expected to enter IPv6 literal addresses in devices or 449 applications, given their much greater length and the apparent 450 randomness of such addresses to a typical home user. Thus, even for 451 the simplest of functions, simple naming and the associated (minimal, 452 and ideally zero configuration) discovery of services is imperative 453 for the easy deployment and use of homenet devices and applications. 454 As mentioned previously, this means that zeroconf naming and service 455 discovery protocols must be capable of operating across subnet 456 boundaries. 458 2.6. IPv6-only operation 460 It is likely that IPv6-only networking will be deployed first in 461 'greenfield' homenet scenarios, or perhaps as one element of an 462 otherwise dual-stack network. Running IPv6-only adds additional 463 requirements, e.g. for devices to get configuration information via 464 IPv6 transport (not relying on an IPv4 protocol such as IPv4 DHCP), 465 and for devices to be able to initiate communications to external 466 devices that are IPv4-only. Thus, for example, the following 467 requirements are amongst those that should be considered in IPv6-only 468 environments: 470 o Ensuring there is a way to access content in the IPv4 Internet. 471 This can be arranged through appropriate use of NAT64 [RFC6144] 472 and DNS64 [RFC6145], for example, or via a node-based DS-Lite 473 [RFC6333] approach. 475 o Ensuring DNS resolver discovery mechanisms are enabled for IPv6. 476 Both stateless DHCPv6 [RFC3736] [RFC3646] and Router Advertisement 477 options [RFC6106] may have to be supported and turned on by 478 default to ensure maximum compatibility with all types of hosts in 479 the network. This requires, however, that a working DNS server is 480 known and addressable via IPv6, and that the automatic discovery 481 of such a server is possible through multiple routers in the 482 homenet. 484 o Ensuring all nodes in the home network support operations in IPv6- 485 only mode. Some current devices work well with dual-stack but 486 fail to recognise connectivity when IPv4 DHCP fails, for instance. 488 The widespread availability of robust solutions to these types of 489 requirements will help accelerate the uptake of IPv6-only homenets. 490 The specifics of these are however beyond the scope of this document, 491 especially those functions that reside on the CER. 493 3. Homenet Architecture 495 The aim of this text is to outline how to construct advanced IPv6- 496 based home networks involving multiple routers and subnets using 497 standard IPv6 protocols and addressing [RFC2460] [RFC4291]. In this 498 section, we present the elements of the proposed home networking 499 architecture, with discussion of the associated design principles. 501 In general, home network equipment needs to be able to operate in 502 networks with a range of different properties and topologies, where 503 home users may plug components together in arbitrary ways and expect 504 the resulting network to operate. Significant manual configuration 505 is rarely, if at all, possible, or even desirable given the knowledge 506 level of typical home users. Thus the network should, as far as 507 possible, be self-configuring, though configuration by advanced users 508 should not be precluded. 510 The homenet needs to be able to handle or provision at least 511 o Routing 513 o Prefix configuration for routers 515 o Name resolution 517 o Service discovery 519 o Network security 521 The remainder of this document describes the principles by which the 522 homenet architecture may deliver these properties. 524 3.1. General Principles 526 There is little that the Internet standards community can do about 527 the physical topologies or the need for some networks to be separated 528 at the network layer for policy or link layer compatibility reasons. 529 However, there is a lot of flexibility in using IP addressing and 530 inter-networking mechanisms. This text discusses how such 531 flexibility should be used to provide the best user experience and 532 ensure that the network can evolve with new applications in the 533 future. The principles described in this text should be followed 534 when designing homenet solutions. 536 3.1.1. Reuse existing protocols 538 It is desirable to reuse existing protocols where possible, but at 539 the same time to avoid consciously precluding the introduction of new 540 or emerging protocols. A generally conservative approach, giving 541 weight to running (and available) code, is preferable. Where new 542 protocols are required, evidence of commitment to implementation by 543 appropriate vendors or development communities is highly desirable. 544 Protocols used should be backwardly compatible, and forward 545 compatible where changes are made. 547 3.1.2. Minimise changes to hosts and routers 549 Where possible, any requirement for changes to hosts and routers 550 should be minimised, though solutions which, for example, 551 incrementally improve capability with host or router changes may be 552 acceptable. 554 3.2. Homenet Topology 556 This section considers homenet topologies, and the principles that 557 may be applied in designing an architecture to support as wide a 558 range of such topologies as possible. 560 3.2.1. Supporting arbitrary topologies 562 There should ideally be no built-in assumptions about the topology in 563 home networks, as users are capable of connecting their devices in 564 'ingenious' ways. Thus arbitrary topologies and arbitrary routing 565 will need to be supported, or at least the failure mode for when the 566 user makes a mistake should be as robust as possible, e.g. de- 567 activating a certain part of the infrastructure to allow the rest to 568 operate. In such cases, the user should ideally have some useful 569 indication of the failure mode encountered. 571 There should be no topology scenarios which cause loss of 572 connectivity, except when the user creates a physical island within 573 the topology. Some potentially pathological cases that can be 574 created include bridging ports of a router together, however this 575 case can be detected and dealt with by the router. Loops within a 576 routed topology are in a sense good in that they offer redundancy. 577 Bridging loops can be dangerous but are also detectable when a switch 578 learns the MAC of one of its interfaces on another or runs a spanning 579 tree or link state protocol. It is only loops using simple repeaters 580 that are truly pathological. 582 The topology of the homenet may change over time, due to the addition 583 or removal of equipment, but also due to temporary failures or 584 connectivity problems. In some cases this may lead to, for example, 585 a multihomed homenet being split into two isolated homenets, or, 586 after such a fault is remedied, two isolated parts reconfiguring back 587 to a single network. 589 3.2.2. Network topology models 591 Most IPv4 home network models at the time of writing tend to be 592 relatively simple, typically a single NAT router to the ISP and a 593 single internal subnet but, as discussed earlier, evolution in 594 network architectures is driving more complex topologies, such as the 595 separation of guest and private networks. There may also be some 596 cascaded IPv4 NAT scenarios, which we mention in the next section. 597 For IPv6 homenets, the network models described in [RFC6204] and its 598 successor RFC 6204-bis [I-D.ietf-v6ops-6204bis] should, as a minimum, 599 be supported. 601 There are a number of properties or attributes of a home network that 602 we can use to describe its topology and operation. The following 603 properties apply to any IPv6 home network: 605 o Presence of internal routers. The homenet may have one or more 606 internal routers, or may only provide subnetting from interfaces 607 on the CER. 609 o Presence of isolated internal subnets. There may be isolated 610 internal subnets, with no direct connectivity between them within 611 the homenet (with each having its own external connectivity). 612 Isolation may be physical, or implemented via IEEE 802.1q VLANs. 613 The latter is however not something a typical user would be 614 expected to configure. 616 o Demarcation of the CER. The CER(s) may or may not be managed by 617 the ISP. If the demarcation point is such that the customer can 618 provide or manage the CER, its configuration must be simple. Both 619 models must be supported. 621 Various forms of multihoming are likely to become more prevalent with 622 IPv6 home networks, as discussed further below. Thus the following 623 properties should also be considered for such networks: 625 o Number of upstream providers. The majority of home networks today 626 consist of a single upstream ISP, but it may become more common in 627 the future for there to be multiple ISPs, whether for resilience 628 or provision of additional services. Each would offer its own 629 prefix. Some may or may not provide a default route to the public 630 Internet. 632 o Number of CERs. The homenet may have a single CER, which might be 633 used for one or more providers, or multiple CERs. The presence of 634 multiple CERs adds additional complexity for multihoming 635 scenarios, and protocols like PCP that need to manage connection- 636 oriented state mappings. 638 In the following sections we give some examples of the types of 639 homenet topologies we may see in the future. This is not intended to 640 be an exhaustive or complete list, rather an indicative one to 641 facilitate the discussion in this text. 643 3.2.2.1. A: Single ISP, Single CER, Internal routers 645 Figure 1 shows a home network with multiple local area networks. 646 These may be needed for reasons relating to different link layer 647 technologies in use or for policy reasons, e.g. classic Ethernet in 648 one subnet and a LLN link layer technology in another. In this 649 example there is no single router that a priori understands the 650 entire topology. The topology itself may also be complex, and it may 651 not be possible to assume a pure tree form, for instance (because 652 home users may plug routers together to form arbitrary topologies 653 including loops). 655 +-------+-------+ \ 656 | Service | \ 657 | Provider | | Service 658 | Router | | Provider 659 +-------+-------+ | network 660 | / 661 | Customer / 662 | Internet connection 663 | 664 +------+--------+ \ 665 | IPv6 | \ 666 | Customer Edge | \ 667 | Router | | 668 +----+-+---+----+ | 669 Network A | | | Network B(E) | 670 ----+-------------+----+ | +---+-------------+------+ | 671 | | | | | | | 672 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | | 673 |IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | | 674 | H1 | | H2 | | | H3 | | H4 | | | 675 +----------+ +----------+ | +----------+ +----------+ | | 676 | | | | | 677 Link F | ---+------+------+-----+ | 678 | | Network E(B) | 679 +------+--------+ | | End-User 680 | IPv6 | | | networks 681 | Interior +------+ | 682 | Router | | 683 +---+-------+-+-+ | 684 Network C | | Network D | 685 ----+-------------+---+ +---+-------------+--- | 686 | | | | | 687 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 688 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 689 | H5 | | H6 | | H7 | | H8 | / 690 +----------+ +----------+ +----------+ +----------+ / 692 Figure 1 694 In this diagram there is one CER. It has a single uplink interface. 695 It has three additional interfaces connected to Network A, Link F, 696 and Network B. IPv6 Internal Router (IR) has four interfaces 697 connected to Link F, Network C, Network D and Network E. Network B 698 and Network E have been bridged, likely inadvertently. This could be 699 as a result of connecting a wire between a switch for Network B and a 700 switch for Network E. 702 Any of logical Networks A through F might be wired or wireless. 704 Where multiple hosts are shown, this might be through one or more 705 physical ports on the CER or IPv6 (IR), wireless networks, or through 706 one or more layer-2 only Ethernet switches. 708 3.2.2.2. B: Two ISPs, Two CERs, Shared subnet 710 +-------+-------+ +-------+-------+ \ 711 | Service | | Service | \ 712 | Provider A | | Provider B | | Service 713 | Router | | Router | | Provider 714 +------+--------+ +-------+-------+ | network 715 | | / 716 | Customer | / 717 | Internet connections | / 718 | | 719 +------+--------+ +-------+-------+ \ 720 | IPv6 | | IPv6 | \ 721 | Customer Edge | | Customer Edge | \ 722 | Router 1 | | Router 2 | / 723 +------+--------+ +-------+-------+ / 724 | | / 725 | | | End-User 726 ---+---------+---+---------------+--+----------+--- | network(s) 727 | | | | \ 728 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 729 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 730 | H1 | | H2 | | H3 | | H4 | / 731 +----------+ +----------+ +----------+ +----------+ 733 Figure 2 735 Figure 2 illustrates a multihomed homenet model, where the customer 736 has connectivity via CER1 to ISP A and via CER2 to ISP B. This 737 example shows one shared subnet where IPv6 nodes would potentially be 738 multihomed and receive multiple IPv6 global addresses, one per ISP. 739 This model may also be combined with that shown in Figure 1 to create 740 a more complex scenario with multiple internal routers. Or the above 741 shared subnet may be split in two, such that each CER serves a 742 separate isolated subnet, which is a scenario seen with some IPv4 743 networks today. 745 3.2.2.3. C: Two ISPs, One CER, Shared subnet 747 +-------+-------+ +-------+-------+ \ 748 | Service | | Service | \ 749 | Provider A | | Provider B | | Service 750 | Router | | Router | | Provider 751 +-------+-------+ +-------+-------+ | network 752 | | / 753 | Customer | / 754 | Internet | / 755 | connections | | 756 +---------+---------+ \ 757 | IPv6 | \ 758 | Customer Edge | \ 759 | Router | / 760 +---------+---------+ / 761 | / 762 | | End-User 763 ---+------------+-------+--------+-------------+--- | network(s) 764 | | | | \ 765 +----+-----+ +----+-----+ +----+-----+ +-----+----+ \ 766 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 767 | H1 | | H2 | | H3 | | H4 | / 768 +----------+ +----------+ +----------+ +----------+ 770 Figure 3 772 Figure 3 illustrates a model where a home network may have multiple 773 connections to multiple providers or multiple logical connections to 774 the same provider, with shared internal subnets. 776 In general, while the architecture may focus on likely common 777 topologies, it should not preclude any arbitrary topology from being 778 constructed. 780 3.2.3. Dual-stack topologies 782 It is expected that most homenet deployments will for the immediate 783 future be dual-stack IPv4/IPv6. In such networks it is important not 784 to introduce new IPv6 capabilities that would cause a failure if used 785 alongside IPv4+NAT, given that such dual-stack homenets will be 786 commonplace for some time. That said, it is desirable that IPv6 787 works better than IPv4 in as many scenarios as possible. Further, 788 the homenet architecture must operate in the absence of IPv4. 790 A general recommendation is to follow the same topology for IPv6 as 791 is used for IPv4, but not to use NAT. Thus there should be routed 792 IPv6 where an IPv4 NAT is used and, where there is no NAT, routing or 793 bridging may be used. Routing may have advantages when compared to 794 bridging together high speed and lower speed shared media, and in 795 addition bridging may not be suitable for some networks, such as ad- 796 hoc mobile networks. 798 In some cases IPv4 home networks may feature cascaded NATs. End 799 users are frequently unaware that they have created such networks as 800 'home routers' and 'home switches' are frequently confused. In 801 addition, there are cases where NAT routers are included within 802 Virtual Machine Hypervisors, or where Internet connection sharing 803 services have been enabled. This document applies equally to such 804 hidden NAT 'routers'. IPv6 routed versions of such cases will be 805 required. We should thus also note that routers in the homenet may 806 not be separate physical devices; they may be embedded within other 807 devices. 809 3.2.4. Multihoming 811 A homenet may be multihomed to multiple providers, as the network 812 models above illustrate. This may either take a form where there are 813 multiple isolated networks within the home or a more integrated 814 network where the connectivity selection needs to be dynamic. 815 Current practice is typically of the former kind, but the latter is 816 expected to become more commonplace. 818 In the general homenet architecture, multihomed hosts should be 819 multi-addressed with a global IPv6 address from the global prefix 820 delegated from each ISP they communicate with or through. When such 821 multi-addressing is in use, hosts need some way to pick source and 822 destination address pairs for connections. A host may choose a 823 source address to use by various methods, most commonly [RFC6724]. 824 Applications may of course do different things, and this should not 825 be precluded. 827 For the single CER Network Model C illustrated above, multihoming may 828 be offered by source routing at the CER. With multiple exit routers, 829 as in CER Network Model B, the complexity rises. Given a packet with 830 a source address on the home network, the packet must be routed to 831 the proper egress to avoid BCP 38 filtering if exiting through the 832 wrong ISP. It is highly desirable that the packet is routed in the 833 most efficient manner to the correct exit, though as a minimum 834 requirement the packet should not be dropped. 836 The homenet architecture should support both the above models, i.e. 837 one or more CERs. However, the general multihoming problem is broad, 838 and solutions suggested to date within the IETF have included complex 839 architectures for monitoring connectivity, traffic engineering, 840 identifier-locator separation, connection survivability across 841 multihoming events, and so on. It is thus important that the homenet 842 architecture should as far as possible minimise the complexity of any 843 multihoming support. 845 An example of such a 'simpler' approach has been documented in 846 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. Alternatively a 847 flooding/routing protocol could potentially be used to pass 848 information through the homenet, such that internal routers and 849 ultimately end hosts could learn per-prefix configuration 850 information, allowing better address selection decisions to be made. 851 However, this would imply router and, most likely, host changes. 852 Another avenue is to introduce support for source routing throughout 853 the homenet; while greatly improving the 'intelligence' of routing 854 decisions within the homenet, such an approach would require 855 relatively significant router changes but avoid host changes. 857 As explained previously, while NPTv6 has been proposed for providing 858 multi-homing support in networks, its use is not recommended in the 859 homenet architecture. 861 It should be noted that some multihoming scenarios may see one 862 upstream being a "walled garden", and thus only appropriate for 863 connectivity to the services of that provider; an example may be a 864 VPN service that only routes back to the enterprise business network 865 of a user in the homenet. While we should not specifically target 866 walled garden multihoming as a principal goal, it should not be 867 precluded. 869 The homenet architecture should also not preclude use of host or 870 application-oriented tools, e.g. Shim6 [RFC5533], MPTCP [RFC6824] or 871 Happy Eyeballs [RFC6555]. In general, any incremental improvements 872 obtained by host changes should give benefit for the hosts 873 introducing them, but not be required. 875 3.3. A Self-Organising Network 877 The home network architecture should be naturally self-organising and 878 self-configuring under different circumstances relating to the 879 connectivity status to the Internet, number of devices, and physical 880 topology. At the same time, it should be possible for advanced users 881 to manually adjust (override) the current configuration. 883 While a goal of the homenet architecture is for the network to be as 884 self-organising as possible, there may be instances where some manual 885 configuration is required, e.g. the entry of a cryptographic key to 886 apply wireless security, or to configure a shared routing secret. 887 The latter may be relevant when considering how to bootstrap a 888 routing configuration. It is highly desirable that the number of 889 such configurations is minimised. 891 3.3.1. Differentiating neighbouring homenets 893 It is important that self-configuration with 'unintended' devices is 894 avoided. There should be a way for a user to administratively assert 895 in a simple way whether or not a device belongs to a homenet. The 896 goal is to allow the establishment of borders, particularly between 897 two adjacent homenets, and to avoid unauthorised devices from 898 participating in the homenet. Such an authorisation capability may 899 need to operate through multiple hops in the homenet. 901 The homenet should thus support a way for a homenet owner to claim 902 ownership of their devices in a reasonably secure way. This could be 903 achieved by a pairing mechanism, by for example pressing buttons 904 simultaneously on an authenticated and a new homenet device. Or by 905 an enrolment process, as described in 906 [I-D.behringer-homenet-trust-bootstrap]. 908 3.3.2. Largest practical subnets 910 Today's IPv4 home networks generally have a single subnet, and early 911 dual-stack deployments have a single congruent IPv6 subnet, possibly 912 with some bridging functionality. More recently, some vendors have 913 started to introduce 'home' and 'guest' functions, which in IPv6 914 would be implemented as two subnets. 916 Future home networks are highly likely to have one or more internal 917 routers and thus need multiple subnets, for the reasons described 918 earlier. As part of the self-organisation of the network, the 919 homenet should subdivide itself to the largest practical subnets that 920 can be constructed within the constraints of link layer mechanisms, 921 bridging, physical connectivity, and policy, and where applicable 922 performance or other criteria. 924 While it may be desirable to maximise the chance of link-local 925 protocols operating across a homenet by maximising the size of a 926 subnet, multi-subnet home networks are inevitable, so their support 927 must be included. 929 3.3.3. Homenet realms and borders 931 The homenet will need to be aware of the extent of its own 'site', 932 which will, for example, define the borders for ULA and site scope 933 multicast traffic, and may require specific security policies to be 934 applied. The homenet will have one or more such borders with 935 external connectivity providers. 937 A homenet will most likely also have internal borders between 938 internal realms, e.g. a guest realm or a corporate network extension 939 realm. It should be possible to automatically discover these 940 borders, which will determine, for example, the scope of where 941 network prefixes, routing information, network traffic, service 942 discovery and naming may be shared. The default mode internally 943 should be to share everything. 945 It is expected that a realm would span at least an entire subnet, and 946 thus the borders lie at routers which receive delegated prefixes 947 within the homenet. It is also desirable for a richer security model 948 that hosts, which may be running in a transparent communication mode, 949 are able to make communication decisions based on available realm and 950 associated prefix information in the same way that routers at realm 951 borders can. 953 A simple homenet model may just consider three types of realm and the 954 borders between them, namely the internal homenet, the ISP and a 955 guest network. In this case the borders will include that from the 956 homenet to the ISP, that from the guest network to the ISP, and that 957 from the homenet to the guest network. Regardless, it should be 958 possible for additional types of realms and borders to be defined, 959 e.g. for some specific Grid or LLN-based network, and for these to be 960 detected automatically, and for an appropriate default policy to be 961 applied as to what type of traffic/data can flow across such borders. 963 It is desirable to classify the external border of the home network 964 as a unique logical interface separating the home network from 965 service provider network/s. This border interface may be a single 966 physical interface to a single service provider, multiple layer 2 967 sub-interfaces to a single service provider, or multiple connections 968 to a single or multiple providers. This border makes it possible to 969 describe edge operations and interface requirements across multiple 970 functional areas including security, routing, service discovery, and 971 router discovery. 973 Some initial proposals towards border discovery are presented in 974 [I-D.kline-default-perimeter]. 976 It should be possible for the homenet user to override any 977 automatically determined borders and the default policies applied 978 between them. 980 3.4. Homenet Addressing 982 The IPv6 addressing scheme used within a homenet must conform to the 983 IPv6 addressing architecture [RFC4291]. In this section we discuss 984 how the homenet needs to adapt to the prefixes made available to it 985 by its upstream ISP, such that internal subnets, hosts and devices 986 can obtain the and configure the necessary addressing information to 987 operate. 989 3.4.1. Use of ISP-delegated IPv6 prefixes 991 Discussion of IPv6 prefix allocation policies is included in 992 [RFC6177]. In practice, a homenet may receive an arbitrary length 993 IPv6 prefix from its provider, e.g. /60, /56 or /48. The offered 994 prefix may be stable or change from time to time; it is generally 995 expected that ISPs will offer relatively stable prefixes to their 996 residential customers. Regardless, the home network needs to be 997 adaptable as far as possible to ISP prefix allocation policies, and 998 thus make no assumptions about the stability of the prefix received 999 from an ISP, or the length of the prefix that may be offered. 1001 However, if, for example, only a /64 is offered by the ISP, the 1002 homenet may be severely constrained or even unable to function. 1003 [RFC6177] (BCP 157) states that "a key principle for address 1004 management is that end sites always be able to obtain a reasonable 1005 amount of address space for their actual and planned usage, and over 1006 time ranges specified in years rather than just months. In practice, 1007 that means at least one /64, and in most cases significantly more. 1008 One particular situation that must be avoided is having an end site 1009 feel compelled to use IPv6-to-IPv6 Network Address Translation or 1010 other burdensome address conservation techniques because it could not 1011 get sufficient address space." This architecture text assumes that 1012 this guidance is being followed by ISPs. 1014 There are many problems that would arise from a homenet not being 1015 offered a sufficient prefix size for its needs. Rather than attempt 1016 to contrive a method for a homenet to operate in a constrained manner 1017 when faced with insufficient prefixes, such as the use of subnet 1018 prefixes longer than /64 (which would break SLAAC), use of NPTv6, or 1019 falling back to bridging across potentially very different media, it 1020 is recommended that the receiving router instead enters an error 1021 state and issues appropriate warnings. Some consideration may need 1022 to be given to how such a warning or error state should best be 1023 presented to a typical home user. 1025 Thus a homenet CER should request, for example via DHCP-PD, that it 1026 would like a /48 prefix from its ISP, i.e. it asks the ISP for the 1027 maximum size prefix it might expect to be offered, even if in 1028 practice it may only be offered a /56 or /60. For a typical IPv6 1029 homenet, it is not recommended that an ISP offer less than a /60 1030 prefix, and it is highly preferable that the ISP offers at least a 1031 /56. It is expected that the allocated prefix to the homenet from 1032 any single ISP is a contiguous, aggregated one. While it may be 1033 possible for a homenet CER to issue multiple prefix requests to 1034 attempt to obtain multiple delegations, such behaviour is out of 1035 scope of this document. 1037 There are reports that some CER equipment does not support receipt of 1038 a prefix bigger than /64, but the homenet architecture is designed 1039 for future IPv6 home networks, and we assume that such restricted 1040 equipment will become rarer over time. 1042 It is expected that ISPs will deliver a relatively stable prefix to 1043 residential customers. The norm for residential customers of large 1044 ISPs may be similar to their single IPv4 address provision; by 1045 default it is likely to remain persistent for some time, but changes 1046 in the ISP's own provisioning systems may lead to the customer's IP 1047 (and in the IPv6 case their prefix pool) changing. It is not 1048 expected that ISPs will generally support Provider Independent (PI) 1049 addressing for residential homenets. 1051 When an ISP does need to restructure, and in doing so renumber its 1052 customer homenets, 'flash' renumbering is likely to be imposed. This 1053 implies a need for the homenet to be able to handle a sudden 1054 renumbering event which, unlike the process described in [RFC4192], 1055 would be a 'flag day" event, which means that a graceful renumbering 1056 process moving through a state with two active prefixes in use would 1057 not be possible. While renumbering can be viewed as an extended 1058 version of an initial numbering process, the difference between flash 1059 renumbering and an initial 'cold start' is the need to provide 1060 service continuity. 1062 There may be cases where local law means some ISPs are required to 1063 change IPv6 prefixes (current IPv4 addresses) for privacy reasons for 1064 their customers. In such cases it may be possible to avoid an 1065 instant 'flash' renumbering and plan a non-flag day renumbering as 1066 per RFC 4192. Similarly, if an ISP has a planned renumbering 1067 process, it may be able to adjust lease timers, etc appropriately. 1069 The customer may of course also choose to move to a new ISP, and thus 1070 begin using a new prefix. In such cases the customer should expect a 1071 discontinuity, and not only may the prefix change, but potentially 1072 also the prefix length if the new ISP offers a different default size 1073 prefix. The homenet may also be forced to renumber itself if 1074 significant internal 'replumbing' is undertaken by the user. 1075 Regardless, it's desirable that homenet protocols support rapid 1076 renumbering and that operational processes don't add unnecessary 1077 complexity for the renumbering process. Further, the introduction of 1078 any new homenet protocols should not make any form of renumbering any 1079 more complex than it already is. 1081 Finally, the internal operation of the home network should also not 1082 depend on the availability of the ISP network at any given time, 1083 other than of course for connectivity to services or systems off the 1084 home network. This reinforces the use of ULAs for stable internal 1085 communication, and the need for a naming and service discovery 1086 mechanism that can operate independently within the homenet. 1088 3.4.2. Stable internal IP addresses 1090 The network should by default attempt to provide IP-layer 1091 connectivity between all internal parts of the homenet as well as to 1092 and from the external Internet, subject to the filtering policies or 1093 other policy constraints discussed later in the security section. 1095 ULAs should be used within the scope of a homenet to support stable 1096 routing and connectivity between subnets and hosts regardless of 1097 whether a globally unique ISP-provided prefix is available. In the 1098 case of a prolonged external connectivity outage, ULAs allow internal 1099 operations across routed subnets to continue. ULA addresses also 1100 allow constrained LLN devices to create permanent relationships 1101 between IPv6 addresses, e.g. from a wall controller to a lamp, where 1102 symbolic host names would require additional non-volatile memory and 1103 updating global prefixes in sleeping LLN devices might also be 1104 problematic. 1106 As discussed previously, it would be expected that ULAs would 1107 normally be used alongside one or more global prefixes in a homenet, 1108 such that hosts become multi-addressed with both globally unique and 1109 ULA prefixes. ULAs should be used for all devices, not just those 1110 intended to only have internal connectivity. Default address 1111 selection would then enable ULAs to be preferred for internal 1112 communications between devices that are using ULA prefixes generated 1113 within the same homenet. 1115 In cases where ULA prefixes are in use within a homenet but there is 1116 no external IPv6 connectivity (and thus no GUAs in use), 1117 recommendations ULA-5, L-3 and L-4 in RFC 6204 should be followed to 1118 ensure correct operation, in particular where the homenet may be 1119 dual-stack with IPv4 external connectivity. The use of the Route 1120 Information Option described in [RFC4191] provides a mechanism to 1121 advertise such more-specific ULA routes. 1123 The use of ULAs should be restricted to the homenet scope through 1124 filtering at the border(s) of the homenet, as mandated by RFC 6024 1125 requirement S-2. 1127 Note that it is possible that in some cases multiple /48 ULA prefixes 1128 may be in use within the same homenet, e.g. when the network is being 1129 deployed, perhaps also without external connectivity. In cases where 1130 multiple ULA /48's are in use, hosts need to know that each /48 is 1131 local to the homenet, e.g. by inclusion in their local address 1132 selection policy table. 1134 3.4.3. Internal prefix delegation 1136 As mentioned above, there are various sources of prefixes. From the 1137 homenet perspective, a single global prefix from each ISP should be 1138 received on the border CER [RFC3633]. Where multiple CERs exist with 1139 multiple ISP prefix pools, it is expected that routers within the 1140 homenet would assign themselves prefixes from each ISP they 1141 communicate with/through. As discussed above, a ULA prefix should be 1142 provisioned for stable internal communications or for use on 1143 constrained/LLN networks. 1145 The delegation or availability of a prefix pool to the homenet should 1146 allow subsequent internal autonomous delegation of prefixes for use 1147 within the homenet. Such internal delegation should not assume a 1148 flat or hierarchical model, nor should it make an assumption about 1149 whether the delegation of internal prefixes is distributed or 1150 centralised. The assignment mechanism should provide reasonable 1151 efficiency, so that typical home network prefix allocation sizes can 1152 accommodate all the necessary /64 allocations in most cases, and not 1153 waste prefixes. Further, duplicate assignment of multiple /64s to 1154 the same network should be avoided, and the network should behave as 1155 gracefully as possible in the event of prefix exhaustion (though the 1156 options in such cases may be limited). 1158 Where the home network has multiple CERs and these are delegated 1159 prefix pools from their attached ISPs, the internal prefix delegation 1160 would be expected to be served by each CER for each prefix associated 1161 with it. However, where ULAs are used, most likely but not 1162 necessarily in parallel with global prefixes, one router should be 1163 elected as 'master' for delegation of ULA prefixes for the homenet, 1164 such that only one /48 ULA covers the whole homenet where possible. 1165 That router should generate a /48 ULA for the site, and then delegate 1166 /64's from that ULA prefix to subnets. In cases where two /48 ULAs 1167 are generated within a homenet, the network should still continue to 1168 function, meaning that hosts will need to determine that each ULA is 1169 local to the homenet. 1171 Delegation within the homenet should result in each link being 1172 assigned a stable prefix that is persistent across reboots, power 1173 outages and similar short-term outages. The availability of 1174 persistent prefixes should not depend on the router boot order. The 1175 addition of a new routing device should not affect existing 1176 persistent prefixes, but persistence may not be expected in the face 1177 of significant 'replumbing' of the homenet. However, delegated ULA 1178 prefixes within the homenet should remain persistent through an ISP- 1179 driven renumbering event. 1181 Provisioning such persistent prefixes may imply the need for stable 1182 storage on routing devices, and also a method for a home user to 1183 'reset' the stored prefix should a significant reconfiguration be 1184 required (though ideally the home user should not be involved at 1185 all). 1187 Several proposals have been made for prefix delegation within a 1188 homenet. One group of proposals is based on DHCPv6 PD, as described 1189 in [I-D.baker-homenet-prefix-assignment], [RFC3315] and [RFC3633]. 1190 DHCPv6 PD is also used by [I-D.grundemann-homenet-hipnet]. Another 1191 proposal uses OSPFv3, as described in 1192 [I-D.arkko-homenet-prefix-assignment] and 1193 [I-D.ietf-ospf-ospfv3-autoconfig]. 1195 The above methods assume that all router devices participating in a 1196 homenet use the same internal prefix delegation method. This implies 1197 that only one delegation method should be in use. 1199 3.4.4. Coordination of configuration information 1201 The network elements will need to be integrated in a way that takes 1202 account of the various lifetimes on timers that are used on different 1203 elements, e.g. DHCPv6 PD, router, valid prefix and preferred prefix 1204 timers. 1206 3.4.5. Privacy 1208 There are no specific privacy concerns discussed in this text. It 1209 should be noted that, in general, ISPs are expected to offer 1210 relatively stable IPv6 prefixes to customers, and thus the network 1211 prefix associated with the host addresses they use may not change 1212 over a reasonably long period of time. This exposure is similar to 1213 IPv4 networks that expose the same IPv4 global address via use of 1214 NAT, where the IPv4 address received from the ISP may change over 1215 time, but not necessarily that frequently. 1217 Hosts inside an IPv6 homenet may get new IPv6 addresses over time 1218 regardless, e.g. through Privacy Addresses [RFC4941]. This may 1219 benefit mutual privacy of users within a home network, but not mask 1220 which home network traffic is sourced from. 1222 3.5. Routing functionality 1224 Routing functionality is required when there are multiple routers 1225 deployed within the internal home network. This functionality could 1226 be as simple as the current 'default route is up' model of IPv4 NAT, 1227 or, more likely, it would involve running an appropriate routing 1228 protocol. Regardless of the solution method, the functionality 1229 discussed below should be met. 1231 The homenet unicast routing protocol should preferably be an existing 1232 deployed protocol that has been shown to be reliable and robust, and 1233 it is preferable that the protocol is both 'lightweight' and that 1234 open source implementations are readily available. It is desirable 1235 that the routing protocol has knowledge of the homenet topology, 1236 which implies a link-state protocol is preferable. This would mean 1237 the routing protocol gives a consistent view of the network, and that 1238 it can pass around more than just routing information. 1240 Multiple interface PHYs must be accounted for in the homenet routed 1241 topology. Technologies such as Ethernet, WiFi, MoCA, etc must be 1242 capable of coexisting in the same environment and should be treated 1243 as part of any routed deployment. The inclusion of the PHY layer 1244 characteristics including bandwidth, loss, and latency in path 1245 computation should be considered for optimising communication in the 1246 homenet. 1248 The routing protocol should support the generic use of multiple 1249 customer Internet connections, and the concurrent use of multiple 1250 delegated prefixes. A routing protocol that can make routing 1251 decisions based on source and destination addresses is thus 1252 desirable, to avoid upstream ISP BCP38 ingress filtering problems. 1253 Multihoming support should also include load-balancing to multiple 1254 providers, and failover from a primary to a backup link when 1255 available. The protocol however should not require upstream ISP 1256 connectivity to be established to continue routing within the 1257 homenet. 1259 The routing environment should be self-configuring, as discussed 1260 previously. An example of how OSPFv3 can be self-configuring in a 1261 homenet is described in [I-D.ietf-ospf-ospfv3-autoconfig]. 1262 Minimising convergence time should be a goal in any routed 1263 environment, but as a guideline a maximum convergence time at most 30 1264 seconds should be the target. 1266 As per prefix delegation, it is assumed that a single routing 1267 solution is in use in the homenet architecture. If there is an 1268 identified need to support multiple solutions, these must be 1269 interoperable. 1271 An appropriate mechanism is required to discover which router(s) in 1272 the homenet are providing the CER function. Borders may include but 1273 are not limited to the interface to the upstream ISP, a gateway 1274 device to a separate home network such as a LLN network, or a gateway 1275 to a guest or private corporate extension network. In some cases 1276 there may be no border present, which may for example occur before an 1277 upstream connection has been established. The border discovery 1278 functionality may be integrated into the routing protocol itself, but 1279 may also be imported via a separate discovery mechanism. 1281 In general, LLN or other networks should be able to attach and 1282 participate the same way as the main homenet, or alternatively map/be 1283 gatewayed to the main homenet. Current home deployments use largely 1284 different mechanisms in sensor and basic Internet connectivity 1285 networks. IPv6 VM solutions may also add additional routing 1286 requirements. 1288 3.5.1. Multicast support 1290 It is desirable that, subject to the capacities of devices on certain 1291 media types, multicast routing is supported across the homenet. The 1292 natural scopes for multicast would be link-local or site-local, with 1293 the latter constrained within the homenet, but other policy borders, 1294 e.g. to a guest subnet, or to certain media types, may also affect 1295 where specific multicast traffic is routed. 1297 There may be different drivers for multicast to be supported across 1298 the homenet, e.g. for service discovery should a proposal such as 1299 xmDNS [I-D.lynn-homenet-site-mdns] be deployed, or potentially for 1300 novel streaming or filesharing applications. Where multicast is 1301 routed across a homenet an appropriate multicast routing protocol is 1302 required, one that as per the unicast routing protocol should be 1303 self-configuring. It must be possible to scope or filter multicast 1304 traffic to avoid it being flooded to network media where devices 1305 cannot reasonably support it. 1307 The multicast environment should support the ability for applications 1308 to pick a unique multicast group to use. 1310 3.6. Security 1312 The security of an IPv6 homenet is an important consideration. The 1313 most notable difference to the IPv4 operational model is the removal 1314 of NAT, the introduction of global addressability of devices, and 1315 thus a need to consider whether devices should have global 1316 reachability. Regardless, hosts need to be able to operate securely, 1317 end-to-end where required, and also be robust against malicious 1318 traffic direct towards them. However, there are other challenges 1319 introduced, e.g. default filtering policies at the borders between 1320 various homenet realms. 1322 3.6.1. Addressability vs reachability 1324 An IPv6-based home network architecture should embrace the 1325 transparent end-to-end communications model as described in 1326 [RFC2775]. Each device should be globally addressable, and those 1327 addresses must not be altered in transit. However, security 1328 perimeters can be applied to restrict end-to-end communications, and 1329 thus while a host may be globally addressable it may not be globally 1330 reachable. 1332 [RFC4864] describes a 'Simple Security' model for IPv6 networks, 1333 whereby stateful perimeter filtering can be applied to control the 1334 reachability of devices in a homenet. RFC 4864 states in Section 4.2 1335 that "the use of firewalls ... is recommended for those that want 1336 boundary protection in addition to host defences". It should be 1337 noted that a 'default deny' filtering approach would effectively 1338 replace the need for IPv4 NAT traversal protocols with a need to use 1339 a signalling protocol to request a firewall hole be opened, e.g. a 1340 protocol such as UPnP or PCP [I-D.ietf-pcp-base]. In networks with 1341 multiple CERs, the signalling would need to handle the cases of flows 1342 that may use one or more exit routers. CERs would need to be able to 1343 advertise their existence for such protocols. 1345 [RFC6092] expands on RFC 4864, giving a more detailed discussion of 1346 IPv6 perimeter security recommendations, without mandating a 'default 1347 deny' approach. Indeed, RFC 6092 does not enforce a particular mode 1348 of operation, instead stating that CERs must provide an easily 1349 selected configuration option that permits a 'transparent' mode, thus 1350 ensuring a 'default allow' model is available. The homenet 1351 architecture text makes no recommendation on the default setting, and 1352 refers the reader to RFC 6092. 1354 3.6.2. Filtering at borders 1356 It is desirable that there are mechanisms to detect different types 1357 of borders within the homenet, as discussed previously, and further 1358 mechanisms to then apply different types of filtering policies at 1359 those borders, e.g. whether naming and service discovery should pass 1360 a given border. Any such policies should be able to be easily 1361 applied by typical home users, e.g. to give a user in a guest network 1362 access to media services in the home, or access to a printer. Simple 1363 mechanisms to apply policy changes, or associations between devices, 1364 will be required. 1366 There are cases where full internal connectivity may not be 1367 desirable, e.g. in certain utility networking scenarios, or where 1368 filtering is required for policy reasons against guest network 1369 subnet(s). Some scenarios/models may as a result involve running 1370 isolated subnet(s) with their own CERs. In such cases connectivity 1371 would only be expected within each isolated network (though traffic 1372 may potentially pass between them via external providers). 1374 LLNs provide an another example of where there may be secure 1375 perimeters inside the homenet. Constrained LLN nodes may implement 1376 network key security but may depend on access policies enforced by 1377 the LLN border router. 1379 3.6.3. Marginal Effectiveness of NAT and Firewalls 1381 Security by way of obscurity (address translation) or through 1382 firewalls (filtering) is at best marginally effective. The very poor 1383 security track record of home computer, home networking and business 1384 PC computers and networking is testimony to its ineffectiveness. A 1385 security compromise behind the firewall of any device exposes all 1386 others, making an entire network that relies on obscurity or a 1387 firewall as vulnerable as the most insecure device on the private 1388 side of the network. 1390 However, given home network products with very poor security, putting 1391 a firewall in place does provide some protection, even if only 1392 marginally effective. The use of firewalls today, whether a good 1393 practice or not, is common practice and whatever protection afforded, 1394 even if marginally effective, should not be lost. 1396 3.6.4. Device capabilities 1398 In terms of the devices, homenet hosts should implement their own 1399 security policies in accordance to their computing capabilities. 1400 They should have the means to request transparent communications to 1401 be able to be initiated to them through security filters in the 1402 homenet, either for all ports or for specific services. Users should 1403 have simple methods to associate devices to services that they wish 1404 to operate transparently through (CER) borders. 1406 3.6.5. ULAs as a hint of connection origin 1408 As noted in Section 3.6, if appropriate filtering is in place on the 1409 CER(s), as mandated by RFC 6024 requirement S-2, a ULA source address 1410 may be taken as an indication of locally sourced traffic. This 1411 indication could then be used with security settings to designate 1412 between which nodes a particular application is allowed to 1413 communicate, provided ULA address space is filtered appropriately at 1414 the boundary of the realm. 1416 3.7. Naming and Service Discovery 1418 The homenet requires devices to be able to determine and use unique 1419 names by which they can be accessed on the network. Users and 1420 devices will need to be able to discover devices and services 1421 available on the network, e.g. media servers, printers, displays or 1422 specific home automation devices. Thus naming and service discovery 1423 must be supported in the homenet, and, given the nature of typical 1424 home network users, the service(s) providing this function must as 1425 far as possible support unmanaged operation. 1427 The naming system will be required to work internally or externally, 1428 be the user within the homenet or outside it, i.e. the user should be 1429 able to refer to devices by name, and potentially connect to them, 1430 wherever they may be. The most natural way to think about such 1431 naming and service discovery is to enable it to work across the 1432 entire homenet residence (site), disregarding technical borders such 1433 as subnets but respecting policy borders such as those between guest 1434 and other internal network realms. Remote access may be desired by 1435 the homenet residents while travelling, but also potentially by 1436 manufacturers or other 'benevolent' third parties. 1438 3.7.1. Discovering services 1440 Users will typically perform service discovery through GUI interfaces 1441 that allow them to browse services on their network in an appropriate 1442 and intuitive way. Devices may also need to discover other devices, 1443 without any user intervention or choice. Either way, such interfaces 1444 are beyond the scope of this document, but the interface should have 1445 an appropriate API for the discovery to be performed. 1447 Such interfaces may also typically hide the local domain name element 1448 from users, especially where only one name space is available. 1449 However, as we discuss below, in some cases the ability to discover 1450 available domains may be useful. 1452 We note that current zero-configuration service discovery protocols 1453 are generally aimed at single subnets. There is thus a choice to 1454 make for multi-subnet homenets as to whether such protocols should be 1455 proxied or extended to operate across a whole homenet. In this 1456 context, that may mean bridging a link-local method, taking care to 1457 avoid loops, or extending the scope of multicast traffic used for the 1458 purpose. It may mean that some proxy or hybrid service is utilised, 1459 perhaps co-resident on the CER. Or it may be that a new approach is 1460 preferable, e.g. flooding information around the homenet as 1461 attributes within the routing protocol (which could allow per-prefix 1462 configuration). However, we should prefer approaches that are 1463 backwardly compatible, and allow current implementations to continue 1464 to be used. Note that this document does not mandate a particular 1465 solution, rather it expresses the principles that should be used for 1466 a homenet naming and service discovery environment. 1468 One of the primary challenges facing service discovery today is lack 1469 of interoperability due to the ever increasing number of service 1470 discovery protocols available. While it is conceivable for consumer 1471 devices to support multiple discovery protocols, this is clearly not 1472 the most efficient use of network and computational resources. One 1473 goal of the homenet architecture should be a path to service 1474 discovery protocol interoperability either through a standards based 1475 translation scheme, hooks into current protocols to allow some for of 1476 communication among discovery protocols, extensions to support a 1477 central service repository in the homenet, or simply convergence 1478 towards a unified protocol suite. 1480 3.7.2. Assigning names to devices 1482 Given the large number of devices that may be networked in the 1483 future, devices should have a means to generate their own unique 1484 names within a homenet, and to detect clashes should they arise, e.g. 1485 where a second device of the same type/vendor as an existing device 1486 with the same default name is deployed, or where two running network 1487 elements with such devices are suddenly joined. It is expected that 1488 a device should have a fixed name while within the scope of the 1489 homenet. 1491 Users will also want simple ways to (re)name devices, again most 1492 likely through an appropriate and intuitive interface that is beyond 1493 the scope of this document. Note the name a user assigns to a device 1494 may be a label that is stored on the device as an attribute of the 1495 device, and may be distinct from the name used in a name service, 1496 e.g. 'Study Laser Printer' as opposed to printer2.. 1498 3.7.3. Name spaces 1500 If access to homenet devices is required remotely from anywhere on 1501 the Internet, then at least one globally unique name space is 1502 required, though the use of multiple name spaces should not be 1503 precluded. The name space(s) should be served authoritatively by the 1504 homenet, most likely by a server resident on the CER. Such name 1505 spaces may be acquired by the user or provided/generated by their ISP 1506 or an alternative cloud-based service. It is likely that the default 1507 case is that a homenet will use a global domain provided by the ISP, 1508 but advanced users wishing to use a name space that is independent of 1509 their provider in the longer term should be able to acquire and use 1510 their own domain name. For users wanting to use their own 1511 independent domain names, such services are already available. 1513 Devices may also be assigned different names in different name 1514 spaces, e.g. by third parties who may manage systems or devices in 1515 the homenet on behalf of the resident(s). Remote management of the 1516 homenet is out of scope of this document. 1518 If however a global name space is not available, the homenet will 1519 need to pick and use a local name space which would only have meaning 1520 within the local homenet (i.e. it would not be used for remote access 1521 to the homenet). The .local name space currently has a special 1522 meaning for certain existing protocols which have link-local scope, 1523 and is thus not appropriate for multi-subnet home networks. A 1524 different name space is thus required for the homenet. 1526 One approach for picking a local name space is to use an Ambiguous 1527 Local Qualified Domain Name (ALQDN) space, such as .sitelocal (or an 1528 appropriate name reserved for the purpose). While this is a simple 1529 approach, there is the potential in principle for devices that are 1530 bookmarked somehow by an application in one homenet to be confused 1531 with a device with the same name in another homenet. In practice 1532 however the underlying service discovery protocols should be capable 1533 of handling moving to a network where a new device is using the same 1534 name as a device used previously in another homenet. 1536 An alternative approach for a local name space would be to use a 1537 Unique Locally Qualified Domain Name (ULQDN) space such as 1538 ..sitelocal. The could be generated in 1539 a variety of ways, one potentially being based on the local /48 ULA 1540 prefix being used across the homenet. Such a should 1541 survive a cold restart, i.e. be consistent after a network power- 1542 down, or, if a value is not set on startup, the CER or device running 1543 the name service should generate a default value. It would be 1544 desirable for the homenet user to be able to override the 1545 with a value of their choice, but that would increase 1546 the likelihood of a name conflict. 1548 In the (likely) event that the homenet is accessible from outside the 1549 homenet (using the global name space), it is vital that the homenet 1550 name space follow the rules and conventions of the global name space. 1551 In this mode of operation, names in the homenet (including those 1552 automatically generated by devices) must be usable as labels in the 1553 global name space. [RFC5890] describes considerations for 1554 Internationalizing Domain Names in Applications (IDNA). 1556 Also, with the introduction of new 'dotless' top level domains, there 1557 is also potential for ambiguity between, for example, a local host 1558 called 'computer' and (if it is registered) a .computer gTLD. Thus 1559 qualified names should always be used, whether these are exposed to 1560 the user or not. 1562 There may be use cases where either different name spaces may be 1563 desired for different realms in the homenet, or for segmentation of a 1564 single name space within the homenet. Thus hierarchical name space 1565 management is likely to be required. There should also be nothing to 1566 prevent individual device(s) being independently registered in 1567 external name spaces. 1569 Where a user is in a remote network wishing to access devices in 1570 their home network, there may be a requirement to consider the domain 1571 search order presented where multiple associated name spaces exist. 1572 This also implies that a domain discovery function is desirable. 1574 It may be the case that not all devices in the homenet are made 1575 available by name via an Internet name space, and that a 'split view' 1576 is preferred for certain devices. 1578 This document makes no assumption about the presence or omission of a 1579 reverse lookup service. There is an argument that it may be useful 1580 for presenting logging information to users with meaningful device 1581 names rather than literal addresses. 1583 3.7.4. The homenet name service 1585 The homenet name service should support both lookups and discovery. 1586 A lookup would operate via a direct query to a known service, while 1587 discovery may use multicast messages or a service where applications 1588 register in order to be found. 1590 It is highly desirable that the homenet name service must at the very 1591 least co-exist with the Internet name service. There should also be 1592 a bias towards proven, existing solutions. The strong implication is 1593 thus that the homenet service is DNS-based, or DNS-compatible. There 1594 are naming protocols that are designed to be configured and operate 1595 Internet-wide, like unicast-based DNS, but also protocols that are 1596 designed for zero-configuration local environments, like mDNS 1597 [RFC6762]. 1599 When DNS is used as the homenet name service, it includes both a 1600 resolving service and an authoritative service. The authoritative 1601 service hosts the homenet related zone. One approach when 1602 provisioning such a name service, which is designed to facilitate 1603 name resolution from the global Internet, is to run an authoritative 1604 name service on the CER and a secondary resolving name service 1605 provided by the ISP or perhaps a cloud-based third party. 1607 Where zeroconf name services are used, it is desirable that these can 1608 also coexist with the Internet name service. In particular, where 1609 the homenet is using a global name space, it is desirable that 1610 devices have the ability, where desired, to add entries to that name 1611 space. There should also be a mechanism for such entries to be 1612 removed or expired from the global name space. 1614 To protect against attacks such as cache poisoning, it is desirable 1615 to support appropriate name service security methods, including 1616 DNSSEC. 1618 Finally, the impact of a change in CER must be considered. It would 1619 be desirable to retain any relevant state (configuration) that was 1620 held in the old CER. This might imply that state information should 1621 be distributed in the homenet, to be recoverable by/to the new CER, 1622 or to the homenet's ISP or a third party cloud-based service by some 1623 means. 1625 3.7.5. Independent operation 1627 Name resolution and service discovery for reachable devices must 1628 continue to function if the local network is disconnected from the 1629 global Internet, e.g. a local media server should still be available 1630 even if the Internet link is down for an extended period. This 1631 implies the local network should also be able to perform a complete 1632 restart in the absence of external connectivity, and have local 1633 naming and service discovery operate correctly. 1635 The approach described above of a local authoritative name service 1636 with a cache would allow local operation for sustained ISP outages. 1638 Having an independent local trust anchor is desirable, to support 1639 secure exchanges should external connectivity be unavailable. 1641 A change in ISP should not affect local naming and service discovery. 1642 However, if the homenet uses a global name space provided by the ISP, 1643 then this will obviously have an impact if the user changes their 1644 network provider. 1646 3.7.6. Considerations for LLNs 1648 In some parts of the homenet, in particular LLNs or any devices where 1649 battery power is used, devices may be sleeping, in which case a proxy 1650 for such nodes may be required, that could respond (for example) to 1651 multicast service discovery requests. Those same devices or parts of 1652 the network may have less capacity for multicast traffic that may be 1653 flooded from other parts of the network. In general, message 1654 utilisation should be efficient considering the network technologies 1655 and constrained devices that the service may need to operate over. 1657 There are efforts underway to determine naming and discovery 1658 solutions for use by the Constrained Application Protocol (CoAP) in 1659 LLN networks. These are outside the scope of this document. 1661 3.7.7. DNS resolver discovery 1663 Automatic discovery of a name service to allow client devices in the 1664 homenet to resolve external domains on the Internet is required, and 1665 such discovery must support clients that may be a number of router 1666 hops away from the name service. Similarly the search domains for 1667 local FQDN-derived zones should be included. 1669 3.7.8. Devices roaming from the homenet 1671 It is likely that some devices which have registered names within the 1672 homenet Internet name space and that are mobile will attach to the 1673 Internet at other locations and acquire an IP address at those 1674 locations. In such cases it may be desirable that devices may be 1675 accessed by the same name as is used in the home network. 1677 Solutions to this problem are not discussed in this document. They 1678 may include use of Mobile IPv6, or Dynamic DNS, either of which would 1679 put additional requirements on to the homenet. 1681 3.8. Other Considerations 1683 This section discusses two other considerations for home networking 1684 that the architecture should not preclude, but that this text is 1685 neutral towards. 1687 3.8.1. Quality of Service 1689 Support for QoS in a multi-service homenet may be a requirement, e.g. 1690 for a critical system (perhaps healthcare related), or for 1691 differentiation between different types of traffic (file sharing, 1692 cloud storage, live streaming, VoIP, etc). Different media types may 1693 have different such properties or capabilities. 1695 However, homenet scenarios should require no new QoS protocols. A 1696 DiffServ [RFC2475] approach with a small number of predefined traffic 1697 classes may generally be sufficient, though at present there is 1698 little experience of QoS deployment in home networks. It is likely 1699 that QoS, or traffic prioritisation, methods will be required at the 1700 CER, and potentially around boundaries between different media types 1701 (where for example some traffic may simply not be appropriate for 1702 some media, and need to be dropped to avoid drowning the constrained 1703 media). 1705 There may also be complementary mechanisms that could be beneficial 1706 to application performance and behaviour in the homenet domain, such 1707 as ensuring proper buffering algorithms are used as described in 1708 [Gettys11]. 1710 3.8.2. Operations and Management 1712 The homenet should be self-organising and configuring as far as 1713 possible, and thus not be pro-actively managed by the home user. 1714 Thus protocols to manage the network are not discussed in this 1715 architecture text. 1717 However, users may be interested in the status of their networks and 1718 devices on the network, in which case simplified monitoring 1719 mechanisms may be desirable. It may also be the case that an ISP, or 1720 a third party, might offer management of the homenet on behalf of a 1721 user, in which case management protocols would be required. How such 1722 management is done is out of scope of this document; many solutions 1723 exist. 1725 3.9. Implementing the Architecture on IPv6 1727 This architecture text encourages re-use of existing protocols. Thus 1728 the necessary mechanisms are largely already part of the IPv6 1729 protocol set and common implementations, though there are some 1730 exceptions. 1732 For automatic routing, it is expected that solutions can be found 1733 based on existing protocols. Some relatively smaller updates are 1734 likely to be required, e.g. a new mechanism may be needed in order to 1735 turn a selected protocol on by default, a mechanism may be required 1736 to automatically assign prefixes to links within the homenet. 1738 Some functionality, if required by the architecture, may need more 1739 significant changes or require development of new protocols, e.g. 1740 support for multihoming with multiple exit routers would likely 1741 require extensions to support source and destination address based 1742 routing within the homenet. 1744 Some protocol changes are however required in the architecture, e.g. 1745 for name resolution and service discovery, extensions to existing 1746 zeroconf link-local name resolution protocols are needed to enable 1747 them to work across subnets, within the scope of the home network 1748 site. 1750 Some of the hardest problems in developing solutions for home 1751 networking IPv6 architectures include discovering the right borders 1752 where the 'home' domain ends and the service provider domain begins, 1753 deciding whether some of the necessary discovery mechanism extensions 1754 should affect only the network infrastructure or also hosts, and the 1755 ability to turn on routing, prefix delegation and other functions in 1756 a backwards compatible manner. 1758 4. Conclusions 1760 This text defines principles and requirements for a homenet 1761 architecture. The principles and requirements documented here should 1762 be observed by any future texts describing homenet protocols for 1763 routing, prefix management, security, naming or service discovery. 1765 5. References 1767 5.1. Normative References 1769 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1770 (IPv6) Specification", RFC 2460, December 1998. 1772 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1773 and M. Carney, "Dynamic Host Configuration Protocol for 1774 IPv6 (DHCPv6)", RFC 3315, July 2003. 1776 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1777 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1778 December 2003. 1780 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1781 (DHCP) Service for IPv6", RFC 3736, April 2004. 1783 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1784 Addresses", RFC 4193, October 2005. 1786 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1787 Architecture", RFC 4291, February 2006. 1789 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1790 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1791 May 2007. 1793 [RFC5890] Klensin, J., "Internationalized Domain Names for 1794 Applications (IDNA): Definitions and Document Framework", 1795 RFC 5890, August 2010. 1797 5.2. Informative References 1799 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1800 E. Lear, "Address Allocation for Private Internets", 1801 BCP 5, RFC 1918, February 1996. 1803 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1804 and W. Weiss, "An Architecture for Differentiated 1805 Services", RFC 2475, December 1998. 1807 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1808 February 2000. 1810 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1811 Defeating Denial of Service Attacks which employ IP Source 1812 Address Spoofing", BCP 38, RFC 2827, May 2000. 1814 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1815 Address Translator (Traditional NAT)", RFC 3022, 1816 January 2001. 1818 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1819 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1820 December 2003. 1822 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1823 More-Specific Routes", RFC 4191, November 2005. 1825 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1826 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1827 September 2005. 1829 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1830 Extensions for Stateless Address Autoconfiguration in 1831 IPv6", RFC 4941, September 2007. 1833 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1834 Shim Protocol for IPv6", RFC 5533, June 2009. 1836 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1837 Infrastructures (6rd) -- Protocol Specification", 1838 RFC 5969, August 2010. 1840 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1841 Customer Premises Equipment (CPE) for Providing 1842 Residential IPv6 Internet Service", RFC 6092, 1843 January 2011. 1845 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1846 "IPv6 Router Advertisement Options for DNS Configuration", 1847 RFC 6106, November 2010. 1849 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1850 IPv4/IPv6 Translation", RFC 6144, April 2011. 1852 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1853 Algorithm", RFC 6145, April 2011. 1855 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1856 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 1858 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1859 Troan, "Basic Requirements for IPv6 Customer Edge 1860 Routers", RFC 6204, April 2011. 1862 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1863 Translation", RFC 6296, June 2011. 1865 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1866 Stack Lite Broadband Deployments Following IPv4 1867 Exhaustion", RFC 6333, August 2011. 1869 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1870 Dual-Stack Hosts", RFC 6555, April 2012. 1872 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 1873 "Default Address Selection for Internet Protocol Version 6 1874 (IPv6)", RFC 6724, September 2012. 1876 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1877 February 2013. 1879 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1880 "TCP Extensions for Multipath Operation with Multiple 1881 Addresses", RFC 6824, January 2013. 1883 [I-D.lynn-homenet-site-mdns] 1884 Lynn, K. and D. Sturek, "Extended Multicast DNS", 1885 draft-lynn-homenet-site-mdns-01 (work in progress), 1886 September 2012. 1888 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] 1889 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 1890 Wing, "IPv6 Multihoming without Network Address 1891 Translation", 1892 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05 (work 1893 in progress), March 2013. 1895 [I-D.baker-homenet-prefix-assignment] 1896 Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small 1897 Networks", draft-baker-homenet-prefix-assignment-01 (work 1898 in progress), March 2012. 1900 [I-D.arkko-homenet-prefix-assignment] 1901 Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment 1902 in a Home Network", 1903 draft-arkko-homenet-prefix-assignment-03 (work in 1904 progress), October 2012. 1906 [I-D.ietf-ospf-ospfv3-autoconfig] 1907 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 1908 draft-ietf-ospf-ospfv3-autoconfig-02 (work in progress), 1909 April 2013. 1911 [I-D.ietf-pcp-base] 1912 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1913 Selkirk, "Port Control Protocol (PCP)", 1914 draft-ietf-pcp-base-29 (work in progress), November 2012. 1916 [I-D.grundemann-homenet-hipnet] 1917 Grundemann, C., Donley, C., Brzozowski, J., Howard, L., 1918 and V. Kuarsingh, "A Near Term Solution for Home IP 1919 Networking (HIPnet)", draft-grundemann-homenet-hipnet-01 1920 (work in progress), February 2013. 1922 [I-D.kline-default-perimeter] 1923 Kline, E., "Default Border Definition", 1924 draft-kline-default-perimeter-01 (work in progress), 1925 November 2012. 1927 [I-D.ietf-v6ops-6204bis] 1928 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1929 Requirements for IPv6 Customer Edge Routers", 1930 draft-ietf-v6ops-6204bis-12 (work in progress), 1931 October 2012. 1933 [I-D.behringer-homenet-trust-bootstrap] 1934 Behringer, M., Pritikin, M., and S. Bjarnason, 1935 "Bootstrapping Trust on a Homenet", 1936 draft-behringer-homenet-trust-bootstrap-00 (work in 1937 progress), October 2012. 1939 [Gettys11] 1940 Gettys, J., "Bufferbloat: Dark Buffers in the Internet", 1941 March 2011, 1942 . 1944 [IGD-2] UPnP Gateway Committee, "Internet Gateway Device (IGD) V 1945 2.0", September 2010, . 1948 Appendix A. Acknowledgments 1950 The authors would like to thank Aamer Akhter, Mark Andrews, Dmitry 1951 Anipko, Ran Atkinson, Fred Baker, Ray Bellis, Teco Boot, John 1952 Brzozowski, Cameron Byrne, Brian Carpenter, Stuart Cheshire, Lorenzo 1953 Colitti, Robert Cragie, Ralph Droms, Lars Eggert, Jim Gettys, Olafur 1954 Gudmundsson, Wassim Haddad, Joel M. Halpern, David Harrington, Lee 1955 Howard, Ray Hunter, Joel Jaeggli, Heather Kirksey, Ted Lemon, Acee 1956 Lindem, Kerry Lynn, Daniel Migault, Erik Nordmark, Michael 1957 Richardson, Mattia Rossi, Barbara Stark, Markus Stenberg, Sander 1958 Steffann, Don Sturek, Andrew Sullivan, Dave Taht, Dave Thaler, 1959 Michael Thomas, Mark Townsley, JP Vasseur, Curtis Villamizar, Dan 1960 Wing, Russ White, and James Woodyatt for their comments and 1961 contributions within homenet WG meetings and on the WG mailing list. 1962 An acknowledgement generally means that person's text made it in to 1963 the document, or was helpful in clarifying or reinforcing an aspect 1964 of the document. 1966 Appendix B. Changes 1968 This section will be removed in the final version of the text. 1970 B.1. Version 08 1972 Changes made include: 1974 o Various clarifications made in response to list comments 1976 o Added note on ULAs with IPv4, where no GUAs in use 1978 o Added note on naming and internationalisation (IDNA) 1980 o Added note on trust relationships when adding devices 1982 o Added note for MPTCP 1984 o Added various naming and SD notes 1985 o Added various notes on delegated ISP prefixes 1987 B.2. Version 07 1989 Changes made include: 1991 o Removed reference to NPTv6 in section 3.2.4. Instead now say it 1992 has an architectural cost to use in the earlier section, and thus 1993 it is not recommended for use in the homenet architecture. 1995 o Removed 'proxy or extend?' section. Included shorter text in main 1996 body, without mandating either approach for service discovery. 1998 o Made it clearer that ULAs are expected to be used alongside 1999 globals. 2001 o Removed reference to 'advanced security' as described in 2002 draft-vyncke-advanced-ipv6-security. 2004 o Balanced the text between ULQDN and ALQDN. 2006 o Clarify text does not assume default deny or allow on CER, but 2007 that either mode may be enabled. 2009 o Removed ULA-C reference for 'simple' addresses. Instead only 2010 suggested service discovery to find such devices. 2012 o Reiterated that single/multiple CER models to be supported for 2013 multihoming. 2015 o Reordered section 3.3 to improve flow. 2017 o Added recommendation that homenet is not allocated less than /60, 2018 and a /56 is preferable. 2020 o Tidied up first few intro sections. 2022 o Other minor edits from list feedback. 2024 B.3. Version 06 2026 Changes made include: 2028 o Stated that unmanaged goal is 'as far as possible'. 2030 o Added note about multiple /48 ULAs potentially being in use. 2032 o Minor edits from list feedback. 2034 B.4. Version 05 2036 Changes made include: 2038 o Some significant changes to naming and SD section. 2040 o Removed some expired drafts. 2042 o Added notes about issues caused by ISP only delegating a /64. 2044 o Recommended against using prefixes longer than /64. 2046 o Suggested CER asks for /48 by DHCP-PD, even if it only receives 2047 less. 2049 o Added note about DS-Lite but emphasised transition is out of 2050 scope. 2052 o Added text about multicast routing. 2054 B.5. Version 04 2056 Changes made include: 2058 o Moved border section from IPv6 differences to principles section. 2060 o Restructured principles into areas. 2062 o Added summary of naming and service discovery discussion from WG 2063 list. 2065 B.6. Version 03 2067 Changes made include: 2069 o Various improvements to the readability. 2071 o Removed bullet lists of requirements, as requested by chair. 2073 o Noted 6204bis has replaced advanced-cpe draft. 2075 o Clarified the topology examples are just that. 2077 o Emphasised we are not targetting walled gardens, but they should 2078 not be precluded. 2080 o Also changed text about requiring support for walled gardens. 2082 o Noted that avoiding falling foul of ingress filtering when 2083 multihomed is desirable. 2085 o Improved text about realms, detecting borders and policies at 2086 borders. 2088 o Stated this text makes no recommendation about default security 2089 model. 2091 o Added some text about failure modes for users plugging things 2092 arbitrarily. 2094 o Expanded naming and service discovery text. 2096 o Added more text about ULAs. 2098 o Removed reference to version 1 on chair feedback. 2100 o Stated that NPTv6 adds architectural cost but is not a homenet 2101 matter if deployed at the CER. This text only considers the 2102 internal homenet. 2104 o Noted multihoming is supported. 2106 o Noted routers may not by separate devices, they may be embedded in 2107 devices. 2109 o Clarified simple and advanced security some more, and RFC 4864 and 2110 6092. 2112 o Stated that there should be just one secret key, if any are used 2113 at all. 2115 o For multihoming, support multiple CERs but note that routing to 2116 the correct CER to avoid ISP filtering may not be optimal within 2117 the homenet. 2119 o Added some ISPs renumber due to privacy laws. 2121 o Removed extra repeated references to Simple Security. 2123 o Removed some solution creep on RIOs/RAs. 2125 o Load-balancing scenario added as to be supported. 2127 B.7. Version 02 2129 Changes made include: 2131 o Made the IPv6 implications section briefer. 2133 o Changed Network Models section to describe properties of the 2134 homenet with illustrative examples, rather than implying the 2135 number of models was fixed to the six shown in 01. 2137 o Text to state multihoming support focused on single CER model. 2138 Multiple CER support is desirable, but not required. 2140 o Stated that NPTv6 not supported. 2142 o Added considerations section for operations and management. 2144 o Added bullet point principles/requirements to Section 3.4. 2146 o Changed IPv6 solutions must not adversely affect IPv4 to should 2147 not. 2149 o End-to-end section expanded to talk about "Simple Security" and 2150 borders. 2152 o Extended text on naming and service discovery. 2154 o Added reference to RFC 2775, RFC 6177. 2156 o Added reference to the new xmDNS draft. 2158 o Added naming/SD requirements from Ralph Droms. 2160 Authors' Addresses 2162 Tim Chown (editor) 2163 University of Southampton 2164 Highfield 2165 Southampton, Hampshire SO17 1BJ 2166 United Kingdom 2168 Email: tjc@ecs.soton.ac.uk 2169 Jari Arkko 2170 Ericsson 2171 Jorvas 02420 2172 Finland 2174 Email: jari.arkko@piuha.net 2176 Anders Brandt 2177 Sigma Designs 2178 Emdrupvej 26A, 1 2179 Copenhagen DK-2100 2180 Denmark 2182 Email: abr@sdesigns.dk 2184 Ole Troan 2185 Cisco Systems, Inc. 2186 Drammensveien 145A 2187 Oslo N-0212 2188 Norway 2190 Email: ot@cisco.com 2192 Jason Weil 2193 Time Warner Cable 2194 13820 Sunrise Valley Drive 2195 Herndon, VA 20171 2196 USA 2198 Email: jason.weil@twcable.com