idnits 2.17.1 draft-ietf-homenet-arch-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 4299 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 normative reference: RFC 6204 (Obsoleted by RFC 7084) == Outdated reference: A later version (-12) exists of draft-ietf-v6ops-6204bis-09 -- 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 6555 (Obsoleted by RFC 8305) == Outdated reference: A later version (-01) exists of draft-lynn-homenet-site-mdns-00 == 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-26 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Chown, Ed. 3 Internet-Draft University of Southampton 4 Intended status: Informational J. Arkko 5 Expires: January 17, 2013 Ericsson 6 A. Brandt 7 Sigma Designs 8 O. Troan 9 Cisco Systems, Inc. 10 J. Weil 11 Time Warner Cable 12 July 16, 2012 14 Home Networking Architecture for IPv6 15 draft-ietf-homenet-arch-04 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 January 17, 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 . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . 11 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 possible subnets . . . . . . . . . . . . . . . 19 88 3.3.3. Handling multiple homenets . . . . . . . . . . . . . . 20 89 3.3.4. Coordination of configuration information . . . . . . 20 90 3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . . 20 91 3.4.1. Use of ISP-delegated IPv6 prefixes . . . . . . . . . . 20 92 3.4.2. Stable internal IP addresses . . . . . . . . . . . . . 22 93 3.4.3. Internal prefix delegation . . . . . . . . . . . . . . 22 94 3.4.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . 24 95 3.5. Routing functionality . . . . . . . . . . . . . . . . . . 24 96 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 3.6.1. Addressability vs reachability . . . . . . . . . . . . 26 98 3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 27 99 3.6.3. Device capabilities . . . . . . . . . . . . . . . . . 27 100 3.6.4. ULAs as a hint of connection origin . . . . . . . . . 27 101 3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 27 102 3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 30 103 3.8.1. Proxy or Extend? . . . . . . . . . . . . . . . . . . . 30 104 3.8.2. Quality of Service . . . . . . . . . . . . . . . . . . 30 105 3.8.3. Operations and Management . . . . . . . . . . . . . . 31 106 3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 31 107 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 32 108 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 109 5.1. Normative References . . . . . . . . . . . . . . . . . . . 32 110 5.2. Informative References . . . . . . . . . . . . . . . . . . 33 111 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 36 112 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 36 113 B.1. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 36 114 B.2. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 36 115 B.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 38 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 118 1. Introduction 120 This document focuses on evolving networking technology within 121 increasingly large residential home networks and the associated 122 challenges with their deployment and operation. There is a growing 123 trend in home networking for the proliferation of networking 124 technology in an increasingly broad range of devices and media. This 125 evolution in scale and diversity sets requirements on IETF protocols. 126 Some of these requirements relate to the introduction of IPv6, others 127 to the introduction of specialised networks for home automation and 128 sensors. 130 While at the time of writing some complex home network topologies 131 exist, most operate based on IPv4, employ solutions that we would 132 like to avoid such as (cascaded) network address translation (NAT), 133 or require expert assistance to set up. In IPv6 home networks, there 134 are likely to be scenarios where internal routing is required, for 135 example to support private and guest networks, in which case such 136 networks may use increasing numbers of subnets, and require methods 137 for IPv6 prefixes to be delegated to those subnets. The assumption 138 of this document is that the homenet is as far as possible self- 139 organising and self-configuring, and is thus not pro-actively managed 140 by the residential user. 142 The architectural constructs in this document are focused on the 143 problems to be solved when introducing IPv6 with an eye towards a 144 better result than what we have today with IPv4, as well as a better 145 result than if the IETF had not given this specific guidance. The 146 document aims to provide the basis and guiding principles for how 147 standard IPv6 mechanisms and addressing [RFC2460] [RFC4291] can be 148 employed in home networking, while coexisting with existing IPv4 149 mechanisms. In emerging dual-stack home networks it is vital that 150 introducing IPv6 does not adversely affect IPv4 operation. We assume 151 that the IPv4 network architecture in home networks is what it is, 152 and can not be affected by new recommendations. Future deployments, 153 or specific subnets within an otherwise dual-stack home network, may 154 be IPv6-only, in which case considerations for IPv4 impact would not 155 apply. 157 This architecture document proposes a baseline homenet architecture, 158 based on protocols and implementations that are as far as possible 159 proven and robust. The scope of the document is primarily the 160 network layer technologies that provide the basic functionality to 161 enable addressing, connectivity, routing, naming and service 162 discovery. While it may, for example, state that homenet components 163 must be simple to deploy and use, it does not discuss specific user 164 interfaces, nor does it discuss specific physical, wireless or data- 165 link layer considerations. 167 [RFC6204] defines basic requirements for customer edge routers 168 (CERs). The scope of this text is the internal homenet, and thus 169 specific features on the CER are out of scope for this text. While 170 the network may be dual-stack or IPv6-only, the definition of 171 specific transition tools on the CER, as introduced in RFC 6204-bis 172 [I-D.ietf-v6ops-6204bis] with DS-Lite [RFC6333] and 6rd [RFC5969], 173 are considered issues for that RFC, and are thus also out of scope of 174 this text. 176 1.1. Terminology and Abbreviations 178 In this section we define terminology and abbreviations used 179 throughout the text. 181 o "Advanced Security". Describes advanced security functions for a 182 CER, as defined in [I-D.vyncke-advanced-ipv6-security], where the 183 default inbound connection policy is generally "default allow". 185 o CER: Customer Edge Router. A border router at the edge of the 186 homenet. 188 o LLN: Low-power and lossy network. 190 o NAT: Network Address Translation. Typically referring to IPv4 191 Network Address and Port Translation (NAPT) [RFC3022]. 193 o NPTv6: Network Prefix Translation for IPv6 [RFC6296]. 195 o PCP: Port Control Protocol [I-D.ietf-pcp-base]. 197 o "Simple Security". Defined in [RFC4864] and expanded further in 198 [RFC6092]; describes recommended perimeter security capabilities 199 for IPv6 networks. 201 o ULA: IPv6 Unique Local Addresses [RFC4193]. 203 o UPnP: Universal Plug and Play. Includes the Internet Gateway 204 Device (IGD) function, which for IPv6 is UPnP IGD Version 2 205 [IGD-2]. 207 o VM: Virtual machine. 209 o WPA2: Wi-Fi Protected Access, as defined by the Wi-Fi Alliance. 211 2. Effects of IPv6 on Home Networking 213 Service providers are deploying IPv6, content is becoming available 214 on IPv6 (accelerated recently by the World IPv6 Launch event) and 215 support for IPv6 is increasingly available in devices and software 216 used in the home. While IPv6 resembles IPv4 in many ways, it changes 217 address allocation principles, making multi-addressing the norm, and 218 allowing direct IP addressability of home networking devices from the 219 Internet. This section presents an overview of some of the key 220 implications of the introduction of IPv6 for home networking, that 221 are simultaneously both promising and problematic. 223 2.1. Multiple subnets and routers 225 The introduction of IPv6 for home networking enables the potential 226 for every home network to be delegated enough address space to 227 provision globally unique prefixes for each subnet in the home. Such 228 subnetting is not common practice in existing IPv4 homenets, but is 229 very likely to become increasingly standard in future IPv6 homenets. 231 While simple layer 3 topologies involving as few subnets as possible 232 are preferred in home networks, the incorporation of dedicated 233 (routed) subnets remains necessary for a variety of reasons. For 234 instance, an increasingly common feature in modern home routers is 235 the ability to support both guest and private network subnets. 236 Likewise, there may be a need to separate building control or 237 corporate extensions from the main Internet access network, or 238 different subnets may in general be associated with parts of the 239 homenet that have different routing and security policies. Further, 240 link layer networking technology is poised to become more 241 heterogeneous, as networks begin to employ both traditional Ethernet 242 technology and link layers designed for low-power and lossy networks 243 (LLNs), such as those used for certain types of sensor devices. 244 Constraining the flow of certain traffic from Ethernet links to much 245 lower capacity links thus becomes an important topic. 247 Documents that provide some more specific background and depth on 248 this topic include: [I-D.herbst-v6ops-cpeenhancements], 249 [I-D.baker-fun-multi-router], and [I-D.baker-fun-routing-class]. 251 The addition of routing between subnets raises the issue of how to 252 extend mechanisms such as service discovery which currently rely on 253 link-local addressing to limit scope. There are two broad choices; 254 extend existing protocols to work across the scope of the homenet, or 255 introduce proxies for existing link-layer protocols. This topic is 256 discussed later in the document. 258 There will also be the need to discover which routers in the homenet 259 are the border router(s) by an appropriate mechanism. Here, there 260 are a number of choices. These include an appropriate service 261 discovery protocol, or the use of a well-known name, resolved by some 262 local name service. Both might have to deal with handling more than 263 one router responding in multihomed environments. 265 2.2. Global addressability and elimination of NAT 267 Current IPv4 home networks typically receive a single global IPv4 268 address from their ISP and use NAT with private [RFC1918] addresses 269 for devices within the network. An IPv6 home network removes the 270 need to use NAT given the ISP offers a sufficiently large globally 271 unique IPv6 prefix to the homenet, allowing every device on every 272 link to be assigned a globally unique IPv6 address. 274 The end-to-end communication that is potentially enabled with IPv6 is 275 on the one hand an incredible opportunity for innovation and simpler 276 network operation, but it is also a concern as it exposes nodes in 277 the internal networks to receipt of otherwise unwanted traffic from 278 the Internet. There may thus be an expectation of improved host 279 security to compensate for this, at least in general networked 280 devices, but it must be noted that many devices may also (for 281 example) ship with default settings that make them readily vulnerable 282 to compromise by external attackers if globally accessible, or may 283 simply not have robustness designed-in because it was either assumed 284 such devices would only be used on private networks or the device 285 itself doesn't have the computing power to apply the necessary 286 security methods. 288 IPv6 networks may or may not have filters applied at their borders, 289 i.e. at the homenet CER. [RFC4864], [RFC6092] and 290 [I-D.vyncke-advanced-ipv6-security] discuss such filtering, and the 291 merits of "default allow" against "default deny" policies for 292 external traffic initiated into a homenet. It is important to 293 distinguish between addressability and reachability. While IPv6 294 offers global addressability through use of globally unique addresses 295 in the home, whether they are globally reachable or not would depend 296 on the firewall or filtering configuration, and not, as is commonly 297 the case with IPv4, the presence or use of NAT. 299 2.3. Multi-Addressing of devices 301 In an IPv6 network, devices may acquire multiple addresses, typically 302 at least a link-local address and a globally unique address. They 303 may also have an IPv4 address if the network is dual-stack, a Unique 304 Local Address (ULA) [RFC4193] (see below), and one or more IPv6 305 Privacy Addresses [RFC4941]. 307 Thus it should be considered the norm for devices on IPv6 home 308 networks to be multi-addressed, and to need to make appropriate 309 address selection decisions for the candidate source and destination 310 address pairs. Default Address Selection for IPv6 311 [I-D.ietf-6man-rfc3484bis] provides a solution for this, though it 312 may face problems in the event of multihoming, where nodes will be 313 configured with one address from each upstream ISP prefix. In such 314 cases the presence of upstream ingress filtering requires multi- 315 addressed nodes to select the correct source address to be used for 316 the corresponding uplink, to avoid ISP BCP 38 ingress filtering, but 317 the node may not have the information it needs to make that decision 318 based on addresses alone. We discuss such challenges in the 319 multihoming section later in this document. 321 2.4. Unique Local Addresses (ULAs) 323 [RFC4193] defines Unique Local Addresses (ULAs) for IPv6 that may be 324 used to address devices within the scope of a single site. Support 325 for ULAs for IPv6 CERs is described in [RFC6204]. A home network 326 running IPv6 may deploy ULAs for stable communication between devices 327 (on different subnets) within the network where the externally 328 allocated global prefix changes over time (e.g. due to renumbering 329 within the subscriber's ISP) or where external connectivity is 330 temporarily unavailable. 332 A counter-argument to using ULAs is that it is undesirable to 333 aggressively deprecate global prefixes for temporary loss of 334 connectivity, so for a host to lose its global address there would 335 have to be a connection breakage longer than the lease period, and 336 even then, deprecating prefixes when there is no connectivity may not 337 be advisable. It should also be noted that there may be timers on 338 the prefix lease to the homenet, on the internal prefix delegations, 339 and on the Router Advertisements to the hosts. Despite this counter- 340 argument, while setting a network up there may be a period with no 341 connectivity, in which case ULAs would be required for inter-subnet 342 communication. In the case where LLNs are being set up in a new 343 home/deployment, individual LLNs may, at least initially, each use 344 their own /48 ULA prefix. 346 Default address selection mechanisms should ensure a ULA source 347 address is used to communicate with ULA destination addresses when 348 appropriate, in particular when the ULA destination lies within a /48 349 ULA prefix known to be used within the same homenet. Note that 350 unlike the IPv4 private RFC 1918 space, the use of ULAs does not 351 imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT 352 [RFC6296], rather that external communications should use a node's 353 additional globally unique IPv6 source address. 355 2.5. Naming, and manual configuration of IP addresses 357 Some IPv4 home networking devices expose IPv4 addresses to users, 358 e.g. the IPv4 address of a home IPv4 CER that may be configured via a 359 web interface. Users should not be expected to enter IPv6 literal 360 addresses in homenet devices or applications, given their much 361 greater length and apparent randomness to a typical home user. While 362 shorter addresses, perhaps ones registered with IANA from ULA-C space 363 [I-D.hain-ipv6-ulac], could be used for specific devices/services, in 364 general it is better to not expose users to real IPv6 addresses. 365 Thus, even for the simplest of functions, simple naming and the 366 associated (ideally zero configuration) discovery of services is 367 imperative for the easy deployment and use of homenet devices and 368 applications. 370 In a multi-subnet homenet, naming and service discovery should be 371 expected to be capable of operating across the scope of the entire 372 home network, and thus be able to cross subnet boundaries. It should 373 be noted that in IPv4, such services do not generally function across 374 home router NAT boundaries, so this is one area where there is room 375 for improvement in IPv6. 377 2.6. IPv6-only operation 379 It is likely that IPv6-only networking will be deployed first in 380 "greenfield" homenet scenarios, or perhaps as one element of an 381 otherwise dual-stack network. Running IPv6-only adds additional 382 requirements, e.g. for devices to get configuration information via 383 IPv6 transport (not relying on an IPv4 protocol such as IPv4 DHCP), 384 and for devices to be able to initiate communications to external 385 devices that are IPv4-only. Thus, for example, the following 386 requirements are amongst those that should be considered in IPv6-only 387 environments: 389 o Ensuring there is a way to access content in the IPv4 Internet. 390 This can be arranged through incorporating NAT64 [RFC6144] and 391 DNS64 [RFC6145] functionality in the home gateway router, for 392 instance. Such features are outside the scope of this document 393 however, being CER functions. 395 o DNS discovery mechanisms are enabled for IPv6. Both stateless 396 DHCPv6 [RFC3736] [RFC3646] and Router Advertisement options 397 [RFC6106] may have to be supported and turned on by default to 398 ensure maximum compatibility with all types of hosts in the 399 network. This requires, however, that a working DNS server is 400 known and addressable via IPv6, and that such discovery options 401 can operate through multiple routers in the homenet. 403 o All nodes in the home network support operations in IPv6-only 404 mode. Some current devices work well with dual-stack but fail to 405 recognise connectivity when IPv4 DHCP fails, for instance. 407 The widespread availability of robust solutions to these types of 408 requirements will help accelerate the uptake of IPv6-only homenets. 410 3. Homenet Architecture 412 The aim of this architecture text is to outline how to construct 413 advanced IPv6-based home networks involving multiple routers and 414 subnets using standard IPv6 protocols and addressing [RFC2460] 415 [RFC4291]. In this section, we present the elements of such a home 416 networking architecture, with discussion of the associated design 417 principles. 419 Existing IETF work [RFC6204] defines the "basic" requirements for 420 Customer Edge Routers, while [I-D.ietf-v6ops-6204bis] extends RFC 421 6204 to describe additional features. The homenet architecture is 422 focused on the internal homenet, rather than the CER(s). In general, 423 home network equipment needs to be able to operate in networks with a 424 range of different properties and topologies, where home users may 425 plug components together in arbitrary ways and expect the resulting 426 network to operate. Significant manual configuration is rarely, if 427 at all, possible, given the knowledge level of typical home users. 428 Thus the network should, as far as possible, be self-configuring. 430 The equipment also needs to be prepared to handle at least 432 o Routing 434 o Prefix configuration for routers 436 o Name resolution 438 o Service discovery 440 o Network security 442 The remainder of this document describes the principles by which a 443 homenet architecture may deliver these properties. 445 3.1. General Principles 447 There is little that the Internet standards community can do about 448 the physical topologies or the need for some networks to be separated 449 at the network layer for policy or link layer compatibility reasons. 451 However, there is a lot of flexibility in using IP addressing and 452 inter-networking mechanisms. This architecture text discusses how 453 this flexibility should be used to provide the best user experience 454 and ensure that the network can evolve with new applications in the 455 future. The principles described in this text should be followed 456 when designing homenet solutions. 458 3.1.1. Reuse existing protocols 460 It is desirable to reuse existing protocols where possible, but at 461 the same time to avoid consciously precluding the introduction of new 462 or emerging protocols. A generally conservative approach, giving 463 weight to running code, is preferable. Where new protocols are 464 required, evidence of commitment to implementation by appropriate 465 vendors or development communities is highly desirable. Protocols 466 used should be backwardly compatible, and forward compatible where 467 changes are made. 469 3.1.2. Minimise changes to hosts and routers 471 Where possible, any requirement for changes to hosts and routers 472 should be minimised, though solutions which, for example, 473 incrementally improve with host changes may be acceptable. 475 3.2. Homenet Topology 477 In this section we consider homenet topologies, and the principles we 478 may apply in designing an architecture to support as wide a range as 479 possible of such topologies. 481 3.2.1. Supporting arbitrary topologies 483 There should ideally be no built-in assumptions about the topology in 484 home networks, as users are capable of connecting their devices in 485 "ingenious" ways. Thus arbitrary topologies and arbitrary routing 486 will need to be supported, or at least the failure mode for when the 487 user makes a mistake should be as robust as possible, e.g. de- 488 activating a certain part of the infrastructure to allow the rest to 489 operate. In such cases, the user should ideally have some useful 490 indication of the failure mode encountered. 492 3.2.2. Network topology models 494 Most IPv4 home network models at the time of writing tend to be 495 relatively simple, typically a single NAT router to the ISP and a 496 single internal subnet but, as discussed earlier, evolution in 497 network architectures is driving more complex topologies, such as the 498 separation of visitor and private networks. 500 In general, the models described in [RFC6204] and its successor RFC 501 6204-bis [I-D.ietf-v6ops-6204bis] should be supported by the IPv6 502 home networking architecture. The functions resident on the CER 503 itself are, as stated previously, out of scope of this text. 505 There are a number of properties or attributes of a home network that 506 we can use to describe its topology and operation. The following 507 properties apply to any IPv6 home network: 509 o Presence of internal routers. The homenet may have one or more 510 internal routers, or may only provide subnetting from interfaces 511 on the CER. 513 o Presence of isolated internal subnets. There may be isolated 514 internal subnets, with no direct connectivity between them within 515 the homenet. Isolation may be physical, or implemented via IEEE 516 802.1q VLANs. 518 o Demarcation of the CER. The CER(s) may or may not be managed by 519 the ISP. If the demarcation point is such that the customer can 520 provide or manage the CER, its configuration must be simple. Both 521 models must be supported. 523 Various forms of multihoming are likely to be more prevalent with 524 IPv6 home networks, as discussed further below. Thus the following 525 properties should also be considered for such networks: 527 o Number of upstream providers. A typical homenet might just have a 528 single upstream ISP, but it may become more common for there to be 529 multiple ISPs, whether for resilience or provision of additional 530 services. Each would offer its own prefix. Some may or may not 531 be walled gardens. 533 o Number of CERs. The homenet may have a single CER, which might be 534 used for one or more providers, or multiple CERs. The presence of 535 multiple CERs adds additional complexity for multihoming 536 scenarios, and protocols like PCP that need to manage connection- 537 oriented state mappings. 539 A separate discussion of physical infrastructures for homenets is 540 included in and [I-D.arkko-homenet-physical-standard]. 542 In the following sections we give some examples of the types of 543 homenet topologies we may see in the future. This is not intended to 544 be an exhaustive or complete list, rather an indicative one to 545 facilitate the discussion in this text. 547 3.2.2.1. A: Single ISP, Single CER, Internal routers 549 Figure 1 shows a network with multiple local area networks. These 550 may be needed for reasons relating to different link layer 551 technologies in use or for policy reasons, e.g. classic Ethernet in 552 one subnet and a LLN link layer technology in another. In this 553 example there is no single router that a priori understands the 554 entire topology. The topology itself may also be complex, and it may 555 not be possible to assume a pure tree form, for instance (home users 556 may plug routers together to form arbitrary topologies including 557 loops). 559 +-------+-------+ \ 560 | Service | \ 561 | Provider | | Service 562 | Router | | Provider 563 +-------+-------+ | network 564 | / 565 | Customer / 566 | Internet connection 567 | 568 +------+--------+ \ 569 | IPv6 | \ 570 | Customer Edge | \ 571 | Router | | 572 +----+-+---+----+ | 573 Network A | | | Network B/E | 574 ----+-------------+----+ | +---+-------------+------+ | 575 | | | | | | | | 576 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | | 577 |IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | | 578 | | | | | | | | | | | 579 +----------+ +----------+ | +----------+ +----------+ | | 580 | | | | | 581 | ---+------+------+-----+ | 582 | | Network B/E | 583 +------+--------+ | | End-User 584 | IPv6 | | | networks 585 | Interior +------+ | 586 | Router | | 587 +---+-------+-+-+ | 588 Network C | | Network D | 589 ----+-------------+---+- --+---+-------------+--- | 590 | | | | | 591 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 592 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 593 | | | | | | | | / 594 +----------+ +----------+ +----------+ +----------+ / 596 Figure 1 598 3.2.2.2. B: Two ISPs, Two CERs, Shared subnet 600 +-------+-------+ +-------+-------+ \ 601 | Service | | Service | \ 602 | Provider A | | Provider B | | Service 603 | Router | | Router | | Provider 604 +------+--------+ +-------+-------+ | network 605 | | / 606 | Customer | / 607 | Internet connections | / 608 | | 609 +------+--------+ +-------+-------+ \ 610 | IPv6 | | IPv6 | \ 611 | Customer Edge | | Customer Edge | \ 612 | Router 1 | | Router 2 | / 613 +------+--------+ +-------+-------+ / 614 | | / 615 | | | End-User 616 ---+---------+---+---------------+--+----------+--- | network(s) 617 | | | | \ 618 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 619 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 620 | | | | | | | | / 621 +----------+ +----------+ +----------+ +----------+ 623 Figure 2 625 Figure 2 illustrates a multihomed homenet model, where the customer 626 has connectivity via CER1 to ISP A and via CER2 to ISP B. This 627 example shows one shared subnet where IPv6 nodes would potentially be 628 multihomed and receive multiple IPv6 global addresses, one per ISP. 629 This model may also be combined with that shown in Figure 1 to create 630 a more complex scenario with multiple internal routers. Or the above 631 shared subnet may be split in two, such that each CER serves a 632 separate isolated subnet, which is a scenario seen with some IPv4 633 networks today. 635 3.2.2.3. C: Two ISPs, One CER, Shared subnet 637 +-------+-------+ +-------+-------+ \ 638 | Service | | Service | \ 639 | Provider A | | Provider B | | Service 640 | Router | | Router | | Provider 641 +-------+-------+ +-------+-------+ | network 642 | | / 643 | Customer | / 644 | Internet | / 645 | connections | | 646 +---------+---------+ \ 647 | IPv6 | \ 648 | Customer Edge | \ 649 | Router | / 650 +---------+---------+ / 651 | / 652 | | End-User 653 ---+------------+-------+--------+-------------+--- | network(s) 654 | | | | \ 655 +----+-----+ +----+-----+ +----+-----+ +-----+----+ \ 656 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 657 | | | | | | | | / 658 +----------+ +----------+ +----------+ +----------+ 660 Figure 3 662 Figure 3 illustrates a model where a home network may have multiple 663 connections to multiple providers or multiple logical connections to 664 the same provider, with shared internal subnets. 666 In general, while the architecture may focus on likely common 667 topologies, it should not preclude any arbitrary topology from being 668 constructed. 670 3.2.3. Dual-stack topologies 672 It is expected that most homenet deployments will for the immediate 673 future be dual-stack IPv4/IPv6. In such networks it is important not 674 to introduce new IPv6 capabilities that would cause a failure if used 675 alongside IPv4+NAT, given that such dual-stack homenets will be 676 commonplace for some time. That said, it is desirable that IPv6 677 works better than IPv4 in as many scenarios as possible. Further, 678 the homenet architecture must operate in the absence of IPv4. 680 A general recommendation is to follow the same topology for IPv6 as 681 is used for IPv4, but not to use NAT. Thus there should be routed 682 IPv6 where an IPv4 NAT is used, and where there is no NAT there 683 should be bridging if the link layer allows this. 685 In some cases IPv4 NAT home networks may feature cascaded NATs, which 686 may include cases where NAT routers are included within VMs, or where 687 Internet connection sharing services are used. IPv6 routed versions 688 of such cases will be required. We should thus note that routers in 689 the homenet may not be separate physical devices; they may be 690 embedded within other devices. 692 3.2.4. Multihoming 694 A homenet may be multihomed to multiple providers, as the network 695 models above illustrate. This may either take a form where there are 696 multiple isolated networks within the home or a more integrated 697 network where the connectivity selection needs to be dynamic. 698 Current practice is typically of the former kind, but the latter is 699 expected to become more commonplace. 701 The general multihoming problem is broad, and solutions suggested to 702 date within the IETF may include complex architectures for monitoring 703 connectivity, traffic engineering, identifier-locator separation, 704 connection survivability across multihoming events, and so on. It is 705 thus important that the homenet architecture should as far as 706 possible minimise the complexity of any multihoming support. So we 707 should limit the support to the smallest subset of the overall 708 problem to meet the requirements of the topologies described above. 709 This means that the homenet architecture should not try to make 710 another attempt at solving complex multihoming, and we should prefer 711 to support scenarios for which solutions exist today. 713 In the general homenet architecture, hosts should be multi-addressed 714 with globally unique prefixes from each ISP they may communicate with 715 or through. An alternative for a homenet would be to deploy NPTv6 716 [RFC6296] at the CER, with ULAs then typically used internally, but 717 this mode is not considered by this text. If NPTv6 is used, the 718 internal part of the homenet (which is the scope of this text) simply 719 sees only the one (ULA) prefix in use. It should be noted that 720 running NPTv6 has an architectural cost, due to the prefix 721 translation used. 723 When multi-addressing is in use, hosts need some way to pick source 724 and destination address pairs for connections. A host may choose a 725 source address to use by various methods, which would typically 726 include [I-D.ietf-6man-rfc3484bis]. Applications may of course do 727 different things, and this should not be precluded. 729 For the single CER Network Model C, multihoming may be offered by 730 source routing at the CER. With multiple exit routers, the 731 complexity rises. Given a packet with a source address on the 732 network, the packet must be routed to the proper egress to avoid BCP 733 38 filtering at an ISP that did not delegate the prefix the address 734 is chosen from. While the packet might not take an optimal path to 735 the correct exit CER, the minimum requirement is that the packet is 736 not dropped. It is of course highly desirable that the packet is 737 routed in the most efficient manner to the correct exit. 739 There are various potential approaches to this problem, one example 740 being described in [I-D.v6ops-multihoming-without-ipv6nat]. Another 741 is discussed in [I-D.baker-fun-multi-router], which explores support 742 for source routing throughout the homenet. This approach would 743 however likely require relatively significant routing changes to 744 route the packet to the correct exit given the source address. Such 745 changes should preferably be minimised. 747 There are some other multihoming considerations for homenet 748 scenarios. First, it may be the case that multihoming applies due to 749 an ISP migration from a transition method to a native deployment, 750 e.g. a 6rd [RFC5969] sunset scenario, as discussed in 751 [I-D.townsley-troan-ipv6-ce-transitioning]. Second, one upstream may 752 be a "walled garden", and thus only appropriate to be used for 753 connectivity to the services of that provider; an example may be a 754 VPN service that only routes back to the enterprise business network 755 of a user in the homenet. While we should not specifically target 756 walled garden multihoming as a principal goal, it should not be 757 precluded. 759 Host-based methods such as Shim6 [RFC5533] have been defined, but of 760 course require support in the hosts. There are also application- 761 oriented approaches such as Happy Eyeballs [RFC6555]; simplified 762 versions of this are for example already implemented in some 763 commonly-used web browsers. The homenet architecture should not 764 preclude use of such tools should hosts include their support. 766 3.3. A Self-Organising Network 768 A home network architecture should be naturally self-organising and 769 self-configuring under different circumstances relating to the 770 connectivity status to the Internet, number of devices, and physical 771 topology. While the homenet should be self-organising, it should be 772 possible to manually adjust (override) the current configuration. 774 While a goal of the homenet architecture is for the network to be as 775 self-organising as possible, there may be instances where some manual 776 configuration is required, e.g. the entry of a WPA2 key to apply 777 wireless security, or to configure a shared routing secret. The 778 latter may be relevant when considering how to bootstrap a routing 779 configuration. It is highly desirable that only one such key is 780 needed for any set of functions, to increase usability for the 781 homenet user. 783 3.3.1. Homenet realms and borders 785 The homenet will need to be aware of the extent of its own "site", 786 which will define the borders for ULAs, site scope multicast, service 787 discovery and security policies. The homenet will have one or more 788 borders with external connectivity providers and potentially also 789 have borders within the internal network (e.g. for policy-based 790 reasons). It should be possible to automatically perform border 791 discovery for the different borders. Such borders determine for 792 example the scope of where prefixes, routing information, network 793 traffic, service discovery and naming may be shared. The default 794 internally should be to share everything. 796 A simple homenet model may just consider three types of realm and the 797 borders between them. For example if the realms are the homenet, the 798 ISP and the visitor network, then the borders will include that from 799 the homenet to the ISP, and that from the homenet to a guest network. 800 Regardless, it should be possible for additional types of realms and 801 borders to be defined, e.g. for some specific Grid or LLN-based 802 network, and for these to be detected automatically, and for an 803 appropriate default policy to be applied as to what type of traffic/ 804 data can flow across such borders. 806 It is desirable to classify the external border of the home network 807 as a unique logical interface separating the home network from 808 service provider network/s. This border interface may be a single 809 physical interface to a single service provider, multiple layer 2 810 sub-interfaces to a single service provider, or multiple connections 811 to a single or multiple providers. This border makes it possible to 812 describe edge operations and interface requirements across multiple 813 functional areas including security, routing, service discovery, and 814 router discovery. 816 It should be possible for the homenet user to override any 817 automatically determined borders and the default policies applied 818 between them. 820 3.3.2. Largest possible subnets 822 Today's IPv4 home networks generally have a single subnet, and early 823 dual-stack deployments have a single congruent IPv6 subnet, possibly 824 with some bridging functionality. More recently, some vendors have 825 started to introduce "home" and "guest" functions, which in IPv6 826 would be implemented as two subnets. 828 Future home networks are highly likely to have one or more internal 829 routers and thus need multiple subnets, for the reasons described 830 earlier. As part of the self-organisation of the network, the 831 homenet should subdivide itself to the largest possible subnets that 832 can be constructed within the constraints of link layer mechanisms, 833 bridging, physical connectivity, and policy. 835 While it may be desirable to maximise the chance of link-local 836 protocols operating across a homenet by maximising the size of a 837 subnet, multi-subnet home networks are inevitable, so their support 838 must be included. 840 3.3.3. Handling multiple homenets 842 It is important that self-configuration with "unintended" devices is 843 avoided. Methods are needed for devices to know whether they are 844 intended to be part of the same homenet site or not. Thus methods to 845 ensure separation between neighbouring homenets are required. This 846 may require use of some unique "secret" for devices/protocols in each 847 homenet. Some existing mechanisms exist to assist home users to 848 associate devices as simply as possible, e.g. "connect" button 849 support. 851 3.3.4. Coordination of configuration information 853 The network elements will need to be integrated in a way that takes 854 account of the various lifetimes on timers that are used on different 855 elements, e.g. DHCPv6 PD, router, valid prefix and preferred prefix 856 timers. 858 3.4. Homenet Addressing 860 The IPv6 addressing scheme used within a homenet must conform to the 861 IPv6 addressing architecture [RFC4291]. The homenet will need to 862 adapt to the prefixes made available to it through the prefix 863 delegation method used by its upstream ISP. 865 3.4.1. Use of ISP-delegated IPv6 prefixes 867 A homenet may receive an arbitrary length IPv6 prefix from its 868 provider, e.g. /60, /56 or /48. The offered prefix may be stable or 869 change from time to time. Some ISPs may offer relatively stable 870 prefixes, while others may change the prefix whenever the CER is 871 reset. Some discussion of IPv6 prefix allocation policies is 872 included in [RFC6177] which discusses why, for example, a one-size- 873 fits-all /48 allocation is not desirable. The home network needs to 874 be adaptable to such ISP policies, and thus make no assumptions about 875 the stability of the prefix received from an ISP, or the length of 876 the prefix that may be offered. However, if only a /64 is offered by 877 the ISP, the homenet may be severely constrained, or even unable to 878 function. 880 The internal operation of the home network should also not depend on 881 the availability of the ISP network at any given time, other than for 882 connectivity to services or systems off the home network. This 883 implies the use of ULAs for stable internal communication, as 884 described in the next section. 886 In practice, it is expected that ISPs will deliver a relatively 887 stable home prefix to customers. The norm for residential customers 888 of large ISPs may be similar to their single IPv4 address provision; 889 by default it is likely to remain persistent for some time, but 890 changes in the ISP's own provisioning systems may lead to the 891 customer's IP (and in the IPv6 case their prefix pool) changing. It 892 is not expected that ISPs will support Provider Independent (PI) 893 addressing for general residential homenets. 895 When an ISP needs to restructure and in doing so renumber its 896 customer homenets, "flash" renumbering is likely to be imposed. This 897 implies a need for the homenet to be able to handle a sudden 898 renumbering event which, unlike the process described in [RFC4192], 899 would be a "flag day" event, which means that a graceful renumbering 900 process moving through a state with two active prefixes in use would 901 not be possible. While renumbering is an extended version of an 902 initial numbering process, the difference between flash renumbering 903 and an initial "cold start" is the need to provide service 904 continuity. 906 There may be cases where local law means some ISPs are required to 907 change IPv6 prefixes (current IPv4 addresses) for privacy reasons for 908 their customers. In such cases it may be possible to avoid an 909 instant "flash" renumbering and plan a non-flag day renumbering as 910 per RFC 4192. 912 The customer may of course also choose to move to a new ISP, and thus 913 begin using a new prefix. In such cases the customer should expect a 914 discontinuity, and not only may the prefix change, but potentially 915 also the prefix length, if the new ISP offers a different default 916 size prefix, e.g. a /60 rather than a /56. Regardless, it's 917 desirable that homenet protocols support rapid renumbering and that 918 operational processes don't add unnecessary complexity for the 919 renumbering process. 921 The 6renum WG is studying IPv6 renumbering for enterprise networks. 923 It is not currently targetting homenets, but may produce outputs that 924 are relevant. The introduction of any new homenet protocols should 925 not make any form of renumbering any more complex than it already is. 927 3.4.2. Stable internal IP addresses 929 The network should by default attempt to provide IP-layer 930 connectivity between all internal parts of the homenet as well as to 931 and from the external Internet, subject to the filtering policies or 932 other policy constraints discussed later in the security section. 934 ULAs should be used within the scope of a homenet to support routing 935 between subnets regardless of whether a globally unique ISP-provided 936 prefix is available. It would be expected that ULAs would be used 937 alongside one or more such global prefixes in a homenet, such that 938 hosts become multi-addressed with both globally unique and ULA 939 prefixes. Default address selection would then enable ULAs to be 940 preferred for internal communications between devices that are using 941 ULA prefixes generated within the same homenet. 943 ULA addresses will allow constrained LLN devices to create permanent 944 relationships between IPv6 addresses, e.g. from a wall controller to 945 a lamp. Symbolic host names would require additional non-volatile 946 memory. Updating global prefixes in sleeping LLN devices might also 947 be problematic. 949 ULAs may be used for all devices, not just those intended to only 950 have internal connectivity. ULAs used in this way provide stable 951 internal communications should the ISP-provided prefix (suddenly) 952 change, or external connectivity be temporarily lost. The use of 953 ULAs should be restricted to the homenet scope through filtering at 954 the border(s) of the homenet, as described in RFC 6092. 956 3.4.3. Internal prefix delegation 958 As mentioned above, there are various sources of prefixes, e.g. they 959 may be globally unique prefixes originating from ISP(s), they may be 960 globally unique or ULA prefixes allocated by "master" router(s) in 961 the homenet, or they may be ULAs allocated by LLN gateways. There 962 may also be a prefix associated with NAT64, if in use in the homenet. 964 From the homenet perspective, a single prefix from each ISP should be 965 received on the border CER [RFC3633]. Then each subnet in the 966 homenet should receive a prefix from within the ISP-provided 967 prefix(es). The ISP should only see the aggregate from the homenet, 968 and not single /64 prefixes allocated within the homenet. 970 Delegation should be autonomous, and not assume a flat or 971 hierarchical model. This text makes no assumption about whether the 972 delegation of prefixes is distributed or centralised. The assignment 973 mechanism should provide reasonable efficiency, so that typical home 974 network prefix allocation sizes can accommodate all the necessary /64 975 allocations in most cases, and not waste prefixes. A currently 976 typical /60 allocation gives 16 /64 subnets. Duplicate assignment of 977 multiple /64s to the same network should be avoided. The network 978 should behave as gracefully as possible in the event of prefix 979 exhaustion, though the options in such cases may be limited. 981 Where multiple CERs exist with multiple ISP prefix pools, it is 982 expected that routers within the homenet would assign themselves 983 prefixes from each ISP they communicate with/through. 985 Where ULAs are used, most likely but not necessarily in parallel with 986 global prefixes, one router should be elected to offer ULA prefixes 987 for the homenet. The router should generate a /48 ULA for the site, 988 and then delegate /64's from that ULA prefix to subnets. In the 989 normal state, a single /48 ULA should be used within the homenet. In 990 cases where two /48 ULAs are generated within a homenet, the network 991 should still continue to function. 993 Delegation within the homenet should give each link a prefix that is 994 persistent across reboots, power outages and similar short-term 995 outages. Addition of a new routing device should not affect existing 996 persistent prefixes, but persistence may not be expected in the face 997 of significant "replumbing" of the homenet. Persistent prefixes 998 should not depend on router boot order. Such persistent prefixes may 999 imply the need for stable storage on routing devices, and also a 1000 method for a home user to "reset" the stored prefix should a 1001 significant reconfiguration be required (though ideally the home user 1002 should not be involved at all). 1004 The delegation method should support renumbering, which would 1005 typically be "flash" renumbering in that the homenet would not have 1006 advance notice of the event or thus be able to apply the types of 1007 approach described in [RFC4192]. As a minimum, delegated ULA 1008 prefixes within the homenet should remain persistent through an ISP- 1009 driven renumbering event. 1011 Several proposals have been made for prefix delegation within a 1012 homenet. One group of proposals is based on DHCPv6 PD, as described 1013 in [I-D.baker-homenet-prefix-assignment], 1014 [I-D.chakrabarti-homenet-prefix-alloc], [RFC3315] and [RFC3633]. The 1015 other uses OSPFv3, as described in 1016 [I-D.arkko-homenet-prefix-assignment]. More detailed analysis of 1017 these approaches needs to be made against the requirements/principles 1018 described above. 1020 3.4.4. Privacy 1022 There are no specific privacy concerns discussed in this text. It 1023 should be noted as above that many ISPs are expected to offer 1024 relatively stable IPv6 prefixes to customers, and thus the network 1025 prefix associated with the host addresses they use may not change 1026 over a reasonably long period of time. This exposure is similar to 1027 IPv4 networks that expose the same IPv4 global address via use of 1028 NAT, where the IPv4 address received from the ISP may change over 1029 time, but not necessarily that frequently. 1031 Hosts inside an IPv6 homenet may get new IPv6 addresses over time 1032 regardless, e.g. through Privacy Addresses [RFC4941]. 1034 3.5. Routing functionality 1036 Routing functionality is required when there are multiple routers 1037 deployed within the internal home network. This functionality could 1038 be as simple as the current "default route is up" model of IPv4 NAT, 1039 or, more likely, it would involve running an appropriate routing 1040 protocol. 1042 The homenet routing protocol should preferably be an existing 1043 deployed protocol that has been shown to be reliable and robust, and 1044 it is preferable that the protocol is "lightweight". It is desirable 1045 that the routing protocol has knowledge of the homenet topology, 1046 which implies a link-state protocol is preferable. If so, it is also 1047 desirable that the announcements and use of LSAs and RAs are 1048 appropriately coordinated. This would mean the routing protocol 1049 gives a consistent view of the network, and that it can pass around 1050 more than just routing information. 1052 Multiple interface PHYs must be accounted for in the homenet routed 1053 topology. Technologies such as Ethernet, WiFi, MoCA, etc must be 1054 capable of coexisting in the same environment and should be treated 1055 as part of any routed deployment. The inclusion of the PHY layer 1056 characteristics including bandwidth, loss, and latency in path 1057 computation should be considered for optimising communication in the 1058 homenet. Multiple upstreams should be supported, as described in the 1059 multihoming section earlier. This should include load-balancing to 1060 multiple providers, and failover from a primary to a backup link when 1061 available. The protocol however should not require upstream ISP 1062 connectivity to be established to continue routing within the 1063 homenet. 1065 To support multihoming within a homenet, a routing protocol that can 1066 make routing decisions based on source and destination addresses is 1067 desirable, to avoid upstream ISP ingress filtering problems. In 1068 general the routing protocol should support multiple ISP uplinks and 1069 delegated prefixes in concurrent use. 1071 The routing environment should be self-configuring, as discussed 1072 previously. An example of how OSPFv3 can be self-configuring in a 1073 homenet is described in [I-D.acee-ospf-ospfv3-autoconfig]. 1074 Minimising convergence time should be a goal in any routed 1075 environment, but as a guideline a maximum convergence time of around 1076 30 seconds should be the target. 1078 Any routed solution will require a means for determining the 1079 boundaries of the homenet. Borders may include but are not limited 1080 to the interface to the upstream ISP, or a gateway device to a 1081 separate home network such as a SmartGrid or similar LLN network. In 1082 some cases there may be no border such as occurs before an upstream 1083 connection has been established. The border discovery functionality 1084 may be integrated into the routing protocol itself, but may also be 1085 imported via a separate discovery mechanism. 1087 In general, LLN or other networks should be able to attach and 1088 participate the same way as the main homenet, or alternatively map/be 1089 gatewayed to the main homenet. Current home deployments use largely 1090 different mechanisms in sensor and basic Internet connectivity 1091 networks. IPv6 VM solutions may also add additional routing 1092 requirements. 1094 [I-D.howard-homenet-routing-comparison] contains evaluations of 1095 common routing protocols made against the type of requirements 1096 described above. 1098 3.6. Security 1100 The security of an IPv6 homenet is an important consideration. The 1101 most notable difference to the IPv4 operational model is the removal 1102 of NAT, the introduction of global addressability of devices, and 1103 thus a need to consider whether devices should have global 1104 reachability. However, there are other challenges introduced, e.g. 1105 default filtering policies at the borders between other homenet 1106 realms. 1108 There is no defined "threat model" as such for the type of IPv6 1109 homenet described in this text. Such a document may be very useful. 1110 It may include a variety of perspectives, from probing for specific 1111 types of home appliance being present, to potential denial of service 1112 attacks. Hosts need to be able to operate securely, end-to-end where 1113 required, but also be robust against malicious traffic direct towards 1114 them. We simply note at this point that software on home devices 1115 will have an increase in security if it allows its software to be 1116 updated regularly. 1118 3.6.1. Addressability vs reachability 1120 An IPv6-based home network architecture should embrace and naturally 1121 offer a transparent end-to-end communications model as described in 1122 [RFC2775]. Each device should be addressable by a globally unique 1123 address, and those addresses must not be altered in transit. 1124 Security perimeters can (via policy) restrict end-to-end 1125 communications, and thus while a host may be globally addressable it 1126 may not be globally reachable. 1128 In IPv4 NAT networks, the NAT provides an implicit firewall function. 1129 [RFC4864] describes a "Simple Security" model for IPv6 networks, 1130 whereby stateful perimeter filtering can be applied instead where 1131 global addresses are used. RFC 4864 implies an IPv6 "default deny" 1132 policy for inbound connections be used for similar functionality to 1133 IPv4 NAT. It should be noted that such a "default deny" approach 1134 would effectively replace the need for IPv4 NAT traversal protocols 1135 with a need to use a signalling protocol to request a firewall hole 1136 be opened. Thus to support applications wanting to accept 1137 connections initiated into home networks where a "default deny" 1138 policy is in place support for a signalling protocol such as UPnP or 1139 PCP [I-D.ietf-pcp-base] is required. In networks with multiple CERs, 1140 the signalling would need to handle the cases of flows that may use 1141 one or more exit routers. CERs would need to be able to advertise 1142 their existence for such protocols. 1144 [RFC6092] expands on RFC 4864, giving a more detailed discussion of 1145 IPv6 perimeter security recommendations, without mandating a "default 1146 deny" approach. Indeed, RFC 6092 does not proscribe a particular 1147 mode of operation, instead stating that CERs must provide an easily 1148 selected configuration option that permits a "transparent" mode of 1149 operation, thus ensuring a "default allow" model is available. The 1150 homenet architecture text makes no recommendation on the default 1151 setting, and refers the reader to RFC 6092, which in turn simply 1152 states that a CER should provide functionality sufficient to support 1153 the recommendations in that RFC. 1155 Advanced Security for IPv6 CPEs [I-D.vyncke-advanced-ipv6-security] 1156 takes the approach that in order to provide the greatest end-to-end 1157 transparency as well as security, security policies must be updated 1158 by a trusted party which can provide intrusion signatures and other 1159 "active" information on security threats. This might for example 1160 allow different malware detection profiles to be configured on a CER. 1161 Such methods should be able to be automatically updating. 1163 3.6.2. Filtering at borders 1165 It is desirable that there are mechanisms to detect different types 1166 of borders within the homenet, as discussed previously, and then the 1167 means to apply different types of filtering policies at those 1168 borders, e.g. whether naming and service discovery should pass a 1169 given border. Any such policies should be able to be easily applied 1170 by typical home users, e.g. to give a visitor in a "guest" network 1171 access to media services in the home, or access to a printer in the 1172 residence. Simple mechanisms to apply policy changes, or 1173 associations between devices, will be required. 1175 There are cases where full internal connectivity may not be 1176 desirable, e.g. in certain utility networking scenarios, or where 1177 filtering is required for policy reasons against guest network 1178 subnet(s). Some scenarios/models may as a result involve running 1179 isolated subnet(s) with their own CERs. In such cases connectivity 1180 would only be expected within each isolated network (though traffic 1181 may potentially pass between them via external providers). 1183 LLNs provide an another example of where there may be secure 1184 perimeters inside the homenet. Constrained LLN nodes may implement 1185 WPA2-style network key security but may depend on access policies 1186 enforced by the LLN border router. 1188 3.6.3. Device capabilities 1190 In terms of the devices, homenet hosts should implement their own 1191 security policies in accordance to their computing capabilities. 1192 They should have the means to request transparent communications to 1193 be initiated to them, either for all ports or for specific services. 1194 Users should have simple methods to associate devices to services 1195 that they wish to operate transparently through (CER) borders. 1197 3.6.4. ULAs as a hint of connection origin 1199 It has been suggested that using ULAs would provide an indication to 1200 applications that received traffic is locally sourced. This could 1201 then be used with security settings to designate where a particular 1202 application is allowed to connect to or receive traffic from. 1204 3.7. Naming and Service Discovery 1206 Naming and service discovery must be supported in the homenet. The 1207 service(s) providing this function must support unmanaged operation. 1209 The most natural way to think about such naming and service discovery 1210 is to enable it to work across the entire homenet residence (site), 1211 disregarding technical borders such as subnets but potentially 1212 respecting policy borders such as those between visitor and internal 1213 network realms. 1215 Users will want simple ways to name devices, or be provided with 1216 appropriate ways for devices to generate unique names within the 1217 homenet. Users may typically perform device (re)naming and discovery 1218 through GUI interfaces that hide the local domain name element from 1219 them. Users may also wish to associated named devices to Internet 1220 domains, so that devices in their homenet can be accessed remotely. 1221 Thus from the user's perspective a device is given a name; the user 1222 may expect that same unqualified name toy be valid within the local 1223 name service or through an Internet name service. Thus implies 1224 relative name resolution should be supported, i.e. there is some 1225 naming convention that allows name resolution while mitigating the 1226 need for the user to know an absolute location in the Internet name 1227 space. Or that there is some means to discover the domain 1228 transparently to the user. 1230 Homenet devices may thus appear in one or more local homenet name 1231 spaces and also in one or more Internet name spaces. While typically 1232 there would be only one local name space, there may be scenarios 1233 where segmentation of that name space may be desirable. The naming 1234 system will be required to work internally or externally, be the user 1235 within the homenet or outside it, and there may be multiple naming 1236 domains used for any given device, e.g. Internet, home or guest 1237 domains. It is likely that a home user will want access to many of 1238 the devices and services in their home while "roaming" elsewhere. 1239 However, it may be the case that not all devices in the homenet are 1240 made available by name via an Internet name space, and that a "split 1241 view" is preferred for certain devices. 1243 The homenet name service must therefore at the very least co-exist 1244 with Internet name services. There are naming protocols that are 1245 designed to be configured and operate Internet-wide, like unicast- 1246 based DNS, but also protocols that are designed for zero- 1247 configuration local environments, like mDNS. Consideration should be 1248 made for how these interact with each other in a homenet scenario. 1250 The homenet name service should support both lookups and discovery. 1251 A lookup would operate via a direct query to a known service, while 1252 discovery may use multicast messages (as per mDNS and DNS-SD) or a 1253 service where applications register in order to be found. 1255 Name resolution and service discovery for reachable devices must 1256 continue to function if the local network is disconnected from the 1257 global Internet, e.g. a local media server should still be available 1258 even if the Internet link is down for an extended period. This 1259 implies the local network should also be able to perform a complete 1260 restart in the absence of external connectivity, and have local 1261 naming and discovery operate correctly. This might be achieved via a 1262 local cache and an authoritative local name service. Also, a change 1263 in ISP should also not affect local naming and service discovery. 1265 There should be consideration of the security of any local name 1266 space. A typical problem here may be that many homenets may use a 1267 common "well-known" local domain suffix, e.g. .local, and this may be 1268 ambiguous to a device that could attach to multiple homenets that use 1269 that name, but this is also part of the "avoid joining unintended 1270 networks" problem. A method to utilise a local trust anchor is 1271 desirable. 1273 With the introduction of new "dotless" top level domains, there is 1274 potential for ambiguity between for example a local host called 1275 "computer" and (if it is registered) a .computer gTLD. This suggests 1276 some implicit local name space is probably required. Such a name 1277 space should also be configurable to something else by the user. 1278 Discovery of a name service for access to external Internet resources 1279 is also a fundamental requirement in a multi-subnet homenet; the 1280 problem is not just name and service discovery within the homenet 1281 itself. 1283 In some parts of the homenet, e.g. LLNs, devices may be sleeping, in 1284 which case a proxy for such nodes may be required, that can respond 1285 for example to multicast service discovery requests. Those same 1286 parts of the network may have less capacity for multicast traffic 1287 that may be flooded from other parts of the network. In general, 1288 message utilisation should be efficient considering the network 1289 technologies the service may need to operate over. 1291 A desirable target may be a fully functional, self-configuring secure 1292 local name service so that all devices can be referred to by name, 1293 and these FQDNs are resolved locally. This could make clean use of 1294 ULAs and multiple ISP-provided prefixes much easier. Such a local 1295 name service should be (by default) authoritative for the local name 1296 space in both IPv4 and IPv6. A dual-stack residential gateway should 1297 include a dual-stack DNS server. 1299 Current service discovery protocols are generally aimed at single 1300 subnets. If service discovery is to operate across the an entire 1301 homenet, by adopting an approach like that proposed as Extended mDNS 1302 (xmDNS) [I-D.lynn-homenet-site-mdns], then support may be required 1303 for IPv6 multicast across the scope of the whole homenet. 1305 3.8. Other Considerations 1307 This section discusses some other considerations for home networking 1308 that may affect the architecture. 1310 3.8.1. Proxy or Extend? 1312 There are two broad choices for allowing services that would 1313 otherwise be link-local to work across a homenet site. In the 1314 example of service discovery, one is to take protocols like mDNS and 1315 have them run over site multicast within the homenet. This is fine 1316 if all hosts support the extension, and the scope within any internal 1317 borders is well-understood. But it's not backwards-compatible with 1318 existing link-local protocols. The alternative is to proxy service 1319 discovery across each link, to propagate it. This is more complex, 1320 but is backwards-compatible. It would need to work with IPv6, and 1321 dual-stack. 1323 The homenet architecture proposes that any existing protocols that 1324 are designed to only work within a subnet should be extended to work 1325 across subnets, rather than defining proxy capabilities for each of 1326 those functions. However, while it is desirable to extend protocols 1327 to site scope operation rather than providing proxy functions on 1328 subnet boundaries, the reality is that until all hosts can use site- 1329 scope discovery protocols, existing link-local protocols would need 1330 to be proxied anyway. 1332 Some protocols already have proxy functions defined and in use, e.g. 1333 DHCPv6 relays, in which case those protocols would be expected to 1334 continue to operate that way. 1336 3.8.2. Quality of Service 1338 Support for QoS in a multi-service homenet may be a requirement, e.g. 1339 for a critical system (perhaps healthcare related), or for 1340 differentiation between different types of traffic (file sharing, 1341 cloud storage, live streaming, VoIP, etc). Different media types may 1342 have different such properties or capabilities. 1344 However, homenet scenarios should require no new QoS protocols. A 1345 DiffServ [RFC2475] approach with a small number of predefined traffic 1346 classes should generally be sufficient, though at present there is 1347 little experience of QoS deployment in home networks. It is likely 1348 that QoS, or traffic prioritisation, methods will be required at the 1349 CER, and potentially around boundaries between different media types 1350 (where for example some traffic may simply not be appropriate for 1351 some media, and need to be dropped to avoid drowning the constrained 1352 media). 1354 There may also be complementary mechanisms that could be beneficial 1355 to application performance and behaviour in the homenet domain, such 1356 as ensuring proper buffering algorithms are used as described in 1357 [Gettys11]. 1359 3.8.3. Operations and Management 1361 The homenet should be self-organising and configuring as far as 1362 possible, and thus not be pro-actively managed by the home user. 1363 Thus protocols to manage the network are not discussed in this 1364 architecture text. 1366 However, users may be interested in the status of their networks and 1367 devices on the network, in which case simplified monitoring 1368 mechanisms may be desirable. It may also be the case that an ISP, or 1369 a third party, might offer management of the homenet on behalf of a 1370 user, in which case management protocols would be required. How such 1371 management is done is out of scope of this document; many solutions 1372 exist. 1374 3.9. Implementing the Architecture on IPv6 1376 This architecture text encourages re-use of existing protocols. Thus 1377 the necessary mechanisms are largely already part of the IPv6 1378 protocol set and common implementations. There are though some 1379 exceptions. For automatic routing, it is expected that existing 1380 routing protocols can be used as is. However, a new mechanism may be 1381 needed in order to turn a selected protocol on by default. 1383 Some functionality, if required by the architecture, would add 1384 significant changes or require development of new protocols, e.g. 1385 support for multihoming with multiple exit routers would likely 1386 require extensions to support source and destination address based 1387 routing within the homenet. 1389 Some protocol changes are however required in the architecture, e.g. 1390 for name resolution and service discovery, extensions to existing 1391 multicast-based name resolution protocols are needed to enable them 1392 to work across subnets, within the scope of the home network site. 1394 Some of the hardest problems in developing solutions for home 1395 networking IPv6 architectures include discovering the right borders 1396 where the domain "home" ends and the service provider domain begins, 1397 deciding whether some of the necessary discovery mechanism extensions 1398 should affect only the network infrastructure or also hosts, and the 1399 ability to turn on routing, prefix delegation and other functions in 1400 a backwards compatible manner. 1402 4. Conclusions 1404 This text defines principles and requirements for a homenet 1405 architecture. The principles and requirements documented here should 1406 be observed by any future texts describing homenet protocols for 1407 routing, prefix management, security, naming or service discovery. 1409 5. References 1411 5.1. Normative References 1413 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1414 (IPv6) Specification", RFC 2460, December 1998. 1416 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1417 and M. Carney, "Dynamic Host Configuration Protocol for 1418 IPv6 (DHCPv6)", RFC 3315, July 2003. 1420 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1421 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1422 December 2003. 1424 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1425 (DHCP) Service for IPv6", RFC 3736, April 2004. 1427 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1428 Addresses", RFC 4193, October 2005. 1430 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1431 Architecture", RFC 4291, February 2006. 1433 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1434 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1435 May 2007. 1437 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1438 Extensions for Stateless Address Autoconfiguration in 1439 IPv6", RFC 4941, September 2007. 1441 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1442 Customer Premises Equipment (CPE) for Providing 1443 Residential IPv6 Internet Service", RFC 6092, 1444 January 2011. 1446 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1447 Troan, "Basic Requirements for IPv6 Customer Edge 1448 Routers", RFC 6204, April 2011. 1450 [I-D.ietf-v6ops-6204bis] 1451 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1452 Requirements for IPv6 Customer Edge Routers", 1453 draft-ietf-v6ops-6204bis-09 (work in progress), May 2012. 1455 5.2. Informative References 1457 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1458 E. Lear, "Address Allocation for Private Internets", 1459 BCP 5, RFC 1918, February 1996. 1461 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1462 and W. Weiss, "An Architecture for Differentiated 1463 Services", RFC 2475, December 1998. 1465 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1466 February 2000. 1468 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1469 Address Translator (Traditional NAT)", RFC 3022, 1470 January 2001. 1472 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1473 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1474 December 2003. 1476 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1477 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1478 September 2005. 1480 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1481 Shim Protocol for IPv6", RFC 5533, June 2009. 1483 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1484 Infrastructures (6rd) -- Protocol Specification", 1485 RFC 5969, August 2010. 1487 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1488 "IPv6 Router Advertisement Options for DNS Configuration", 1489 RFC 6106, November 2010. 1491 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1492 IPv4/IPv6 Translation", RFC 6144, April 2011. 1494 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1495 Algorithm", RFC 6145, April 2011. 1497 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1498 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 1500 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1501 Translation", RFC 6296, June 2011. 1503 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1504 Stack Lite Broadband Deployments Following IPv4 1505 Exhaustion", RFC 6333, August 2011. 1507 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1508 Dual-Stack Hosts", RFC 6555, April 2012. 1510 [I-D.baker-fun-multi-router] 1511 Baker, F., "Exploring the multi-router SOHO network", 1512 draft-baker-fun-multi-router-00 (work in progress), 1513 July 2011. 1515 [I-D.lynn-homenet-site-mdns] 1516 Lynn, K. and D. Sturek, "Extended Multicast DNS", 1517 draft-lynn-homenet-site-mdns-00 (work in progress), 1518 March 2012. 1520 [I-D.townsley-troan-ipv6-ce-transitioning] 1521 Townsley, M. and O. Troan, "Basic Requirements for 1522 Customer Edge Routers - multihoming and transition", 1523 draft-townsley-troan-ipv6-ce-transitioning-02 (work in 1524 progress), December 2011. 1526 [I-D.baker-fun-routing-class] 1527 Baker, F., "Routing a Traffic Class", 1528 draft-baker-fun-routing-class-00 (work in progress), 1529 July 2011. 1531 [I-D.howard-homenet-routing-comparison] 1532 Howard, L., "Evaluation of Proposed Homenet Routing 1533 Solutions", draft-howard-homenet-routing-comparison-00 1534 (work in progress), December 2011. 1536 [I-D.herbst-v6ops-cpeenhancements] 1537 Herbst, T. and D. Sturek, "CPE Considerations in IPv6 1538 Deployments", draft-herbst-v6ops-cpeenhancements-00 (work 1539 in progress), October 2010. 1541 [I-D.vyncke-advanced-ipv6-security] 1542 Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced 1543 Security for IPv6 CPE", 1544 draft-vyncke-advanced-ipv6-security-03 (work in progress), 1545 October 2011. 1547 [I-D.ietf-6man-rfc3484bis] 1548 Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 1549 "Default Address Selection for Internet Protocol version 6 1550 (IPv6)", draft-ietf-6man-rfc3484bis-06 (work in progress), 1551 June 2012. 1553 [I-D.v6ops-multihoming-without-ipv6nat] 1554 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 1555 Wing, "IPv6 Multihoming without Network Address 1556 Translation", draft-v6ops-multihoming-without-ipv6nat-00 1557 (work in progress), March 2011. 1559 [I-D.baker-homenet-prefix-assignment] 1560 Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small 1561 Networks", draft-baker-homenet-prefix-assignment-01 (work 1562 in progress), March 2012. 1564 [I-D.arkko-homenet-prefix-assignment] 1565 Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment 1566 in a Home Network", 1567 draft-arkko-homenet-prefix-assignment-02 (work in 1568 progress), July 2012. 1570 [I-D.acee-ospf-ospfv3-autoconfig] 1571 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 1572 draft-acee-ospf-ospfv3-autoconfig-03 (work in progress), 1573 July 2012. 1575 [I-D.ietf-pcp-base] 1576 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1577 Selkirk, "Port Control Protocol (PCP)", 1578 draft-ietf-pcp-base-26 (work in progress), June 2012. 1580 [I-D.hain-ipv6-ulac] 1581 Hain, T., Hinden, R., and G. Huston, "Centrally Assigned 1582 IPv6 Unicast Unique Local Address Prefixes", 1583 draft-hain-ipv6-ulac-02 (work in progress), July 2010. 1585 [I-D.chakrabarti-homenet-prefix-alloc] 1586 Nordmark, E., Chakrabarti, S., Krishnan, S., and W. 1587 Haddad, "Simple Approach to Prefix Distribution in Basic 1588 Home Networks", draft-chakrabarti-homenet-prefix-alloc-01 1589 (work in progress), October 2011. 1591 [I-D.arkko-homenet-physical-standard] 1592 Arkko, J. and A. Keranen, "Minimum Requirements for 1593 Physical Layout of Home Networks", 1594 draft-arkko-homenet-physical-standard-00 (work in 1595 progress), March 2012. 1597 [Gettys11] 1598 Gettys, J., "Bufferbloat: Dark Buffers in the Internet", 1599 March 2011, 1600 . 1602 [IGD-2] UPnP Gateway Committee, "Internet Gateway Device (IGD) V 1603 2.0", September 2010, . 1606 Appendix A. Acknowledgments 1608 The authors would like to thank Aamer Akhter, Mark Andrews, Dmitry 1609 Anipko, Fred Baker, Ray Bellis, Cameron Byrne, Brian Carpenter, 1610 Stuart Cheshire, Lorenzo Colitti, Robert Cragie, Ralph Droms, Lars 1611 Eggert, Jim Gettys, olafur Gudmundsson, Wassim Haddad, Joel M. 1612 Halpern, David Harrington, Lee Howard, Ray Hunter, Joel Jaeggli, 1613 Heather Kirksey, Ted Lemon, Kerry Lynn, Erik Nordmark, Michael 1614 Richardson, Barbara Stark, Sander Steffann, Dave Taht, Dave Thaler, 1615 Mark Townsley, JP Vasseur, Curtis Villamizar, Dan Wing, Russ White, 1616 and James Woodyatt for their contributions within homenet WG meetings 1617 and on the WG mailing list. 1619 Appendix B. Changes 1621 This section will be removed in the final version of the text. 1623 B.1. Version 04 1625 Changes made include: 1627 o Moved border section from IPv6 differences to principles section. 1629 o Restructured principles into areas. 1631 o Added summary of naming and service discovery discussion from WG 1632 list. 1634 B.2. Version 03 1636 Changes made include: 1638 o Various improvements to the readability. 1640 o Removed bullet lists of requirements, as requested by chair. 1642 o Noted 6204bis has replaced advanced-cpe draft. 1644 o Clarified the topology examples are just that. 1646 o Emphasised we are not targetting walled gardens, but they should 1647 not be precluded. 1649 o Also changed text about requiring support for walled gardens. 1651 o Noted that avoiding falling foul of ingress filtering when 1652 multihomed is desirable. 1654 o Improved text about realms, detecting borders and policies at 1655 borders. 1657 o Stated this text makes no recommendation about default security 1658 model. 1660 o Added some text about failure modes for users plugging things 1661 arbitrarily. 1663 o Expanded naming and service discovery text. 1665 o Added more text about ULAs. 1667 o Removed reference to version 1 on chair feedback. 1669 o Stated that NPTv6 adds architectural cost but is not a homenet 1670 matter if deployed at the CER. This text only considers the 1671 internal homenet. 1673 o Noted multihoming is supported. 1675 o Noted routers may not by separate devices, they may be embedded in 1676 devices. 1678 o Clarified simple and advanced security some more, and RFC 4864 and 1679 6092. 1681 o Stated that there should be just one secret key, if any are used 1682 at all. 1684 o For multihoming, support multiple CERs but note that routing to 1685 the correct CER to avoid ISP filtering may not be optimal within 1686 the homenet. 1688 o Added some ISPs renumber due to privacy laws. 1690 o Removed extra repeated references to Simple Security. 1692 o Removed some solution creep on RIOs/RAs. 1694 o Load-balancing scenario added as to be supported. 1696 B.3. Version 02 1698 Changes made include: 1700 o Made the IPv6 implications section briefer. 1702 o Changed Network Models section to describe properties of the 1703 homenet with illustrative examples, rather than implying the 1704 number of models was fixed to the six shown in 01. 1706 o Text to state multihoming support focused on single CER model. 1707 Multiple CER support is desirable, but not required. 1709 o Stated that NPTv6 not supported. 1711 o Added considerations section for operations and management. 1713 o Added bullet point principles/requirements to Section 3.4. 1715 o Changed IPv6 solutions must not adversely affect IPv4 to should 1716 not. 1718 o End-to-end section expanded to talk about "Simple Security" and 1719 borders. 1721 o Extended text on naming and service discovery. 1723 o Added reference to RFC 2775, RFC 6177. 1725 o Added reference to the new xmDNS draft. 1727 o Added naming/SD requirements from Ralph Droms. 1729 Authors' Addresses 1731 Tim Chown (editor) 1732 University of Southampton 1733 Highfield 1734 Southampton, Hampshire SO17 1BJ 1735 United Kingdom 1737 Email: tjc@ecs.soton.ac.uk 1739 Jari Arkko 1740 Ericsson 1741 Jorvas 02420 1742 Finland 1744 Email: jari.arkko@piuha.net 1746 Anders Brandt 1747 Sigma Designs 1748 Emdrupvej 26A, 1 1749 Copenhagen DK-2100 1750 Denmark 1752 Email: abr@sdesigns.dk 1754 Ole Troan 1755 Cisco Systems, Inc. 1756 Drammensveien 145A 1757 Oslo N-0212 1758 Norway 1760 Email: ot@cisco.com 1762 Jason Weil 1763 Time Warner Cable 1764 13820 Sunrise Valley Drive 1765 Herndon, VA 20171 1766 USA 1768 Email: jason.weil@twcable.com