idnits 2.17.1 draft-ietf-homenet-arch-03.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 a Security Considerations section. ** 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 (June 29, 2012) is 4311 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) == 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-01 == Outdated reference: A later version (-03) exists of draft-acee-ospf-ospfv3-autoconfig-02 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-26 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 3 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: December 31, 2012 Ericsson 6 A. Brandt 7 Sigma Designs 8 O. Troan 9 Cisco Systems, Inc. 10 J. Weil 11 Time Warner Cable 12 June 29, 2012 14 Home Networking Architecture for IPv6 15 draft-ietf-homenet-arch-03 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 the architecture for IPv6-based home networking 22 through the associated principles, considerations and requirements. 23 The text briefly highlights the implications of the introduction of 24 IPv6 for home networking, discusses topology scenarios, and suggests 25 how standard IPv6 mechanisms and addressing can be employed in home 26 networking. The architecture describes the need for specific 27 protocol extensions for certain additional functionality. It is 28 assumed that the IPv6 home network is not actively managed, and runs 29 as an IPv6-only or dual-stack network. There are no recommendations 30 in this text for the IPv4 part of the network. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 31, 2012. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 5 68 2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . . 5 69 2.1. Multiple subnets and routers . . . . . . . . . . . . . . . 6 70 2.2. Global addressability and elimination of NAT . . . . . . . 6 71 2.3. Multi-Addressing of devices . . . . . . . . . . . . . . . 7 72 2.4. Unique Local Addresses (ULAs) . . . . . . . . . . . . . . 8 73 2.5. Security and borders . . . . . . . . . . . . . . . . . . . 9 74 2.6. Naming, and manual configuration of IP addresses . . . . . 10 75 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.1. Network Models . . . . . . . . . . . . . . . . . . . . . . 11 77 3.1.1. A: Single ISP, Single CER, Internal routers . . . . . 12 78 3.1.2. B: Two ISPs, Two CERs, Shared subnet . . . . . . . . . 14 79 3.1.3. C: Two ISPs, One CER, Shared subnet . . . . . . . . . 15 80 3.2. Determining the Requirements . . . . . . . . . . . . . . . 15 81 3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 16 82 3.3.1. Multihoming . . . . . . . . . . . . . . . . . . . . . 16 83 3.3.2. Quality of Service . . . . . . . . . . . . . . . . . . 17 84 3.3.3. Operations and Management . . . . . . . . . . . . . . 18 85 3.3.4. Privacy considerations . . . . . . . . . . . . . . . . 18 86 3.4. Design Principles and Requirements . . . . . . . . . . . . 18 87 3.4.1. Reuse existing protocols . . . . . . . . . . . . . . . 19 88 3.4.2. Dual-stack Operation . . . . . . . . . . . . . . . . . 19 89 3.4.3. Largest Possible Subnets . . . . . . . . . . . . . . . 20 90 3.4.4. Security vs Transparent, End-to-End Communications . . 20 91 3.4.5. Internal IP Connectivity . . . . . . . . . . . . . . . 21 92 3.4.6. Routing functionality . . . . . . . . . . . . . . . . 22 93 3.4.7. A Self-organising Network . . . . . . . . . . . . . . 24 94 3.4.8. Fewest Topology Assumptions . . . . . . . . . . . . . 26 95 3.4.9. Naming and Service Discovery . . . . . . . . . . . . . 26 96 3.4.10. Proxy or Extend? . . . . . . . . . . . . . . . . . . . 27 97 3.4.11. Adapt to ISP constraints . . . . . . . . . . . . . . . 28 98 3.5. Implementing the Architecture on IPv6 . . . . . . . . . . 29 99 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 101 5.1. Normative References . . . . . . . . . . . . . . . . . . . 30 102 5.2. Informative References . . . . . . . . . . . . . . . . . . 31 103 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 34 104 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 34 105 B.1. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 35 106 B.2. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 36 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 109 1. Introduction 111 This document focuses on evolving networking technology within 112 increasingly large residential home networks and the associated 113 challenges with their deployment and operation. There is a growing 114 trend in home networking for the proliferation of networking 115 technology in an increasingly broad range of devices and media. This 116 evolution in scale and diversity sets requirements on IETF protocols. 117 Some of these requirements relate to the introduction of IPv6, others 118 to the introduction of specialised networks for home automation and 119 sensors. There are likely to be scenarios where internal routing is 120 required, for example to support private and guest networks, in which 121 case home networks may use increasing numbers of subnets. 123 While at the time of writing some complex home network topologies 124 exist, most operate based on IPv4, employ solutions that we would 125 like to avoid such as (cascaded) network address translation (NAT), 126 or require expert assistance to set up. The assumption of this 127 document is that the homenet is as far as possible self-organising 128 and self-configuring, and is thus not pro-actively managed by the 129 residential user. 131 The architectural constructs in this document are focused on the 132 problems to be solved when introducing IPv6 with an eye towards a 133 better result than what we have today with IPv4, as well as a better 134 result than if the IETF had not given this specific guidance. The 135 document aims to provide the basis and guiding principles for how 136 standard IPv6 mechanisms and addressing [RFC2460] [RFC4291] can be 137 employed in home networking, while coexisting with existing IPv4 138 mechanisms. In emerging dual-stack home networks it is vital that 139 introducing IPv6 does not adversely affect IPv4 operation. Future 140 deployments, or specific subnets within an otherwise dual-stack home 141 network, may be IPv6-only, in which case considerations for IPv4 142 impact would not apply. We assume that the IPv4 network architecture 143 in home networks is what it is, and can not be affected by new 144 recommendations. 146 This architecture document proposes a baseline homenet architecture, 147 based on protocols and implementations that are as far as possible 148 proven and robust. The scope of the document is primarily the 149 network layer technologies that provide the basic functionality to 150 enable addressing, connectivity, routing, naming and service 151 discovery. While it may, for example, state that homenet components 152 must be simple to deploy and use, it does not discuss specific user 153 interfaces, nor does it consider specific physical, wireless or data- 154 link layer considerations. 156 [RFC6204] defines basic requirements for customer edge routers 157 (CERs). The scope of this text is the homenet, and thus the relevant 158 part of RFC 6204 is the internal facing interface as well as any 159 other components within the home network. While the network may be 160 dual-stack or IPv6-only, the definition of specific transition tools 161 on the CER, as introduced in RFC 6204-bis [I-D.ietf-v6ops-6204bis] 162 with DS-Lite [RFC6333] and 6rd [RFC5969], are considered issues for 163 that RFC, and are thus out of scope of this text. 165 1.1. Terminology and Abbreviations 167 In this section we define terminology and abbreviations used 168 throughout the text. 170 o "Advanced Security". Describes advanced security functions for a 171 CER, as defined in [I-D.vyncke-advanced-ipv6-security], where the 172 default inbound connection policy is generally "default allow". 174 o CER: Customer Edge Router. A border router at the edge of the 175 homenet. 177 o LLN: Low-power and lossy network. 179 o NAT: Network Address Translation. Typically referring to IPv4 180 Network Address and Port Translation (NAPT) [RFC3022]. 182 o NPTv6: Network Prefix Translation for IPv6 [RFC6296]. 184 o PCP: Port Control Protocol [I-D.ietf-pcp-base]. 186 o "Simple Security". Defined in [RFC4864] and expanded further in 187 [RFC6092]; describes recommended perimeter security capabilities 188 for IPv6 networks. 190 o ULA: IPv6 Unique Local Addresses [RFC4193]. 192 o UPnP: Universal Plug and Play. Includes the Internet Gateway 193 Device (IGD) function, which for IPv6 is UPnP IGD Version 2 194 [IGD-2]. 196 o VM: Virtual machine. 198 o WPA2: Wi-Fi Protected Access, as defined by the Wi-Fi Alliance. 200 2. Effects of IPv6 on Home Networking 202 Service providers are deploying IPv6, content is becoming available 203 on IPv6, and support for IPv6 is increasingly available in devices 204 and software used in the home. While IPv6 resembles IPv4 in many 205 ways, it changes address allocation principles, making multi- 206 addressing the norm, and allowing direct IP addressability home 207 networking devices from the Internet. This section presents an 208 overview of some of the key implications of the introduction of IPv6 209 for home networking, that are both promising and problematic. 211 2.1. Multiple subnets and routers 213 While simple layer 3 topologies involving as few subnets as possible 214 are preferred in home networks, the incorporation of dedicated 215 (routed) subnets remains necessary for a variety of reasons. For 216 instance, an increasingly common feature in modern home routers is 217 the ability to support both guest and private network subnets. 218 Likewise, there may be a need to separate building control or 219 corporate extensions from the main Internet access network, or 220 different subnets may in general be associated with parts of the 221 homenet that have different routing and security policies. Further, 222 link layer networking technology is poised to become more 223 heterogeneous, as networks begin to employ both traditional Ethernet 224 technology and link layers designed for low-power and lossy networks 225 (LLNs), such as those used for certain types of sensor devices. 227 Documents that provide some more specific background and depth on 228 this topic include: [I-D.herbst-v6ops-cpeenhancements], 229 [I-D.baker-fun-multi-router], and [I-D.baker-fun-routing-class]. 231 The addition of routing between subnets raises the issue of how to 232 extend mechanisms such as service discovery which currently rely on 233 link-local addressing to limit scope. There are two broad choices; 234 extend existing protocols to work across the scope of the homenet, or 235 introduce proxies for existing link-layer protocols. This is 236 discussed later in the document. 238 There will also be the need to discover which routers in the homenet 239 are the border router(s) by an appropriate mechanism. Here, there 240 are a number of choices. These include an appropriate service 241 discovery protocol, or the use of a well-known name, resolved by some 242 local name service. Both might have to deal with handling more than 243 one router responding in multihomed environments. 245 2.2. Global addressability and elimination of NAT 247 Current IPv4 home networks typically receive a single global IPv4 248 address from their ISP and use NAT with private [RFC1918] addresses 249 for devices within the network. An IPv6 home network removes the 250 need to use NAT given the ISP offers a sufficiently large globally 251 unique IPv6 prefix to the homenet, allowing every device on every 252 link to be assigned a globally unique IPv6 address. 254 The end-to-end communication that is potentially enabled with IPv6 is 255 on the one hand an incredible opportunity for innovation and simpler 256 network operation, but it is also a concern as it exposes nodes in 257 the internal networks to receipt of otherwise unwanted traffic from 258 the Internet. There may thus be an expectation of improved host 259 security to compensate for this, at least in general networked 260 devices, but it must be noted that many devices may also (for 261 example) ship with default settings that make them readily vulnerable 262 to compromise by external attackers if globally accessible, or may 263 simply not have robustness designed-in because it was either assumed 264 such devices would only be used on private networks or the device 265 itself doesn't have the computing power to apply the necessary 266 security methods. 268 IPv6 networks may or may not have filters applied at their borders, 269 i.e. at the homenet CER. [RFC4864], [RFC6092] and 270 [I-D.vyncke-advanced-ipv6-security] discuss such filtering, and the 271 merits of "default allow" against "default deny" policies for 272 external traffic initiated into a homenet. It is important to 273 distinguish between addressability and reachability. While IPv6 274 offers global addressability through use of globally unique addresses 275 in the home, whether they are globally reachable or not would depend 276 on the firewall or filtering configuration, and not, as is commonly 277 the case with IPv4, the presence or use of NAT. 279 2.3. Multi-Addressing of devices 281 In an IPv6 network, devices may acquire multiple addresses, typically 282 at least a link-local address and a globally unique address. They 283 may also have an IPv4 address if the network is dual-stack, a Unique 284 Local Address (ULA) [RFC4193] (see below), and one or more IPv6 285 Privacy Addresses [RFC4941]. 287 Thus it should be considered the norm for devices on IPv6 home 288 networks to be multi-addressed, and to need to make appropriate 289 address selection decisions for the candidate source and destination 290 address pairs. Default Address Selection for IPv6 291 [I-D.ietf-6man-rfc3484bis] provides a solution for this, though it 292 may face problems in the event of multihoming, where nodes will be 293 configured with one address from each upstream ISP prefix. In such 294 cases the presence of upstream ingress filtering requires multi- 295 addressed nodes to select the right source address to be used for the 296 corresponding uplink, to avoid ISP BCP 38 ingress filtering, but the 297 node may not have the information it needs to make that decision 298 based on addresses alone. We discuss such challenges in multihoming 299 later in this document. 301 2.4. Unique Local Addresses (ULAs) 303 [RFC4193] defines Unique Local Addresses (ULAs) for IPv6 that may be 304 used to address devices within the scope of a single site. Support 305 for ULAs for IPv6 CERs is described in [RFC6204]. A home network 306 running IPv6 may deploy ULAs for stable communication between devices 307 (on different subnets) within the network where the externally 308 allocated global prefix changes over time (e.g. due to renumbering 309 within the subscriber's ISP) or where external connectivity is 310 temporarily unavailable. 312 A counter-argument to using ULAs is that it is undesirable to 313 aggressively deprecate global prefixes for temporary loss of 314 connectivity, so for a host to lose its global address there would 315 have to be a connection breakage longer than the lease period, and 316 even then, deprecating prefixes when there is no connectivity may not 317 be advisable. It should also be noted that there may be timers on 318 the prefix lease to the homenet, on the internal prefix delegations, 319 and on the Router Advertisements to the hosts. Despite this counter- 320 argument, while setting a network up there may be a period with no 321 connectivity, in which case ULAs would be required for inter-subnet 322 communication. In the case where LLNs are being set up in a new 323 home/deployment, individual LLNs may, at least initially, each use 324 their own /48 ULA prefix. 326 ULA addresses will allow constrained LLN devices to create permanent 327 relationships between IPv6 addresses, e.g. from a wall controller to 328 a lamp. Symbolic host names would require additional non-volatile 329 memory. Updating global prefixes in sleeping LLN devices might also 330 be problematic. 332 It has been suggested that using ULAs would provide an indication to 333 applications that received traffic is locally sourced. This could 334 then be used with security settings to designate where a particular 335 application is allowed to connect to or receive traffic from. 337 Default address selection mechanisms should ensure a ULA source 338 address is used to communicate with ULA destination addresses when 339 appropriate, in particular when the ULA destination lies within a /48 340 ULA prefix known to be used within the same homenet. Unlike the IPv4 341 RFC 1918 space, the use of ULAs does not imply use of host-based IPv6 342 NAT, or NPTv6 prefix-based NAT [RFC6296], rather that external 343 communications should use a node's additional globally unique IPv6 344 source address. 346 2.5. Security and borders 348 The filtering policy to/from the homenet is an important 349 consideration, but the homenet/ISP border may not be the only border 350 in a homenet. It is desirable that there are mechanisms to detect 351 other types of borders, and then the means to apply different types 352 of filtering policies at those borders, e.g. whether naming and 353 service discovery should pass a given border. Any such policies 354 should be able to be easily applied by typical home users, e.g. to 355 give a visitor in a "guest" network access to media services in the 356 home, or access to a printer in the residence. Simple mechanisms to 357 apply policy changes, or associations between devices, will be 358 required. 360 A simple homenet model may just consider three types of realm and the 361 borders between them. For example if the realms are the homenet, the 362 ISP and the visitor network, then the borders will include that from 363 the homenet to the ISP, and that from the homenet to a guest network. 364 Regardless, it should be possible for additional types of realms and 365 borders to be defined, e.g. for some specific Grid or LLN-based 366 network, and for these to be detected or configured, and for an 367 appropriate default policy to be applied as to what type of traffic/ 368 data can flow across such borders. 370 It is desirable to classify the external border of the home network 371 as a unique logical interface separating the home network from 372 service provider network/s. This border interface may be a single 373 physical interface to a single service provider, multiple layer 2 374 sub-interfaces to a single service provider, or multiple connections 375 to a single or multiple providers. This border makes it possible to 376 describe edge operations and interface requirements across multiple 377 functional areas including security, routing, service discovery, and 378 router discovery. 380 while a goal of the homenet architecture is for the network to be as 381 self-organising as possible, there may be instances where some manual 382 configuration is required, e.g. the entry of a key to apply wireless 383 security, or to configure a shared routing secret. The latter may be 384 relevant when considering how to bootstrap a routing configuration. 385 It is highly desirable that only one such key is needed for any set 386 of functions, to increase usability for the homenet user. 388 Advanced Security for IPv6 CPEs [I-D.vyncke-advanced-ipv6-security] 389 takes the approach that in order to provide the greatest end-to-end 390 transparency as well as security, security policies must be updated 391 by a trusted party which can provide intrusion signatures and other 392 "active" information on security threats. This might for example 393 allow different malware detection profiles to be configured on a CER. 395 Such methods should be able to be automatically updating. 397 There is no defined "threat model" as such for the type of IPv6 398 homenet described in this text. Such a document may be very useful. 399 It may include a variety of perspectives, from probing for specific 400 types of home appliance being present, to potential denial of service 401 attacks. Hosts need to be able to operate securely, end-to-end where 402 required, but also be robust against malicious traffic direct towards 403 them. We simply note at this point that software on home devices 404 will have an increase in security if it allows its software to be 405 updated regularly. 407 2.6. Naming, and manual configuration of IP addresses 409 Some IPv4 home networking devices expose IPv4 addresses to users, 410 e.g. the IPv4 address of a home IPv4 CER that may be configured via a 411 web interface. Users should not be expected to enter IPv6 literal 412 addresses in homenet devices or applications, given their much 413 greater length and apparent randomness to a typical home user. While 414 shorter addresses, perhaps ones registered with IANA from ULA-C space 415 [I-D.hain-ipv6-ulac], could be used for specific devices/services, in 416 general it is better to not expose users to real IPv6 addresses. 417 Thus, even for the simplest of functions, simple naming and the 418 associated (ideally zero configuration) discovery of services is 419 imperative for the easy deployment and use of homenet devices and 420 applications. 422 In a multi-subnet homenet, naming and service discovery should be 423 expected to be capable of operating across the scope of the entire 424 home network, and thus be able to cross subnet boundaries. It should 425 be noted that in IPv4, such services do not generally function across 426 home router NAT boundaries, so this is one area where there is scope 427 for an improvement in IPv6. 429 3. Architecture 431 The aim of this architecture text is to outline how to construct home 432 networks involving multiple routers and subnets. In this section, we 433 present a set of typical home network topology models/scenarios, 434 followed by a list of topics that may influence the architectural 435 discussions, and a set of architectural principles and requirements 436 that govern how the various nodes should work together. The 437 architecture also drives what protocol extensions are necessary, as 438 will be discussed briefly in Section 3.5. 440 3.1. Network Models 442 Most IPv4 home network models at the time of writing tend to be 443 relatively simple, typically a single NAT router to the ISP and a 444 single internal subnet but, as discussed earlier, evolution in 445 network architectures is driving more complex topologies, such as the 446 separation of visitor and private networks. 448 In general, the models described in [RFC6204] and its successor RFC 449 6204-bis [I-D.ietf-v6ops-6204bis] should be supported by an IPv6 home 450 networking architecture. 452 There are a number of properties or attributes of a home network that 453 we can use to describe its topology and operation. The following 454 properties apply to any IPv6 home network: 456 o Presence of internal routers. The homenet may have one or more 457 internal routers, or may only provide subnetting from interfaces 458 on the CER. 460 o Presence of isolated internal subnets. There may be isolated 461 internal subnets, with no direct connectivity between them within 462 the homenet. Isolation may be physical, or implemented via IEEE 463 802.1q VLANs. 465 o Demarcation of the CER. The CER(s) may or may not be managed by 466 the ISP. If the demarcation point is such that the customer can 467 provide or manage the CER, its configuration must be simple. Both 468 models must be supported. 470 It has also been suggested that various forms of multihoming are more 471 prevalent with IPv6 home networks. Thus the following properties may 472 also apply to such networks: 474 o Number of upstream providers. A typical homenet might just have a 475 single upstream ISP, but it may become more common for there to be 476 multiple ISPs, whether for resilience or provision of additional 477 services. Each would offer its own prefix. Some may or may not 478 be walled gardens. 480 o Number of CERs. The homenet may have a single CER, which might be 481 used for one or more providers, or multiple CERs. Multiple CERs 482 adds additional complexity for multihoming scenarios, and 483 protocols like PCP that need to manage connection-oriented state 484 mappings. 486 Some separate discussion of physical infrastructures for homenets is 487 included in and [I-D.arkko-homenet-physical-standard]. 489 In principle, we might argue that an architecture for IPv6 homenets 490 should support any arbitrary topology. We discuss this topic later 491 in the text. In the following sections we give some examples of the 492 types of homenet topologies we may see in the future. This is not 493 intended to be an exhaustive or complete list, rather an indicative 494 one to facilitate discussion in this text. 496 3.1.1. A: Single ISP, Single CER, Internal routers 498 Figure 1 shows a network with multiple local area networks. These 499 may be needed for reasons relating to different link layer 500 technologies in use or for policy reasons, e.g. classic Ethernet in 501 one subnet and a LLN link layer technology in another. In this 502 example there is no single router that a priori understands the 503 entire topology. The topology itself may also be complex, and it may 504 not be possible to assume a pure tree form, for instance. This is a 505 valid consideration as home users may plug routers together to form 506 arbitrary topologies including loops (we discuss support for 507 arbitrary topologies in layer sections). 509 +-------+-------+ \ 510 | Service | \ 511 | Provider | | Service 512 | Router | | Provider 513 +-------+-------+ | network 514 | / 515 | Customer / 516 | Internet connection 517 | 518 +------+--------+ \ 519 | IPv6 | \ 520 | Customer Edge | \ 521 | Router | | 522 +----+-+---+----+ | 523 Network A | | | Network B/E | 524 ----+-------------+----+ | +---+-------------+------+ | 525 | | | | | | | | 526 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | | 527 |IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | | 528 | | | | | | | | | | | 529 +----------+ +----------+ | +----------+ +----------+ | | 530 | | | | | 531 | ---+------+------+-----+ | 532 | | Network B/E | 533 +------+--------+ | | End-User 534 | IPv6 | | | networks 535 | Interior +------+ | 536 | Router | | 537 +---+-------+-+-+ | 538 Network C | | Network D | 539 ----+-------------+---+- --+---+-------------+--- | 540 | | | | | 541 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 542 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 543 | | | | | | | | / 544 +----------+ +----------+ +----------+ +----------+ / 546 Figure 1 548 3.1.2. B: Two ISPs, Two CERs, Shared subnet 550 +-------+-------+ +-------+-------+ \ 551 | Service | | Service | \ 552 | Provider A | | Provider B | | Service 553 | Router | | Router | | Provider 554 +------+--------+ +-------+-------+ | network 555 | | / 556 | Customer | / 557 | Internet connections | / 558 | | 559 +------+--------+ +-------+-------+ \ 560 | IPv6 | | IPv6 | \ 561 | Customer Edge | | Customer Edge | \ 562 | Router 1 | | Router 2 | / 563 +------+--------+ +-------+-------+ / 564 | | / 565 | | | End-User 566 ---+---------+---+---------------+--+----------+--- | network(s) 567 | | | | \ 568 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 569 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 570 | | | | | | | | / 571 +----------+ +----------+ +----------+ +----------+ 573 Figure 2 575 Figure 2 illustrates a multihomed home network model, where the 576 customer has connectivity via CER1 to ISP A and via CER2 to ISP B. 577 This example shows one shared subnet where IPv6 nodes would 578 potentially be multihomed and receive multiple IPv6 global addresses, 579 one per ISP. This model may also be combined with that shown in 580 Figure 1 to create a more complex scenario with multiple internal 581 routers. Or the above shared subnet may be split in two, such that 582 each CER serves a separate isolated subnet, which is a scenario seen 583 with some IPv4 networks today. 585 3.1.3. C: Two ISPs, One CER, Shared subnet 587 +-------+-------+ +-------+-------+ \ 588 | Service | | Service | \ 589 | Provider A | | Provider B | | Service 590 | Router | | Router | | Provider 591 +-------+-------+ +-------+-------+ | network 592 | | / 593 | Customer | / 594 | Internet | / 595 | connections | | 596 +---------+---------+ \ 597 | IPv6 | \ 598 | Customer Edge | \ 599 | Router | / 600 +---------+---------+ / 601 | / 602 | | End-User 603 ---+------------+-------+--------+-------------+--- | network(s) 604 | | | | \ 605 +----+-----+ +----+-----+ +----+-----+ +-----+----+ \ 606 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 607 | | | | | | | | / 608 +----------+ +----------+ +----------+ +----------+ 610 Figure 3 612 Figure 3 illustrates a model where a home network may have multiple 613 connections to multiple providers or multiple logical connections to 614 the same provider, with shared internal subnets. 616 3.2. Determining the Requirements 618 [RFC6204] defines "basic" requirements for IPv6 Customer Edge 619 Routers, while [I-D.ietf-v6ops-6204bis] extends RFC 6204 to describe 620 additional features. In general, home network equipment needs to 621 cope with the different types of network properties and topologies as 622 exemplified above. Significant manual configuration is rarely, if at 623 all, possible, given the knowledge level of typical home users. The 624 network should as far as possible be self-configuring. The equipment 625 needs to be prepared to handle at least 627 o Routing 629 o Prefix configuration for routers 630 o Name resolution 632 o Service discovery 634 o Network security 636 The remainder of the architecture document is presented as 637 considerations and principles that lead to more specific requirements 638 for the five general areas listed above. 640 3.3. Considerations 642 This section discusses some considerations for home networking that 643 may affect the architecture and associated requirements. 645 3.3.1. Multihoming 647 A homenet may be multihomed to multiple providers. This may either 648 take a form where there are multiple isolated networks within the 649 home or a more integrated network where the connectivity selection is 650 dynamic. Current practice is typically of the former kind, but the 651 latter is expected to become more commonplace. 653 The general multihoming problem is broad, and solutions suggested to 654 date within the IETF may include complex architectures for monitoring 655 connectivity, traffic engineering, identifier-locator separation, 656 connection survivability across multihoming events, and so on. It is 657 thus important that the homenet architecture should as far as 658 possible minimise the complexity of any multihoming support. So we 659 should limit the support to the smallest subset of the overall 660 problem to meet the requirements of the topologies described above. 661 This means that the homenet architecture should not try to make 662 another attempt at solving complex multihoming, and we should prefer 663 to support scenarios for which solutions exist today. 665 In the general homenet architecture, hosts should be multi-addressed 666 with globally unique prefixes from each ISP they may communicate with 667 or through. The alternative for a homenet would be to deploy NPTv6 668 [RFC6296] at the CER, with ULAs then typically used internally. 669 NPTv6 has some architectural cost, due to the prefix translation 670 used, but the internal part of the homenet (which is the scope of 671 this text) sees only the one prefix in use. 673 When multi-addressing is in use, hosts need some way to pick source 674 and destination address pairs for connections. A host may choose a 675 source address to use by various methods, which would typically 676 include [I-D.ietf-6man-rfc3484bis]. Applications may of course do 677 different things, and this should not be precluded. 679 For the single CER Network Model C, multihoming may be offered by 680 source routing at the CER. With multiple exit routers, the 681 complexity rises. Given a packet with a source address on the 682 network, the packet must be routed to the proper egress to avoid 683 ingress filtering at a wrong ISP. While the packet might not take an 684 optimal path to the correct exit CER, the minimum requirement is that 685 the packet is not dropped, and it is highly desirable that the packet 686 is routed in the most efficient manner to the correct exit. 688 There are various potential approaches to this problem, one example 689 being described in [I-D.v6ops-multihoming-without-ipv6nat]. Another 690 is discussed in [I-D.baker-fun-multi-router], which explores support 691 for source routing throughout the homenet. This approach would 692 however likely require relatively significant routing changes to 693 route the packet to the correct exit given the source address. Such 694 changes should preferably be minimised. 696 There are some other multihoming considerations for homenet 697 scenarios. First, it may be the case that multihoming applies due to 698 an ISP migration from a transition method to a native deployment, 699 e.g. a 6rd [RFC5969] sunset scenario, as discussed in 700 [I-D.townsley-troan-ipv6-ce-transitioning]. Second, one upstream may 701 be a "walled garden", and thus only appropriate to be used for 702 connectivity to the services of that provider; an example may be a 703 VPN service that only routes back to the enterprise business network 704 of a user in the homenet. While we should not specifically target 705 walled garden multihoming as a principal goal, it should not be 706 precluded. 708 Host-based methods such as Shim6 [RFC5533] have been defined, but of 709 course require support in the hosts. There are also application- 710 oriented approaches such as Happy Eyeballs 711 [I-D.ietf-v6ops-happy-eyeballs]; simplified versions of this are for 712 example implemented in some commonly-used web browsers. The homenet 713 architecture should not preclude use of such tools. Solutions that 714 require host changes should be avoided, but solutions which 715 incrementally improve with host changes may be acceptable. 717 3.3.2. Quality of Service 719 Support for QoS in a multi-service homenet may be a requirement, e.g. 720 for a critical system (perhaps healthcare related), or for 721 differentiation between different types of traffic (file sharing, 722 cloud storage, live streaming, VoIP, etc). Different media types may 723 have different such properties or capabilities. 725 However, homenet scenarios should require no new QoS protocols. A 726 DiffServ [RFC2475] approach with a small number of predefined traffic 727 classes should generally be sufficient, though at present there is 728 little experience of QoS deployment in home networks. It is likely 729 that QoS, or traffic prioritisation, methods will be required at the 730 CER, and potentially around boundaries between different media types 731 (where for example some traffic may simply not be appropriate for 732 some media, and need to be dropped to avoid drowning the constrained 733 media). 735 There may also be complementary mechanisms that could be beneficial 736 to application performance and behaviour in the homenet domain, such 737 as ensuring proper buffering algorithms are used as described in 738 [Gettys11]. 740 3.3.3. Operations and Management 742 The homenet should be self-organising and configuring as far as 743 possible, and thus not be pro-actively managed by the home user. 744 Thus protocols to manage the network are not discussed in this 745 architecture text. 747 However, users may be interested in the status of their networks and 748 devices on the network, in which case simplified monitoring 749 mechanisms may be desirable. It may also be the case that an ISP, or 750 a third party, might offer management of the homenet on behalf of a 751 user, in which case management protocols would be required. How such 752 management is done is out of scope of this document; many solutions 753 exist. 755 3.3.4. Privacy considerations 757 There are no specific privacy concerns discussed in this text. It 758 should be noted that many ISPs are expected to offer relatively 759 stable IPv6 prefixes to customers, and thus the network prefix 760 associated with the host addresses they use would not generally 761 change over a reasonable period of time. This exposure is similar to 762 IPv4 networks that expose the same IPv4 global address via use of 763 NAT, where the IPv4 address received from the ISP may change over 764 time. 766 Hosts inside an IPv6 homenet may get new IPv6 addresses over time 767 regardless, e.g. through Privacy Addresses [RFC4941]. 769 3.4. Design Principles and Requirements 771 There is little that the Internet standards community can do about 772 the physical topologies or the need for some networks to be separated 773 at the network layer for policy or link layer compatibility reasons. 774 However, there is a lot of flexibility in using IP addressing and 775 inter-networking mechanisms. In this section we discuss how this 776 flexibility should be used to provide the best user experience and 777 ensure that the network can evolve with new applications in the 778 future. 780 The following principles should be followed when designing homenet 781 solutions. Where requirements are associated with those principles, 782 they are stated. There is no implied priority by the order in which 783 the principles themselves are listed. 785 3.4.1. Reuse existing protocols 787 It is desirable to reuse existing protocols where possible, but at 788 the same time to avoid consciously precluding the introduction of new 789 or emerging protocols. A generally conservative approach, giving 790 weight to running code, is preferable. Where new protocols are 791 required, evidence of commitment to implementation by appropriate 792 vendors or development communities is highly desirable. Protocols 793 used should be backwardly compatible, and forward compatible where 794 changes are made. 796 Where possible, any requirement for changes to hosts and routers 797 should be minimised. 799 3.4.2. Dual-stack Operation 801 The homenet architecture targets both IPv6-only and dual-stack 802 networks. While the CER requirements in RFC 6204 and RFC 6204-bis 803 are aimed at IPv6-only networks, it is likely that dual-stack 804 homenets will be the norm for some period of time. IPv6-only 805 networking may first be deployed in "greenfield" homenet scenarios, 806 or perhaps as one element of an otherwise dual-stack network. The 807 homenet architecture must operate in the absence of IPv4. It is 808 desirable that IPv6 works better than IPv4 in as many scenarios as 809 possible. 811 Running IPv6-only may require documentation of additional 812 considerations such as: 814 o Ensuring there is a way to access content in the IPv4 Internet. 815 This can be arranged through incorporating NAT64 [RFC6144] and 816 DNS64 [RFC6145] functionality in the home gateway router, for 817 instance. Such features are outside the scope of this document 818 however, being CER functions. 820 o DNS discovery mechanisms are enabled for IPv6. Both stateless 821 DHCPv6 [RFC3736] [RFC3646] and Router Advertisement options 822 [RFC6106] may have to be supported and turned on by default to 823 ensure maximum compatibility with all types of hosts in the 824 network. This requires, however, that a working DNS server is 825 known and addressable via IPv6, and that such discovery options 826 can operate through multiple routers in the homenet. 828 o All nodes in the home network support operations in IPv6-only 829 mode. Some current devices work well with dual-stack but fail to 830 recognise connectivity when IPv4 DHCP fails, for instance. 832 In dual-stack networks, solutions for IPv6 should not adversely 833 affect IPv4 operation. It is desirable that topologies of IPv4 and 834 IPv6 networks would be as congruent as possible. 836 3.4.3. Largest Possible Subnets 838 Today's IPv4 home networks generally have a single subnet, and early 839 dual-stack deployments have a single congruent IPv6 subnet, possibly 840 with some bridging functionality. More recently, some vendors have 841 started to introduce "home" and "guest" functions, which in IPv6 842 would be implemented as two subnets. 844 Future home networks are highly likely to have one or more internal 845 routers and thus need multiple subnets, for the reasons described 846 earlier. As part of the self-organisation of the network, the 847 homenet should subdivide itself to the largest possible subnets that 848 can be constructed within the constraints of link layer mechanisms, 849 bridging, physical connectivity, and policy. 851 While it may be desirable to maximise the chance of link-local 852 protocols operating across a homenet by maximising the size of a 853 subnet, multi-subnet home networks are inevitable, so their support 854 must be included. A general recommendation is to follow the same 855 topology for IPv6 as is used for IPv4, but not to use NAT. Thus 856 there should be routed IPv6 where an IPv4 NAT is used, and where 857 there is no NAT there should be bridging if the link layer allows 858 this. 860 In some cases IPv4 NAT home networks may feature cascaded NATs, which 861 may include cases where NAT routers are included within VMs or 862 Internet connection sharing services are used. IPv6 routed versions 863 of such cases will be required. We should thus note that routers in 864 the homenet may not be separate physical devices; they may be 865 embedded within devices. 867 3.4.4. Security vs Transparent, End-to-End Communications 869 An IPv6-based home network architecture should embrace and naturally 870 offer a transparent end-to-end communications model as described in 872 [RFC2775]. Each device should be addressable by a globally unique 873 address, and those addresses must not be altered in transit. 874 Security perimeters can (via policy) restrict end-to-end 875 communications, and thus while a host may be globally addressable it 876 may not be globally reachable. 878 In IPv4 NAT networks, the NAT provides an implicit firewall function. 879 [RFC4864] describes a "Simple Security" model for IPv6 networks, 880 whereby stateful perimeter filtering can be applied instead where 881 global addresses are used. RFC 4864 implies an IPv6 "default deny" 882 policy for inbound connections be used for similar functionality to 883 IPv4 NAT. It should be noted that such a "default deny" approach 884 would effectively replace the need for IPv4 NAT traversal protocols 885 with a need to use a signalling protocol to request a firewall hole 886 be opened. Thus to support applications wanting to accept 887 connections initiated into home networks where a "default deny" 888 policy is in place support for a signalling protocol such as UPnP or 889 PCP [I-D.ietf-pcp-base] is required. In networks with multiple CERs, 890 the signalling would need to handle the cases of flows that may use 891 one or more exit routers. CERs would need to be able to advertise 892 their existence for such protocols. 894 [RFC6092] expands on RFC 4864, giving a more detailed discussion of 895 IPv6 perimeter security recommendations, without mandating a "default 896 deny" approach. Indeed, RFC 6092 does not proscribe a particular 897 mode of operation, instead stating that CERs must provide an easily 898 selected configuration option that permits a "transparent" mode of 899 operation, thus ensuring a "default allow" model is available. The 900 homenet architecture text makes no recommendation on the default 901 setting, and refers the reader to RFC 6092, which in turn simply 902 states that a CER should provide functionality sufficient to support 903 the recommendations in that RFC. 905 In terms of the devices, homenet hosts should implement their own 906 security policies in accordance to their computing capabilities. 907 They should have the means to request transparent communications to 908 be initiated to them, either for all ports or for specific services. 909 Users should have simple methods to associate devices to services 910 that they wish to operate transparently through (CER) borders. 912 3.4.5. Internal IP Connectivity 914 A logical consequence of the end-to-end communications model is that 915 the network should by default attempt to provide IP-layer 916 connectivity between all internal parts of the homenet as well as to 917 and from the external Internet. 919 ULAs should be used within the scope of a homenet to support routing 920 between subnets regardless of whether a globally unique ISP-provided 921 prefix is available. However, it would be expected that ULAs would 922 also be used alongside one or more such global prefixes in a homenet, 923 such that hosts become multi-addressed with both globally unique and 924 ULA prefixes. Default address selection would then enable ULAs to be 925 preferred for internal communications between devices that are using 926 ULA prefixes generated within the same homenet. 928 ULAs may be used for all devices, not just those intended to only 929 have internal connectivity. ULAs used in this way provide stable 930 internal communications should the ISP-provided prefix (suddenly) 931 change, or external connectivity be temporarily lost. The use of 932 ULAs should be restricted to the homenet scope through filtering at 933 the border(s) of the homenet, as described in RFC 6092; thus "end-to- 934 end" for ULAs is limited to the homenet. 936 In some cases full internal connectivity may not be desirable, e.g. 937 in certain utility networking scenarios, or where filtering is 938 required for policy reasons against guest network subnet(s). Some 939 scenarios/models may involve isolated subnet(s) with their own CERs. 940 In such cases connectivity would only be expected within each 941 isolated network (though traffic may potentially pass between them 942 via external providers). 944 LLNs provide an example of where there may be secure perimeters 945 inside the homenet. Constrained LLN nodes may implement WPA2-style 946 network key security but may depend on access policies enforced by 947 the LLN border router. 949 3.4.6. Routing functionality 951 Routing functionality is required when there are multiple routers 952 deployed within the internal home network. This functionality could 953 be as simple as the current "default route is up" model of IPv4 NAT, 954 or, more likely, it would involve running an appropriate routing 955 protocol. 957 The homenet routing protocol should preferably be an existing 958 deployed protocol that has been shown to be reliable and robust, and 959 it is preferable that the protocol is "lightweight". It is desirable 960 that the routing protocol has knowledge of the homenet topology, 961 which implies a link-state protocol is preferable. If so, it is also 962 desirable that the announcements and use of LSAs and RAs are 963 appropriately coordinated. This would mean the routing protocol 964 gives a consistent view of the network, and that it can pass around 965 more than just routing information. 967 Multiple interface PHYs must be accounted for in the homenet routed 968 topology. Technologies such as Ethernet, WiFi, MoCA, etc must be 969 capable of coexisting in the same environment and should be treated 970 as part of any routed deployment. The inclusion of the PHY layer 971 characteristics including bandwidth, loss, and latency in path 972 computation should be considered for optimising communication in the 973 homenet. Multiple upstreams should be supported, as described in the 974 multihoming section earlier. This should include load-balancing to 975 multiple providers, and failover from a primary to a backup link when 976 available. The protocol however should not require upstream ISP 977 connectivity to be established to continue routing within the 978 homenet. 980 To support multihoming within a homenet, a routing protocol that can 981 make routing decisions based on source and destination addresses is 982 desirable, to avoid upstream ISP ingress filtering problems. In 983 general the routing protocol should support multiple ISP uplinks and 984 delegated prefixes in concurrent use. 986 The routing environment should be self-configuring, as discussed in 987 the next subsection. An example of how OSPFv3 can be self- 988 configuring in a homenet is described in 989 [I-D.acee-ospf-ospfv3-autoconfig]. Minimising convergence time 990 should be a goal in any routed environment, but as a guideline a 991 maximum convergence time of around 30 seconds should be the target. 993 Any routed solution will require a means for determining the 994 boundaries of the homenet. Borders may include but are not limited 995 to the interface to the upstream ISP, or a gateway device to a 996 separate home network such as a SmartGrid or similar LLN network. In 997 some cases there may be no border such as occurs before an upstream 998 connection has been established. The border discovery functionality 999 may be integrated into the routing protocol itself, but may also be 1000 imported via a separate discovery mechanism. 1002 In general, LLN or other networks should be able to attach and 1003 participate the same way as the main homenet, or alternatively map/be 1004 gatewayed to the main homenet. Current home deployments use largely 1005 different mechanisms in sensor and basic Internet connectivity 1006 networks. IPv6 VM solutions may also add additional routing 1007 requirements. 1009 [I-D.howard-homenet-routing-comparison] contains evaluations of 1010 common routing protocols made against the type of requirements 1011 described above. 1013 3.4.7. A Self-organising Network 1015 A home network architecture should be naturally self-organising and 1016 self-configuring under different circumstances relating to the 1017 connectivity status to the Internet, number of devices, and physical 1018 topology. While the homenet should be self-organising, it should be 1019 possible to manually adjust (override) the current configuration. 1021 The homenet will need to be aware of the extent of its own "site", as 1022 discussed in the previous section. The homenet "site" defines the 1023 borders for ULAs, site scope multicast, service discovery and 1024 security policies. The homenet will thus have one or more borders 1025 with external connectivity providers and potentially also have 1026 borders within the internal network (e.g. for policy-based reasons). 1027 It should be possible to automatically perform border discovery for 1028 the different borders. Such borders determine for example the scope 1029 of where prefixes, routing information, network traffic, service 1030 discovery and naming may be shared. The default internally should be 1031 to share everything. 1033 The most important function in this respect is prefix delegation and 1034 management. There are various sources of prefixes, e.g. they may be 1035 globally unique prefixes originating from ISP(s), they may be 1036 globally unique or ULA prefixes allocated by "master" router(s) in 1037 the homenet, or they may be ULAs allocated by LLN gateways. There 1038 may also be a prefix associated with NAT64, if in use in the homenet. 1040 From the homenet perspective, a single prefix from each ISP should be 1041 received on the border CER [RFC3633]. Then each subnet in the 1042 homenet should receive a prefix from within the ISP-provided 1043 prefix(es). The ISP should only see the aggregate from the homenet, 1044 and not single /64 prefixes allocated within the homenet. 1046 Delegation should be autonomous, and not assume a flat or 1047 hierarchical model. This text makes no assumption about whether the 1048 delegation of prefixes is distributed or centralised. The assignment 1049 mechanism should provide reasonable efficiency, so that typical home 1050 network prefix allocation sizes can accommodate all the necessary /64 1051 allocations in most cases, and not waste prefixes. A currently 1052 typical /60 allocation gives 16 /64 subnets. Duplicate assignment of 1053 multiple /64s to the same network should be avoided. The network 1054 should behave as gracefully as possible in the event of prefix 1055 exhaustion, though the options in such cases may be limited. 1057 Where multiple CERs exist with multiple ISP prefix pools, it is 1058 expected that routers within the homenet would assign themselves 1059 prefixes from each ISP they communicate with/through. 1061 Where ULAs are used, most likely but not necessarily in parallel with 1062 global prefixes, one router should be elected to offer ULA prefixes 1063 for the homenet. The router should generate a /48 ULA for the site, 1064 and then delegate /64's from that ULA prefix to subnets. In the 1065 normal state, a single /48 ULA should be used within the homenet. In 1066 cases where two /48 ULAs are generated within a homenet, the network 1067 should still continue to function. 1069 Delegation within the homenet should give each link a prefix that is 1070 persistent across reboots, power outages and similar short-term 1071 outages. Addition of a new routing device should not affect existing 1072 persistent prefixes, but persistence may not be expected in the face 1073 of significant "replumbing" of the homenet. Persistent prefixes 1074 should not depend on router boot order. Such persistent prefixes may 1075 imply the need for stable storage on routing devices, and also a 1076 method for a home user to "reset" the stored prefix should a 1077 significant reconfiguration be required (though ideally the home user 1078 should not be involved at all). 1080 The delegation method should support renumbering, which would 1081 typically be "flash" renumbering in that the homenet would not have 1082 advance notice of the event or thus be able to apply the types of 1083 approach described in [RFC4192]. As a minimum, delegated ULA 1084 prefixes within the homenet should remain persistent through an ISP- 1085 driven renumbering event. 1087 Several proposals have been made for prefix delegation within a 1088 homenet. One group of proposals is based on DHCPv6 PD, as described 1089 in [I-D.baker-homenet-prefix-assignment], 1090 [I-D.chakrabarti-homenet-prefix-alloc], [RFC3315] and [RFC3633]. The 1091 other uses OSPFv3, as described in 1092 [I-D.arkko-homenet-prefix-assignment]. More detailed analysis of 1093 these approaches needs to be made against the requirements/principles 1094 described above. 1096 Other parameters of the network will need to be self-organising, but 1097 allow manual override of configurations where reasonable to do so. 1098 The network elements will need to be integrated in a way that takes 1099 account of the various lifetimes on timers that are used on those 1100 different elements, e.g. DHCPv6 PD, router, valid prefix and 1101 preferred prefix timers. 1103 The network cannot be expected to be completely self-organising, e.g. 1104 some security parameters are likely to need manual configuration, 1105 e.g. WPA2 configuration for wireless access control. Some existing 1106 mechanisms exist to assist home users to associate devices as simply 1107 as possible, e.g. "connect" button support. 1109 It is important that self-configuration with "unintended" devices is 1110 avoided. Methods are needed for devices to know whether they are 1111 intended to be part of the same homenet site or not. Thus methods to 1112 ensure separation between neighbouring homenets are required. This 1113 may require use of some unique "secret" for devices/protocols in each 1114 homenet. 1116 3.4.8. Fewest Topology Assumptions 1118 There should ideally be no built-in assumptions about the topology in 1119 home networks, as users are capable of connecting their devices in 1120 "ingenious" ways. Thus arbitrary topologies and arbitrary routing 1121 will need to be supported. or at least the failure mode for when the 1122 user makes a mistake should be as robust as possible, e.g. de- 1123 activating a certain part of the infrastructure to allow the rest to 1124 operate. In such cases, the user should ideally have some useful 1125 indication of the failure mode encountered. 1127 It is important not to introduce new IPv6 scenarios that would break 1128 with IPv4+NAT, given that dual-stack homenets will be commonplace for 1129 some time. There may be IPv6-only topologies that work where IPv4 is 1130 not used or required. 1132 3.4.9. Naming and Service Discovery 1134 Naming and service discovery must be supported in the homenet. The 1135 most natural way to think about such naming and service discovery is 1136 to enable it to work across the entire residence (site), disregarding 1137 technical borders such as subnets but potentially respecting policy 1138 borders such as those between visitor and internal networks. 1139 Discovery of a DNS service for access to external Internet resources 1140 is also a fundamental requirement in a multi-subnet homenet; the 1141 problem is not just name and service discovery within the homent 1142 itself. 1144 Users will need simple ways to name devices, or be provided with 1145 appropriate ways for devices to generate unique names within the 1146 homenet. The naming system will be required to work internally or 1147 externally, be the user within the homenet or outside it, and there 1148 may be multiple naming domains, e.g. Internet, home or guest 1149 domains. It is highly likely that a home user will want access to 1150 many of the devices and services in their home while "roaming" 1151 elsewhere. It may be the case that not all devices in the homenet 1152 are made available by name via any Internet-facing domain, and that a 1153 "split-view" naming system is preferred for certain devices. Also, 1154 name resolution for reachable devices must continue to function if 1155 the local network is disconnected from the global Internet. 1157 A desirable target may be a fully functional, self-configuring secure 1158 local DNS service so that all devices can be referred to by name, and 1159 these FQDNs are resolved locally. This could make clean use of ULAs 1160 and multiple ISP-provided prefixes much easier. Such a local DNS 1161 service should be (by default) authoritative for the local name space 1162 in both IPv4 and IPv6. A dual-stack residential gateway should 1163 include a dual-stack DNS server. 1165 There are naming protocols that are designed to be configured and 1166 operate Internet-wide, like unicast-based DNS, but also protocols 1167 that are designed for zero-configuration environments, like mDNS. 1168 Consideration should be made for how these interact with each other 1169 in a homenet scenario. 1171 With the introduction of new "dotless" top level domains, there is 1172 potential for ambiguity between for example a local host called 1173 "computer" and (if it is registered) a .computer gTLD. This suggests 1174 some implicit local name space is probably required. Such a name 1175 space should also be configurable to something else by the user. 1177 The use of standard local domain name across adjacent homenets 1178 potentially introduces some ambiguity if, for example, a mobile 1179 device should move between two such networks. 1181 Current service discovery protocols are generally aimed at single 1182 subnets. If service discovery is to operate across the an entire 1183 homenet, by adopting an approach like that proposed as Extended mDNS 1184 (xmDNS) [I-D.lynn-homenet-site-mdns], then support may be required 1185 for IPv6 multicast across the scope of the whole homenet. 1187 In some parts of the homenet, e.g. LLNs, devices may be sleeping, in 1188 which case a proxy for such nodes may be required, that can respond 1189 to multicast service discovery requests. Those same parts of the 1190 network may have less capacity for multicast traffic that may be 1191 flooded from other parts of the network. In general, message 1192 utilisation should be efficient considering the network technologies 1193 the service may need to operate over. 1195 3.4.10. Proxy or Extend? 1197 There are two broad choices for allowing services that would 1198 otherwise be link-local to work across a homenet site. In the 1199 example of service discovery, one is to take protocols like mDNS and 1200 have them run over site multicast within the homenet. This is fine 1201 if all hosts support the extension, and the scope within any internal 1202 borders is well-understood. But it's not backwards-compatible with 1203 existing link-local protocols. The alternative is to proxy service 1204 discovery across each link, to propagate it. This is more complex, 1205 but is backwards-compatible. It would need to work with IPv6, and 1206 dual-stack. 1208 The homenet architecture proposes that any existing protocols that 1209 are designed to only work within a subnet should be extended to work 1210 across subnets, rather than defining proxy capabilities for each of 1211 those functions. However, while it is desirable to extend protocols 1212 to site scope operation rather than providing proxy functions on 1213 subnet boundaries, the reality is that until all hosts can use site- 1214 scope discovery protocols, existing link-local protocols would need 1215 to be proxied anyway. 1217 Some protocols already have proxy functions defined and in use, e.g. 1218 DHCPv6 relays, in which case those protocols would be expected to 1219 continue to operate that way. 1221 3.4.11. Adapt to ISP constraints 1223 Different homenets may be subject to different behaviour by their 1224 ISP(s). A homenet may receive an arbitrary length IPv6 prefix from 1225 its provider, e.g. /60, /56 or /48. The offered prefix, may be 1226 stable or change from time to time. Some ISPs may offer relatively 1227 stable prefixes, while others may change the prefix whenever the CER 1228 is reset. Some discussion of IPv6 prefix allocation policies is 1229 included in [RFC6177], which discusses why, for example, a one-size- 1230 fits-all /48 allocation is not desirable. The home network needs to 1231 be adaptable to such ISP policies, and thus make no assumptions about 1232 the stability of the prefix received from an ISP, or the length of 1233 the prefix that may be offered. However, if only a /64 is offered by 1234 the ISP, the homenet may be severely constrained, or even unable to 1235 function. 1237 The internal operation of the home network should also not depend on 1238 the availability of the ISP network at any given time, other than for 1239 connectivity to services or systems off the home network. This 1240 implies the use of ULAs as supported in RFC 6204. If used, ULA 1241 addresses should be stable so that they can always be used 1242 internally, independent of the link to the ISP. 1244 In practice, it is expected that ISPs will deliver a relatively 1245 stable home prefix to customers. The norm for residential customers 1246 of large ISPs may be similar to their single IPv4 address provision; 1247 by default it is likely to remain persistent for some time, but 1248 changes in the ISP's own provisioning systems may lead to the 1249 customer's IP (and in the IPv6 case their prefix pool) changing. It 1250 is not expected that ISPs will support Provider Independent (PI) 1251 addressing in general residential homenets. 1253 When an ISP needs to restructure and in doing so renumber its 1254 customer homenets, "flash" renumbering is likely to be imposed. This 1255 implies a need for the homenet to be able to handle a sudden 1256 renumbering event which, unlike the process described in [RFC4192], 1257 would be a "flag day" event, which means that a graceful renumbering 1258 process moving through a state with two active prefixes in use would 1259 not be possible. While renumbering is an extended version of an 1260 initial numbering process, the difference between flash renumbering 1261 and an initial "cold start" is the need to provide service 1262 continuity. 1264 There may be cases where local law means some ISPs are required to 1265 change IPv6 prefixes (current IPv4 addresses) for privacy reasons for 1266 their customers. In such cases it may be possible to avoid an 1267 instant "flash" renumbering and plan a non-flag day renumbering as 1268 per RFC 4192. 1270 The customer may of course also choose to move to a new ISP, and thus 1271 begin using a new prefix. In such cases the customer should expect a 1272 discontinuity. In such cases, not only may the prefix change, but 1273 potentially the prefix length, if the new ISP offers a different 1274 default size prefix, e.g. a /60 rather than a /56. Regardless, it's 1275 desirable that homenet protocols support rapid renumbering and that 1276 operational processes don't add unnecessary complexity for the 1277 renumbering process. 1279 The 6renum WG is studying IPv6 renumbering for enterprise networks. 1280 It is not currently targetting homenets, but may produce outputs that 1281 are relevant. The introduction of any new homenet protocols should 1282 not make any form of renumbering any more complex than it already is. 1284 3.5. Implementing the Architecture on IPv6 1286 This architecture text encourages re-use of existing protocols. Thus 1287 the necessary mechanisms are largely already part of the IPv6 1288 protocol set and common implementations. There are though some 1289 exceptions. For automatic routing, it is expected that existing 1290 routing protocols can be used as is. However, a new mechanism may be 1291 needed in order to turn a selected protocol on by default. 1293 Some functionality, if required by the architecture, would add 1294 significant changes or require development of new protocols, e.g. 1295 support for multihoming with multiple exit routers would likely 1296 require extensions to support source and destination address based 1297 routing within the homenet. 1299 Some protocol changes are however required in the architecture, e.g. 1300 for name resolution and service discovery, extensions to existing 1301 multicast-based name resolution protocols are needed to enable them 1302 to work across subnets, within the scope of the home network site. 1304 Some of the hardest problems in developing solutions for home 1305 networking IPv6 architectures include discovering the right borders 1306 where the domain "home" ends and the service provider domain begins, 1307 deciding whether some of the necessary discovery mechanism extensions 1308 should affect only the network infrastructure or also hosts, and the 1309 ability to turn on routing, prefix delegation and other functions in 1310 a backwards compatible manner. 1312 4. Conclusions 1314 This text defines principles and requirements for a homenet 1315 architecture. The principles and requirements documented here should 1316 be observed by any future texts describing homenet protocols for 1317 routing, prefix management, security, naming or service discovery. 1319 5. References 1321 5.1. Normative References 1323 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1324 (IPv6) Specification", RFC 2460, December 1998. 1326 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1327 and M. Carney, "Dynamic Host Configuration Protocol for 1328 IPv6 (DHCPv6)", RFC 3315, July 2003. 1330 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1331 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1332 December 2003. 1334 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1335 (DHCP) Service for IPv6", RFC 3736, April 2004. 1337 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1338 Addresses", RFC 4193, October 2005. 1340 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1341 Architecture", RFC 4291, February 2006. 1343 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1344 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1345 May 2007. 1347 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1348 Extensions for Stateless Address Autoconfiguration in 1349 IPv6", RFC 4941, September 2007. 1351 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1352 Customer Premises Equipment (CPE) for Providing 1353 Residential IPv6 Internet Service", RFC 6092, 1354 January 2011. 1356 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1357 Troan, "Basic Requirements for IPv6 Customer Edge 1358 Routers", RFC 6204, April 2011. 1360 [I-D.ietf-v6ops-6204bis] 1361 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1362 Requirements for IPv6 Customer Edge Routers", 1363 draft-ietf-v6ops-6204bis-09 (work in progress), May 2012. 1365 5.2. Informative References 1367 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1368 E. Lear, "Address Allocation for Private Internets", 1369 BCP 5, RFC 1918, February 1996. 1371 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1372 and W. Weiss, "An Architecture for Differentiated 1373 Services", RFC 2475, December 1998. 1375 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1376 February 2000. 1378 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1379 Address Translator (Traditional NAT)", RFC 3022, 1380 January 2001. 1382 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1383 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1384 December 2003. 1386 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1387 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1388 September 2005. 1390 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1391 Shim Protocol for IPv6", RFC 5533, June 2009. 1393 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1394 Infrastructures (6rd) -- Protocol Specification", 1395 RFC 5969, August 2010. 1397 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1398 "IPv6 Router Advertisement Options for DNS Configuration", 1399 RFC 6106, November 2010. 1401 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1402 IPv4/IPv6 Translation", RFC 6144, April 2011. 1404 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1405 Algorithm", RFC 6145, April 2011. 1407 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1408 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 1410 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1411 Translation", RFC 6296, June 2011. 1413 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1414 Stack Lite Broadband Deployments Following IPv4 1415 Exhaustion", RFC 6333, August 2011. 1417 [I-D.baker-fun-multi-router] 1418 Baker, F., "Exploring the multi-router SOHO network", 1419 draft-baker-fun-multi-router-00 (work in progress), 1420 July 2011. 1422 [I-D.lynn-homenet-site-mdns] 1423 Lynn, K. and D. Sturek, "Extended Multicast DNS", 1424 draft-lynn-homenet-site-mdns-00 (work in progress), 1425 March 2012. 1427 [I-D.townsley-troan-ipv6-ce-transitioning] 1428 Townsley, M. and O. Troan, "Basic Requirements for 1429 Customer Edge Routers - multihoming and transition", 1430 draft-townsley-troan-ipv6-ce-transitioning-02 (work in 1431 progress), December 2011. 1433 [I-D.baker-fun-routing-class] 1434 Baker, F., "Routing a Traffic Class", 1435 draft-baker-fun-routing-class-00 (work in progress), 1436 July 2011. 1438 [I-D.howard-homenet-routing-comparison] 1439 Howard, L., "Evaluation of Proposed Homenet Routing 1440 Solutions", draft-howard-homenet-routing-comparison-00 1441 (work in progress), December 2011. 1443 [I-D.herbst-v6ops-cpeenhancements] 1444 Herbst, T. and D. Sturek, "CPE Considerations in IPv6 1445 Deployments", draft-herbst-v6ops-cpeenhancements-00 (work 1446 in progress), October 2010. 1448 [I-D.vyncke-advanced-ipv6-security] 1449 Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced 1450 Security for IPv6 CPE", 1451 draft-vyncke-advanced-ipv6-security-03 (work in progress), 1452 October 2011. 1454 [I-D.ietf-6man-rfc3484bis] 1455 Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 1456 "Default Address Selection for Internet Protocol version 6 1457 (IPv6)", draft-ietf-6man-rfc3484bis-06 (work in progress), 1458 June 2012. 1460 [I-D.v6ops-multihoming-without-ipv6nat] 1461 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 1462 Wing, "IPv6 Multihoming without Network Address 1463 Translation", draft-v6ops-multihoming-without-ipv6nat-00 1464 (work in progress), March 2011. 1466 [I-D.baker-homenet-prefix-assignment] 1467 Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small 1468 Networks", draft-baker-homenet-prefix-assignment-01 (work 1469 in progress), March 2012. 1471 [I-D.arkko-homenet-prefix-assignment] 1472 Arkko, J. and A. Lindem, "Prefix Assignment in a Home 1473 Network", draft-arkko-homenet-prefix-assignment-01 (work 1474 in progress), October 2011. 1476 [I-D.acee-ospf-ospfv3-autoconfig] 1477 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 1478 draft-acee-ospf-ospfv3-autoconfig-02 (work in progress), 1479 May 2012. 1481 [I-D.ietf-pcp-base] 1482 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1483 Selkirk, "Port Control Protocol (PCP)", 1484 draft-ietf-pcp-base-26 (work in progress), June 2012. 1486 [I-D.hain-ipv6-ulac] 1487 Hain, T., Hinden, R., and G. Huston, "Centrally Assigned 1488 IPv6 Unicast Unique Local Address Prefixes", 1489 draft-hain-ipv6-ulac-02 (work in progress), July 2010. 1491 [I-D.ietf-v6ops-happy-eyeballs] 1492 Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1493 Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-07 1494 (work in progress), December 2011. 1496 [I-D.chakrabarti-homenet-prefix-alloc] 1497 Nordmark, E., Chakrabarti, S., Krishnan, S., and W. 1498 Haddad, "Simple Approach to Prefix Distribution in Basic 1499 Home Networks", draft-chakrabarti-homenet-prefix-alloc-01 1500 (work in progress), October 2011. 1502 [I-D.arkko-homenet-physical-standard] 1503 Arkko, J. and A. Keranen, "Minimum Requirements for 1504 Physical Layout of Home Networks", 1505 draft-arkko-homenet-physical-standard-00 (work in 1506 progress), March 2012. 1508 [Gettys11] 1509 Gettys, J., "Bufferbloat: Dark Buffers in the Internet", 1510 March 2011, 1511 . 1513 [IGD-2] UPnP Gateway Committee, "Internet Gateway Device (IGD) V 1514 2.0", September 2010, . 1517 Appendix A. Acknowledgments 1519 The authors would like to thank Aamer Akhter, Mark Andrews, Dmitry 1520 Anipko, Fred Baker, Ray Bellis, Cameron Byrne, Brian Carpenter, 1521 Stuart Cheshire, Lorenzo Colitti, Robert Cragie, Ralph Droms, Lars 1522 Eggert, Jim Gettys, Wassim Haddad, Joel M. Halpern, David Harrington, 1523 Lee Howard, Ray Hunter, Joel Jaeggli, Heather Kirksey, Ted Lemon, 1524 Kerry Lynn, Erik Nordmark, Michael Richardson, Barbara Stark, Sander 1525 Steffann, Dave Thaler, JP Vasseur, Curtis Villamizar, Dan Wing, Russ 1526 White, and James Woodyatt for their contributions within homenet WG 1527 meetings and the mailing list, and Mark Townsley for being an initial 1528 editor/author of this text before taking his position as homenet WG 1529 co-chair. 1531 Appendix B. Changes 1533 This section will be removed in the final version of the text. 1535 B.1. Version 03 1537 Changes made include: 1539 o Various improvements to the readability. 1541 o Removed bullet lists of requirements, as requested by chair. 1543 o Noted 6204bis has replaced advanced-cpe draft. 1545 o Clarified the topology examples are just that. 1547 o Emphasised we are not targetting walled gardens, but they should 1548 not be precluded. 1550 o Also changed text about requiring support for walled gardens. 1552 o Noted that avoiding falling foul of ingress filtering when 1553 multihomed is desirable. 1555 o Improved text about realms, detecting borders and policies at 1556 borders. 1558 o Stated this text makes no recommendation about default security 1559 model. 1561 o Added some text about failure modes for users plugging things 1562 arbitrarily. 1564 o Expanded naming and service discovery text. 1566 o Added more text about ULAs. 1568 o Removed reference to version 1 on chair feedback. 1570 o Stated that NPTv6 adds architectural cost but is not a homenet 1571 matter if deployed at the CER. This text only considers the 1572 internal homenet. 1574 o Noted multihoming is supported. 1576 o Noted routers may not by separate devices, they may be embedded in 1577 devices. 1579 o Clarified simple and advanced security some more, and RFC 4864 and 1580 6092. 1582 o Stated that there should be just one secret key, if any are used 1583 at all. 1585 o For multihoming, support multiple CERs but note that routing to 1586 the correct CER to avoid ISP filtering may not be optimal within 1587 the homenet. 1589 o Added some ISPs renumber due to privacy laws. 1591 o Removed extra repeated references to Simple Security. 1593 o Removed some solution creep on RIOs/RAs. 1595 o Load-balancing scenario added as to be supported. 1597 B.2. Version 02 1599 Changes made include: 1601 o Made the IPv6 implications section briefer. 1603 o Changed Network Models section to describe properties of the 1604 homenet with illustrative examples, rather than implying the 1605 number of models was fixed to the six shown in 01. 1607 o Text to state multihoming support focused on single CER model. 1608 Multiple CER support is desirable, but not required. 1610 o Stated that NPTv6 not supported. 1612 o Added considerations section for operations and management. 1614 o Added bullet point principles/requirements to Section 3.4. 1616 o Changed IPv6 solutions must not adversely affect IPv4 to should 1617 not. 1619 o End-to-end section expanded to talk about "Simple Security" and 1620 borders. 1622 o Extended text on naming and service discovery. 1624 o Added reference to RFC 2775, RFC 6177. 1626 o Added reference to the new xmDNS draft. 1628 o Added naming/SD requirements from Ralph Droms. 1630 Authors' Addresses 1632 Tim Chown (editor) 1633 University of Southampton 1634 Highfield 1635 Southampton, Hampshire SO17 1BJ 1636 United Kingdom 1638 Email: tjc@ecs.soton.ac.uk 1640 Jari Arkko 1641 Ericsson 1642 Jorvas 02420 1643 Finland 1645 Email: jari.arkko@piuha.net 1647 Anders Brandt 1648 Sigma Designs 1649 Emdrupvej 26A, 1 1650 Copenhagen DK-2100 1651 Denmark 1653 Email: abr@sdesigns.dk 1655 Ole Troan 1656 Cisco Systems, Inc. 1657 Drammensveien 145A 1658 Oslo N-0212 1659 Norway 1661 Email: ot@cisco.com 1663 Jason Weil 1664 Time Warner Cable 1665 13820 Sunrise Valley Drive 1666 Herndon, VA 20171 1667 USA 1669 Email: jason.weil@twcable.com