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