idnits 2.17.1 draft-ietf-homenet-arch-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2012) is 4208 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) == Outdated reference: A later version (-04) exists of draft-mglt-homenet-front-end-naming-delegation-00 == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 == Outdated reference: A later version (-04) exists of draft-arkko-homenet-prefix-assignment-02 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-28 == Outdated reference: A later version (-01) exists of draft-kline-default-perimeter-00 == Outdated reference: A later version (-12) exists of draft-ietf-v6ops-6204bis-11 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 5 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 22, 2013 Ericsson 6 A. Brandt 7 Sigma Designs 8 O. Troan 9 Cisco Systems, Inc. 10 J. Weil 11 Time Warner Cable 12 October 19, 2012 14 Home Networking Architecture for IPv6 15 draft-ietf-homenet-arch-05 17 Abstract 19 This text describes evolving networking technology within 20 increasingly large residential home networks. The goal of this 21 document is to define an architecture for IPv6-based home networking, 22 while describing the associated principles, considerations and 23 requirements. The text briefly highlights the specific implications 24 of the introduction of IPv6 for home networking, discusses the 25 elements of the architecture, and suggests how standard IPv6 26 mechanisms and addressing can be employed in home networking. The 27 architecture describes the need for specific protocol extensions for 28 certain additional functionality. It is assumed that the IPv6 home 29 network is not actively managed, and runs as an IPv6-only or dual- 30 stack network. There are no recommendations in this text for the 31 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 22, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 5 69 2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . . 6 70 2.1. Multiple subnets and routers . . . . . . . . . . . . . . . 6 71 2.2. Global addressability and elimination of NAT . . . . . . . 7 72 2.3. Multi-Addressing of devices . . . . . . . . . . . . . . . 7 73 2.4. Unique Local Addresses (ULAs) . . . . . . . . . . . . . . 8 74 2.5. Naming, and manual configuration of IP addresses . . . . . 9 75 2.6. IPv6-only operation . . . . . . . . . . . . . . . . . . . 9 76 3. Homenet Architecture . . . . . . . . . . . . . . . . . . . . . 10 77 3.1. General Principles . . . . . . . . . . . . . . . . . . . . 11 78 3.1.1. Reuse existing protocols . . . . . . . . . . . . . . . 11 79 3.1.2. Minimise changes to hosts and routers . . . . . . . . 11 80 3.2. Homenet Topology . . . . . . . . . . . . . . . . . . . . . 11 81 3.2.1. Supporting arbitrary topologies . . . . . . . . . . . 11 82 3.2.2. Network topology models . . . . . . . . . . . . . . . 12 83 3.2.3. Dual-stack topologies . . . . . . . . . . . . . . . . 16 84 3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 17 85 3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 18 86 3.3.1. Homenet realms and borders . . . . . . . . . . . . . . 19 87 3.3.2. Largest practical subnets . . . . . . . . . . . . . . 20 88 3.3.3. Handling multiple homenets . . . . . . . . . . . . . . 20 89 3.3.4. Coordination of configuration information . . . . . . 20 90 3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . . 21 91 3.4.1. Use of ISP-delegated IPv6 prefixes . . . . . . . . . . 21 92 3.4.2. Stable internal IP addresses . . . . . . . . . . . . . 22 93 3.4.3. Internal prefix delegation . . . . . . . . . . . . . . 23 94 3.4.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . 24 95 3.5. Routing functionality . . . . . . . . . . . . . . . . . . 24 96 3.5.1. Multicast routing . . . . . . . . . . . . . . . . . . 26 98 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 3.6.1. Addressability vs reachability . . . . . . . . . . . . 26 100 3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 27 101 3.6.3. Marginal Effectiveness of NAT and Firewalls . . . . . 28 102 3.6.4. Device capabilities . . . . . . . . . . . . . . . . . 28 103 3.6.5. ULAs as a hint of connection origin . . . . . . . . . 28 104 3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 29 105 3.7.1. Discovering services . . . . . . . . . . . . . . . . . 29 106 3.7.2. Assigning names to devices . . . . . . . . . . . . . . 29 107 3.7.3. Name spaces . . . . . . . . . . . . . . . . . . . . . 30 108 3.7.4. The homenet name service . . . . . . . . . . . . . . . 31 109 3.7.5. Independent operation . . . . . . . . . . . . . . . . 32 110 3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 33 111 3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 33 112 3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 33 113 3.8.1. Proxy or Extend? . . . . . . . . . . . . . . . . . . . 33 114 3.8.2. Quality of Service . . . . . . . . . . . . . . . . . . 34 115 3.8.3. Operations and Management . . . . . . . . . . . . . . 34 116 3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 35 117 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 35 118 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 119 5.1. Normative References . . . . . . . . . . . . . . . . . . . 35 120 5.2. Informative References . . . . . . . . . . . . . . . . . . 36 121 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 39 122 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 40 123 B.1. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 40 124 B.2. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 40 125 B.3. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 40 126 B.4. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 42 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 129 1. Introduction 131 This document focuses on evolving networking technology within 132 increasingly large residential home networks and the associated 133 challenges with their deployment and operation. There is a growing 134 trend in home networking for the proliferation of networking 135 technology in an increasingly broad range of devices and media. This 136 evolution in scale and diversity sets requirements on IETF protocols. 137 Some of these requirements relate to the introduction of IPv6, others 138 to the introduction of specialised networks for home automation and 139 sensors. 141 While at the time of writing some complex home network topologies 142 exist, most operate based on IPv4, employ solutions that we would 143 like to avoid such as (cascaded) network address translation (NAT), 144 or require expert assistance to set up. In IPv6 home networks, there 145 are likely to be scenarios where internal routing is required, for 146 example to support private and guest networks, in which case such 147 networks may use increasing numbers of subnets, and require methods 148 for IPv6 prefixes to be delegated to those subnets. The assumption 149 of this document is that the homenet is as far as possible self- 150 organising and self-configuring, and is thus need not be pro-actively 151 managed by the residential user. 153 The architectural constructs in this document are focused on the 154 problems to be solved when introducing IPv6 with an eye towards a 155 better result than what we have today with IPv4, as well as a better 156 result than if the IETF had not given this specific guidance. The 157 document aims to provide the basis and guiding principles for how 158 standard IPv6 mechanisms and addressing [RFC2460] [RFC4291] can be 159 employed in home networking, while coexisting with existing IPv4 160 mechanisms. In emerging dual-stack home networks it is vital that 161 introducing IPv6 does not adversely affect IPv4 operation. We assume 162 that the IPv4 network architecture in home networks is what it is, 163 and can not be affected by new recommendations. Future deployments, 164 or specific subnets within an otherwise dual-stack home network, may 165 be IPv6-only, in which case considerations for IPv4 impact would not 166 apply. 168 This architecture document proposes a baseline homenet architecture, 169 based on protocols and implementations that are as far as possible 170 proven and robust. The scope of the document is primarily the 171 network layer technologies that provide the basic functionality to 172 enable addressing, connectivity, routing, naming and service 173 discovery. While it may, for example, state that homenet components 174 must be simple to deploy and use, it does not discuss specific user 175 interfaces, nor does it discuss specific physical, wireless or data- 176 link layer considerations. 178 [RFC6204] defines basic requirements for customer edge routers 179 (CERs). The scope of this text is the internal homenet, and thus 180 specific features on the CER are out of scope for this text. While 181 the network may be dual-stack or IPv6-only, the definition of 182 specific transition tools on the CER, as introduced in RFC 6204-bis 183 [I-D.ietf-v6ops-6204bis] with DS-Lite [RFC6333] and 6rd [RFC5969], 184 are considered issues for that RFC, and are thus also out of scope of 185 this text. 187 1.1. Terminology and Abbreviations 189 In this section we define terminology and abbreviations used 190 throughout the text. 192 o "Advanced Security". Describes advanced security functions for a 193 CER, as defined in [I-D.vyncke-advanced-ipv6-security], where the 194 default inbound connection policy is generally "default allow". 196 o ALQDN: Ambiguous Locally Qualified Domain Name. An example would 197 be .sitelocal. 199 o CER: Customer Edge Router. A border router at the edge of the 200 homenet. 202 o FQDN: Fully Qualified Domain Name. A globally unique name space. 204 o LLN: Low-power and lossy network. 206 o LQDN: Locally Qualified Domain Name. A name space local to the 207 homenet. 209 o NAT: Network Address Translation. Typically referring to IPv4 210 Network Address and Port Translation (NAPT) [RFC3022]. 212 o NPTv6: Network Prefix Translation for IPv6 [RFC6296]. 214 o PCP: Port Control Protocol [I-D.ietf-pcp-base]. 216 o "Simple Security". Defined in [RFC4864] and expanded further in 217 [RFC6092]; describes recommended perimeter security capabilities 218 for IPv6 networks. 220 o ULA: IPv6 Unique Local Addresses [RFC4193]. 222 o ULQDN: Unique Locally Qualified Domain Name. An example might be 223 ..sitelocal. 225 o UPnP: Universal Plug and Play. Includes the Internet Gateway 226 Device (IGD) function, which for IPv6 is UPnP IGD Version 2 227 [IGD-2]. 229 o VM: Virtual machine. 231 o WPA2: Wi-Fi Protected Access, as defined by the Wi-Fi Alliance. 233 2. Effects of IPv6 on Home Networking 235 While IPv6 resembles IPv4 in many ways, it changes address allocation 236 principles, making multi-addressing the norm, and allowing direct IP 237 addressability of home networking devices from the Internet. This 238 section presents an overview of some of the key implications of the 239 introduction of IPv6 for home networking, that are simultaneously 240 both promising and problematic. 242 2.1. Multiple subnets and routers 244 The introduction of IPv6 for home networking enables the potential 245 for every home network to be delegated enough address space to 246 provision globally unique prefixes for each subnet in the home. Such 247 subnetting is not common practice in existing IPv4 homenets, but is 248 very likely to become increasingly standard in future IPv6 homenets. 250 While simple layer 3 topologies involving as few subnets as possible 251 are preferred in home networks, the incorporation of dedicated 252 (routed) subnets remains necessary for a variety of reasons. For 253 instance, an increasingly common feature in modern home routers is 254 the ability to support both guest and private network subnets. 255 Likewise, there may be a need to separate building control or 256 corporate extensions from the main Internet access network, or 257 different subnets may in general be associated with parts of the 258 homenet that have different routing and security policies. Further, 259 link layer networking technology is poised to become more 260 heterogeneous, as networks begin to employ both traditional Ethernet 261 technology and link layers designed for low-power and lossy networks 262 (LLNs), such as those used for certain types of sensor devices. 263 Constraining the flow of certain traffic from Ethernet links to much 264 lower capacity links thus becomes an important topic. 266 The addition of routing between subnets raises the issue of how to 267 extend mechanisms such as service discovery which currently rely on 268 link-local addressing to limit scope. There are two broad choices; 269 extend existing protocols to work across the scope of the homenet, or 270 introduce proxies for existing link layer protocols. This topic is 271 discussed later in the document. 273 There will also be the need to discover which routers in the homenet 274 are the border router(s) by an appropriate mechanism. Here, there 275 are a number of choices, including the use of an appropriate service 276 discovery protocol. Whatever method is chosen would likely have to 277 deal with handling more than one router responding in multihomed 278 environments. 280 2.2. Global addressability and elimination of NAT 282 Current IPv4 home networks typically receive a single global IPv4 283 address from their ISP and use NAT with private [RFC1918] addresses 284 for devices within the network. An IPv6 home network removes the 285 need to use NAT given the ISP offers a sufficiently large globally 286 unique IPv6 prefix to the homenet, allowing every device on every 287 subnet to be assigned a globally unique IPv6 address. 289 The end-to-end communication that is potentially enabled with IPv6 is 290 on the one hand an incredible opportunity for innovation and simpler 291 network operation, but it is also a concern as it exposes nodes in 292 the internal networks to receipt of otherwise unwanted traffic from 293 the Internet. While devices and applications can potentially talk 294 directly to each other when all devices have globally unique 295 addresses, there may be an expectation of improved host security to 296 compensate for this. It should be noted that many devices may (for 297 example) ship with default settings that make them readily vulnerable 298 to compromise by external attackers if globally accessible, or may 299 simply not have robustness designed-in because it was either assumed 300 such devices would only be used on private networks or the device 301 itself doesn't have the computing power to apply the necessary 302 security methods. 304 IPv6 networks may or may not have filters applied at their borders, 305 i.e. at the homenet CER. [RFC4864], [RFC6092] and 306 [I-D.vyncke-advanced-ipv6-security] discuss such filtering, and the 307 merits of "default allow" against "default deny" policies for 308 external traffic initiated into a homenet. It is important to 309 distinguish between addressability and reachability. While IPv6 310 offers global addressability through use of globally unique addresses 311 in the home, whether they are globally reachable or not would depend 312 on the firewall or filtering configuration, and not, as is commonly 313 the case with IPv4, the presence or use of NAT. 315 2.3. Multi-Addressing of devices 317 In an IPv6 network, devices may acquire multiple addresses, typically 318 at least a link-local address and a globally unique address. They 319 may also have an IPv4 address if the network is dual-stack, a Unique 320 Local Address (ULA) [RFC4193] (see below), and one or more IPv6 321 Privacy Addresses [RFC4941]. 323 Thus it should be considered the norm for devices on IPv6 home 324 networks to be multi-addressed, and to need to make appropriate 325 address selection decisions for the candidate source and destination 326 address pairs. Default Address Selection for IPv6 [RFC6724] provides 327 a solution for this, though it may face problems in the event of 328 multihoming, where nodes will be configured with one address from 329 each upstream ISP prefix. In such cases the presence of upstream 330 ingress filtering requires multi-addressed nodes to select the 331 correct source address to be used for the corresponding uplink, to 332 avoid ISP BCP 38 ingress filtering, but the node may not have the 333 information it needs to make that decision based on addresses alone. 334 We discuss such challenges in the multihoming section later in this 335 document. 337 2.4. Unique Local Addresses (ULAs) 339 [RFC4193] defines Unique Local Addresses (ULAs) for IPv6 that may be 340 used to address devices within the scope of a single site. Support 341 for ULAs for IPv6 CERs is described in [RFC6204]. A home network 342 running IPv6 may deploy ULAs for stable communication between devices 343 (on different subnets) within the network where the externally 344 allocated global prefix changes over time (e.g. due to renumbering 345 within the subscriber's ISP) or where external connectivity is 346 temporarily unavailable. 348 A counter-argument to using ULAs is that it is undesirable to 349 aggressively deprecate global prefixes for temporary loss of 350 connectivity, so for a host to lose its global address there would 351 have to be a connection breakage longer than the lease period, and 352 even then, deprecating prefixes when there is no connectivity may not 353 be advisable. It should also be noted that there may be timers on 354 the prefix lease to the homenet, on the internal prefix delegations, 355 and on the Router Advertisements to the hosts. Despite this counter- 356 argument, while setting a network up there may be a period with no 357 connectivity, in which case ULAs would be required for inter-subnet 358 communication. In the case where LLNs are being set up in a new 359 home/deployment, individual LLNs may, at least initially, each use 360 their own /48 ULA prefix. 362 Default address selection mechanisms should ensure a ULA source 363 address is used to communicate with ULA destination addresses when 364 appropriate, in particular when the ULA destination lies within a /48 365 ULA prefix known to be used within the same homenet. Note that 366 unlike the IPv4 private RFC 1918 space, the use of ULAs does not 367 imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT 368 [RFC6296], rather that external communications should use a node's 369 additional globally unique IPv6 source address. 371 2.5. Naming, and manual configuration of IP addresses 373 Some IPv4 home networking devices expose IPv4 addresses to users, 374 e.g. the IPv4 address of a home IPv4 CER that may be configured via a 375 web interface. Users should not be expected to enter IPv6 literal 376 addresses in homenet devices or applications, given their much 377 greater length and apparent randomness to a typical home user. While 378 shorter addresses, perhaps ones registered with IANA from ULA-C space 379 [I-D.hain-ipv6-ulac], could be used for specific devices/services, in 380 general it is better to not expose users to real IPv6 addresses. 381 Thus, even for the simplest of functions, simple naming and the 382 associated (ideally zero configuration) discovery of services is 383 imperative for the easy deployment and use of homenet devices and 384 applications. 386 In a multi-subnet homenet, naming and service discovery should be 387 expected to be capable of operating across the scope of the entire 388 home network, and thus be able to cross subnet boundaries. It should 389 be noted that in IPv4, such services do not generally function across 390 home router NAT boundaries, so this is one area where there is room 391 for improvement in IPv6. 393 2.6. IPv6-only operation 395 It is likely that IPv6-only networking will be deployed first in 396 "greenfield" homenet scenarios, or perhaps as one element of an 397 otherwise dual-stack network. Running IPv6-only adds additional 398 requirements, e.g. for devices to get configuration information via 399 IPv6 transport (not relying on an IPv4 protocol such as IPv4 DHCP), 400 and for devices to be able to initiate communications to external 401 devices that are IPv4-only. Thus, for example, the following 402 requirements are amongst those that should be considered in IPv6-only 403 environments: 405 o Ensuring there is a way to access content in the IPv4 Internet. 406 This can be arranged through appropriate use of NAT64 [RFC6144] 407 and DNS64 [RFC6145], for example, or via a node-based DS-Lite 408 [RFC6333] approach. 410 o DNS discovery mechanisms are enabled for IPv6. Both stateless 411 DHCPv6 [RFC3736] [RFC3646] and Router Advertisement options 412 [RFC6106] may have to be supported and turned on by default to 413 ensure maximum compatibility with all types of hosts in the 414 network. This requires, however, that a working DNS server is 415 known and addressable via IPv6, and that the automatic discovery 416 of such a server is possible through multiple routers in the 417 homenet. 419 o All nodes in the home network support operations in IPv6-only 420 mode. Some current devices work well with dual-stack but fail to 421 recognise connectivity when IPv4 DHCP fails, for instance. 423 The widespread availability of robust solutions to these types of 424 requirements will help accelerate the uptake of IPv6-only homenets. 425 The specifics of these are however beyond the scope of this document, 426 especially those functions that reside on the CPE. 428 3. Homenet Architecture 430 The aim of this architecture text is to outline how to construct 431 advanced IPv6-based home networks involving multiple routers and 432 subnets using standard IPv6 protocols and addressing [RFC2460] 433 [RFC4291]. In this section, we present the elements of such a home 434 networking architecture, with discussion of the associated design 435 principles. 437 Existing IETF work [RFC6204] defines the "basic" requirements for 438 Customer Edge Routers, while [I-D.ietf-v6ops-6204bis] extends RFC 439 6204 to describe additional features. The homenet architecture is 440 focused on the internal homenet, rather than the CER(s). In general, 441 home network equipment needs to be able to operate in networks with a 442 range of different properties and topologies, where home users may 443 plug components together in arbitrary ways and expect the resulting 444 network to operate. Significant manual configuration is rarely, if 445 at all, possible, given the knowledge level of typical home users. 446 Thus the network should, as far as possible, be self-configuring. 448 The equipment also needs to be prepared to handle at least 450 o Routing 452 o Prefix configuration for routers 454 o Name resolution 456 o Service discovery 458 o Network security 460 The remainder of this document describes the principles by which a 461 homenet architecture may deliver these properties. 463 3.1. General Principles 465 There is little that the Internet standards community can do about 466 the physical topologies or the need for some networks to be separated 467 at the network layer for policy or link layer compatibility reasons. 468 However, there is a lot of flexibility in using IP addressing and 469 inter-networking mechanisms. This architecture text discusses how 470 this flexibility should be used to provide the best user experience 471 and ensure that the network can evolve with new applications in the 472 future. The principles described in this text should be followed 473 when designing homenet solutions. 475 3.1.1. Reuse existing protocols 477 It is desirable to reuse existing protocols where possible, but at 478 the same time to avoid consciously precluding the introduction of new 479 or emerging protocols. A generally conservative approach, giving 480 weight to running code, is preferable. Where new protocols are 481 required, evidence of commitment to implementation by appropriate 482 vendors or development communities is highly desirable. Protocols 483 used should be backwardly compatible, and forward compatible where 484 changes are made. 486 3.1.2. Minimise changes to hosts and routers 488 Where possible, any requirement for changes to hosts and routers 489 should be minimised, though solutions which, for example, 490 incrementally improve with host changes may be acceptable. 492 3.2. Homenet Topology 494 This section considers homenet topologies, and the principles that 495 may be applied in designing an architecture to support as wide a 496 range as possible of such topologies. 498 3.2.1. Supporting arbitrary topologies 500 There should ideally be no built-in assumptions about the topology in 501 home networks, as users are capable of connecting their devices in 502 "ingenious" ways. Thus arbitrary topologies and arbitrary routing 503 will need to be supported, or at least the failure mode for when the 504 user makes a mistake should be as robust as possible, e.g. de- 505 activating a certain part of the infrastructure to allow the rest to 506 operate. In such cases, the user should ideally have some useful 507 indication of the failure mode encountered. 509 There are no topology secenarios which could cause loss of 510 connectivity, except when the user creates a physical island within 511 the topology. Some potentially pathological cases that can be 512 created include bridging ports of a router together, however this 513 case can be detected and dealt with by the router. Routing cycles 514 within a topology are in a sense good in that they offer redundancy. 515 Bridging cyslces can be dangerous but are also detectable when a 516 switch learns the MAC of one of its interfaces on another or runs a 517 spanning tree or link state protocol. It is only cycles using simple 518 repeaters that are truly pathological. 520 3.2.2. Network topology models 522 Most IPv4 home network models at the time of writing tend to be 523 relatively simple, typically a single NAT router to the ISP and a 524 single internal subnet but, as discussed earlier, evolution in 525 network architectures is driving more complex topologies, such as the 526 separation of guest and private networks. There may also be some 527 cascaded IPv4 NAT scenarios, which we mention in the next section. 529 In general, the models described in [RFC6204] and its successor RFC 530 6204-bis [I-D.ietf-v6ops-6204bis] should be supported by the IPv6 531 home networking architecture. The functions resident on the CER 532 itself are, as stated previously, out of scope of this text. 534 There are a number of properties or attributes of a home network that 535 we can use to describe its topology and operation. The following 536 properties apply to any IPv6 home network: 538 o Presence of internal routers. The homenet may have one or more 539 internal routers, or may only provide subnetting from interfaces 540 on the CER. 542 o Presence of isolated internal subnets. There may be isolated 543 internal subnets, with no direct connectivity between them within 544 the homenet. Isolation may be physical, or implemented via IEEE 545 802.1q VLANs. The latter is however not something a typical user 546 would be expected to configure. 548 o Demarcation of the CER. The CER(s) may or may not be managed by 549 the ISP. If the demarcation point is such that the customer can 550 provide or manage the CER, its configuration must be simple. Both 551 models must be supported. 553 Various forms of multihoming are likely to be more prevalent with 554 IPv6 home networks, as discussed further below. Thus the following 555 properties should also be considered for such networks: 557 o Number of upstream providers. A typical homenet might just have a 558 single upstream ISP, but it may become more common for there to be 559 multiple ISPs, whether for resilience or provision of additional 560 services. Each would offer its own prefix. Some may or may not 561 be walled gardens. 563 o Number of CERs. The homenet may have a single CER, which might be 564 used for one or more providers, or multiple CERs. The presence of 565 multiple CERs adds additional complexity for multihoming 566 scenarios, and protocols like PCP that need to manage connection- 567 oriented state mappings. 569 In the following sections we give some examples of the types of 570 homenet topologies we may see in the future. This is not intended to 571 be an exhaustive or complete list, rather an indicative one to 572 facilitate the discussion in this text. 574 3.2.2.1. A: Single ISP, Single CER, Internal routers 576 Figure 1 shows a network with multiple local area networks. These 577 may be needed for reasons relating to different link layer 578 technologies in use or for policy reasons, e.g. classic Ethernet in 579 one subnet and a LLN link layer technology in another. In this 580 example there is no single router that a priori understands the 581 entire topology. The topology itself may also be complex, and it may 582 not be possible to assume a pure tree form, for instance (home users 583 may plug routers together to form arbitrary topologies including 584 loops). 586 +-------+-------+ \ 587 | Service | \ 588 | Provider | | Service 589 | Router | | Provider 590 +-------+-------+ | network 591 | / 592 | Customer / 593 | Internet connection 594 | 595 +------+--------+ \ 596 | IPv6 | \ 597 | Customer Edge | \ 598 | Router | | 599 +----+-+---+----+ | 600 Network A | | | Network B(E) | 601 ----+-------------+----+ | +---+-------------+------+ | 602 | | | | | | | 603 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | | 604 |IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | | 605 | H1 | | H2 | | | H3 | | H4 | | | 606 +----------+ +----------+ | +----------+ +----------+ | | 607 | | | | | 608 Link F | ---+------+------+-----+ | 609 | | Network E(B) | 610 +------+--------+ | | End-User 611 | IPv6 | | | networks 612 | Interior +------+ | 613 | Router | | 614 +---+-------+-+-+ | 615 Network C | | Network D | 616 ----+-------------+---+ +---+-------------+--- | 617 | | | | | 618 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 619 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 620 | H5 | | H6 | | H7 | | H8 | / 621 +----------+ +----------+ +----------+ +----------+ / 623 Figure 1 625 In this diagram there is one CER. It has a single uplink interface. 626 It has three additional interfaces connected to Network A, Link F, 627 and Network B. IPv6 Internal Router (IR) has four interfaces 628 connected to Link F, Network C, Network D and Network E. Network B 629 and Network E have been bridged, likely inadvertedly. This could be 630 as a result of connecting a wire between a switch for Network B and a 631 switch for Network E. 633 Any of logical Networks A through F might be wired or wireless. 635 Where multiple hosts are shown, this might be through one or more 636 physical ports on the CER or IPv6 (IR), wireless networks, or through 637 one or more layer-2 only ethernet switches. 639 3.2.2.2. B: Two ISPs, Two CERs, Shared subnet 641 +-------+-------+ +-------+-------+ \ 642 | Service | | Service | \ 643 | Provider A | | Provider B | | Service 644 | Router | | Router | | Provider 645 +------+--------+ +-------+-------+ | network 646 | | / 647 | Customer | / 648 | Internet connections | / 649 | | 650 +------+--------+ +-------+-------+ \ 651 | IPv6 | | IPv6 | \ 652 | Customer Edge | | Customer Edge | \ 653 | Router 1 | | Router 2 | / 654 +------+--------+ +-------+-------+ / 655 | | / 656 | | | End-User 657 ---+---------+---+---------------+--+----------+--- | network(s) 658 | | | | \ 659 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 660 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 661 | H1 | | H2 | | H3 | | H4 | / 662 +----------+ +----------+ +----------+ +----------+ 664 Figure 2 666 Figure 2 illustrates a multihomed homenet model, where the customer 667 has connectivity via CER1 to ISP A and via CER2 to ISP B. This 668 example shows one shared subnet where IPv6 nodes would potentially be 669 multihomed and receive multiple IPv6 global addresses, one per ISP. 670 This model may also be combined with that shown in Figure 1 to create 671 a more complex scenario with multiple internal routers. Or the above 672 shared subnet may be split in two, such that each CER serves a 673 separate isolated subnet, which is a scenario seen with some IPv4 674 networks today. 676 3.2.2.3. C: Two ISPs, One CER, Shared subnet 678 +-------+-------+ +-------+-------+ \ 679 | Service | | Service | \ 680 | Provider A | | Provider B | | Service 681 | Router | | Router | | Provider 682 +-------+-------+ +-------+-------+ | network 683 | | / 684 | Customer | / 685 | Internet | / 686 | connections | | 687 +---------+---------+ \ 688 | IPv6 | \ 689 | Customer Edge | \ 690 | Router | / 691 +---------+---------+ / 692 | / 693 | | End-User 694 ---+------------+-------+--------+-------------+--- | network(s) 695 | | | | \ 696 +----+-----+ +----+-----+ +----+-----+ +-----+----+ \ 697 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 698 | H1 | | H2 | | H3 | | H4 | / 699 +----------+ +----------+ +----------+ +----------+ 701 Figure 3 703 Figure 3 illustrates a model where a home network may have multiple 704 connections to multiple providers or multiple logical connections to 705 the same provider, with shared internal subnets. 707 In general, while the architecture may focus on likely common 708 topologies, it should not preclude any arbitrary topology from being 709 constructed. 711 3.2.3. Dual-stack topologies 713 It is expected that most homenet deployments will for the immediate 714 future be dual-stack IPv4/IPv6. In such networks it is important not 715 to introduce new IPv6 capabilities that would cause a failure if used 716 alongside IPv4+NAT, given that such dual-stack homenets will be 717 commonplace for some time. That said, it is desirable that IPv6 718 works better than IPv4 in as many scenarios as possible. Further, 719 the homenet architecture must operate in the absence of IPv4. 721 A general recommendation is to follow the same topology for IPv6 as 722 is used for IPv4, but not to use NAT. Thus there should be routed 723 IPv6 where an IPv4 NAT is used, and where there is no NAT routing or 724 bridging may be used. Routing may have advantages when compared to 725 bridging together high speed and lower speed shared media, and in 726 addition bridging may not be suitable for some media, such as ad-hoc 727 mobile networks. 729 In some cases IPv4 NAT home networks may feature cascaded NATs, which 730 may include cases where NAT routers are included within VMs, or where 731 Internet connection sharing services are used. IPv6 routed versions 732 of such cases will be required. We should thus note that routers in 733 the homenet may not be separate physical devices; they may be 734 embedded within other devices. 736 3.2.4. Multihoming 738 A homenet may be multihomed to multiple providers, as the network 739 models above illustrate. This may either take a form where there are 740 multiple isolated networks within the home or a more integrated 741 network where the connectivity selection needs to be dynamic. 742 Current practice is typically of the former kind, but the latter is 743 expected to become more commonplace. 745 The general multihoming problem is broad, and solutions suggested to 746 date within the IETF may include complex architectures for monitoring 747 connectivity, traffic engineering, identifier-locator separation, 748 connection survivability across multihoming events, and so on. It is 749 thus important that the homenet architecture should as far as 750 possible minimise the complexity of any multihoming support. So we 751 should limit the support to the smallest subset of the overall 752 problem to meet the requirements of the topologies described above. 753 This means that the homenet architecture should not try to make 754 another attempt at solving complex multihoming, and we should prefer 755 to support scenarios for which solutions exist today. 757 In the general homenet architecture, hosts should be multi-addressed 758 with globally unique prefixes from each ISP they may communicate with 759 or through. An alternative for a homenet would be to deploy NPTv6 760 [RFC6296] at the CER, with ULAs then typically used internally, but 761 this mode is not considered by this text. If NPTv6 is used, the 762 internal part of the homenet (which is the scope of this text) simply 763 sees only the one (ULA) prefix in use. It should be noted that 764 running NPTv6 has an architectural cost, due to the prefix 765 translation used. 767 When multi-addressing is in use, hosts need some way to pick source 768 and destination address pairs for connections. A host may choose a 769 source address to use by various methods, which would typically 770 include [RFC6724]. Applications may of course do different things, 771 and this should not be precluded. 773 For the single CER Network Model C, multihoming may be offered by 774 source routing at the CER. With multiple exit routers, the 775 complexity rises. Given a packet with a source address on the 776 network, the packet must be routed to the proper egress to avoid BCP 777 38 [RFC2827] filtering at an ISP that did not delegate the prefix the 778 address is chosen from. While the packet might not take an optimal 779 path to the correct exit CER, the minimum requirement is that the 780 packet is not dropped. It is of course highly desirable that the 781 packet is routed in the most efficient manner to the correct exit. 783 There are various potential approaches to this problem, one example 784 being described in [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. 785 Another is discussed in [I-D.baker-fun-multi-router], which explores 786 support for source routing throughout the homenet. This approach 787 would however likely require relatively significant routing changes 788 to route the packet to the correct exit given the source address. 789 Such changes should preferably be minimised. 791 There are some other multihoming considerations for homenet 792 scenarios. First, it may be the case that multihoming applies due to 793 an ISP migration from a transition method to a native deployment, 794 e.g. a 6rd [RFC5969] sunset scenario. Second, one upstream may be a 795 "walled garden", and thus only appropriate to be used for 796 connectivity to the services of that provider; an example may be a 797 VPN service that only routes back to the enterprise business network 798 of a user in the homenet. While we should not specifically target 799 walled garden multihoming as a principal goal, it should not be 800 precluded. 802 Host-based methods such as Shim6 [RFC5533] have been defined, but of 803 course require support in the hosts. There are also application- 804 oriented approaches such as Happy Eyeballs [RFC6555]; simplified 805 versions of this are for example already implemented in some 806 commonly-used web browsers. The homenet architecture should not 807 preclude use of such tools should hosts include their support. 809 3.3. A Self-Organising Network 811 A home network architecture should be naturally self-organising and 812 self-configuring under different circumstances relating to the 813 connectivity status to the Internet, number of devices, and physical 814 topology. While the homenet should be self-organising, it should be 815 possible to manually adjust (override) the current configuration. 817 While a goal of the homenet architecture is for the network to be as 818 self-organising as possible, there may be instances where some manual 819 configuration is required, e.g. the entry of a WPA2 key to apply 820 wireless security, or to configure a shared routing secret. The 821 latter may be relevant when considering how to bootstrap a routing 822 configuration. It is highly desirable that only one such key is 823 needed for any set of functions, to increase usability for the 824 homenet user. 826 3.3.1. Homenet realms and borders 828 The homenet will need to be aware of the extent of its own "site", 829 which will define the borders for ULAs, site scope multicast, service 830 discovery and security policies. The homenet will have one or more 831 borders with external connectivity providers and potentially also 832 have borders within the internal network (e.g. for policy-based 833 reasons). It should be possible to automatically perform border 834 discovery for the different borders. Such borders determine for 835 example the scope of where prefixes, routing information, network 836 traffic, service discovery and naming may be shared. The default 837 mode internally should be to share everything. 839 It is expected that a realm would span at least an entire subnet, and 840 thus be associated to one delegated prefix within the homenet. It is 841 also desirable for a richer security model that hosts, which may be 842 running in a transparent communication mode, are able to make 843 decisions based on available realm and associated prefix information 844 in the same way that routers at realm borders can. 846 A simple homenet model may just consider three types of realm and the 847 borders between them. For example if the realms are the homenet, the 848 ISP and the guest network, then the borders will include that from 849 the homenet to the ISP, and that from the homenet to a guest network. 850 Regardless, it should be possible for additional types of realms and 851 borders to be defined, e.g. for some specific Grid or LLN-based 852 network, and for these to be detected automatically, and for an 853 appropriate default policy to be applied as to what type of traffic/ 854 data can flow across such borders. 856 It is desirable to classify the external border of the home network 857 as a unique logical interface separating the home network from 858 service provider network/s. This border interface may be a single 859 physical interface to a single service provider, multiple layer 2 860 sub-interfaces to a single service provider, or multiple connections 861 to a single or multiple providers. This border makes it possible to 862 describe edge operations and interface requirements across multiple 863 functional areas including security, routing, service discovery, and 864 router discovery. 866 It should be possible for the homenet user to override any 867 automatically determined borders and the default policies applied 868 between them. 870 Some initial proposals towards border discovery are presented in 871 [I-D.kline-default-perimeter]. 873 3.3.2. Largest practical subnets 875 Today's IPv4 home networks generally have a single subnet, and early 876 dual-stack deployments have a single congruent IPv6 subnet, possibly 877 with some bridging functionality. More recently, some vendors have 878 started to introduce "home" and "guest" functions, which in IPv6 879 would be implemented as two subnets. 881 Future home networks are highly likely to have one or more internal 882 routers and thus need multiple subnets, for the reasons described 883 earlier. As part of the self-organisation of the network, the 884 homenet should subdivide itself to the largest practical subnets that 885 can be constructed within the constraints of link layer mechanisms, 886 bridging, physical connectivity, and policy, and where applicable 887 performance or other criteria. For example, bridging a busy Gigabit 888 Ethernet subnet and a wireless subnet together may impact wireless 889 performance. 891 While it may be desirable to maximise the chance of link-local 892 protocols operating across a homenet by maximising the size of a 893 subnet, multi-subnet home networks are inevitable, so their support 894 must be included. 896 3.3.3. Handling multiple homenets 898 It is important that self-configuration with "unintended" devices is 899 avoided. Methods are needed for devices to know whether they are 900 intended to be part of the same homenet site or not. Thus methods to 901 ensure separation between neighbouring homenets are required. This 902 may require use of some unique "secret" for devices/protocols in each 903 homenet. Some existing mechanisms exist to assist home users to 904 associate devices as simply as possible, e.g. "connect" button 905 support. 907 3.3.4. Coordination of configuration information 909 The network elements will need to be integrated in a way that takes 910 account of the various lifetimes on timers that are used on different 911 elements, e.g. DHCPv6 PD, router, valid prefix and preferred prefix 912 timers. 914 3.4. Homenet Addressing 916 The IPv6 addressing scheme used within a homenet must conform to the 917 IPv6 addressing architecture [RFC4291]. The homenet will need to 918 adapt to the prefixes made available to it through the prefix 919 delegation method used by its upstream ISP. 921 3.4.1. Use of ISP-delegated IPv6 prefixes 923 A homenet may receive an arbitrary length IPv6 prefix from its 924 provider, e.g. /60, /56 or /48. The offered prefix may be stable or 925 change from time to time. Some ISPs may offer relatively stable 926 prefixes, while others may change the prefix whenever the CER is 927 reset. Some discussion of IPv6 prefix allocation policies is 928 included in [RFC6177] which discusses why, for example, a one-size- 929 fits-all /48 allocation is not desirable. 931 The home network needs to be adaptable to such ISP policies, and thus 932 make no assumptions about the stability of the prefix received from 933 an ISP, or the length of the prefix that may be offered. However, if 934 only a /64 is offered by the ISP, the homenet may be severely 935 constrained (with IPv6 not reaching all devices in the home, or use 936 of some form of IPv6 NAT being forced), or even unable to function. 937 While it may be possible to operate a DHCPv6-only network with 938 prefixes longer than /64, doing so would break SLAAC, and is thus not 939 recommended. 941 A DHCPv6-PD capable router should "hint" that it would like a /48 942 prefix from its ISP, i.e. the CPE asks the ISP for the maximum size 943 prefix it might expect to be offered, but in practice it may 944 typically only be offered a /56 or /60. 946 The internal operation of the home network should also not depend on 947 the availability of the ISP network at any given time, other than for 948 connectivity to services or systems off the home network. This 949 implies the use of ULAs for stable internal communication, as 950 described in the next section. 952 In practice, it is expected that ISPs will deliver a relatively 953 stable home prefix to customers. The norm for residential customers 954 of large ISPs may be similar to their single IPv4 address provision; 955 by default it is likely to remain persistent for some time, but 956 changes in the ISP's own provisioning systems may lead to the 957 customer's IP (and in the IPv6 case their prefix pool) changing. It 958 is not expected that ISPs will support Provider Independent (PI) 959 addressing for general residential homenets. 961 When an ISP needs to restructure and in doing so renumber its 962 customer homenets, "flash" renumbering is likely to be imposed. This 963 implies a need for the homenet to be able to handle a sudden 964 renumbering event which, unlike the process described in [RFC4192], 965 would be a "flag day" event, which means that a graceful renumbering 966 process moving through a state with two active prefixes in use would 967 not be possible. While renumbering is an extended version of an 968 initial numbering process, the difference between flash renumbering 969 and an initial "cold start" is the need to provide service 970 continuity. The deprecated addresses may remain usable for a short 971 period of time within the homenet. 973 There may be cases where local law means some ISPs are required to 974 change IPv6 prefixes (current IPv4 addresses) for privacy reasons for 975 their customers. In such cases it may be possible to avoid an 976 instant "flash" renumbering and plan a non-flag day renumbering as 977 per RFC 4192. 979 The customer may of course also choose to move to a new ISP, and thus 980 begin using a new prefix. In such cases the customer should expect a 981 discontinuity, and not only may the prefix change, but potentially 982 also the prefix length, if the new ISP offers a different default 983 size prefix, e.g. a /60 rather than a /56. Regardless, it's 984 desirable that homenet protocols support rapid renumbering and that 985 operational processes don't add unnecessary complexity for the 986 renumbering process. 988 The 6renum WG has studied IPv6 renumbering for enterprise networks. 989 It has not as yet targetted homenets, but may produce outputs that 990 are relevant. The introduction of any new homenet protocols should 991 not make any form of renumbering any more complex than it already is. 993 3.4.2. Stable internal IP addresses 995 The network should by default attempt to provide IP-layer 996 connectivity between all internal parts of the homenet as well as to 997 and from the external Internet, subject to the filtering policies or 998 other policy constraints discussed later in the security section. 1000 ULAs should be used within the scope of a homenet to support routing 1001 between subnets regardless of whether a globally unique ISP-provided 1002 prefix is available. It would be expected that ULAs would be used 1003 alongside one or more such global prefixes in a homenet, such that 1004 hosts become multi-addressed with both globally unique and ULA 1005 prefixes. Default address selection would then enable ULAs to be 1006 preferred for internal communications between devices that are using 1007 ULA prefixes generated within the same homenet. 1009 ULA addresses will allow constrained LLN devices to create permanent 1010 relationships between IPv6 addresses, e.g. from a wall controller to 1011 a lamp. Symbolic host names would require additional non-volatile 1012 memory. Updating global prefixes in sleeping LLN devices might also 1013 be problematic. 1015 ULAs may be used for all devices, not just those intended to only 1016 have internal connectivity. ULAs used in this way provide stable 1017 internal communications should the ISP-provided prefix (suddenly) 1018 change, or external connectivity be temporarily lost. The use of 1019 ULAs should be restricted to the homenet scope through filtering at 1020 the border(s) of the homenet, as described in RFC 6092. 1022 3.4.3. Internal prefix delegation 1024 As mentioned above, there are various sources of prefixes, e.g. they 1025 may be globally unique prefixes originating from ISP(s), they may be 1026 globally unique or ULA prefixes allocated by "master" router(s) in 1027 the homenet, or they may be ULAs allocated by LLN gateways. There 1028 may also be a prefix associated with NAT64, if in use in the homenet. 1030 From the homenet perspective, a single prefix from each ISP should be 1031 received on the border CER [RFC3633]. Then each subnet in the 1032 homenet should receive a prefix from within the ISP-provided 1033 prefix(es). The ISP should only see the aggregate from the homenet, 1034 and not single /64 prefixes allocated within the homenet. 1036 Delegation should be autonomous, and not assume a flat or 1037 hierarchical model. This text makes no assumption about whether the 1038 delegation of prefixes is distributed or centralised. The assignment 1039 mechanism should provide reasonable efficiency, so that typical home 1040 network prefix allocation sizes can accommodate all the necessary /64 1041 allocations in most cases, and not waste prefixes. A currently 1042 typical /60 allocation gives 16 /64 subnets. Duplicate assignment of 1043 multiple /64s to the same network should be avoided. The network 1044 should behave as gracefully as possible in the event of prefix 1045 exhaustion, though the options in such cases may be limited. 1047 Where multiple CERs exist with multiple ISP prefix pools, it is 1048 expected that routers within the homenet would assign themselves 1049 prefixes from each ISP they communicate with/through. 1051 Where ULAs are used, most likely but not necessarily in parallel with 1052 global prefixes, one router should be elected to offer ULA prefixes 1053 for the homenet. The router should generate a /48 ULA for the site, 1054 and then delegate /64's from that ULA prefix to subnets. In the 1055 normal state, a single /48 ULA should be used within the homenet. In 1056 cases where two /48 ULAs are generated within a homenet, the network 1057 should still continue to function. 1059 Delegation within the homenet should give each subnet a prefix that 1060 is persistent across reboots, power outages and similar short-term 1061 outages. Addition of a new routing device should not affect existing 1062 persistent prefixes, but persistence may not be expected in the face 1063 of significant "replumbing" of the homenet. Persistent prefixes 1064 should not depend on router boot order. Such persistent prefixes may 1065 imply the need for stable storage on routing devices, and also a 1066 method for a home user to "reset" the stored prefix should a 1067 significant reconfiguration be required (though ideally the home user 1068 should not be involved at all). 1070 The delegation method should support renumbering, which would 1071 typically be "flash" renumbering in that the homenet would not have 1072 advance notice of the event or thus be able to apply the types of 1073 approach described in [RFC4192]. As a minimum, delegated ULA 1074 prefixes within the homenet should remain persistent through an ISP- 1075 driven renumbering event. 1077 Several proposals have been made for prefix delegation within a 1078 homenet. One group of proposals is based on DHCPv6 PD, as described 1079 in [I-D.baker-homenet-prefix-assignment], 1080 [I-D.chakrabarti-homenet-prefix-alloc], [RFC3315] and [RFC3633]. The 1081 other uses OSPFv3, as described in 1082 [I-D.arkko-homenet-prefix-assignment]. More detailed analysis of 1083 these approaches needs to be made against the requirements/principles 1084 described above. For example, DHCPv6 solutions may have problems in 1085 multihomed scenarios with loops in the topology. 1087 3.4.4. Privacy 1089 There are no specific privacy concerns discussed in this text. It 1090 should be noted as above that many ISPs are expected to offer 1091 relatively stable IPv6 prefixes to customers, and thus the network 1092 prefix associated with the host addresses they use may not change 1093 over a reasonably long period of time. This exposure is similar to 1094 IPv4 networks that expose the same IPv4 global address via use of 1095 NAT, where the IPv4 address received from the ISP may change over 1096 time, but not necessarily that frequently. 1098 Hosts inside an IPv6 homenet may get new IPv6 addresses over time 1099 regardless, e.g. through Privacy Addresses [RFC4941]. 1101 3.5. Routing functionality 1103 Routing functionality is required when there are multiple routers 1104 deployed within the internal home network. This functionality could 1105 be as simple as the current "default route is up" model of IPv4 NAT, 1106 or, more likely, it would involve running an appropriate routing 1107 protocol. 1109 The homenet unicast routing protocol should preferably be an existing 1110 deployed protocol that has been shown to be reliable and robust, and 1111 it is preferable that the protocol is "lightweight". It is desirable 1112 that the routing protocol has knowledge of the homenet topology, 1113 which implies a link-state protocol is preferable. If so, it is also 1114 desirable that the announcements and use of LSAs and RAs are 1115 appropriately coordinated. This would mean the routing protocol 1116 gives a consistent view of the network, and that it can pass around 1117 more than just routing information. 1119 Multiple interface PHYs must be accounted for in the homenet routed 1120 topology. Technologies such as Ethernet, WiFi, MoCA, etc must be 1121 capable of coexisting in the same environment and should be treated 1122 as part of any routed deployment. The inclusion of the PHY layer 1123 characteristics including bandwidth, loss, and latency in path 1124 computation should be considered for optimising communication in the 1125 homenet. Multiple upstreams should be supported, as described in the 1126 multihoming section earlier. This should include load-balancing to 1127 multiple providers, and failover from a primary to a backup link when 1128 available. The protocol however should not require upstream ISP 1129 connectivity to be established to continue routing within the 1130 homenet. 1132 To support multihoming within a homenet, a routing protocol that can 1133 make routing decisions based on source and destination addresses is 1134 desirable, to avoid upstream ISP ingress filtering problems. In 1135 general the routing protocol should support multiple ISP uplinks and 1136 delegated prefixes in concurrent use. 1138 The routing environment should be self-configuring, as discussed 1139 previously. An example of how OSPFv3 can be self-configuring in a 1140 homenet is described in [I-D.acee-ospf-ospfv3-autoconfig]. 1141 Minimising convergence time should be a goal in any routed 1142 environment, but as a guideline a maximum convergence time of around 1143 30 seconds should be the target. 1145 Any routed solution will require a means for determining the 1146 boundaries of the homenet. Borders may include but are not limited 1147 to the interface to the upstream ISP, or a gateway device to a 1148 separate home network such as a LLN network. In some cases there may 1149 be no border present, which may for example occur before an upstream 1150 connection has been established. The border discovery functionality 1151 may be integrated into the routing protocol itself, but may also be 1152 imported via a separate discovery mechanism. 1154 In general, LLN or other networks should be able to attach and 1155 participate the same way as the main homenet, or alternatively map/be 1156 gatewayed to the main homenet. Current home deployments use largely 1157 different mechanisms in sensor and basic Internet connectivity 1158 networks. IPv6 VM solutions may also add additional routing 1159 requirements. 1161 3.5.1. Multicast routing 1163 It is also desirable that multicast routing is supported across the 1164 homenet. The natural scopes for multicast would be link-local or 1165 site-local, with the latter constrained within the homenet, but other 1166 policy borders, e.g. to a guest subnet, may also affect where 1167 specific multicast traffic is routed. 1169 Where multicast is routed cross a homenet an appropriate multicast 1170 routing protocol is required, one that as per the unicast routing 1171 protocol should be self-configuring. The multicast environment 1172 should support the ability for applications to pick a unique 1173 multicast group to use. 1175 3.6. Security 1177 The security of an IPv6 homenet is an important consideration. The 1178 most notable difference to the IPv4 operational model is the removal 1179 of NAT, the introduction of global addressability of devices, and 1180 thus a need to consider whether devices should have global 1181 reachability. However, there are other challenges introduced, e.g. 1182 default filtering policies at the borders between other homenet 1183 realms. 1185 There is no defined "threat model" as such for the type of IPv6 1186 homenet described in this text. Such a document may be very useful. 1187 It may include a variety of perspectives, from probing for specific 1188 types of home appliance being present, to potential denial of service 1189 attacks. Hosts need to be able to operate securely, end-to-end where 1190 required, but also be robust against malicious traffic direct towards 1191 them. We simply note at this point that software on home devices are 1192 likely to have an increase in security if it allows its software to 1193 be updated regularly. 1195 3.6.1. Addressability vs reachability 1197 An IPv6-based home network architecture should embrace and naturally 1198 offer a transparent end-to-end communications model as described in 1199 [RFC2775]. Each device should be addressable by a globally unique 1200 address, and those addresses must not be altered in transit. 1201 Security perimeters can (via policy) restrict end-to-end 1202 communications, and thus while a host may be globally addressable it 1203 may not be globally reachable. 1205 In IPv4 NAT networks, the NAT provides an implicit firewall function. 1206 [RFC4864] describes a "Simple Security" model for IPv6 networks, 1207 whereby stateful perimeter filtering can be applied instead where 1208 global addresses are used. RFC 4864 implies an IPv6 "default deny" 1209 policy for inbound connections be used for similar functionality to 1210 IPv4 NAT. It should be noted that such a "default deny" approach 1211 would effectively replace the need for IPv4 NAT traversal protocols 1212 with a need to use a signalling protocol to request a firewall hole 1213 be opened. Thus to support applications wanting to accept 1214 connections initiated into home networks where a "default deny" 1215 policy is in place support for a signalling protocol such as UPnP or 1216 PCP [I-D.ietf-pcp-base] is required. In networks with multiple CERs, 1217 the signalling would need to handle the cases of flows that may use 1218 one or more exit routers. CERs would need to be able to advertise 1219 their existence for such protocols. 1221 [RFC6092] expands on RFC 4864, giving a more detailed discussion of 1222 IPv6 perimeter security recommendations, without mandating a "default 1223 deny" approach. Indeed, RFC 6092 does not prescribe a particular 1224 mode of operation, instead stating that CERs must provide an easily 1225 selected configuration option that permits a "transparent" mode of 1226 operation, thus ensuring a "default allow" model is available. The 1227 homenet architecture text makes no recommendation on the default 1228 setting, and refers the reader to RFC 6092. 1230 Advanced Security for IPv6 CPEs [I-D.vyncke-advanced-ipv6-security] 1231 takes the approach that in order to provide the greatest end-to-end 1232 transparency as well as security, security policies must be updated 1233 by a trusted party which can provide intrusion signatures and other 1234 "active" information on security threats. This might for example 1235 allow different malware detection profiles to be configured on a CER. 1236 Such methods should be able to be automatically updating. 1238 3.6.2. Filtering at borders 1240 It is desirable that there are mechanisms to detect different types 1241 of borders within the homenet, as discussed previously, and then the 1242 means to apply different types of filtering policies at those 1243 borders, e.g. whether naming and service discovery should pass a 1244 given border. Any such policies should be able to be easily applied 1245 by typical home users, e.g. to give a user in a guest network access 1246 to media services in the home, or access to a printer. Simple 1247 mechanisms to apply policy changes, or associations between devices, 1248 will be required. 1250 There are cases where full internal connectivity may not be 1251 desirable, e.g. in certain utility networking scenarios, or where 1252 filtering is required for policy reasons against guest network 1253 subnet(s). Some scenarios/models may as a result involve running 1254 isolated subnet(s) with their own CERs. In such cases connectivity 1255 would only be expected within each isolated network (though traffic 1256 may potentially pass between them via external providers). 1258 LLNs provide an another example of where there may be secure 1259 perimeters inside the homenet. Constrained LLN nodes may implement 1260 WPA2-style network key security but may depend on access policies 1261 enforced by the LLN border router. 1263 3.6.3. Marginal Effectiveness of NAT and Firewalls 1265 Security by way of obscurity (address translation) or through 1266 firewalls (filtering) is at best marginally effective. The very poor 1267 security track record of home computer, home networking and business 1268 PC computers and networking is testomony to its ineffectiveness. A 1269 compromise behind the firewall of any device exposes all others, 1270 making an entire network that relies on obscurity or a firewall as 1271 vulnerable as the most insecure device on the private side of the 1272 network. 1274 However, given home network products with very poor security, putting 1275 a firewall in place does provide some protection, even if only 1276 marginally effective. IPv6 global reachability may increase the need 1277 to solve the underlying problem of certain insecure home and business 1278 computer and network products. The use of firewalls today, whether a 1279 good practice or not, is common practice and whatever protection 1280 afforded, even if marginally effective, must not be lost. 1282 3.6.4. Device capabilities 1284 In terms of the devices, homenet hosts should implement their own 1285 security policies in accordance to their computing capabilities. 1286 They should have the means to request transparent communications to 1287 be initiated to them, either for all ports or for specific services. 1288 Users should have simple methods to associate devices to services 1289 that they wish to operate transparently through (CER) borders. 1291 3.6.5. ULAs as a hint of connection origin 1293 It has been suggested that using ULAs would provide an indication to 1294 applications that received traffic is locally sourced. This could 1295 then be used with security settings to designate where a particular 1296 application is allowed to connect to or receive traffic from. 1298 3.7. Naming and Service Discovery 1300 Naming and service discovery must be supported in the homenet, and 1301 the service(s) providing this function must support unmanaged 1302 operation. 1304 The naming system will be required to work internally or externally, 1305 be the user within the homenet or outside it. The most natural way 1306 to think about such naming and service discovery is to enable it to 1307 work across the entire homenet residence (site), disregarding 1308 technical borders such as subnets but respecting policy borders such 1309 as those between guest and other internal network realms. 1311 3.7.1. Discovering services 1313 Users will typically perform service discovery through GUI interfaces 1314 that allow them to browse services on their network in an appropriate 1315 and intuitive way. Such interfaces are beyond the scope of this 1316 document, but the interface should have an appropriate API for the 1317 discovery to be performed. 1319 Such interfaces may also typically hide the local domain name element 1320 from users, especially where only one name space is available. As we 1321 discuss below, in some cases the ability to discover available 1322 domains may be useful. 1324 We note that current service discovery protocols are generally aimed 1325 at single subnets. There is thus a choice to make for multi-subnet 1326 homenets as to whether such protocols should be proxied or extended 1327 to operate across a whole homenet. This issue is discussed in more 1328 detail in a later section of this text. The outcome may have an 1329 impact, for example, on whether support may be required for IPv6 1330 multicast routing across the scope of the whole homenet. In general 1331 we should prefer approaches that are backwardly compatible, and allow 1332 current implementations to continue to be used. 1334 3.7.2. Assigning names to devices 1336 Given the large number of devices that may be networked in the 1337 future, devices should have a means to generate their own unique 1338 names within a homenet, and to detect clashes should they arise, e.g. 1339 where two devices of the same type are deployed with the same default 1340 name, or where two running network elements are suddenly joined. 1342 Users will also want simple ways to (re)name devices, again most 1343 likely through an appropriate and intuitive interface that is beyond 1344 the scope of this document. Note the name a user assigns to a device 1345 may be a label that is stored on the device as an attribute of the 1346 device, and may be distinct from the name used in a name service, 1347 e.g. 'Laser Printer in the Study Room' as opposed to 1348 printer2.sitelocal. 1350 3.7.3. Name spaces 1352 It is desirable that only one name space is in use in the homenet, 1353 and that this name space is served authoritatively by a server in the 1354 homenet, most likely resident on the CER. 1356 If a user wishes to access their home devices remotely from elsewhere 1357 on the Internet a globally unique name space is required. This may 1358 be acquired by the user or provided/generated by their ISP. It is 1359 expected that the default case is that a homenet will use a global 1360 domain provided by the ISP, but users wishing to use a name space 1361 that is independent of their provider in the longer term may seek 1362 their own domain name. Examples of provider name space delegation 1363 approaches are described in [I-D.mglt-homenet-naming-delegation] and 1364 [I-D.mglt-homenet-front-end-naming-delegation]. For users wanting to 1365 use their own independent domain names, such services are already 1366 available. 1368 If however a global name space is not available, the homenet will 1369 need to uck and tse a local name space, which would only have meaning 1370 within the local homenet (i.e. it would not be used for remote access 1371 to the homenet). The .local name space has a special meaning for 1372 certain existing protocols which have link-local scope, and is thus 1373 not appropriate for multi-subnet home networks. A differently named 1374 name space is thus required for the homenet. 1376 One approach for picking a local name space is to use an Ambiguous 1377 Local Qualified Domain Name (ALQDN) space, such as .sitelocal (or an 1378 appropriate name reserved for the purpose). While this is a simple 1379 approach, there is the potential for devices that are bookmarked 1380 somehow by an application in one homenet to be confused with a device 1381 with the same name in another homenet. 1383 An alternative approach for local name space would be to use a Unique 1384 Locally Qualified Domain Name (ULQDN) space such as 1385 ..sitelocal. The could be generated in 1386 a variety of ways, one potentially being based on the local ULA 1387 prefix across the homenet. Such a should survive a 1388 cold start, or if an existing value is not set on startup, the CER or 1389 device running the name service should generate a default value. It 1390 could be desirable for the homenet user to be able to override the 1391 with a value of their choice, but that would increase 1392 the likelihood of a name conflict. 1394 Whichever approach is used, the intent is to disambiguate the name 1395 space across different homenets, not to create a new IANA name space 1396 for such networks. If remote access to the homenet is required, a 1397 global domain is required. 1399 With the introduction of new "dotless" top level domains, there is 1400 potential for ambiguity between for example a local host called 1401 "computer" and (if it is registered) a .computer gTLD. Thus 1402 qualified names should always be used, whether these are exposed to 1403 the user or not. 1405 There may be use cases where segmentation of the name space is 1406 desirable, e.g. for use in different realms within the homenet. Thus 1407 hierarchical name space management is likely to be required. 1409 Where a user may be in a remote network wishing to access devices in 1410 their home network, there may be a requirement to consider the domain 1411 search order presented where two name spaces exist. In such cases, a 1412 GUI may present the user a choice of domains to use, where the name 1413 of their devices is thus relative to that domain. This implies that 1414 a domain discovery function is desirable. 1416 It may be the case that not all devices in the homenet are made 1417 available by name via an Internet name space, and that a 'split view' 1418 is preferred for certain devices. 1420 This document makes no assumption about the presence or omission of a 1421 reverse lookup service. There is an argument that it may be useful 1422 for presenting logging information to users with meaningful device 1423 names rather than literal addresses. 1425 3.7.4. The homenet name service 1427 The homenet name service should support both lookups and discovery. 1428 A lookup would operate via a direct query to a known service, while 1429 discovery may use multicast messages or a service where applications 1430 register in order to be found. 1432 It is highly desirable that the homenet name service must at the very 1433 least co-exist with the Internet name service. There should also be 1434 a bias towards proven, existing solutions. The strong implication is 1435 thus that the homenet service is DNS-based, or DNS-compatible. There 1436 are naming protocols that are designed to be configured and operate 1437 Internet-wide, like unicast-based DNS, but also protocols that are 1438 designed for zero-configuration local environments, like mDNS. 1440 As described in [I-D.mglt-homenet-naming-delegation], one approach is 1441 to run an authoritative name service in the homenet, most likely on 1442 the CER, which caches results, and to have the homenet's ISP provide 1443 a secondary name service. 1445 For a service such as mDNS to coexist with an Internet name service, 1446 where the homenet is preferably using a global domain name, it is 1447 desirable that the zeroconf devices have a way to add their names to 1448 the global name space in use. Zeroconf protocols could be used to 1449 indicate global FQDNs, e.g. an mDNS service could return a FQDN in a 1450 SRV record. 1452 Regardless, a method for local name service entries to be populated 1453 automatically by devices is desirable. Interfaces to devices might 1454 choose to give users the option as to whether the device should 1455 register itself in the global name space. There should also be a 1456 defined mechanism for device entries to be removed or expired from 1457 the global name space. 1459 It has been suggested for example that Dynamic DNS could be made to 1460 operate in a zero-configuration mode using a locally significant root 1461 domain and with minimal configuration or using a DHCPv6 based 1462 (details to-be-defined) means of automated delegation populate a 1463 global DNS zone. 1465 To protect against attacks such as cache poisoning, it is desirable 1466 to support appropriate name service security methods, including 1467 DNSSEC. 1469 The impact of a change in CER must be considered. It would be 1470 desirable to retain any relevant state (configuration) that was held 1471 in the old CER. This might imply that state information should be 1472 distributed in the homenet, to be recoverable by/to the new CER. 1474 3.7.5. Independent operation 1476 Name resolution and service discovery for reachable devices must 1477 continue to function if the local network is disconnected from the 1478 global Internet, e.g. a local media server should still be available 1479 even if the Internet link is down for an extended period. This 1480 implies the local network should also be able to perform a complete 1481 restart in the absence of external connectivity, and have local 1482 naming and service discovery operate correctly. 1484 The approach described above of a local authoritative name service 1485 with a cache would allow local operation for sustained ISP outages. 1487 Having an independent local trust anchor is desirable, to support 1488 secure exchanges should external connectivity be unavailable. 1490 A change in ISP should should not affect local naming and service 1491 discovery. However, if the homenet uses a global name space provided 1492 by the ISP, then this will obviously have an impact if the user 1493 changes their network provider. 1495 3.7.6. Considerations for LLNs 1497 In some parts of the homenet, in particular LLNs, devices may be 1498 sleeping, in which case a proxy for such nodes may be required, that 1499 can respond (for example) to multicast service discovery requests. 1500 Those same parts of the network may have less capacity for multicast 1501 traffic that may be flooded from other parts of the network. In 1502 general, message utilisation should be efficient considering the 1503 network technologies the service may need to operate over. 1505 There are efforts underway to determine naming and dicovery solutions 1506 for use by the Constrained Application Protocol (CoAP) in LLN 1507 networks. These are outside the scope of this document. 1509 3.7.7. DNS resolver discovery 1511 Automatic discovery of a name service to allow client devices in the 1512 homenet to resolve external domains on the Internet is required, and 1513 such discovery must support clients that may be a number of router 1514 hops away from the name service. 1516 3.8. Other Considerations 1518 This section discusses some other considerations for home networking 1519 that may affect the architecture. 1521 3.8.1. Proxy or Extend? 1523 There are two broad choices for allowing services that would 1524 otherwise be link-local to work across a homenet site. In the 1525 example of service discovery, one is to take protocols like mDNS and 1526 have them run over site multicast within the homenet, as described in 1527 the Extended mDNS proposal (xmDNS) [I-D.lynn-homenet-site-mdns]. 1528 This is fine if all hosts support the extension, and the scope within 1529 any internal borders is well-understood. But it's not backwards- 1530 compatible with existing link-local protocols. The alternative is to 1531 proxy service discovery across subnets to propagate it. This is more 1532 complex, but is backwards-compatible. It would need to work with 1533 IPv6, and dual-stack. 1535 The homenet architecture proposes that any existing protocols that 1536 are designed to only work within a subnet should be extended to work 1537 across subnets, rather than defining proxy capabilities for each of 1538 those functions. However, while it is desirable to extend protocols 1539 to site scope operation rather than providing proxy functions on 1540 subnet boundaries, the reality is that until all hosts can use site- 1541 scope discovery protocols, existing link-local protocols would need 1542 to be proxied anyway. 1544 Some protocols already have proxy functions defined and in use, e.g. 1545 DHCPv6 relays, in which case those protocols would be expected to 1546 continue to operate that way. 1548 3.8.2. Quality of Service 1550 Support for QoS in a multi-service homenet may be a requirement, e.g. 1551 for a critical system (perhaps healthcare related), or for 1552 differentiation between different types of traffic (file sharing, 1553 cloud storage, live streaming, VoIP, etc). Different media types may 1554 have different such properties or capabilities. 1556 However, homenet scenarios should require no new QoS protocols. A 1557 DiffServ [RFC2475] approach with a small number of predefined traffic 1558 classes should generally be sufficient, though at present there is 1559 little experience of QoS deployment in home networks. It is likely 1560 that QoS, or traffic prioritisation, methods will be required at the 1561 CER, and potentially around boundaries between different media types 1562 (where for example some traffic may simply not be appropriate for 1563 some media, and need to be dropped to avoid drowning the constrained 1564 media). 1566 There may also be complementary mechanisms that could be beneficial 1567 to application performance and behaviour in the homenet domain, such 1568 as ensuring proper buffering algorithms are used as described in 1569 [Gettys11]. 1571 3.8.3. Operations and Management 1573 The homenet should be self-organising and configuring as far as 1574 possible, and thus not be pro-actively managed by the home user. 1575 Thus protocols to manage the network are not discussed in this 1576 architecture text. 1578 However, users may be interested in the status of their networks and 1579 devices on the network, in which case simplified monitoring 1580 mechanisms may be desirable. It may also be the case that an ISP, or 1581 a third party, might offer management of the homenet on behalf of a 1582 user, in which case management protocols would be required. How such 1583 management is done is out of scope of this document; many solutions 1584 exist. 1586 3.9. Implementing the Architecture on IPv6 1588 This architecture text encourages re-use of existing protocols. Thus 1589 the necessary mechanisms are largely already part of the IPv6 1590 protocol set and common implementations. There are though some 1591 exceptions. For automatic routing, it is expected that existing 1592 routing protocols can be used as is. However, a new mechanism may be 1593 needed in order to turn a selected protocol on by default. 1595 Some functionality, if required by the architecture, would add 1596 significant changes or require development of new protocols, e.g. 1597 support for multihoming with multiple exit routers would likely 1598 require extensions to support source and destination address based 1599 routing within the homenet. 1601 Some protocol changes are however required in the architecture, e.g. 1602 for name resolution and service discovery, extensions to existing 1603 multicast-based name resolution protocols are needed to enable them 1604 to work across subnets, within the scope of the home network site. 1606 Some of the hardest problems in developing solutions for home 1607 networking IPv6 architectures include discovering the right borders 1608 where the "home" domain ends and the service provider domain begins, 1609 deciding whether some of the necessary discovery mechanism extensions 1610 should affect only the network infrastructure or also hosts, and the 1611 ability to turn on routing, prefix delegation and other functions in 1612 a backwards compatible manner. 1614 4. Conclusions 1616 This text defines principles and requirements for a homenet 1617 architecture. The principles and requirements documented here should 1618 be observed by any future texts describing homenet protocols for 1619 routing, prefix management, security, naming or service discovery. 1621 5. References 1623 5.1. Normative References 1625 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1626 (IPv6) Specification", RFC 2460, December 1998. 1628 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1629 and M. Carney, "Dynamic Host Configuration Protocol for 1630 IPv6 (DHCPv6)", RFC 3315, July 2003. 1632 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1633 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1634 December 2003. 1636 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1637 (DHCP) Service for IPv6", RFC 3736, April 2004. 1639 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1640 Addresses", RFC 4193, October 2005. 1642 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1643 Architecture", RFC 4291, February 2006. 1645 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1646 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1647 May 2007. 1649 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1650 Extensions for Stateless Address Autoconfiguration in 1651 IPv6", RFC 4941, September 2007. 1653 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1654 Customer Premises Equipment (CPE) for Providing 1655 Residential IPv6 Internet Service", RFC 6092, 1656 January 2011. 1658 5.2. Informative References 1660 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1661 E. Lear, "Address Allocation for Private Internets", 1662 BCP 5, RFC 1918, February 1996. 1664 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1665 and W. Weiss, "An Architecture for Differentiated 1666 Services", RFC 2475, December 1998. 1668 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1669 February 2000. 1671 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1672 Defeating Denial of Service Attacks which employ IP Source 1673 Address Spoofing", BCP 38, RFC 2827, May 2000. 1675 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1676 Address Translator (Traditional NAT)", RFC 3022, 1677 January 2001. 1679 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1680 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1681 December 2003. 1683 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1684 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1685 September 2005. 1687 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1688 Shim Protocol for IPv6", RFC 5533, June 2009. 1690 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1691 Infrastructures (6rd) -- Protocol Specification", 1692 RFC 5969, August 2010. 1694 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1695 "IPv6 Router Advertisement Options for DNS Configuration", 1696 RFC 6106, November 2010. 1698 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1699 IPv4/IPv6 Translation", RFC 6144, April 2011. 1701 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1702 Algorithm", RFC 6145, April 2011. 1704 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1705 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 1707 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1708 Troan, "Basic Requirements for IPv6 Customer Edge 1709 Routers", RFC 6204, April 2011. 1711 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1712 Translation", RFC 6296, June 2011. 1714 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1715 Stack Lite Broadband Deployments Following IPv4 1716 Exhaustion", RFC 6333, August 2011. 1718 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1719 Dual-Stack Hosts", RFC 6555, April 2012. 1721 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 1722 "Default Address Selection for Internet Protocol Version 6 1723 (IPv6)", RFC 6724, September 2012. 1725 [I-D.mglt-homenet-front-end-naming-delegation] 1726 Cloetens, W., Lemordant, P., and D. Migault, "IPv6 Home 1727 Network Front End Naming Delegation", 1728 draft-mglt-homenet-front-end-naming-delegation-00 (work in 1729 progress), July 2012. 1731 [I-D.mglt-homenet-naming-delegation] 1732 Cloetens, W., Lemordant, P., and D. Migault, "IPv6 Home 1733 Network Naming Delegation Architecture", 1734 draft-mglt-homenet-naming-delegation-00 (work in 1735 progress), July 2012. 1737 [I-D.baker-fun-multi-router] 1738 Baker, F., "Exploring the multi-router SOHO network", 1739 draft-baker-fun-multi-router-00 (work in progress), 1740 July 2011. 1742 [I-D.lynn-homenet-site-mdns] 1743 Lynn, K. and D. Sturek, "Extended Multicast DNS", 1744 draft-lynn-homenet-site-mdns-01 (work in progress), 1745 September 2012. 1747 [I-D.vyncke-advanced-ipv6-security] 1748 Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced 1749 Security for IPv6 CPE", 1750 draft-vyncke-advanced-ipv6-security-03 (work in progress), 1751 October 2011. 1753 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] 1754 Matsushima, S., Okimoto, T., Troan, O., Miles, D., and D. 1755 Wing, "IPv6 Multihoming without Network Address 1756 Translation", 1757 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 (work 1758 in progress), February 2012. 1760 [I-D.baker-homenet-prefix-assignment] 1761 Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small 1762 Networks", draft-baker-homenet-prefix-assignment-01 (work 1763 in progress), March 2012. 1765 [I-D.arkko-homenet-prefix-assignment] 1766 Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment 1767 in a Home Network", 1768 draft-arkko-homenet-prefix-assignment-02 (work in 1769 progress), July 2012. 1771 [I-D.acee-ospf-ospfv3-autoconfig] 1772 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 1773 draft-acee-ospf-ospfv3-autoconfig-03 (work in progress), 1774 July 2012. 1776 [I-D.ietf-pcp-base] 1777 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1778 Selkirk, "Port Control Protocol (PCP)", 1779 draft-ietf-pcp-base-28 (work in progress), October 2012. 1781 [I-D.kline-default-perimeter] 1782 Kline, E., "Default Perimeter Identification", 1783 draft-kline-default-perimeter-00 (work in progress), 1784 July 2012. 1786 [I-D.hain-ipv6-ulac] 1787 Hain, T., Hinden, R., and G. Huston, "Centrally Assigned 1788 IPv6 Unicast Unique Local Address Prefixes", 1789 draft-hain-ipv6-ulac-02 (work in progress), July 2010. 1791 [I-D.chakrabarti-homenet-prefix-alloc] 1792 Nordmark, E., Chakrabarti, S., Krishnan, S., and W. 1793 Haddad, "Simple Approach to Prefix Distribution in Basic 1794 Home Networks", draft-chakrabarti-homenet-prefix-alloc-01 1795 (work in progress), October 2011. 1797 [I-D.ietf-v6ops-6204bis] 1798 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1799 Requirements for IPv6 Customer Edge Routers", 1800 draft-ietf-v6ops-6204bis-11 (work in progress), 1801 September 2012. 1803 [Gettys11] 1804 Gettys, J., "Bufferbloat: Dark Buffers in the Internet", 1805 March 2011, 1806 . 1808 [IGD-2] UPnP Gateway Committee, "Internet Gateway Device (IGD) V 1809 2.0", September 2010, . 1812 Appendix A. Acknowledgments 1814 The authors would like to thank Aamer Akhter, Mark Andrews, Dmitry 1815 Anipko, Fred Baker, Ray Bellis, Cameron Byrne, Brian Carpenter, 1816 Stuart Cheshire, Lorenzo Colitti, Robert Cragie, Ralph Droms, Lars 1817 Eggert, Jim Gettys, olafur Gudmundsson, Wassim Haddad, Joel M. 1818 Halpern, David Harrington, Lee Howard, Ray Hunter, Joel Jaeggli, 1819 Heather Kirksey, Ted Lemon, Acee Lindem, Kerry Lynn, Erik Nordmark, 1820 Michael Richardson, Barbara Stark, Sander Steffann, Don Sturek, Dave 1821 Taht, Dave Thaler, Michael Thomas, Mark Townsley, JP Vasseur, Curtis 1822 Villamizar, Dan Wing, Russ White, and James Woodyatt for their 1823 comments and contributions within homenet WG meetings and on the WG 1824 mailing list. 1826 Appendix B. Changes 1828 This section will be removed in the final version of the text. 1830 B.1. Version 05 1832 Changes made include: 1834 o Some significant changes to naming and SD section. 1836 o Removed some expired drafts. 1838 o Added notes about issues caused by ISP only delegating a /64. 1840 o Recommended against using prefixes longer than /64. 1842 o Suggested CPE asks for /48 by DHCP-PD, even if it only receives 1843 less. 1845 o Added note about DS-Lite but emphasised transition is out of 1846 scope. 1848 o Added text about multicast routing. 1850 B.2. Version 04 1852 Changes made include: 1854 o Moved border section from IPv6 differences to principles section. 1856 o Restructured principles into areas. 1858 o Added summary of naming and service discovery discussion from WG 1859 list. 1861 B.3. Version 03 1863 Changes made include: 1865 o Various improvements to the readability. 1867 o Removed bullet lists of requirements, as requested by chair. 1869 o Noted 6204bis has replaced advanced-cpe draft. 1871 o Clarified the topology examples are just that. 1873 o Emphasised we are not targetting walled gardens, but they should 1874 not be precluded. 1876 o Also changed text about requiring support for walled gardens. 1878 o Noted that avoiding falling foul of ingress filtering when 1879 multihomed is desirable. 1881 o Improved text about realms, detecting borders and policies at 1882 borders. 1884 o Stated this text makes no recommendation about default security 1885 model. 1887 o Added some text about failure modes for users plugging things 1888 arbitrarily. 1890 o Expanded naming and service discovery text. 1892 o Added more text about ULAs. 1894 o Removed reference to version 1 on chair feedback. 1896 o Stated that NPTv6 adds architectural cost but is not a homenet 1897 matter if deployed at the CER. This text only considers the 1898 internal homenet. 1900 o Noted multihoming is supported. 1902 o Noted routers may not by separate devices, they may be embedded in 1903 devices. 1905 o Clarified simple and advanced security some more, and RFC 4864 and 1906 6092. 1908 o Stated that there should be just one secret key, if any are used 1909 at all. 1911 o For multihoming, support multiple CERs but note that routing to 1912 the correct CER to avoid ISP filtering may not be optimal within 1913 the homenet. 1915 o Added some ISPs renumber due to privacy laws. 1917 o Removed extra repeated references to Simple Security. 1919 o Removed some solution creep on RIOs/RAs. 1921 o Load-balancing scenario added as to be supported. 1923 B.4. Version 02 1925 Changes made include: 1927 o Made the IPv6 implications section briefer. 1929 o Changed Network Models section to describe properties of the 1930 homenet with illustrative examples, rather than implying the 1931 number of models was fixed to the six shown in 01. 1933 o Text to state multihoming support focused on single CER model. 1934 Multiple CER support is desirable, but not required. 1936 o Stated that NPTv6 not supported. 1938 o Added considerations section for operations and management. 1940 o Added bullet point principles/requirements to Section 3.4. 1942 o Changed IPv6 solutions must not adversely affect IPv4 to should 1943 not. 1945 o End-to-end section expanded to talk about "Simple Security" and 1946 borders. 1948 o Extended text on naming and service discovery. 1950 o Added reference to RFC 2775, RFC 6177. 1952 o Added reference to the new xmDNS draft. 1954 o Added naming/SD requirements from Ralph Droms. 1956 Authors' Addresses 1958 Tim Chown (editor) 1959 University of Southampton 1960 Highfield 1961 Southampton, Hampshire SO17 1BJ 1962 United Kingdom 1964 Email: tjc@ecs.soton.ac.uk 1966 Jari Arkko 1967 Ericsson 1968 Jorvas 02420 1969 Finland 1971 Email: jari.arkko@piuha.net 1973 Anders Brandt 1974 Sigma Designs 1975 Emdrupvej 26A, 1 1976 Copenhagen DK-2100 1977 Denmark 1979 Email: abr@sdesigns.dk 1981 Ole Troan 1982 Cisco Systems, Inc. 1983 Drammensveien 145A 1984 Oslo N-0212 1985 Norway 1987 Email: ot@cisco.com 1989 Jason Weil 1990 Time Warner Cable 1991 13820 Sunrise Valley Drive 1992 Herndon, VA 20171 1993 USA 1995 Email: jason.weil@twcable.com