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