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