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