idnits 2.17.1 draft-ietf-homenet-arch-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2014) is 3577 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 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: January 5, 2015 Ericsson 6 A. Brandt 7 Sigma Designs 8 O. Troan 9 Cisco Systems, Inc. 10 J. Weil 11 Time Warner Cable 12 July 4, 2014 14 IPv6 Home Networking Architecture Principles 15 draft-ietf-homenet-arch-17 17 Abstract 19 This text describes evolving networking technology within residential 20 home networks with increasing numbers of devices and a trend towards 21 increased internal routing. The goal of this document is to define a 22 general architecture for IPv6-based home networking, describing the 23 associated principles, considerations and requirements. The text 24 briefly highlights specific implications of the introduction of IPv6 25 for home networking, discusses the elements of the architecture, and 26 suggests how standard IPv6 mechanisms and addressing can be employed 27 in home networking. The architecture describes the need for specific 28 protocol extensions for certain additional functionality. It is 29 assumed that the IPv6 home network is not actively managed, and runs 30 as an IPv6-only or dual-stack network. There are no recommendations 31 in this text for the IPv4 part of the network. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 5, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 5 69 2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . 6 70 2.1. Multiple subnets and routers . . . . . . . . . . . . . . 7 71 2.2. Global addressability and elimination of NAT . . . . . . 8 72 2.3. Multi-Addressing of devices . . . . . . . . . . . . . . . 8 73 2.4. Unique Local Addresses (ULAs) . . . . . . . . . . . . . . 9 74 2.5. Avoiding manual configuration of IP addresses . . . . . . 10 75 2.6. IPv6-only operation . . . . . . . . . . . . . . . . . . . 11 76 3. Homenet Architecture Principles . . . . . . . . . . . . . . . 11 77 3.1. General Principles . . . . . . . . . . . . . . . . . . . 12 78 3.1.1. Reuse existing protocols . . . . . . . . . . . . . . 12 79 3.1.2. Minimise changes to hosts and routers . . . . . . . . 12 80 3.2. Homenet Topology . . . . . . . . . . . . . . . . . . . . 13 81 3.2.1. Supporting arbitrary topologies . . . . . . . . . . . 13 82 3.2.2. Network topology models . . . . . . . . . . . . . . . 13 83 3.2.3. Dual-stack topologies . . . . . . . . . . . . . . . . 18 84 3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 19 85 3.2.5. Mobility support . . . . . . . . . . . . . . . . . . 20 86 3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 20 87 3.3.1. Differentiating neighbouring homenets . . . . . . . . 21 88 3.3.2. Largest practical subnets . . . . . . . . . . . . . . 21 89 3.3.3. Handling varying link technologies . . . . . . . . . 22 90 3.3.4. Homenet realms and borders . . . . . . . . . . . . . 22 91 3.3.5. Configuration information from the ISP . . . . . . . 23 92 3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . 23 93 3.4.1. Use of ISP-delegated IPv6 prefixes . . . . . . . . . 24 94 3.4.2. Stable internal IP addresses . . . . . . . . . . . . 26 95 3.4.3. Internal prefix delegation . . . . . . . . . . . . . 27 96 3.4.4. Coordination of configuration information . . . . . . 28 97 3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28 99 3.5. Routing functionality . . . . . . . . . . . . . . . . . . 28 100 3.5.1. Unicast Routing Within the Homenet . . . . . . . . . 29 101 3.5.2. Unicast Routing at the Homenet Border . . . . . . . . 31 102 3.5.3. Multicast support . . . . . . . . . . . . . . . . . . 31 103 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 32 104 3.6.1. Addressability vs reachability . . . . . . . . . . . 32 105 3.6.2. Filtering at borders . . . . . . . . . . . . . . . . 33 106 3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . 33 107 3.6.4. Exfiltration concerns . . . . . . . . . . . . . . . . 34 108 3.6.5. Device capabilities . . . . . . . . . . . . . . . . . 34 109 3.6.6. ULAs as a hint of connection origin . . . . . . . . . 34 110 3.7. Naming and Service Discovery . . . . . . . . . . . . . . 34 111 3.7.1. Discovering services . . . . . . . . . . . . . . . . 35 112 3.7.2. Assigning names to devices . . . . . . . . . . . . . 36 113 3.7.3. The homenet name service . . . . . . . . . . . . . . 36 114 3.7.4. Name spaces . . . . . . . . . . . . . . . . . . . . . 37 115 3.7.5. Independent operation . . . . . . . . . . . . . . . . 39 116 3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 40 117 3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . 40 118 3.7.8. Devices roaming to/from the homenet . . . . . . . . . 40 119 3.8. Other Considerations . . . . . . . . . . . . . . . . . . 41 120 3.8.1. Quality of Service . . . . . . . . . . . . . . . . . 41 121 3.8.2. Operations and Management . . . . . . . . . . . . . . 41 122 3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 42 123 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 43 124 5. Security Considerations . . . . . . . . . . . . . . . . . . . 43 125 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 126 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 127 7.1. Normative References . . . . . . . . . . . . . . . . . . 43 128 7.2. Informative References . . . . . . . . . . . . . . . . . 44 129 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 47 130 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 47 131 B.1. Version 17 . . . . . . . . . . . . . . . . . . . . . . . 47 132 B.2. Version 16 . . . . . . . . . . . . . . . . . . . . . . . 47 133 B.3. Version 15 . . . . . . . . . . . . . . . . . . . . . . . 47 134 B.4. Version 14 . . . . . . . . . . . . . . . . . . . . . . . 48 135 B.5. Version 13 . . . . . . . . . . . . . . . . . . . . . . . 48 136 B.6. Version 12 . . . . . . . . . . . . . . . . . . . . . . . 48 137 B.7. Version 11 (after IESG review) . . . . . . . . . . . . . 48 138 B.8. Version 10 (after AD review) . . . . . . . . . . . . . . 49 139 B.9. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 49 140 B.10. Version 08 . . . . . . . . . . . . . . . . . . . . . . . 49 141 B.11. Version 07 . . . . . . . . . . . . . . . . . . . . . . . 50 142 B.12. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 51 143 B.13. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 51 144 B.14. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 51 145 B.15. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 51 146 B.16. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 53 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 150 1. Introduction 152 This document focuses on evolving networking technology within 153 residential home networks with increasing numbers of devices and a 154 trend towards increased internal routing, and the associated 155 challenges with their deployment and operation. There is a growing 156 trend in home networking for the proliferation of networking 157 technology through an increasingly broad range of devices and media. 158 This evolution in scale and diversity sets requirements on IETF 159 protocols. Some of these requirements relate to the introduction of 160 IPv6, others to the introduction of specialised networks for home 161 automation and sensors. 163 While at the time of writing some complex home network topologies 164 exist, most are relatively simple single subnet networks, and 165 ostensibly operate using just IPv4. While there may be IPv6 traffic 166 within the network, e.g., for service discovery, the homenet is 167 provisioned by the ISP as an IPv4 network. Such networks also 168 typically employ solutions that should be avoided, such as private 169 [RFC1918] addressing with (cascaded) network address translation 170 (NAT) [RFC3022], or they may require expert assistance to set up. 172 In contrast, emerging IPv6-capable home networks are very likely to 173 have multiple internal subnets, e.g., to facilitate private and guest 174 networks, heterogeneous link layers, and smart grid components, and 175 have enough address space available to allow every device to have a 176 globally unique address. This implies that internal routing 177 functionality is required, and that the homenet's ISP both provides a 178 large enough prefix to allocate a prefix to each subnet, and that a 179 method is supported for such prefixes to be delegated efficiently to 180 those subnets. 182 It is not practical to expect home users to configure their networks. 183 Thus the assumption of this document is that the homenet is as far as 184 possible self-organising and self-configuring, i.e., it should 185 function without pro-active management by the residential user. 187 The architectural constructs in this document are focused on the 188 problems to be solved when introducing IPv6, with an eye towards a 189 better result than what we have today with IPv4, as well as aiming at 190 a more consistent solution that addresses as many of the identified 191 requirements as possible. The document aims to provide the basis and 192 guiding principles for how standard IPv6 mechanisms and addressing 193 [RFC2460] [RFC4291] can be employed in home networking, while 194 coexisting with existing IPv4 mechanisms. In emerging dual-stack 195 home networks it is vital that introducing IPv6 does not adversely 196 affect IPv4 operation. We assume that the IPv4 network architecture 197 in home networks is what it is, and can not be modified by new 198 recommendations. This document does not discuss how IPv4 home 199 networks provision or deliver support for multiple subnets. It 200 should not be assumed that any future new functionality created with 201 IPv6 in mind will be backward-compatible to include IPv4 support. 202 Further, future deployments, or specific subnets within an otherwise 203 dual-stack home network, may be IPv6-only, in which case 204 considerations for IPv4 impact would not apply. 206 This document proposes a baseline homenet architecture, using 207 protocols and implementations that are as far as possible proven and 208 robust. The scope of the document is primarily the network layer 209 technologies that provide the basic functionality to enable 210 addressing, connectivity, routing, naming and service discovery. 211 While it may, for example, state that homenet components must be 212 simple to deploy and use, it does not discuss specific user 213 interfaces, nor does it discuss specific physical, wireless or data- 214 link layer considerations. Likewise, we also do not specify the 215 whole design of a homenet router from top to bottom, rather we focus 216 on the Layer 3 aspects. This means that Layer 2 is largely out of 217 scope, we're assuming a data link layer that supports IPv6 is 218 present, and that we react accordingly. Any IPv6-over-Foo 219 definitions occur elsewhere. 221 [RFC7084], which has obsoleted [RFC6204], defines basic requirements 222 for customer edge routers (CERs). The update includes the definition 223 of requirements for specific transition tools on the CER, 224 specifically DS-Lite [RFC6333] and 6rd [RFC5969]. Such detailed 225 specification of CER devices is considered out of scope of this 226 architecture document, and we assume that any required update of the 227 CER device specification as a result of adopting this architecture 228 will be handled as separate and specific updates to these existing 229 documents. Further, the scope of this text is the internal homenet, 230 and thus specific features on the WAN side of the CER are out of 231 scope for this text. 233 1.1. Terminology and Abbreviations 235 In this section we define terminology and abbreviations used 236 throughout the text. 238 o Border: a point, typically resident on a router, between two 239 networks, e.g., between the main internal homenet and a guest 240 network. This defines point(s) at which filtering and forwarding 241 policies for different types of traffic may be applied. 243 o CER: Customer Edge Router: A border router intended for use in a 244 homenet, which connects the homenet to a service provider network. 246 o FQDN: Fully Qualified Domain Name. A globally unique name. 248 o Guest network: A part of the home network intended for use by 249 visitors or guests to the home(net). Devices on the guest network 250 may typically not see or be able to use all services in the 251 home(net). 253 o Homenet: A home network, comprising host and router equipment, 254 with one or more CERs providing connectivity to service provider 255 network(s). 257 o Internet Service Provider (ISP): an entity that provides access to 258 the Internet. In this document, a service provider specifically 259 offers Internet access using IPv6, and may also offer IPv4 260 Internet access. The service provider can provide such access 261 over a variety of different transport methods such as DSL, cable, 262 wireless, and others. 264 o LLN: Low-power and lossy network. 266 o LQDN: Locally Qualified Domain Name. A name local to the homenet. 268 o NAT: Network Address Translation. Typically referring to IPv4 269 Network Address and Port Translation (NAPT) [RFC3022]. 271 o NPTv6: Network Prefix Translation for IPv6 [RFC6296]. 273 o PCP: Port Control Protocol [RFC6887]. 275 o Realm: a network delimited by a defined border. A guest network 276 within a homenet may form one realm. 278 o 'Simple Security'. Defined in [RFC4864] and expanded further in 279 [RFC6092]; describes recommended perimeter security capabilities 280 for IPv6 networks. 282 o ULA: IPv6 Unique Local Address [RFC4193]. 284 o VM: Virtual machine. 286 2. Effects of IPv6 on Home Networking 288 While IPv6 resembles IPv4 in many ways, there are some notable 289 differences in the way it may typically be deployed. It changes 290 address allocation principles, making multi-addressing the norm, and, 291 through the vastly increased address space, allows globally unique IP 292 addresses to be used for all devices in a home network. This section 293 presents an overview of some of the key implications of the 294 introduction of IPv6 for home networking, that are simultaneously 295 both promising and problematic. 297 2.1. Multiple subnets and routers 299 While simple layer 3 topologies involving as few subnets as possible 300 are preferred in home networks, the incorporation of dedicated 301 (routed) subnets remains necessary for a variety of reasons. For 302 instance, an increasingly common feature in modern home routers is 303 the ability to support both guest and private network subnets. 304 Likewise, there may be a need to separate home automation or 305 corporate extension LANs (whereby a home worker can have their 306 corporate network extended into the home using a virtual private 307 network, commonly presented as one port on an Ethernet device) from 308 the main Internet access network, or different subnets may in general 309 be associated with parts of the homenet that have different routing 310 and security policies. Further, link layer networking technology is 311 poised to become more heterogeneous, as networks begin to employ both 312 traditional Ethernet technology and link layers designed for low- 313 power and lossy networks (LLNs), such as those used for certain types 314 of sensor devices. Constraining the flow of certain traffic from 315 Ethernet links to much lower capacity links thus becomes an important 316 topic. 318 The introduction of IPv6 for home networking makes it possible for 319 every home network to be delegated enough address space from its ISP 320 to provision globally unique prefixes for each such subnet in the 321 home. While the number of addresses in a standard /64 IPv6 prefix is 322 practically unlimited, the number of prefixes available for 323 assignment to the home network is not. As a result the growth 324 inhibitor for the home network shifts from the number of addresses to 325 the number of prefixes offered by the provider; this topic is 326 discussed in [RFC6177] (BCP 157), which recommends that "end sites 327 always be able to obtain a reasonable amount of address space for 328 their actual and planned usage". 330 The addition of routing between subnets raises a number of issues. 331 One is a method by which prefixes can be efficiently allocated to 332 each subnet, without user intervention. Another is the issue of how 333 to extend mechanisms such as zero configuration service discovery 334 which currently only operate within a single subnet using link-local 335 traffic. In a typical IPv4 home network, there is only one subnet, 336 so such mechanisms would normally operate as expected. For multi- 337 subnet IPv6 home networks there are two broad choices to enable such 338 protocols to work across the scope of the entire homenet; extend 339 existing protocols to work across that scope, or introduce proxies 340 for existing link layer protocols. This topic is discussed in 341 Section 3.7. 343 2.2. Global addressability and elimination of NAT 345 The possibility for direct end-to-end communication on the Internet 346 to be restored by the introduction of IPv6 is on the one hand an 347 incredible opportunity for innovation and simpler network operation, 348 but on the other hand it is also a concern as it potentially exposes 349 nodes in the internal networks to receipt of unwanted and possibly 350 malicious traffic from the Internet. 352 With devices and applications able to talk directly to each other 353 when they have globally unique addresses, there may be an expectation 354 of improved host security to compensate for this. It should be noted 355 that many devices may (for example) ship with default settings that 356 make them readily vulnerable to compromise by external attackers if 357 globally accessible, or may simply not have robustness designed-in 358 because it was either assumed such devices would only be used on 359 private networks or the device itself doesn't have the computing 360 power to apply the necessary security methods. In addition, the 361 upgrade cycle for devices (or their firmware) may be slow, and/or 362 lack auto-update mechanisms. 364 It is thus important to distinguish between addressability and 365 reachability. While IPv6 offers global addressability through use of 366 globally unique addresses in the home, whether devices are globally 367 reachable or not would depend on any firewall or filtering 368 configuration, and not, as is commonly the case with IPv4, the 369 presence or use of NAT. In this respect, IPv6 networks may or may 370 not have filters applied at their borders to control such traffic, 371 i.e., at the homenet CER. [RFC4864] and [RFC6092] discuss such 372 filtering, and the merits of 'default allow' against 'default deny' 373 policies for external traffic initiated into a homenet. This topic 374 is discussed further in Section 3.6.1. 376 2.3. Multi-Addressing of devices 378 In an IPv6 network, devices will often acquire multiple addresses, 379 typically at least a link-local address and one or more globally 380 unique addresses. Where a homenet is multihomed, a device would 381 typically receive a globally unique address (GUA) from within the 382 delegated prefix from each upstream ISP. Devices may also have an 383 IPv4 address if the network is dual-stack, an IPv6 Unique Local 384 Address (ULA) [RFC4193] (see below), and one or more IPv6 Privacy 385 Addresses [RFC4941]. 387 It should thus be considered the norm for devices on IPv6 home 388 networks to be multi-addressed, and to need to make appropriate 389 address selection decisions for the candidate source and destination 390 address pairs for any given connection. In multihoming scenarios 391 nodes will be configured with one address from each upstream ISP 392 prefix. In such cases the presence of upstream BCP 38 [RFC2827] 393 ingress filtering requires such multi-addressed nodes to select the 394 correct source address to be used for the corresponding uplink. 395 Default Address Selection for IPv6 [RFC6724] provides a solution for 396 this, but a challenge here is that the node may not have the 397 information it needs to make that decision based on addresses alone. 398 We discuss this challenge in Section 3.2.4. 400 2.4. Unique Local Addresses (ULAs) 402 [RFC4193] defines Unique Local Addresses (ULAs) for IPv6 that may be 403 used to address devices within the scope of a single site. Support 404 for ULAs for IPv6 CERs is described in [RFC7084]. A home network 405 running IPv6 should deploy ULAs alongside its globally unique 406 prefix(es) to allow stable communication between devices (on 407 different subnets) within the homenet where that externally allocated 408 globally unique prefix may change over time, e.g., due to renumbering 409 within the subscriber's ISP, or where external connectivity may be 410 temporarily unavailable. A homenet using provider-assigned global 411 addresses is exposed to its ISP renumbering the network to a much 412 larger degree than before whereas, for IPv4, NAT isolated the user 413 against ISP renumbering to some extent. 415 While setting up a network there may be a period where it has no 416 external connectivity, in which case ULAs would be required for 417 inter-subnet communication. In the case where home automation 418 networks are being set up in a new home/deployment (as early as 419 during construction of the home), such networks will likely need to 420 use their own /48 ULA prefix. Depending upon circumstances beyond 421 the control of the owner of the homenet, it may be impossible to 422 renumber the ULA used by the home automation network so routing 423 between ULA /48s may be required. Also, some devices, particularly 424 constrained devices, may have only a ULA (in addition to a link- 425 local), while others may have both a GUA and a ULA. 427 Note that unlike private IPv4 RFC 1918 space, the use of ULAs does 428 not imply use of an IPv6 equivalent of a traditional IPv4 NAT 429 [RFC3022], or of NPTv6 prefix-based NAT [RFC6296]. When an IPv6 node 430 in a homenet has both a ULA and a globally unique IPv6 address, it 431 should only use its ULA address internally, and use its additional 432 globally unique IPv6 address as a source address for external 433 communications. This should be the natural behaviour given support 434 for Default Address Selection for IPv6 [RFC6724]. By using such 435 globally unique addresses between hosts and devices in remote 436 networks, the architectural cost and complexity, particularly to 437 applications, of NAT or NPTv6 translation is avoided. As such, 438 neither IPv6 NAT or NPTv6 is recommended for use in the homenet 439 architecture. Further, the homenet border router(s) should filter 440 packets with ULA source/destination addresses as discussed in 441 Section 3.4.2. 443 Devices in a homenet may be given only a ULA as a means to restrict 444 reachability from outside the homenet. ULAs can be used by default 445 for devices that, without additional configuration (e.g., via a web 446 interface), would only offer services to the internal network. For 447 example, a printer might only accept incoming connections on a ULA 448 until configured to be globally reachable, at which point it acquires 449 a global IPv6 address and may be advertised via a global name space. 451 Where both a ULA and a global prefix are in use, the ULA source 452 address is used to communicate with ULA destination addresses when 453 appropriate, i.e., when the ULA source and destination lie within the 454 /48 ULA prefix(es) known to be used within the same homenet. In 455 cases where multiple /48 ULA prefixes are in use within a single 456 homenet (perhaps because multiple homenet routers each independently 457 auto-generate a /48 ULA prefix and then share prefix/routing 458 information), utilising a ULA source address and a ULA destination 459 address from two disjoint internal ULA prefixes is preferable to 460 using GUAs. 462 While a homenet should operate correctly with two or more /48 ULAs 463 enabled, a mechanism for the creation and use of a single /48 ULA 464 prefix is desirable for addressing consistency and policy 465 enforcement. 467 A counter-argument to using ULAs is that it is undesirable to 468 aggressively deprecate global prefixes for temporary loss of 469 connectivity, so for a host to lose its global address there would 470 have to be a connection breakage longer than the lease period, and 471 even then, deprecating prefixes when there is no connectivity may not 472 be advisable. However, it is assumed in this architecture that 473 homenets should support and use ULAs. 475 2.5. Avoiding manual configuration of IP addresses 477 Some IPv4 home networking devices expose IPv4 addresses to users, 478 e.g., the IPv4 address of a home IPv4 CER that may be configured via 479 a web interface. In potentially complex future IPv6 homenets, users 480 should not be expected to enter IPv6 literal addresses in devices or 481 applications, given their much greater length and the apparent 482 randomness of such addresses to a typical home user. Thus, even for 483 the simplest of functions, simple naming and the associated (minimal, 484 and ideally zero configuration) discovery of services is imperative 485 for the easy deployment and use of homenet devices and applications. 487 2.6. IPv6-only operation 489 It is likely that IPv6-only networking will be deployed first in new 490 home network deployments, often referred to as 'greenfield' 491 scenarios, where there is no existing IPv4 capability, or perhaps as 492 one element of an otherwise dual-stack network. Running IPv6-only 493 adds additional requirements, e.g., for devices to get configuration 494 information via IPv6 transport (not relying on an IPv4 protocol such 495 as IPv4 DHCP), and for devices to be able to initiate communications 496 to external devices that are IPv4-only. 498 Some specific transition technologies which may be deployed by the 499 homenet's ISP are discussed in [RFC7084]. In addition, certain other 500 functions may be desirable on the CER, e.g., to access content in the 501 IPv4 Internet, NAT64 [RFC6144] and DNS64 [RFC6145] may be applicable. 503 The widespread availability of robust solutions to these types of 504 requirements will help accelerate the uptake of IPv6-only homenets. 505 The specifics of these are however beyond the scope of this document, 506 especially those functions that reside on the CER. 508 3. Homenet Architecture Principles 510 The aim of this text is to outline how to construct advanced IPv6- 511 based home networks involving multiple routers and subnets using 512 standard IPv6 addressing and protocols [RFC2460] [RFC4291] as the 513 basis. As described in Section 3.1, solutions should as far as 514 possible re-use existing protocols, and minimise changes to hosts and 515 routers, but some new protocols, or extensions, are likely to be 516 required. In this section, we present the elements of the proposed 517 home networking architecture, with discussion of the associated 518 design principles. 520 In general, home network equipment needs to be able to operate in 521 networks with a range of different properties and topologies, where 522 home users may plug components together in arbitrary ways and expect 523 the resulting network to operate. Significant manual configuration 524 is rarely, if at all, possible, or even desirable given the knowledge 525 level of typical home users. Thus the network should, as far as 526 possible, be self-configuring, though configuration by advanced users 527 should not be precluded. 529 The homenet needs to be able to handle or provision at least 530 o Routing 532 o Prefix configuration for routers 534 o Name resolution 536 o Service discovery 538 o Network security 540 The remainder of this document describes the principles by which the 541 homenet architecture may deliver these properties. 543 3.1. General Principles 545 There is little that the Internet standards community can do about 546 the physical topologies or the need for some networks to be separated 547 at the network layer for policy or link layer compatibility reasons. 548 However, there is a lot of flexibility in using IP addressing and 549 inter-networking mechanisms. This text discusses how such 550 flexibility should be used to provide the best user experience and 551 ensure that the network can evolve with new applications in the 552 future. The principles described in this text should be followed 553 when designing homenet protocol solutions. 555 3.1.1. Reuse existing protocols 557 Existing protocols will be used to meet the requirements of home 558 networks. Where necessary, extensions will be made to those 559 protocols. When no existing protocol is found to be suitable, a new 560 or emerging protocol may be used. Therefore, it is important that no 561 design or architectural decisions are made that would preclude the 562 use of new or emerging protocols. 564 A generally conservative approach, giving weight to running (and 565 available) code, is preferable. Where new protocols are required, 566 evidence of commitment to implementation by appropriate vendors or 567 development communities is highly desirable. Protocols used should 568 be backwardly compatible, and forward compatible where changes are 569 made. 571 3.1.2. Minimise changes to hosts and routers 573 In order to maximise deployability of new homenets, where possible 574 any requirement for changes to hosts and routers should be minimised, 575 though solutions which, for example, incrementally improve capability 576 with host or router changes may be acceptable. There may be cases 577 where changes are unavoidable, e.g., to allow a given homenet routing 578 protocol to be self-configuring, or to support routing based on 579 sources addresses in addition to destination addresses (to improve 580 multihoming support, as discussed in Section 3.2.4). 582 3.2. Homenet Topology 584 This section considers homenet topologies, and the principles that 585 may be applied in designing an architecture to support as wide a 586 range of such topologies as possible. 588 3.2.1. Supporting arbitrary topologies 590 There should ideally be no built-in assumptions about the topology in 591 home networks, as users are capable of connecting their devices in 592 'ingenious' ways. Thus arbitrary topologies and arbitrary routing 593 will need to be supported, or at least the failure mode for when the 594 user makes a mistake should be as robust as possible, e.g., de- 595 activating a certain part of the infrastructure to allow the rest to 596 operate. In such cases, the user should ideally have some useful 597 indication of the failure mode encountered. 599 There should be no topology scenarios which cause loss of 600 connectivity, except when the user creates a physical island within 601 the topology. Some potentially pathological cases that can be 602 created include bridging ports of a router together, however this 603 case can be detected and dealt with by the router. Loops within a 604 routed topology are in a sense good in that they offer redundancy. 605 Topologies that include potential bridging loops can be dangerous but 606 are also detectable when a switch learns the MAC of one of its 607 interfaces on another or runs a spanning tree or link state protocol. 608 It is only topologies with such potential loops using simple 609 repeaters that are truly pathological. 611 The topology of the homenet may change over time, due to the addition 612 or removal of equipment, but also due to temporary failures or 613 connectivity problems. In some cases this may lead to, for example, 614 a multihomed homenet being split into two isolated homenets, or, 615 after such a fault is remedied, two isolated parts reconfiguring back 616 to a single network. 618 3.2.2. Network topology models 620 As hinted above, while the architecture may focus on likely common 621 topologies, it should not preclude any arbitrary topology from being 622 constructed. 624 Most IPv4 home network models at the time of writing tend to be 625 relatively simple, typically a single NAT router to the ISP and a 626 single internal subnet but, as discussed earlier, evolution in 627 network architectures is driving more complex topologies, such as the 628 separation of guest and private networks. There may also be some 629 cascaded IPv4 NAT scenarios, which we mention in the next section. 630 For IPv6 homenets, the Network Architectures described in [RFC7084] 631 should, as a minimum, be supported. 633 There are a number of properties or attributes of a home network that 634 we can use to describe its topology and operation. The following 635 properties apply to any IPv6 home network: 637 o Presence of internal routers. The homenet may have one or more 638 internal routers, or may only provide subnetting from interfaces 639 on the CER. 641 o Presence of isolated internal subnets. There may be isolated 642 internal subnets, with no direct connectivity between them within 643 the homenet (with each having its own external connectivity). 644 Isolation may be physical, or implemented via IEEE 802.1q VLANs. 645 The latter is however not something a typical user would be 646 expected to configure. 648 o Demarcation of the CER. The CER(s) may or may not be managed by 649 the ISP. If the demarcation point is such that the customer can 650 provide or manage the CER, its configuration must be simple. Both 651 models must be supported. 653 Various forms of multihoming are likely to become more prevalent with 654 IPv6 home networks, where the homenet may have two or more external 655 ISP connections, as discussed further below. Thus the following 656 properties should also be considered for such networks: 658 o Number of upstream providers. The majority of home networks today 659 consist of a single upstream ISP, but it may become more common in 660 the future for there to be multiple ISPs, whether for resilience 661 or provision of additional services. Each would offer its own 662 prefix. Some may or may not provide a default route to the public 663 Internet. 665 o Number of CERs. The homenet may have a single CER, which might be 666 used for one or more providers, or multiple CERs. The presence of 667 multiple CERs adds additional complexity for multihoming 668 scenarios, and protocols like PCP that may need to manage 669 connection-oriented state mappings on the same CER as used for 670 subsequent traffic flows. 672 In the following sections we give some examples of the types of 673 homenet topologies we may see in the future. This is not intended to 674 be an exhaustive or complete list, rather an indicative one to 675 facilitate the discussion in this text. 677 3.2.2.1. A: Single ISP, Single CER, Internal routers 679 Figure 1 shows a home network with multiple local area networks. 680 These may be needed for reasons relating to different link layer 681 technologies in use or for policy reasons, e.g., classic Ethernet in 682 one subnet and a LLN link layer technology in another. In this 683 example there is no single router that a priori understands the 684 entire topology. The topology itself may also be complex, and it may 685 not be possible to assume a pure tree form, for instance (because 686 home users may plug routers together to form arbitrary topologies 687 including those with potential loops in them). 689 +-------+-------+ \ 690 | Service | \ 691 | Provider | | Service 692 | Router | | Provider 693 +-------+-------+ | network 694 | / 695 | Customer / 696 | Internet connection 697 | 698 +------+--------+ \ 699 | IPv6 | \ 700 | Customer Edge | \ 701 | Router | | 702 +----+-+---+----+ | 703 Network A | | | Network B(E) | 704 ----+-------------+----+ | +---+-------------+------+ | 705 | | | | | | | 706 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | | 707 |IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | | 708 | H1 | | H2 | | | H3 | | H4 | | | 709 +----------+ +----------+ | +----------+ +----------+ | | 710 | | | | | 711 Link F | ---+------+------+-----+ | 712 | | Network E(B) | 713 +------+--------+ | | End-User 714 | IPv6 | | | networks 715 | Interior +------+ | 716 | Router | | 717 +---+-------+-+-+ | 718 Network C | | Network D | 719 ----+-------------+---+ +---+-------------+--- | 720 | | | | | 721 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 722 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 723 | H5 | | H6 | | H7 | | H8 | / 724 +----------+ +----------+ +----------+ +----------+ / 726 Figure 1 728 In this diagram there is one CER. It has a single uplink interface. 729 It has three additional interfaces connected to Network A, Link F, 730 and Network B. IPv6 Internal Router (IR) has four interfaces 731 connected to Link F, Network C, Network D and Network E. Network B 732 and Network E have been bridged, likely inadvertently. This could be 733 as a result of connecting a wire between a switch for Network B and a 734 switch for Network E. 736 Any of logical Networks A through F might be wired or wireless. 737 Where multiple hosts are shown, this might be through one or more 738 physical ports on the CER or IPv6 (IR), wireless networks, or through 739 one or more layer-2 only Ethernet switches. 741 3.2.2.2. B: Two ISPs, Two CERs, Shared subnet 743 +-------+-------+ +-------+-------+ \ 744 | Service | | Service | \ 745 | Provider A | | Provider B | | Service 746 | Router | | Router | | Provider 747 +------+--------+ +-------+-------+ | network 748 | | / 749 | Customer | / 750 | Internet connections | / 751 | | 752 +------+--------+ +-------+-------+ \ 753 | IPv6 | | IPv6 | \ 754 | Customer Edge | | Customer Edge | \ 755 | Router 1 | | Router 2 | / 756 +------+--------+ +-------+-------+ / 757 | | / 758 | | | End-User 759 ---+---------+---+---------------+--+----------+--- | network(s) 760 | | | | \ 761 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 762 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 763 | H1 | | H2 | | H3 | | H4 | / 764 +----------+ +----------+ +----------+ +----------+ 766 Figure 2 768 Figure 2 illustrates a multihomed homenet model, where the customer 769 has connectivity via CER1 to ISP A and via CER2 to ISP B. This 770 example shows one shared subnet where IPv6 nodes would potentially be 771 multihomed and receive multiple IPv6 global prefixes, one per ISP. 772 This model may also be combined with that shown in Figure 1 to create 773 a more complex scenario with multiple internal routers. Or the above 774 shared subnet may be split in two, such that each CER serves a 775 separate isolated subnet, which is a scenario seen with some IPv4 776 networks today. 778 3.2.2.3. C: Two ISPs, One CER, Shared subnet 779 +-------+-------+ +-------+-------+ \ 780 | Service | | Service | \ 781 | Provider A | | Provider B | | Service 782 | Router | | Router | | Provider 783 +-------+-------+ +-------+-------+ | network 784 | | / 785 | Customer | / 786 | Internet | / 787 | connections | 788 +---------+---------+ \ 789 | IPv6 | \ 790 | Customer Edge | \ 791 | Router | / 792 +---------+---------+ / 793 | / 794 | | End-User 795 ---+------------+-------+--------+-------------+--- | network(s) 796 | | | | \ 797 +----+-----+ +----+-----+ +----+-----+ +-----+----+ \ 798 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 799 | H1 | | H2 | | H3 | | H4 | / 800 +----------+ +----------+ +----------+ +----------+ 802 Figure 3 804 Figure 3 illustrates a model where a home network may have multiple 805 connections to multiple providers or multiple logical connections to 806 the same provider, with shared internal subnets. 808 3.2.3. Dual-stack topologies 810 It is expected that most homenet deployments will for the immediate 811 future be dual-stack IPv4/IPv6. In such networks it is important not 812 to introduce new IPv6 capabilities that would cause a failure if used 813 alongside IPv4+NAT, given that such dual-stack homenets will be 814 commonplace for some time. That said, it is desirable that IPv6 815 works better than IPv4 in as many scenarios as possible. Further, 816 the homenet architecture must operate in the absence of IPv4. 818 A general recommendation is to follow the same topology for IPv6 as 819 is used for IPv4, but not to use NAT. Thus there should be routed 820 IPv6 where an IPv4 NAT is used and, where there is no NAT, routing or 821 bridging may be used. Routing may have advantages when compared to 822 bridging together high speed and lower speed shared media, and in 823 addition bridging may not be suitable for some networks, such as ad- 824 hoc mobile networks. 826 In some cases IPv4 home networks may feature cascaded NATs. End 827 users are frequently unaware that they have created such networks as 828 'home routers' and 'home switches' are frequently confused. In 829 addition, there are cases where NAT routers are included within 830 Virtual Machine Hypervisors, or where Internet connection sharing 831 services have been enabled. This document applies equally to such 832 hidden NAT 'routers'. IPv6 routed versions of such cases will be 833 required. We should thus also note that routers in the homenet may 834 not be separate physical devices; they may be embedded within other 835 devices. 837 3.2.4. Multihoming 839 A homenet may be multihomed to multiple providers, as the network 840 models above illustrate. This may either take a form where there are 841 multiple isolated networks within the home or a more integrated 842 network where the connectivity selection needs to be dynamic. 843 Current practice is typically of the former kind, but the latter is 844 expected to become more commonplace. 846 In the general homenet architecture, multihomed hosts should be 847 multi-addressed with a global IPv6 address from the global prefix 848 delegated from each ISP they communicate with or through. When such 849 multi-addressing is in use, hosts need some way to pick source and 850 destination address pairs for connections. A host may choose a 851 source address to use by various methods, most commonly [RFC6724]. 852 Applications may of course do different things, and this should not 853 be precluded. 855 For the single CER Network Model C illustrated above, multihoming may 856 be offered by source-based routing at the CER. With multiple exit 857 routers, as in CER Network Model B, the complexity rises. Given a 858 packet with a source address on the home network, the packet must be 859 routed to the proper egress to avoid BCP 38 ingress filtering if 860 exiting through the wrong ISP. It is highly desirable that the 861 packet is routed in the most efficient manner to the correct exit, 862 though as a minimum requirement the packet should not be dropped. 864 The homenet architecture should support both the above models, i.e., 865 one or more CERs. However, the general multihoming problem is broad, 866 and solutions suggested to date within the IETF have included complex 867 architectures for monitoring connectivity, traffic engineering, 868 identifier-locator separation, connection survivability across 869 multihoming events, and so on. It is thus important that the homenet 870 architecture should as far as possible minimise the complexity of any 871 multihoming support. 873 An example of such a 'simpler' approach has been documented in 874 [RFC7157]. Alternatively a flooding/routing protocol could 875 potentially be used to pass information through the homenet, such 876 that internal routers and ultimately end hosts could learn per-prefix 877 configuration information, allowing better address selection 878 decisions to be made. However, this would imply router and, most 879 likely, host changes. Another avenue is to introduce support 880 throughout the homenet for routing which is based on the source as 881 well as the destination address of each packet. While greatly 882 improving the 'intelligence' of routing decisions within the homenet, 883 such an approach would require relatively significant router changes 884 but avoid host changes. 886 As explained previously, while NPTv6 has been proposed for providing 887 multi-homing support in networks, its use is not recommended in the 888 homenet architecture. 890 It should be noted that some multihoming scenarios may see one 891 upstream being a "walled garden", and thus only appropriate for 892 connectivity to the services of that provider; an example may be a 893 VPN service that only routes back to the enterprise business network 894 of a user in the homenet. As per Section 4.2.1 of [RFC3002] we do 895 not specifically target walled garden multihoming as a goal of this 896 document. 898 The homenet architecture should also not preclude use of host or 899 application-oriented tools, e.g., Shim6 [RFC5533], MPTCP [RFC6824] or 900 Happy Eyeballs [RFC6555]. In general, any incremental improvements 901 obtained by host changes should give benefit for the hosts 902 introducing them, but not be required. 904 3.2.5. Mobility support 906 Devices may be mobile within the homenet. While resident on the same 907 subnet, their address will remain persistent, but should devices move 908 to a different (wireless) subnet, they will acquire a new address in 909 that subnet. It is desirable that the homenet supports internal 910 device mobility. To do so, the homenet may either extend the reach 911 of specific wireless subnets to enable wireless roaming across the 912 home (availability of a specific subnet across the home), or it may 913 support mobility protocols to facilitate such roaming where multiple 914 subnets are used. 916 3.3. A Self-Organising Network 918 The home network infrastructure should be naturally self-organising 919 and self-configuring under different circumstances relating to the 920 connectivity status to the Internet, number of devices, and physical 921 topology. At the same time, it should be possible for advanced users 922 to manually adjust (override) the current configuration. 924 While a goal of the homenet architecture is for the network to be as 925 self-organising as possible, there may be instances where some manual 926 configuration is required, e.g., the entry of a cryptographic key to 927 apply wireless security, or to configure a shared routing secret. 928 The latter may be relevant when considering how to bootstrap a 929 routing configuration. It is highly desirable that the number of 930 such configurations is minimised. 932 3.3.1. Differentiating neighbouring homenets 934 It is important that self-configuration with 'unintended' devices is 935 avoided. There should be a way for a user to administratively assert 936 in a simple way whether or not a device belongs to a given homenet. 937 The goal is to allow the establishment of borders, particularly 938 between two adjacent homenets, and to avoid unauthorised devices from 939 participating in the homenet. Such an authorisation capability may 940 need to operate through multiple hops in the homenet. 942 The homenet should thus support a way for a homenet owner to claim 943 ownership of their devices in a reasonably secure way. This could be 944 achieved by a pairing mechanism, by for example pressing buttons 945 simultaneously on an authenticated and a new homenet device, or by an 946 enrolment process as part of an autonomic networking environment. 948 While there may be scenarios where one homenet may wish to 949 intentionally gain access through another, e.g. to share external 950 connectivity costs, such scenarios are not discussed in this 951 document. 953 3.3.2. Largest practical subnets 955 Today's IPv4 home networks generally have a single subnet, and early 956 dual-stack deployments have a single congruent IPv6 subnet, possibly 957 with some bridging functionality. More recently, some vendors have 958 started to introduce 'home' and 'guest' functions, which in IPv6 959 would be implemented as two subnets. 961 Future home networks are highly likely to have one or more internal 962 routers and thus need multiple subnets, for the reasons described 963 earlier. As part of the self-organisation of the network, the 964 homenet should subdivide itself into the largest practical subnets 965 that can be constructed within the constraints of link layer 966 mechanisms, bridging, physical connectivity, and policy, and where 967 applicable performance or other criteria. In such subdivisions the 968 logical topology may not necessarily match the physical topology. 970 This text does not, however, make recommendations on how such 971 subdivision should occur. It is expected that subsequent documents 972 will address this problem. 974 While it may be desirable to maximise the chance of link-local 975 protocols operating across a homenet by maximising the size of a 976 subnet, multi-subnet home networks are inevitable, so their support 977 must be included. 979 3.3.3. Handling varying link technologies 981 Homenets tend to grow organically over many years, and a homenet will 982 typically be built over link-layer technologies from different 983 generations. Current homenets typically use links ranging from 984 1Mbit/s up to 1Gbit/s, which is a three orders of magnitude 985 throughput discrepancy. We expect this discrepancy to widen further 986 as both high-speed and low-power technologies are deployed. 988 Homenet protocols should be designed to deal well with 989 interconnecting links of very different throughputs. In particular, 990 flows local to a link should not be flooded throughout the homenet, 991 even when sent over multicast, and, whenever possible, the homenet 992 protocols should be able to choose the faster links and avoid the 993 slower ones. 995 Links (particularly wireless links) may also have limited numbers of 996 transmit opportunities (txops), and there is a clear trend driven by 997 both power and downward compatibility constraints toward aggregation 998 of packets into these limited txops while increasing throughput. 999 Transmit opportunities may be a system's scarcest resource and 1000 therefore also strongly limit actual throughput available. 1002 3.3.4. Homenet realms and borders 1004 The homenet will need to be aware of the extent of its own 'site', 1005 which will, for example, define the borders for ULA and site scope 1006 multicast traffic, and may require specific security policies to be 1007 applied. The homenet will have one or more such borders with 1008 external connectivity providers. 1010 A homenet will most likely also have internal borders between 1011 internal realms, e.g., a guest realm or a corporate network extension 1012 realm. It is desirable that appropriate borders can be configured to 1013 determine, for example, the scope of where network prefixes, routing 1014 information, network traffic, service discovery and naming may be 1015 shared. The default mode internally should be to share everything. 1017 It is expected that a realm would span at least an entire subnet, and 1018 thus the borders lie at routers which receive delegated prefixes 1019 within the homenet. It is also desirable, for a richer security 1020 model, that hosts are able to make communication decisions based on 1021 available realm and associated prefix information in the same way 1022 that routers at realm borders can. 1024 A simple homenet model may just consider three types of realm and the 1025 borders between them, namely the internal homenet, the ISP and a 1026 guest network. In this case the borders will include that from the 1027 homenet to the ISP, that from the guest network to the ISP, and that 1028 from the homenet to the guest network. Regardless, it should be 1029 possible for additional types of realms and borders to be defined, 1030 e.g., for some specific LLN-based network, such as Smart Grid, and 1031 for these to be detected automatically, and for an appropriate 1032 default policy to be applied as to what type of traffic/data can flow 1033 across such borders. 1035 It is desirable to classify the external border of the home network 1036 as a unique logical interface separating the home network from 1037 service provider network/s. This border interface may be a single 1038 physical interface to a single service provider, multiple layer 2 1039 sub-interfaces to a single service provider, or multiple connections 1040 to a single or multiple providers. This border makes it possible to 1041 describe edge operations and interface requirements across multiple 1042 functional areas including security, routing, service discovery, and 1043 router discovery. 1045 It should be possible for the homenet user to override any 1046 automatically determined borders and the default policies applied 1047 between them, the exception being that it may not be possible to 1048 override policies defined by the ISP at the external border. 1050 3.3.5. Configuration information from the ISP 1052 In certain cases, it may be useful for the homenet to get certain 1053 configuration information from its ISP. For example, the homenet 1054 DHCP server may request and forward some options that it gets from 1055 its upstream DHCP server, though the specifics of the options may 1056 vary across deployments. There is potential complexity here of 1057 course should the homenet be multihomed. 1059 3.4. Homenet Addressing 1061 The IPv6 addressing scheme used within a homenet must conform to the 1062 IPv6 addressing architecture [RFC4291]. In this section we discuss 1063 how the homenet needs to adapt to the prefixes made available to it 1064 by its upstream ISP, such that internal subnets, hosts and devices 1065 can obtain the and configure the necessary addressing information to 1066 operate. 1068 3.4.1. Use of ISP-delegated IPv6 prefixes 1070 Discussion of IPv6 prefix allocation policies is included in 1071 [RFC6177]. In practice, a homenet may receive an arbitrary length 1072 IPv6 prefix from its provider, e.g., /60, /56 or /48. The offered 1073 prefix may be stable or change from time to time; it is generally 1074 expected that ISPs will offer relatively stable prefixes to their 1075 residential customers. Regardless, the home network needs to be 1076 adaptable as far as possible to ISP prefix allocation policies, and 1077 thus make no assumptions about the stability of the prefix received 1078 from an ISP, or the length of the prefix that may be offered. 1080 However, if, for example, only a /64 is offered by the ISP, the 1081 homenet may be severely constrained or even unable to function. 1082 [RFC6177] (BCP 157) states that "a key principle for address 1083 management is that end sites always be able to obtain a reasonable 1084 amount of address space for their actual and planned usage, and over 1085 time ranges specified in years rather than just months. In practice, 1086 that means at least one /64, and in most cases significantly more. 1087 One particular situation that must be avoided is having an end site 1088 feel compelled to use IPv6-to-IPv6 Network Address Translation or 1089 other burdensome address conservation techniques because it could not 1090 get sufficient address space." This architecture document assumes 1091 that the guidance in the quoted text is being followed by ISPs. 1093 There are many problems that would arise from a homenet not being 1094 offered a sufficient prefix size for its needs. Rather than attempt 1095 to contrive a method for a homenet to operate in a constrained manner 1096 when faced with insufficient prefixes, such as the use of subnet 1097 prefixes longer than /64 (which would break stateless address 1098 autoconfiguration [RFC4862]), use of NPTv6, or falling back to 1099 bridging across potentially very different media, it is recommended 1100 that the receiving router instead enters an error state and issues 1101 appropriate warnings. Some consideration may need to be given to how 1102 such a warning or error state should best be presented to a typical 1103 home user. 1105 Thus a homenet CER should request, for example via DHCP Prefix 1106 Delegation (DHCP PD) [RFC3633], that it would like a /48 prefix from 1107 its ISP, i.e., it asks the ISP for the maximum size prefix it might 1108 expect to be offered, even if in practice it may only be offered a 1109 /56 or /60. For a typical IPv6 homenet, it is not recommended that 1110 an ISP offer less than a /60 prefix, and it is highly preferable that 1111 the ISP offers at least a /56. It is expected that the allocated 1112 prefix to the homenet from any single ISP is a contiguous, aggregated 1113 one. While it may be possible for a homenet CER to issue multiple 1114 prefix requests to attempt to obtain multiple delegations, such 1115 behaviour is out of scope of this document. 1117 The norm for residential customers of large ISPs may be similar to 1118 their single IPv4 address provision; by default it is likely to 1119 remain persistent for some time, but changes in the ISP's own 1120 provisioning systems may lead to the customer's IP (and in the IPv6 1121 case their prefix pool) changing. It is not expected that ISPs will 1122 generally support Provider Independent (PI) addressing for 1123 residential homenets. 1125 When an ISP does need to restructure, and in doing so renumber its 1126 customer homenets, 'flash' renumbering is likely to be imposed. This 1127 implies a need for the homenet to be able to handle a sudden 1128 renumbering event which, unlike the process described in [RFC4192], 1129 would be a 'flag day" event, which means that a graceful renumbering 1130 process moving through a state with two active prefixes in use would 1131 not be possible. While renumbering can be viewed as an extended 1132 version of an initial numbering process, the difference between flash 1133 renumbering and an initial 'cold start' is the need to provide 1134 service continuity. 1136 There may be cases where local law means some ISPs are required to 1137 change IPv6 prefixes (current IPv4 addresses) for privacy reasons for 1138 their customers. In such cases it may be possible to avoid an 1139 instant 'flash' renumbering and plan a non-flag day renumbering as 1140 per RFC 4192. Similarly, if an ISP has a planned renumbering 1141 process, it may be able to adjust lease timers, etc appropriately. 1143 The customer may of course also choose to move to a new ISP, and thus 1144 begin using a new prefix. In such cases the customer should expect a 1145 discontinuity, and not only may the prefix change, but potentially 1146 also the prefix length if the new ISP offers a different default size 1147 prefix. The homenet may also be forced to renumber itself if 1148 significant internal 'replumbing' is undertaken by the user. 1149 Regardless, it's desirable that homenet protocols support rapid 1150 renumbering and that operational processes don't add unnecessary 1151 complexity for the renumbering process. Further, the introduction of 1152 any new homenet protocols should not make any form of renumbering any 1153 more complex than it already is. 1155 Finally, the internal operation of the home network should also not 1156 depend on the availability of the ISP network at any given time, 1157 other than of course for connectivity to services or systems off the 1158 home network. This reinforces the use of ULAs for stable internal 1159 communication, and the need for a naming and service discovery 1160 mechanism that can operate independently within the homenet. 1162 3.4.2. Stable internal IP addresses 1164 The network should by default attempt to provide IP-layer 1165 connectivity between all internal parts of the homenet as well as to 1166 and from the external Internet, subject to the filtering policies or 1167 other policy constraints discussed later in the security section. 1169 ULAs should be used within the scope of a homenet to support stable 1170 routing and connectivity between subnets and hosts regardless of 1171 whether a globally unique ISP-provided prefix is available. In the 1172 case of a prolonged external connectivity outage, ULAs allow internal 1173 operations across routed subnets to continue. ULA addresses also 1174 allow constrained devices to create permanent relationships between 1175 IPv6 addresses, e.g., from a wall controller to a lamp, where 1176 symbolic host names would require additional non-volatile memory and 1177 updating global prefixes in sleeping devices might also be 1178 problematic. 1180 As discussed previously, it would be expected that ULAs would 1181 normally be used alongside one or more global prefixes in a homenet, 1182 such that hosts become multi-addressed with both globally unique and 1183 ULA prefixes. ULAs should be used for all devices, not just those 1184 intended to only have internal connectivity. Default address 1185 selection would then enable ULAs to be preferred for internal 1186 communications between devices that are using ULA prefixes generated 1187 within the same homenet. 1189 In cases where ULA prefixes are in use within a homenet but there is 1190 no external IPv6 connectivity (and thus no GUAs in use), 1191 recommendations ULA-5, L-3 and L-4 in RFC 7084 should be followed to 1192 ensure correct operation, in particular where the homenet may be 1193 dual-stack with IPv4 external connectivity. The use of the Route 1194 Information Option described in [RFC4191] provides a mechanism to 1195 advertise such more-specific ULA routes. 1197 The use of ULAs should be restricted to the homenet scope through 1198 filtering at the border(s) of the homenet, as mandated by RFC 7084 1199 requirement S-2. 1201 Note that it is possible that in some cases multiple /48 ULA prefixes 1202 may be in use within the same homenet, e.g., when the network is 1203 being deployed, perhaps also without external connectivity. In cases 1204 where multiple ULA /48's are in use, hosts need to know that each /48 1205 is local to the homenet, e.g., by inclusion in their local address 1206 selection policy table. 1208 3.4.3. Internal prefix delegation 1210 As mentioned above, there are various sources of prefixes. From the 1211 homenet perspective, a single global prefix from each ISP should be 1212 received on the border CER [RFC3633]. Where multiple CERs exist with 1213 multiple ISP prefix pools, it is expected that routers within the 1214 homenet would assign themselves prefixes from each ISP they 1215 communicate with/through. As discussed above, a ULA prefix should be 1216 provisioned for stable internal communications or for use on 1217 constrained/LLN networks. 1219 The delegation or availability of a prefix pool to the homenet should 1220 allow subsequent internal autonomous delegation of prefixes for use 1221 within the homenet. Such internal delegation should not assume a 1222 flat or hierarchical model, nor should it make an assumption about 1223 whether the delegation of internal prefixes is distributed or 1224 centralised. The assignment mechanism should provide reasonable 1225 efficiency, so that typical home network prefix allocation sizes can 1226 accommodate all the necessary /64 allocations in most cases, and not 1227 waste prefixes. Further, duplicate assignment of multiple /64s to 1228 the same network should be avoided, and the network should behave as 1229 gracefully as possible in the event of prefix exhaustion (though the 1230 options in such cases may be limited). 1232 Where the home network has multiple CERs and these are delegated 1233 prefix pools from their attached ISPs, the internal prefix delegation 1234 would be expected to be served by each CER for each prefix associated 1235 with it. Where ULAs are used, it is preferable that only one /48 ULA 1236 covers the whole homenet, from which /64's can be delegated to the 1237 subnets. In cases where two /48 ULAs are generated within a homenet, 1238 the network should still continue to function, meaning that hosts 1239 will need to determine that each ULA is local to the homenet. 1241 Delegation within the homenet should result in each link being 1242 assigned a stable prefix that is persistent across reboots, power 1243 outages and similar short-term outages. The availability of 1244 persistent prefixes should not depend on the router boot order. The 1245 addition of a new routing device should not affect existing 1246 persistent prefixes, but persistence may not be expected in the face 1247 of significant 'replumbing' of the homenet. However, delegated ULA 1248 prefixes within the homenet should remain persistent through an ISP- 1249 driven renumbering event. 1251 Provisioning such persistent prefixes may imply the need for stable 1252 storage on routing devices, and also a method for a home user to 1253 'reset' the stored prefix should a significant reconfiguration be 1254 required (though ideally the home user should not be involved at 1255 all). 1257 This document makes no specific recommendation towards solutions, but 1258 notes that it is very likely that all routing devices participating 1259 in a homenet must use the same internal prefix delegation method. 1260 This implies that only one delegation method should be in use. 1262 3.4.4. Coordination of configuration information 1264 The network elements will need to be integrated in a way that takes 1265 account of the various lifetimes on timers that are used on different 1266 elements, e.g., DHCPv6 PD, router, valid prefix and preferred prefix 1267 timers. 1269 3.4.5. Privacy 1271 If ISPs offer relatively stable IPv6 prefixes to customers, the 1272 network prefix part of addresses associated with the homenet may not 1273 change over a reasonably long period of time. 1275 The exposure of which traffic is sourced from the same homenet is 1276 thus similar to IPv4; the single IPv4 global address seen through use 1277 of IPv4 NAT gives the same hint as the global IPv6 prefix seen for 1278 IPv6 traffic. 1280 While IPv4 NAT may obfuscate to an external observer which internal 1281 devices traffic is sourced from, IPv6, even with use of Privacy 1282 Addresses [RFC4941], adds additional exposure of which traffic is 1283 sourced from the same internal device, through use of the same IPv6 1284 source address for a period of time. 1286 3.5. Routing functionality 1288 Routing functionality is required when there are multiple routers 1289 deployed within the internal home network. This functionality could 1290 be as simple as the current 'default route is up' model of IPv4 NAT, 1291 or, more likely, it would involve running an appropriate routing 1292 protocol. 1294 A mechanism is required to discover which router(s) in the homenet 1295 are providing the CER function. Borders may include but are not 1296 limited to the interface to the upstream ISP, a gateway device to a 1297 separate home network such as a LLN network, or a gateway to a guest 1298 or private corporate extension network. In some cases there may be 1299 no border present, which may for example occur before an upstream 1300 connection has been established. 1302 The routing environment should be self-configuring, as discussed 1303 previously. The homenet self-configuration process and the routing 1304 protocol must interact in a predictable manner, especially during 1305 startup and reconvergence. The border discovery functionality and 1306 other self-configuration functionality may be integrated into the 1307 routing protocol itself, but may also be imported via a separate 1308 discovery mechanism. 1310 It is preferable that configuration information is distributed and 1311 synchronised within the homenet by a separate configuration protocol. 1313 The homenet routing protocol should be based on a previously deployed 1314 protocol that has been shown to be reliable and robust. This does 1315 not preclude the selection of a newer protocol for which a high 1316 quality open source implementation becomes available. The resulting 1317 code must support lightweight implementations, and be suitable for 1318 incorporation into consumer devices, where both fixed and temporary 1319 storage and processing power are at a premium. 1321 At most, one unicast and one multicast routing protocol should be in 1322 use at a given time in a given homenet. In some simple topologies, 1323 no routing protocol may be needed. If more than one routing protocol 1324 is supported by routers in a given homenet, then a mechanism is 1325 required to ensure that all routers in that homenet use the same 1326 protocol. 1328 The homenet architecture is IPv6 only. In practice, dual-stack 1329 homenets are still likely for the foreseeable future, as described in 1330 Section 3.2.3. Whilst support for IPv4 and other address families 1331 may therefore be beneficial, it is not an explicit requirement to 1332 carry the routing information in the same routing protocol. 1334 Multiple types of physical interfaces must be accounted for in the 1335 homenet routing topology. Technologies such as Ethernet, WiFi, 1336 Multimedia over Coax Alliance (MoCA), etc. must be capable of 1337 coexisting in the same environment and should be treated as part of 1338 any routed deployment. The inclusion of physical layer 1339 characteristics in path computation should be considered for 1340 optimising communication in the homenet. 1342 3.5.1. Unicast Routing Within the Homenet 1344 The role of the unicast routing protocol is to provide good enough 1345 end-to-end connectivity often enough, where good/often enough is 1346 defined by user expectations. 1348 Due to the use of a variety of diverse underlying link technologies, 1349 path selection in a homenet may benefit from being more refined than 1350 minimising hop count. It may also be beneficial for traffic to use 1351 multiple paths to a given destination within the homenet where 1352 available, rather than just a single best path. 1354 Minimising convergence time should be a goal in any routed 1355 environment. It is reasonable to assume that convergence time should 1356 not be significantly longer than network outages users are accustomed 1357 to should their CER reboot. 1359 The homenet architecture is agnostic as to the choice of underlying 1360 routing technology, e.g., link state versus Bellman-Ford. 1362 The routing protocol should support the generic use of multiple 1363 customer Internet connections, and the concurrent use of multiple 1364 delegated prefixes. A routing protocol that can make routing 1365 decisions based on source and destination addresses is thus highly 1366 desirable, to avoid upstream ISP BCP 38 ingress filtering problems. 1367 Multihoming support may also include load-balancing to multiple 1368 providers, and failover from a primary to a backup link when 1369 available. The protocol should not require upstream ISP connectivity 1370 to be established to continue routing within the homenet. 1372 The homenet architecture is agnostic on a minimum hop count that has 1373 to be supported by the routing protocol. The architecture should 1374 however be scalable to other scenarios where homenet technology may 1375 be deployed, which may include small office and small enterprise 1376 sites. To allow for such cases it would be desirable that the 1377 architecture is scalable to higher hop counts and to a larger numbers 1378 of routers than would be typical in a true home network. 1380 At the time of writing, link layer networking technology is poised to 1381 become more heterogeneous, as networks begin to employ both 1382 traditional Ethernet technology and link layers designed for low- 1383 power and lossy networks (LLNs), such as those used for certain types 1384 of sensor devices. 1386 Ideally, LLN or other logically separate networks should be able 1387 exchange routes such that IP traffic may be forwarded among the 1388 networks via gateway routers which interoperate with both the homenet 1389 and any LLNs. Current home deployments use largely different 1390 mechanisms in sensor and basic Internet connectivity networks. IPv6 1391 virtual machine (VM) solutions may also add additional routing 1392 requirements. 1394 In this homenet architecture, LLNs and other specialised networks are 1395 considered stub areas of the homenet, and are thus not expected to 1396 act as a transit for traffic between more traditional media. 1398 3.5.2. Unicast Routing at the Homenet Border 1400 The current practice defined in [RFC7084] would suggest that routing 1401 between the homenet CER and the Service Provider Router follow the 1402 model of [RFC7084] Section 4 WAN Side Requirements, at least in 1403 initial deployments. However, consideration of whether a routing 1404 protocol is used between the homenet CER and the Service provider 1405 Router is out of scope of this document. 1407 3.5.3. Multicast support 1409 It is desirable that, subject to the capacities of devices on certain 1410 media types, multicast routing is supported across the homenet, 1411 including source-specific multicast (SSM) [RFC4607] . 1413 [RFC4291] requires that any boundary of scope 4 or higher (i.e., 1414 admin-local or higher) be administratively configured. Thus the 1415 boundary at the homenet-ISP border must be administratively 1416 configured, though that may be triggered by an administrative 1417 function such as DHCP-PD. Other multicast forwarding policy borders 1418 may also exist within the homenet, e.g., to/from a guest subnet, 1419 whilst the use of certain link media types may also affect where 1420 specific multicast traffic is forwarded or routed. 1422 There may be different drivers for multicast to be supported across 1423 the homenet, e.g., for homenet-wide service discovery should a 1424 multicast service discovery protocol of scope greater than link-local 1425 be defined, or potentially for multicast-based streaming or 1426 filesharing applications. Where multicast is routed across a homenet 1427 an appropriate multicast routing protocol is required, one that as 1428 per the unicast routing protocol should be self-configuring. As 1429 hinted above, it must be possible to scope or filter multicast 1430 traffic to avoid it being flooded to network media where devices 1431 cannot reasonably support it. 1433 A homenet may not only use multicast internally, it may also be a 1434 consumer or provider of external multicast traffic, where the 1435 homenet's ISP supports such multicast operation. This may be 1436 valuable for example where live video applications are being sourced 1437 to/from the homenet. 1439 The multicast environment should support the ability for applications 1440 to pick a unique multicast group to use. 1442 3.6. Security 1444 The security of an IPv6 homenet is an important consideration. The 1445 most notable difference to the IPv4 operational model is the removal 1446 of NAT, the introduction of global addressability of devices, and 1447 thus a need to consider whether devices should have global 1448 reachability. Regardless, hosts need to be able to operate securely, 1449 end-to-end where required, and also be robust against malicious 1450 traffic directed towards them. However, there are other challenges 1451 introduced, e.g., default filtering policies at the borders between 1452 various homenet realms. 1454 3.6.1. Addressability vs reachability 1456 An IPv6-based home network architecture should embrace the 1457 transparent end-to-end communications model as described in 1458 [RFC2775]. Each device should be globally addressable, and those 1459 addresses must not be altered in transit. However, security 1460 perimeters can be applied to restrict end-to-end communications, and 1461 thus while a host may be globally addressable it may not be globally 1462 reachable. 1464 [RFC4864] describes a 'Simple Security' model for IPv6 networks, 1465 whereby stateful perimeter filtering can be applied to control the 1466 reachability of devices in a homenet. RFC 4864 states in Section 4.2 1467 that "the use of firewalls ... is recommended for those that want 1468 boundary protection in addition to host defences". It should be 1469 noted that a 'default deny' filtering approach would effectively 1470 replace the need for IPv4 NAT traversal protocols with a need to use 1471 a signalling protocol to request a firewall hole be opened, e.g., a 1472 protocol such as PCP [RFC6887]. In networks with multiple CERs, the 1473 signalling would need to handle the cases of flows that may use one 1474 or more exit routers. CERs would need to be able to advertise their 1475 existence for such protocols. 1477 [RFC6092] expands on RFC 4864, giving a more detailed discussion of 1478 IPv6 perimeter security recommendations, without mandating a 'default 1479 deny' approach. Indeed, RFC 6092 does not enforce a particular mode 1480 of operation, instead stating that CERs must provide an easily 1481 selected configuration option that permits a 'transparent' mode, thus 1482 ensuring a 'default allow' model is available. 1484 The topic of whether future home networks as described in this 1485 document should have have a 'default deny' or 'default allow' 1486 position has been discussed at length in various IETF meetings 1487 without any consensus being reached on which approach is more 1488 appropriate. Further, the choice of which default to apply may be 1489 situational, and thus this text makes no recommendation on the 1490 default setting beyond what is written on this topic in RFC 6092. We 1491 note in Section 3.6.3 below that the implicit firewall function of an 1492 IPv4 NAT is commonplace today, and thus future CERs targeted at home 1493 networks should continue to support the option of running in 'default 1494 deny mode', whether or not that is the default setting 1496 3.6.2. Filtering at borders 1498 It is desirable that there are mechanisms to detect different types 1499 of borders within the homenet, as discussed previously, and further 1500 mechanisms to then apply different types of filtering policies at 1501 those borders, e.g., whether naming and service discovery should pass 1502 a given border. Any such policies should be able to be easily 1503 applied by typical home users, e.g., to give a user in a guest 1504 network access to media services in the home, or access to a printer. 1505 Simple mechanisms to apply policy changes, or associations between 1506 devices, will be required. 1508 There are cases where full internal connectivity may not be 1509 desirable, e.g., in certain utility networking scenarios, or where 1510 filtering is required for policy reasons against guest network 1511 subnet(s). Some scenarios/models may as a result involve running 1512 isolated subnet(s) with their own CERs. In such cases connectivity 1513 would only be expected within each isolated network (though traffic 1514 may potentially pass between them via external providers). 1516 LLNs provide an another example of where there may be secure 1517 perimeters inside the homenet. Constrained LLN nodes may implement 1518 network key security but may depend on access policies enforced by 1519 the LLN border router. 1521 Considerations for differentiating neighbouring homenets are 1522 discussed in Section 3.3.1. 1524 3.6.3. Partial Effectiveness of NAT and Firewalls 1526 Security by way of obscurity (address translation) or through 1527 firewalls (filtering) is at best only partially effective. The very 1528 poor security track record of home computer, home networking and 1529 business PC computers and networking is testimony to this. A 1530 security compromise behind the firewall of any device exposes all 1531 others, making an entire network that relies on obscurity or a 1532 firewall as vulnerable as the most insecure device on the private 1533 side of the network. 1535 However, given current evidence of home network products with very 1536 poor default device security, putting a firewall in place does 1537 provide some level of protection. The use of firewalls today, 1538 whether a good practice or not, is common practice and the capability 1539 to afford protection via a 'default deny' setting, even if marginally 1540 effective, should not be lost. Thus, while it is highly desirable 1541 that all hosts in a homenet be adequately protected by built-in 1542 security functions, it should also be assumed that all CERs will 1543 continue to support appropriate perimeter defence functions, as per 1544 [RFC7084]. 1546 3.6.4. Exfiltration concerns 1548 As homenets become more complex, with more devices, and with service 1549 discovery potentially enabled across the whole home, there are 1550 potential concerns over the leakage of information should devices use 1551 discovery protocols to gather information and report it to equipment 1552 vendors or application service providers. 1554 While it is not clear how such exfiltration could be easily avoided, 1555 the threat should be recognised, be it from a new piece of hardware 1556 or some 'app' installed on a personal device. 1558 3.6.5. Device capabilities 1560 In terms of the devices, homenet hosts should implement their own 1561 security policies in accordance to their computing capabilities. 1562 They should have the means to request transparent communications to 1563 be able to be initiated to them through security filters in the 1564 homenet, either for all ports or for specific services. Users should 1565 have simple methods to associate devices to services that they wish 1566 to operate transparently through (CER) borders. 1568 3.6.6. ULAs as a hint of connection origin 1570 As noted in Section 3.6, if appropriate filtering is in place on the 1571 CER(s), as mandated by RFC 7084 requirement S-2, a ULA source address 1572 may be taken as an indication of locally sourced traffic. This 1573 indication could then be used with security settings to designate 1574 between which nodes a particular application is allowed to 1575 communicate, provided ULA address space is filtered appropriately at 1576 the boundary of the realm. 1578 3.7. Naming and Service Discovery 1580 The homenet requires devices to be able to determine and use unique 1581 names by which they can be accessed on the network, and which are not 1582 used by other devices on the network. Users and devices will need to 1583 be able to discover devices and services available on the network, 1584 e.g., media servers, printers, displays or specific home automation 1585 devices. Thus naming and service discovery must be supported in the 1586 homenet, and, given the nature of typical home network users, the 1587 service(s) providing this function must as far as possible support 1588 unmanaged operation. 1590 The naming system will be required to work internally or externally, 1591 be the user within the homenet or outside it, i.e., the user should 1592 be able to refer to devices by name, and potentially connect to them, 1593 wherever they may be. The most natural way to think about such 1594 naming and service discovery is to enable it to work across the 1595 entire homenet residence (site), disregarding technical borders such 1596 as subnets but respecting policy borders such as those between guest 1597 and other internal network realms. Remote access may be desired by 1598 the homenet residents while travelling, but also potentially by 1599 manufacturers or other 'benevolent' third parties. 1601 3.7.1. Discovering services 1603 Users will typically perform service discovery through graphical user 1604 interfaces (GUIs) that allow them to browse services on their network 1605 in an appropriate and intuitive way. Devices may also need to 1606 discover other devices, without any user intervention or choice. 1607 Either way, such interfaces are beyond the scope of this document, 1608 but the interface should have an appropriate application programming 1609 interface (API) for the discovery to be performed. 1611 Such interfaces may also typically hide the local domain name element 1612 from users, especially where only one name space is available. 1613 However, as we discuss below, in some cases the ability to discover 1614 available domains may be useful. 1616 We note that current zero-configuration service discovery protocols 1617 are generally aimed at single subnets. There is thus a choice to 1618 make for multi-subnet homenets as to whether such protocols should be 1619 proxied or extended to operate across a whole homenet. In this 1620 context, that may mean bridging a link-local method, taking care to 1621 avoid packets entering looping paths, or extending the scope of 1622 multicast traffic used for the purpose. It may mean that some proxy 1623 or hybrid service is utilised, perhaps co-resident on the CER. Or it 1624 may be that a new approach is preferable, e.g., flooding information 1625 around the homenet as attributes within the routing protocol (which 1626 could allow per-prefix configuration). However, we should prefer 1627 approaches that are backwardly compatible, and allow current 1628 implementations to continue to be used. Note that this document does 1629 not mandate a particular solution, rather it expresses the principles 1630 that should be used for a homenet naming and service discovery 1631 environment. 1633 One of the primary challenges facing service discovery today is lack 1634 of interoperability due to the ever increasing number of service 1635 discovery protocols available. While it is conceivable for consumer 1636 devices to support multiple discovery protocols, this is clearly not 1637 the most efficient use of network and computational resources. One 1638 goal of the homenet architecture should be a path to service 1639 discovery protocol interoperability either through a standards based 1640 translation scheme, hooks into current protocols to allow some for of 1641 communication among discovery protocols, extensions to support a 1642 central service repository in the homenet, or simply convergence 1643 towards a unified protocol suite. 1645 3.7.2. Assigning names to devices 1647 Given the large number of devices that may be networked in the 1648 future, devices should have a means to generate their own unique 1649 names within a homenet, and to detect clashes should they arise, 1650 e.g., where a second device of the same type/vendor as an existing 1651 device with the same default name is deployed, or where a new subnet 1652 is added to the homenet which already has a device of the same name. 1653 It is expected that a device should have a fixed name while within 1654 the scope of the homenet. 1656 Users will also want simple ways to (re)name devices, again most 1657 likely through an appropriate and intuitive interface that is beyond 1658 the scope of this document. Note the name a user assigns to a device 1659 may be a label that is stored on the device as an attribute of the 1660 device, and may be distinct from the name used in a name service, 1661 e.g., 'Study Laser Printer' as opposed to printer2.. 1663 3.7.3. The homenet name service 1665 The homenet name service should support both lookups and discovery. 1666 A lookup would operate via a direct query to a known service, while 1667 discovery may use multicast messages or a service where applications 1668 register in order to be found. 1670 It is highly desirable that the homenet name service must at the very 1671 least co-exist with the Internet name service. There should also be 1672 a bias towards proven, existing solutions. The strong implication is 1673 thus that the homenet service is DNS-based, or DNS-compatible. There 1674 are naming protocols that are designed to be configured and operate 1675 Internet-wide, like unicast-based DNS, but also protocols that are 1676 designed for zero-configuration local environments, like mDNS 1677 [RFC6762]. 1679 When DNS is used as the homenet name service, it typically includes 1680 both a resolving service and an authoritative service. The 1681 authoritative service hosts the homenet related zone. One approach 1682 when provisioning such a name service, which is designed to 1683 facilitate name resolution from the global Internet, is to run an 1684 authoritative name service on the CER and a secondary authoritative 1685 name service provided by the ISP or perhaps an external third party. 1687 Where zero configuration name services are used, it is desirable that 1688 these can also coexist with the Internet name service. In 1689 particular, where the homenet is using a global name space, it is 1690 desirable that devices have the ability, where desired, to add 1691 entries to that name space. There should also be a mechanism for 1692 such entries to be removed or expired from the global name space. 1694 To protect against attacks such as cache poisoning, where an attacker 1695 is able to insert a bogus DNS entry in the local cache, it is 1696 desirable to support appropriate name service security methods, 1697 including DNS Security Extensions (DNSSEC) [RFC4033], on both the 1698 authoritative server and the resolver sides. Where DNS is used, the 1699 homenet router or naming service must not prevent DNSSEC from 1700 operating. 1702 While this document does not specify hardware requirements, it is 1703 worth noting briefly here that e.g., in support of DNSSEC, 1704 appropriate homenet devices should have good random number generation 1705 capability, and future homenet specifications should indicate where 1706 high quality random number generators, i.e., with decent entropy, are 1707 needed. 1709 Finally, the impact of a change in CER must be considered. It would 1710 be desirable to retain any relevant state (configuration) that was 1711 held in the old CER. This might imply that state information should 1712 be distributed in the homenet, to be recoverable by/to the new CER, 1713 or to the homenet's ISP or a third party externally provided service 1714 by some means. 1716 3.7.4. Name spaces 1718 If access to homenet devices is required remotely from anywhere on 1719 the Internet, then at least one globally unique name space is 1720 required, though the use of multiple name spaces should not be 1721 precluded. One approach is that the name space(s) used for the 1722 homenet would be served authoritatively by the homenet, most likely 1723 by a server resident on the CER. Such name spaces may be acquired by 1724 the user or provided/generated by their ISP or an alternative 1725 externally provided service. It is likely that the default case is 1726 that a homenet will use a global domain provided by the ISP, but 1727 advanced users wishing to use a name space that is independent of 1728 their provider in the longer term should be able to acquire and use 1729 their own domain name. For users wanting to use their own 1730 independent domain names, such services are already available. 1732 Devices may also be assigned different names in different name 1733 spaces, e.g., by third parties who may manage systems or devices in 1734 the homenet on behalf of the resident(s). Remote management of the 1735 homenet is out of scope of this document. 1737 If however a global name space is not available, the homenet will 1738 need to pick and use a local name space which would only have meaning 1739 within the local homenet (i.e., it would not be used for remote 1740 access to the homenet). The .local name space currently has a 1741 special meaning for certain existing protocols which have link-local 1742 scope, and is thus not appropriate for multi-subnet home networks. A 1743 different name space is thus required for the homenet. 1745 One approach for picking a local name space is to use an Ambiguous 1746 Local Qualified Domain Name (ALQDN) space, such as .sitelocal (or an 1747 appropriate name reserved for the purpose). While this is a simple 1748 approach, there is the potential in principle for devices that are 1749 bookmarked somehow by name by an application in one homenet to be 1750 confused with a device with the same name in another homenet. In 1751 practice however the underlying service discovery protocols should be 1752 capable of handling moving to a network where a new device is using 1753 the same name as a device used previously in another homenet. 1755 An alternative approach for a local name space would be to use a 1756 Unique Locally Qualified Domain Name (ULQDN) space such as 1757 ..sitelocal. The could be generated in 1758 a variety of ways, one potentially being based on the local /48 ULA 1759 prefix being used across the homenet. Such a should 1760 survive a cold restart, i.e., be consistent after a network power- 1761 down, or, if a value is not set on startup, the CER or device running 1762 the name service should generate a default value. It would be 1763 desirable for the homenet user to be able to override the 1764 with a value of their choice, but that would increase 1765 the likelihood of a name conflict. Any generated 1766 should not be predictable; thus adding a salt/hash function would be 1767 desirable. 1769 In the (likely) event that the homenet is accessible from outside the 1770 homenet (using the global name space), it is vital that the homenet 1771 name space follow the rules and conventions of the global name space. 1772 In this mode of operation, names in the homenet (including those 1773 automatically generated by devices) must be usable as labels in the 1774 global name space. [RFC5890] describes considerations for 1775 Internationalizing Domain Names in Applications (IDNA). 1777 Also, with the introduction of new 'dotless' top level domains, there 1778 is also potential for ambiguity between, for example, a local host 1779 called 'computer' and (if it is registered) a .computer gTLD. Thus 1780 qualified names should always be used, whether these are exposed to 1781 the user or not. The IAB has issued a statement which explains why 1782 dotless domains should be considered harmful [IABdotless]. 1784 There may be use cases where either different name spaces may be 1785 desired for different realms in the homenet, or for segmentation of a 1786 single name space within the homenet. Thus hierarchical name space 1787 management is likely to be required. There should also be nothing to 1788 prevent individual device(s) being independently registered in 1789 external name spaces. 1791 It may be the case that if there are two or more CERs serving the 1792 home network, that if each has name space delegated from a different 1793 ISP there is the potential for devices in the home to have multiple 1794 fully qualified names under multiple domains. 1796 Where a user is in a remote network wishing to access devices in 1797 their home network, there may be a requirement to consider the domain 1798 search order presented where multiple associated name spaces exist. 1799 This also implies that a domain discovery function is desirable. 1801 It may be the case that not all devices in the homenet are made 1802 available by name via an Internet name space, and that a 'split view' 1803 (as described in [RFC6950] Section 4) is preferred for certain 1804 devices, whereby devices inside the homenet see different DNS 1805 responses to those outside. 1807 Finally, this document makes no assumption about the presence or 1808 omission of a reverse lookup service. There is an argument that it 1809 may be useful for presenting logging information to users with 1810 meaningful device names rather than literal addresses. There are 1811 also some services, most notably email mail exchangers, where some 1812 operators have chosen to require a valid reverse lookup before 1813 accepting connections. 1815 3.7.5. Independent operation 1817 Name resolution and service discovery for reachable devices must 1818 continue to function if the local network is disconnected from the 1819 global Internet, e.g., a local media server should still be available 1820 even if the Internet link is down for an extended period. This 1821 implies the local network should also be able to perform a complete 1822 restart in the absence of external connectivity, and have local 1823 naming and service discovery operate correctly. 1825 The approach described above of a local authoritative name service 1826 with a cache would allow local operation for sustained ISP outages. 1828 Having an independent local trust anchor is desirable, to support 1829 secure exchanges should external connectivity be unavailable. 1831 A change in ISP should not affect local naming and service discovery. 1832 However, if the homenet uses a global name space provided by the ISP, 1833 then this will obviously have an impact if the user changes their 1834 network provider. 1836 3.7.6. Considerations for LLNs 1838 In some parts of the homenet, in particular LLNs or any devices where 1839 battery power is used, devices may be sleeping, in which case a proxy 1840 for such nodes may be required, that could respond (for example) to 1841 multicast service discovery requests. Those same devices or parts of 1842 the network may have less capacity for multicast traffic that may be 1843 flooded from other parts of the network. In general, message 1844 utilisation should be efficient considering the network technologies 1845 and constrained devices that the service may need to operate over. 1847 There are efforts underway to determine naming and discovery 1848 solutions for use by the Constrained Application Protocol (CoAP) 1849 [RFC7252] in LLN networks. These are outside the scope of this 1850 document. 1852 3.7.7. DNS resolver discovery 1854 Automatic discovery of a name service to allow client devices in the 1855 homenet to resolve external domains on the Internet is required, and 1856 such discovery must support clients that may be a number of router 1857 hops away from the name service. Similarly it may be desirable to 1858 convey any DNS domain search list that may be in effect for the 1859 homenet. 1861 3.7.8. Devices roaming to/from the homenet 1863 It is likely that some devices which have registered names within the 1864 homenet Internet name space and that are mobile will attach to the 1865 Internet at other locations and acquire an IP address at those 1866 locations. Devices may move between different homenets. In such 1867 cases it is desirable that devices may be accessed by the same name 1868 as is used in their home network. 1870 Solutions to this problem are not discussed in this document. They 1871 may include use of Mobile IPv6 or Dynamic DNS, either of which would 1872 put additional requirements on to the homenet, or establishment of a 1873 (VPN) tunnel to a server in the home network. 1875 3.8. Other Considerations 1877 This section discusses two other considerations for home networking 1878 that the architecture should not preclude, but that this text is 1879 neutral towards. 1881 3.8.1. Quality of Service 1883 Support for Quality of Service in a multi-service homenet may be a 1884 requirement, e.g., for a critical system (perhaps healthcare 1885 related), or for differentiation between different types of traffic 1886 (file sharing, cloud storage, live streaming, VoIP, etc). Different 1887 link media types may have different such properties or capabilities. 1889 However, homenet scenarios should require no new Quality of Service 1890 protocols. A DiffServ [RFC2475] approach with a small number of 1891 predefined traffic classes may generally be sufficient, though at 1892 present there is little experience of Quality of Service deployment 1893 in home networks. It is likely that QoS, or traffic prioritisation, 1894 methods will be required at the CER, and potentially around 1895 boundaries between different link media types (where for example some 1896 traffic may simply not be appropriate for some media, and need to be 1897 dropped to avoid overloading the constrained media). 1899 There may also be complementary mechanisms that could be beneficial 1900 to application performance and behaviour in the homenet domain, such 1901 as ensuring proper buffering algorithms are used as described in 1902 [Gettys11]. 1904 3.8.2. Operations and Management 1906 In this section we briefly review some initial considerations for 1907 operations and management in the type of homenet described in this 1908 document. It is expected that a separate document will define an 1909 appropriate operations and management framework for such homenets. 1911 As described in this document, the homenet should have the general 1912 goal of being self-organising and configuring from the network layer 1913 perspective, e.g. prefixes should be able to be assigned to router 1914 interfaces. Further, applications running on devices should be able 1915 to use zero configuration service discovery protocols to discover 1916 services of interest to the home user. In contrast, a home user 1917 would not be expected, for example, to have to assign prefixes to 1918 links, or manage the DNS entries for the home network. Such expert 1919 operation should not be precluded, but it is not the norm. 1921 The user may still be required to, or wish to, perform some 1922 configuration of the network and the devices on it. Examples might 1923 include entering a security key to enable access to their wireless 1924 network, or choosing to give a 'friendly name' to a device presented 1925 to them through service discovery. Configuration of link layer and 1926 application layer services is out of scope of this architectural 1927 principles document, but are likely to be required in an operational 1928 homenet. 1930 While not being expected to actively configure the networking 1931 elements of their homenet, users may be interested in being able to 1932 view the status of their networks and the devices connected to it, in 1933 which case appropriate network monitoring protocols will be required 1934 to allow them to view their network, and its status, e.g. via a web 1935 interface or equivalent. While the user may not understand how the 1936 network operates, it is reasonable to assume they are interested in 1937 understanding what faults or problems may exist on it. Such 1938 monitoring may extend to other devices on the network, e.g. storage 1939 devices, or web cameras, but such devices are beyond the scope of 1940 this document. 1942 It may also be the case that an ISP, or a third party, might wish to 1943 offer a remote management service for the homenet on behalf of the 1944 user, or to be able to assist the user in event of some problem they 1945 are experiencing, in which case appropriate management and monitoring 1946 protocols would be required. 1948 Specifying the required protocols to facilitate homenet management 1949 and monitoring is out of scope of this document. As stated above, it 1950 is expected that a separate document will be produced to describe the 1951 operations and management framework for the types of home network 1952 presented in this document. 1954 As a final point, we note that it is desirable that all network 1955 management and monitoring functions should be available over IPv6 1956 transport, even where the homenet is dual-stack. 1958 3.9. Implementing the Architecture on IPv6 1960 This architecture text encourages re-use of existing protocols. Thus 1961 the necessary mechanisms are largely already part of the IPv6 1962 protocol set and common implementations, though there are some 1963 exceptions. 1965 For automatic routing, it is expected that solutions can be found 1966 based on existing protocols. Some relatively smaller updates are 1967 likely to be required, e.g., a new mechanism may be needed in order 1968 to turn a selected protocol on by default, a mechanism may be 1969 required to automatically assign prefixes to links within the 1970 homenet. 1972 Some functionality, if required by the architecture, may need more 1973 significant changes or require development of new protocols, e.g., 1974 support for multihoming with multiple exit routers would likely 1975 require extensions to support source and destination address based 1976 routing within the homenet. 1978 Some protocol changes are however required in the architecture, e.g., 1979 for name resolution and service discovery, extensions to existing 1980 zero configuration link-local name resolution protocols are needed to 1981 enable them to work across subnets, within the scope of the home 1982 network site. 1984 Some of the hardest problems in developing solutions for home 1985 networking IPv6 architectures include discovering the right borders 1986 where the 'home' domain ends and the service provider domain begins, 1987 deciding whether some of the necessary discovery mechanism extensions 1988 should affect only the network infrastructure or also hosts, and the 1989 ability to turn on routing, prefix delegation and other functions in 1990 a backwards compatible manner. 1992 4. Conclusions 1994 This text defines principles and requirements for a homenet 1995 architecture. The principles and requirements documented here should 1996 be observed by any future texts describing homenet protocols for 1997 routing, prefix management, security, naming or service discovery. 1999 5. Security Considerations 2001 Security considerations for the homenet architecture are discussed in 2002 Section 3.6 above. 2004 6. IANA Considerations 2006 This document has no actions for IANA. 2008 7. References 2010 7.1. Normative References 2012 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2013 (IPv6) Specification", RFC 2460, December 1998. 2015 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2016 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2017 December 2003. 2019 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2020 Addresses", RFC 4193, October 2005. 2022 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2023 Architecture", RFC 4291, February 2006. 2025 7.2. Informative References 2027 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 2028 E. Lear, "Address Allocation for Private Internets", BCP 2029 5, RFC 1918, February 1996. 2031 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2032 and W. Weiss, "An Architecture for Differentiated 2033 Services", RFC 2475, December 1998. 2035 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2036 2000. 2038 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2039 Defeating Denial of Service Attacks which employ IP Source 2040 Address Spoofing", BCP 38, RFC 2827, May 2000. 2042 [RFC3002] Mitzel, D., "Overview of 2000 IAB Wireless Internetworking 2043 Workshop", RFC 3002, December 2000. 2045 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2046 Address Translator (Traditional NAT)", RFC 3022, January 2047 2001. 2049 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2050 Rose, "DNS Security Introduction and Requirements", RFC 2051 4033, March 2005. 2053 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2054 More-Specific Routes", RFC 4191, November 2005. 2056 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 2057 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 2058 September 2005. 2060 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 2061 IP", RFC 4607, August 2006. 2063 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2064 Address Autoconfiguration", RFC 4862, September 2007. 2066 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 2067 E. Klein, "Local Network Protection for IPv6", RFC 4864, 2068 May 2007. 2070 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 2071 Extensions for Stateless Address Autoconfiguration in 2072 IPv6", RFC 4941, September 2007. 2074 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 2075 Shim Protocol for IPv6", RFC 5533, June 2009. 2077 [RFC5890] Klensin, J., "Internationalized Domain Names for 2078 Applications (IDNA): Definitions and Document Framework", 2079 RFC 5890, August 2010. 2081 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 2082 Infrastructures (6rd) -- Protocol Specification", RFC 2083 5969, August 2010. 2085 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 2086 Customer Premises Equipment (CPE) for Providing 2087 Residential IPv6 Internet Service", RFC 6092, January 2088 2011. 2090 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 2091 IPv4/IPv6 Translation", RFC 6144, April 2011. 2093 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 2094 Algorithm", RFC 6145, April 2011. 2096 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 2097 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 2099 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 2100 Troan, "Basic Requirements for IPv6 Customer Edge 2101 Routers", RFC 6204, April 2011. 2103 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 2104 Translation", RFC 6296, June 2011. 2106 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 2107 Stack Lite Broadband Deployments Following IPv4 2108 Exhaustion", RFC 6333, August 2011. 2110 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 2111 Dual-Stack Hosts", RFC 6555, April 2012. 2113 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 2114 "Default Address Selection for Internet Protocol Version 6 2115 (IPv6)", RFC 6724, September 2012. 2117 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2118 February 2013. 2120 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 2121 "TCP Extensions for Multipath Operation with Multiple 2122 Addresses", RFC 6824, January 2013. 2124 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 2125 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2126 2013. 2128 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 2129 "Architectural Considerations on Application Features in 2130 the DNS", RFC 6950, October 2013. 2132 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 2133 Requirements for IPv6 Customer Edge Routers", RFC 7084, 2134 November 2013. 2136 [RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 2137 Wing, "IPv6 Multihoming without Network Address 2138 Translation", RFC 7157, March 2014. 2140 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2141 Application Protocol (CoAP)", RFC 7252, June 2014. 2143 [IABdotless] 2144 "IAB Statement: Dotless Domains Considered Harmful", 2145 February 2013, . 2149 [Gettys11] 2150 Gettys, J., "Bufferbloat: Dark Buffers in the Internet", 2151 March 2011, 2152 . 2154 Appendix A. Acknowledgments 2156 The authors would like to thank Aamer Akhter, Mikael Abrahamsson, 2157 Mark Andrews, Dmitry Anipko, Ran Atkinson, Fred Baker, Ray Bellis, 2158 Teco Boot, John Brzozowski, Cameron Byrne, Brian Carpenter, Stuart 2159 Cheshire, Julius Chroboczek, Lorenzo Colitti, Robert Cragie, Elwyn 2160 Davies, Ralph Droms, Lars Eggert, Jim Gettys, Olafur Gudmundsson, 2161 Wassim Haddad, Joel M. Halpern, David Harrington, Lee Howard, Ray 2162 Hunter, Joel Jaeggli, Heather Kirksey, Ted Lemon, Acee Lindem, Kerry 2163 Lynn, Daniel Migault, Erik Nordmark, Michael Richardson, Mattia 2164 Rossi, Barbara Stark, Markus Stenberg, Sander Steffann, Don Sturek, 2165 Andrew Sullivan, Dave Taht, Dave Thaler, Michael Thomas, Mark 2166 Townsley, JP Vasseur, Curtis Villamizar, Dan Wing, Russ White, and 2167 James Woodyatt for their comments and contributions within homenet WG 2168 meetings and on the WG mailing list. An acknowledgement generally 2169 means that person's text made it in to the document, or was helpful 2170 in clarifying or reinforcing an aspect of the document. It does not 2171 imply that each contributor agrees with every point in the document. 2173 Appendix B. Changes 2175 This section will be removed in the final version of the text. 2177 B.1. Version 17 2179 Changes made include: 2181 o Updated Section 3.5 on routing functionality. 2183 o Noted consensus in London for a separate configuration protocol. 2185 o Updated text to refer to RFC7084 rather than RFC6204. 2187 o Updated coap reference to the pubished RFC. 2189 B.2. Version 16 2191 Changes made include: 2193 o Reverted back to paragraph on link metric usage. 2195 B.3. Version 15 2197 Changes made include: 2199 o Inserted WG chair compromise text on routing functionality. 2200 Removed paragraph on link metric usage. 2202 B.4. Version 14 2204 Changes made include: 2206 o Changes for Adrian Farrell discuss/comment. 2208 o Very minor wordsmithing requested by Benoit for OAM text. 2210 o Very minor wordsmithing from IETF89 session. 2212 o Added note to support SSM. 2214 o Emphasised at most one routing protocol in use, possibly none. 2216 B.5. Version 13 2218 Changes made include: 2220 o Changes to address last outstanding IESG DISCUSSes/COMMENTs. 2222 B.6. Version 12 2224 Changes made include: 2226 o Fixed minor typo nits introduced in -11. 2228 o Elwyn Davies' gen-art review comments addressed. 2230 o Some further IESG DISCUSSes/COMMENTs addressed. 2232 B.7. Version 11 (after IESG review) 2234 Changes made include: 2236 o Jouni Korhonen's OPSDIR review comments addressed. 2238 o Elwyn Davies' gen-art review comments addressed. 2240 o Considered secdir review by Samiel Weiler; many points addressed. 2242 o Considered APPSDIR review. 2244 o Addressed a large number of IESG comments and discusses. 2246 B.8. Version 10 (after AD review) 2248 Changes made include: 2250 o Minor changes/clarifications resulting from AD review 2252 B.9. Version 09 (after WGLC) 2254 Changes made include: 2256 o Added note about multicast into or out of site 2258 o Removed further personal draft references, replaced with covering 2259 text 2261 o Routing functionality text updated to avoid ambiguity 2263 o Added note that devices away from homenet may tunnel home (via 2264 VPN) 2266 o Added note that homenets more exposed to provider renumbering than 2267 with IPv4 and NAT 2269 o Added note about devices that may be ULA-only until configured to 2270 be globally addressable 2272 o Removed paragraph about broken CERs that do not work with prefixes 2273 other than /64 2275 o Noted no recommendation on methods to convey prefix information is 2276 made in this text 2278 o Stated that this text does not recommend how to form largest 2279 possible subnets 2281 o Added text about homenet evolution and handling disparate media 2282 types 2284 o Rephrased NAT/firewall text on marginal effectiveness 2286 o Emphasised that multihoming may be to any number of ISPs 2288 B.10. Version 08 2290 Changes made include: 2292 o Various clarifications made in response to list comments 2293 o Added note on ULAs with IPv4, where no GUAs in use 2295 o Added note on naming and internationalisation (IDNA) 2297 o Added note on trust relationships when adding devices 2299 o Added note for MPTCP 2301 o Added various naming and SD notes 2303 o Added various notes on delegated ISP prefixes 2305 B.11. Version 07 2307 Changes made include: 2309 o Removed reference to NPTv6 in section 3.2.4. Instead now say it 2310 has an architectural cost to use in the earlier section, and thus 2311 it is not recommended for use in the homenet architecture. 2313 o Removed 'proxy or extend?' section. Included shorter text in main 2314 body, without mandating either approach for service discovery. 2316 o Made it clearer that ULAs are expected to be used alongside 2317 globals. 2319 o Removed reference to 'advanced security' as described in draft- 2320 vyncke-advanced-ipv6-security. 2322 o Balanced the text between ULQDN and ALQDN. 2324 o Clarify text does not assume default deny or allow on CER, but 2325 that either mode may be enabled. 2327 o Removed ULA-C reference for 'simple' addresses. Instead only 2328 suggested service discovery to find such devices. 2330 o Reiterated that single/multiple CER models to be supported for 2331 multihoming. 2333 o Reordered section 3.3 to improve flow. 2335 o Added recommendation that homenet is not allocated less than /60, 2336 and a /56 is preferable. 2338 o Tidied up first few intro sections. 2340 o Other minor edits from list feedback. 2342 B.12. Version 06 2344 Changes made include: 2346 o Stated that unmanaged goal is 'as far as possible'. 2348 o Added note about multiple /48 ULAs potentially being in use. 2350 o Minor edits from list feedback. 2352 B.13. Version 05 2354 Changes made include: 2356 o Some significant changes to naming and SD section. 2358 o Removed some expired drafts. 2360 o Added notes about issues caused by ISP only delegating a /64. 2362 o Recommended against using prefixes longer than /64. 2364 o Suggested CER asks for /48 by DHCP PD, even if it only receives 2365 less. 2367 o Added note about DS-Lite but emphasised transition is out of 2368 scope. 2370 o Added text about multicast routing. 2372 B.14. Version 04 2374 Changes made include: 2376 o Moved border section from IPv6 differences to principles section. 2378 o Restructured principles into areas. 2380 o Added summary of naming and service discovery discussion from WG 2381 list. 2383 B.15. Version 03 2385 Changes made include: 2387 o Various improvements to the readability. 2389 o Removed bullet lists of requirements, as requested by chair. 2391 o Noted 6204bis has replaced advanced-cpe draft. 2393 o Clarified the topology examples are just that. 2395 o Emphasised we are not targetting walled gardens, but they should 2396 not be precluded. 2398 o Also changed text about requiring support for walled gardens. 2400 o Noted that avoiding falling foul of ingress filtering when 2401 multihomed is desirable. 2403 o Improved text about realms, detecting borders and policies at 2404 borders. 2406 o Stated this text makes no recommendation about default security 2407 model. 2409 o Added some text about failure modes for users plugging things 2410 arbitrarily. 2412 o Expanded naming and service discovery text. 2414 o Added more text about ULAs. 2416 o Removed reference to version 1 on chair feedback. 2418 o Stated that NPTv6 adds architectural cost but is not a homenet 2419 matter if deployed at the CER. This text only considers the 2420 internal homenet. 2422 o Noted multihoming is supported. 2424 o Noted routers may not by separate devices, they may be embedded in 2425 devices. 2427 o Clarified simple and advanced security some more, and RFC 4864 and 2428 6092. 2430 o Stated that there should be just one secret key, if any are used 2431 at all. 2433 o For multihoming, support multiple CERs but note that routing to 2434 the correct CER to avoid ISP filtering may not be optimal within 2435 the homenet. 2437 o Added some ISPs renumber due to privacy laws. 2439 o Removed extra repeated references to Simple Security. 2441 o Removed some solution creep on RIOs/RAs. 2443 o Load-balancing scenario added as to be supported. 2445 B.16. Version 02 2447 Changes made include: 2449 o Made the IPv6 implications section briefer. 2451 o Changed Network Models section to describe properties of the 2452 homenet with illustrative examples, rather than implying the 2453 number of models was fixed to the six shown in 01. 2455 o Text to state multihoming support focused on single CER model. 2456 Multiple CER support is desirable, but not required. 2458 o Stated that NPTv6 not supported. 2460 o Added considerations section for operations and management. 2462 o Added bullet point principles/requirements to Section 3.4. 2464 o Changed IPv6 solutions must not adversely affect IPv4 to should 2465 not. 2467 o End-to-end section expanded to talk about "Simple Security" and 2468 borders. 2470 o Extended text on naming and service discovery. 2472 o Added reference to RFC 2775, RFC 6177. 2474 o Added reference to the new xmDNS draft. 2476 o Added naming/SD requirements from Ralph Droms. 2478 Authors' Addresses 2480 Tim Chown (editor) 2481 University of Southampton 2482 Highfield 2483 Southampton , Hampshire SO17 1BJ 2484 United Kingdom 2486 Email: tjc@ecs.soton.ac.uk 2487 Jari Arkko 2488 Ericsson 2489 Jorvas 02420 2490 Finland 2492 Email: jari.arkko@piuha.net 2494 Anders Brandt 2495 Sigma Designs 2496 Emdrupvej 26A, 1 2497 Copenhagen DK-2100 2498 Denmark 2500 Email: abr@sdesigns.dk 2502 Ole Troan 2503 Cisco Systems, Inc. 2504 Drammensveien 145A 2505 Oslo N-0212 2506 Norway 2508 Email: ot@cisco.com 2510 Jason Weil 2511 Time Warner Cable 2512 13820 Sunrise Valley Drive 2513 Herndon, VA 20171 2514 USA 2516 Email: jason.weil@twcable.com