idnits 2.17.1 draft-ietf-homenet-arch-02.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 (March 12, 2012) is 4427 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 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- 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 (-06) exists of draft-ietf-6man-rfc3484bis-01 == 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-01 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-23 Summary: 7 errors (**), 0 flaws (~~), 6 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: September 13, 2012 Ericsson 6 A. Brandt 7 Sigma Designs 8 O. Troan 9 Cisco Systems, Inc. 10 J. Weil 11 Time Warner Cable 12 March 12, 2012 14 Home Networking Architecture for IPv6 15 draft-ietf-homenet-arch-02 17 Abstract 19 This text describes evolving networking technology within small 20 residential home networks. The goal of this memo is to define the 21 architecture for IPv6-based home networking and the associated 22 principles, considerations and requirements. The text briefly 23 highlights the implications of the introduction of IPv6 for home 24 networking, discusses topology scenarios, and suggests how standard 25 IPv6 mechanisms and addressing can be employed in home networking. 26 The architecture describes the need for specific protocol extensions 27 for certain additional functionality. It is assumed that the IPv6 28 home network is not actively managed, and runs as an IPv6-only or 29 dual-stack network. There are no recommendations in this text for 30 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 September 13, 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 . . . . . . . . . . . . . . . 5 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) . . . . . . . . . . . . . . 7 73 2.5. Security and borders . . . . . . . . . . . . . . . . . . . 8 74 2.6. Naming, and manual configuration of IP addresses . . . . . 8 75 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.1. Network Models . . . . . . . . . . . . . . . . . . . . . . 9 77 3.1.1. A: Single ISP, Single CER, Internal routers . . . . . 10 78 3.1.2. B: Two ISPs, Two CERs, Shared subnet . . . . . . . . . 12 79 3.1.3. C: Two ISPs, One CER, Shared subnet . . . . . . . . . 13 80 3.2. Determining the Requirements . . . . . . . . . . . . . . . 13 81 3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 14 82 3.3.1. Multihoming . . . . . . . . . . . . . . . . . . . . . 14 83 3.3.2. Quality of Service . . . . . . . . . . . . . . . . . . 16 84 3.3.3. Operations and Management . . . . . . . . . . . . . . 16 85 3.3.4. Privacy considerations . . . . . . . . . . . . . . . . 16 86 3.4. Design Principles and Requirements . . . . . . . . . . . . 17 87 3.4.1. Reuse existing protocols . . . . . . . . . . . . . . . 17 88 3.4.2. Dual-stack Operation . . . . . . . . . . . . . . . . . 18 89 3.4.3. Largest Possible Subnets . . . . . . . . . . . . . . . 19 90 3.4.4. Security vs Transparent, End-to-End Communications . . 19 91 3.4.5. IP Connectivity between All Nodes . . . . . . . . . . 20 92 3.4.6. Routing functionality . . . . . . . . . . . . . . . . 21 93 3.4.7. Self-Organising . . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . 27 98 3.5. Implementing the Architecture on IPv6 . . . . . . . . . . 29 99 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 29 100 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 101 5.1. Normative References . . . . . . . . . . . . . . . . . . . 29 102 5.2. Informative References . . . . . . . . . . . . . . . . . . 31 103 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 34 104 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 34 105 B.1. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 34 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 108 1. Introduction 110 This document focuses on evolving networking technology within small 111 residential home networks and the associated challenges. There is a 112 growing trend in home networking for the proliferation of networking 113 technology in an increasingly broad range of devices and media. This 114 evolution in scale and diversity sets requirements on IETF protocols. 115 Some of these requirements relate to the introduction of IPv6, others 116 to the introduction of specialised networks for home automation and 117 sensors. There are also likely to be scenarios where internal 118 routing is required, for example to support private and guest 119 networks, in which case home networks will use multiple subnets. 121 While some advanced home networks exist, most operate based on IPv4, 122 employ solutions that we would like to avoid such as (cascaded) 123 network address translation (NAT), or require expert assistance to 124 set up. The assumption of this document is that the homenet is as 125 far as possible self-organising and self-configuring, and is thus not 126 pro-actively managed by the residential user. The architectural 127 constructs in this document are focused on the problems to be solved 128 when introducing IPv6 with an eye towards a better result than what 129 we have today with IPv4, as well as a better result than if the IETF 130 had not given this specific guidance. 132 This architecture document aims to provide the basis and guiding 133 principles for how standard IPv6 mechanisms and addressing [RFC2460] 134 [RFC4291] can be employed in home networking, while coexisting with 135 existing IPv4 mechanisms. In emerging dual-stack home networks it is 136 vital that introducing IPv6 does not adversely affect IPv4 operation. 137 Future deployments, or specific subnets within an otherwise dual- 138 stack home network, may be IPv6-only, in which case considerations 139 for IPv4 impact would not apply. 141 [RFC6204] defines basic requirements for customer edge routers 142 (CERs). The scope of this text is the homenet, and thus the relevant 143 part of RFC 6204 is the internal facing interface as well as any 144 other components within the home network. While the network may be 145 dual-stack or IPv6-only, the definition of specific transition tools 146 on the CER are out of scope of this text, as is any advice regarding 147 architecture of the IPv4 part of the network. We assume that IPv4 148 network architecture in home networks is what it is, and can not be 149 affected by new recommendations. 151 This architecture document proposes a baseline homenet architecture, 152 based on protocols and implementations that are as far as possible 153 proven and robust, and as such is a "version 1" architecture. A 154 future architecture may incorporate more advanced elements at a later 155 date. 157 1.1. Terminology and Abbreviations 159 In this section we define terminology and abbreviations used 160 throughout the text. 162 o CER: Customer Edge Router. The border router at the edge of the 163 homenet. 165 o LLN: Low-power and lossy network. 167 o NAT: Network Address Translation. Typically referring to Network 168 Address and Port Translation (NAPT) [RFC3022]. 170 o NPTv6: Network Prefix Translation for IPv6 [RFC6296]. 172 o PCP: Port Control Protocol [I-D.ietf-pcp-base]. 174 o ULA: Unique Local Addresses [RFC4193]. 176 o UPnP: Universal Plug and Play. Includes Internet Gateway Device 177 (IGD) function, which for IPv6 is UPnP IGD Version 2 [IGD-2]. 179 o VM: Virtual machine. 181 o WPA: Wi-Fi Protected Access, as defined by the Wi-Fi Alliance. 183 2. Effects of IPv6 on Home Networking 185 Service providers are deploying IPv6, content is becoming available 186 on IPv6, and support for IPv6 is increasingly available in devices 187 and software used in the home. While IPv6 resembles IPv4 in many 188 ways, it changes address allocation principles, makes multi- 189 addressing the norm, and allows direct IP addressability and routing 190 to devices in the home from the Internet. This section presents an 191 overview of some of the key implications of the introduction of IPv6 192 for home networking, that are both promising and problematic. 194 2.1. Multiple subnets and routers 196 While simple layer 3 topologies involving as few subnets as possible 197 are preferred in home networks, the incorporation of dedicated 198 (routed) subnets remains necessary for a variety of reasons. 200 For instance, a common feature in modern home routers is the ability 201 to support both guest and private network subnets. Also, link layer 202 networking technology is poised to become more heterogeneous, as 203 networks begin to employ both traditional Ethernet technology and 204 link layers designed for low-power and lossy networks (LLNs) such as 205 those used for certain types of sensor devices. There may also be a 206 need to separate building control or corporate extensions from the 207 main Internet access network. Also, different subnets may be 208 associated with parts of the homenet that have different routing and 209 security policies. 211 Documents that provide some more specific background and depth on 212 this topic include: [I-D.herbst-v6ops-cpeenhancements], 213 [I-D.baker-fun-multi-router], and [I-D.baker-fun-routing-class]. 215 The addition of routing between subnets raises the issue of how to 216 extend mechanisms such as service discovery which currently rely on 217 link-local addressing to limit scope. There will also be the need to 218 discover which are the border router(s) by an appropriate mechanism. 220 2.2. Global addressability and elimination of NAT 222 Current IPv4 home networks typically receive a single global IPv4 223 address from their ISP and use NAT with private [RFC1918] addresses 224 for devices within the network. An IPv6 home network removes the 225 need to use NAT given the ISP offers a sufficiently large globally 226 unique IPv6 prefix to the homenet, allowing every device on every 227 link to be assigned a globally unique IPv6 address. 229 The end-to-end communication that is potentially enabled with IPv6 is 230 on the one hand an incredible opportunity for innovation and simpler 231 network operation, but it is also a concern as it exposes nodes in 232 the internal networks to receipt of otherwise unwanted traffic from 233 the Internet. 235 In IPv4 NAT networks, the NAT provides an implicit firewall function. 236 [RFC4864] suggests that IPv6 networks with global addresses utilise 237 "Simple Security" in border firewalls to restrict incoming 238 connections through a default deny policy. Applications or hosts 239 wanting to accept inbound connections in networks that are compliant 240 with the architecture presented in this document would then need to 241 signal that desire through a protocol such as UPnP or PCP 242 [I-D.ietf-pcp-base]. In networks with multiple CERs, the signalling 243 would need to handle the cases of flows that may use one or both exit 244 routers. 246 The "Simple Security" default deny approach effectively replaces the 247 need for IPv4 NAT traversal by a need to use a signalling protocol to 248 request a firewall hole be opened. [RFC6092] states that while the 249 default should be default deny, CERs should also have an option to be 250 put into a "transparent" mode of operation which enables a default 251 allow model. 253 It is important to distinguish between addressability and 254 reachability. While IPv6 offers global addressability through use of 255 globally unique addresses in the home, whether they are globally 256 reachable or not would depend on the firewall or filtering 257 configuration, and not presence or use of NAT. 259 2.3. Multi-Addressing of devices 261 In an IPv6 network, devices may acquire multiple addresses, typically 262 at least a link-local address and a globally unique address. They 263 may also have an IPv4 address if the network is dual-stack, a Unique 264 Local Address (ULA) [RFC4193] (see below), and one or more IPv6 265 Privacy Addresses [RFC4941]. 267 Thus it should be considered the norm for devices on IPv6 home 268 networks to be multi-addressed, and to need to make appropriate 269 address selection decisions for the candidate source and destination 270 address pairs. Default Address Selection for IPv6 271 [I-D.ietf-6man-rfc3484bis] provides a solution for this, but may face 272 problems in the event of multihoming, where nodes will be configured 273 with one address from each upstream ISP prefix. In such cases the 274 presence of upstream ingress filtering requires multi-addressed nodes 275 to select the right source address to be used for the corresponding 276 uplink, but the node may not have the information it needs to make 277 that decision based on addresses alone. 279 2.4. Unique Local Addresses (ULAs) 281 [RFC4193] defines Unique Local Addresses (ULAs) for IPv6 that may be 282 used to address devices within the scope of a single site. Support 283 for ULAs for IPv6 CERs is described in [RFC6204]. A home network 284 running IPv6 may deploy ULAs for stable communication between devices 285 (on different subnets) within the network where externally allocated 286 global prefix changes over time (either due to renumbering within the 287 subscriber's ISP or a change of ISP) or where external connectivity 288 is temporarily unavailable. 290 A counter-argument to using ULAs is that it is undesirable to 291 aggressively deprecate global prefixes for temporary loss of 292 connectivity, so for a host to lose its global address there would 293 have to be a connection breakage longer than the lease period, and 294 even then, deprecating prefixes when there is no connectivity may not 295 be advisable. It should also be noted that there are timers on the 296 prefix lease to the homenet, on the internal prefix delegations, and 297 on the Router Advertisements to the hosts. Despite this counter- 298 argument, while setting a network up there may be a period with no 299 connectivity, in which case ULAs would be required for inter-subnet 300 communication. 302 It has been suggested that using ULAs would provide an indication to 303 applications that received traffic is locally sourced. This could 304 then be used with security settings to designate where a particular 305 application is allowed to connect to or receive traffic from. 307 ULA addresses will allow constrained LLN devices to create permanent 308 relations between IPv6 addresses, e.g. from a wall controller to a 309 lamp. Symbolic host names would require additional non-volatile 310 memory. Updating global prefixes in sleeping LLN devices might also 311 be problematic. 313 Default address selection mechanisms should ensure a ULA source 314 address is used to communicate with ULA destination addresses when 315 appropriate. Unlike the IPv4 RFC1918 space, the use of ULAs does not 316 imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT 317 [RFC6296], rather that external communications should use a node's 318 globally unique IPv6 source address. 320 2.5. Security and borders 322 Advanced Security for IPv6 CPEs [I-D.vyncke-advanced-ipv6-security] 323 takes the approach that in order to provide the greatest end-to-end 324 transparency as well as security, security policies must be updated 325 by a trusted party which can provide intrusion signatures and other 326 "active" information on security threats. Such methods should be 327 able to be automatically updating. 329 In addition to establishing the security mechanisms themselves, it is 330 important to know where the borders are at which they need to be 331 enabled. Any required policies must be able to be applied by typical 332 home users, e.g. to give a visitor in a "guest" network access to 333 media services in the home. Thus simple "association" mechanisms 334 will be required. 336 It may be useful to classify the external border of the home network 337 as a unique logical interface separating the home network from 338 service provider network/s. This border interface may be a single 339 physical interface to a single service provider, multiple layer 2 340 sub-interfaces to a single service provider, or multiple connections 341 to a single or multiple providers. This border is useful for 342 describing edge operations and interface requirements across multiple 343 functional areas including security, routing, service discovery, and 344 router discovery. 346 2.6. Naming, and manual configuration of IP addresses 348 Some IPv4 home networking devices expose IPv4 addresses to users, 349 e.g. the IPv4 address of a home IPv4 CER that may be configured via a 350 web interface. Users should not be expected to enter IPv6 literal 351 addresses in homenet devices or applications, given their much 352 greater length and apparent randomness to a typical home user. While 353 shorter addresses, perhaps ones registered with IANA from ULA-C 354 space, could be used for specific devices/services, in general it is 355 better to not expose users to real IPv6 addresses. Thus, even for 356 the simplest of functions, simple naming and the associated discovery 357 of services is imperative for easy use of homenet devices and 358 applications. 360 In a multi-subnet homenet, naming and service discovery should be 361 expected to operate across the scope of the entire home network, and 362 thus be able to cross subnet boundaries. It should be noted that in 363 IPv4, such services do not generally function across home router NAT 364 boundaries, so this is one area where there is scope for an 365 improvement in IPv6. 367 3. Architecture 369 An architecture outlines how to construct home networks involving 370 multiple routers and subnets. In this section, we present a set of 371 typical home network topology models/scenarios, followed by a list of 372 topics that may influence the architecture discussions, and a set of 373 architectural principles that govern how the various nodes should 374 work together. Finally, some guidelines are given for realising the 375 architecture with the IPv6 addressing, prefix delegation, global and 376 ULA addresses, source address selection rules and other existing 377 components of the IPv6 architecture. The architecture also drives 378 what protocol extensions are necessary, as will be discussed in 379 Section 3.5. 381 3.1. Network Models 383 Most IPv4 home network models tend to be relatively simple, typically 384 a single NAT router to the ISP and a single internal subnet, but as 385 discussed earlier, evolution in network architectures is driving more 386 complex architectures, such as separation of visitors and private 387 networks. These considerations apply to IPv6 networks as well. 389 In general, the models described in [RFC6204] and 390 [I-D.ietf-v6ops-ipv6-cpe-router-bis] should be supported by an IPv6 391 home networking architecture. 393 The following properties apply to any IPv6 home network: 395 o Presence of internal routers. The homenet may have one or more 396 internal routers, or may only provide subnetting from interfaces 397 on the CER. 399 o Presence of isolated internal subnets. There may be isolated 400 internal subnets, with no direct connectivity between them within 401 the homenet. Isolation may be physical, or implemented via IEEE 402 802.1q VLANs. 404 o Demarcation of the CER. The CER(s) may or may not be managed by 405 the ISP. If the demarcation point is such that the customer can 406 provide or manage the CER, its configuration must be simple. Both 407 models must be supported. 409 It has also been suggested that various forms of multihoming are more 410 prevalent with IPv6 home networks. Thus the following properties may 411 also apply to such networks: 413 o Number of upstream providers. A typical homenet might just have a 414 single upstream ISP, but it may become more common for there to be 415 multiple ISPs, whether for resilience or provision of additional 416 services. Each would offer its own prefix. Some may or may not 417 be walled gardens. 419 o Number of CERs. The homenet may have a single CER, which might be 420 used for one or more providers, or multiple CERs. Multiple CERs 421 adds additional complexity for multihoming scenarios, and 422 protocols like PCP that need to manage connection-oriented state 423 mappings. 425 Some separate discussion of physical infrastructures for homenets is 426 included in and [I-D.arkko-homenet-physical-standard]. 428 In the following sections we show some example homenet models. 430 3.1.1. A: Single ISP, Single CER, Internal routers 432 Figure 1 shows a network with multiple local area networks. These 433 may be needed for reasons relating to different link layer 434 technologies in use or for policy reasons, e.g. classic Ethernet in 435 one subnet and a LLN link layer technology in another. In this 436 example there is no single router that a priori understands the 437 entire topology. The topology itself may also be complex, and it may 438 not be possible to assume a pure tree form, for instance. This is a 439 valid consideration as home users may plug routers together to form 440 arbitrary topologies including loops (we discuss support for 441 arbitrary topologies in layer sections). 443 +-------+-------+ \ 444 | Service | \ 445 | Provider | | Service 446 | Router | | Provider 447 +-------+-------+ | network 448 | / 449 | Customer / 450 | Internet connection 451 | 452 +------+--------+ \ 453 | IPv6 | \ 454 | Customer Edge | \ 455 | Router | | 456 +----+-+---+----+ | 457 Network A | | | Network B/E | 458 ----+-------------+----+ | +---+-------------+------+ | 459 | | | | | | | | 460 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | | 461 |IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | | 462 | | | | | | | | | | | 463 +----------+ +----------+ | +----------+ +----------+ | | 464 | | | | | 465 | ---+------+------+-----+ | 466 | | Network B/E | 467 +------+--------+ | | End-User 468 | IPv6 | | | networks 469 | Interior +------+ | 470 | Router | | 471 +---+-------+-+-+ | 472 Network C | | Network D | 473 ----+-------------+---+- --+---+-------------+--- | 474 | | | | | 475 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 476 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 477 | | | | | | | | / 478 +----------+ +----------+ +----------+ +----------+ / 480 Figure 1 482 3.1.2. B: Two ISPs, Two CERs, Shared subnet 484 +-------+-------+ +-------+-------+ \ 485 | Service | | Service | \ 486 | Provider A | | Provider B | | Service 487 | Router | | Router | | Provider 488 +------+--------+ +-------+-------+ | network 489 | | / 490 | Customer | / 491 | Internet connections | / 492 | | 493 +------+--------+ +-------+-------+ \ 494 | IPv6 | | IPv6 | \ 495 | Customer Edge | | Customer Edge | \ 496 | Router 1 | | Router 2 | / 497 +------+--------+ +-------+-------+ / 498 | | / 499 | | | End-User 500 ---+---------+---+---------------+--+----------+--- | network(s) 501 | | | | \ 502 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 503 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 504 | | | | | | | | / 505 +----------+ +----------+ +----------+ +----------+ 507 Figure 2 509 Figure 2 illustrates a multihomed home network model, where the 510 customer has connectivity via CER1 to ISP A and via CER2 to ISP B. 511 This example shows one shared subnet where IPv6 nodes would 512 potentially be multihomed and receive multiple IPv6 global addresses, 513 one per ISP. This model may also be combined with that shown in 514 Figure 1 to create a more complex scenario with multiple internal 515 routers. Or the above shared subnet may be split in two, such that 516 each CER serves a separate isolated subnet, which is a scenario seen 517 with some IPv4 networks today. 519 3.1.3. C: Two ISPs, One CER, Shared subnet 521 +-------+-------+ +-------+-------+ \ 522 | Service | | Service | \ 523 | Provider A | | Provider B | | Service 524 | Router | | Router | | Provider 525 +-------+-------+ +-------+-------+ | network 526 | | / 527 | Customer | / 528 | Internet | / 529 | connections | | 530 +---------+---------+ \ 531 | IPv6 | \ 532 | Customer Edge | \ 533 | Router | / 534 +---------+---------+ / 535 | / 536 | | End-User 537 ---+------------+-------+--------+-------------+--- | network(s) 538 | | | | \ 539 +----+-----+ +----+-----+ +----+-----+ +-----+----+ \ 540 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 541 | | | | | | | | / 542 +----------+ +----------+ +----------+ +----------+ 544 Figure 3 546 Figure 3 illustrates a model where a home network may have multiple 547 connections to multiple providers or multiple logical connections to 548 the same provider, with shared internal subnets. 550 3.2. Determining the Requirements 552 [RFC6204] defines "basic" requirements for IPv6 Customer Edge 553 Routers, while [I-D.ietf-v6ops-ipv6-cpe-router-bis] describes 554 "advanced" features. In general, home network equipment needs to 555 cope with the different types of network properties and topologies 556 discussed above. Manual configuration is rarely, if at all, 557 possible, given the knowledge level of typical home users. The 558 equipment needs to be prepared to handle at least 560 o Routing 562 o Prefix configuration for routers 564 o Name resolution 565 o Service discovery 567 o Network security 569 The remainder of the architecture document is presented as 570 considerations and principles that lead to more specific requirements 571 for the five general areas listed above. 573 3.3. Considerations 575 This section lists some considerations for home networking that may 576 affect the architecture and associated requirements. 578 3.3.1. Multihoming 580 A homenet may be multihomed to multiple providers. This may either 581 take a form where there are multiple isolated networks within the 582 home a more integrated network where the connectivity selection is 583 dynamic. Current practice is typically of the former kind, but the 584 latter is expected to become more commonplace. 586 In an integrated network, specific appliances or applications may use 587 their own external connectivity, or the entire network may change its 588 connectivity based on the status of the different upstream 589 connections. The complexity of the multihoming solution required 590 will depend on the Network Model deployed. For example, Network 591 Model C in the previous section has a single CER and thus could 592 perform source routing at the single network exit point. 594 The general approach for IPv6 multihoming is for a host to receive 595 multiple addresses from multiple providers, and to select the 596 appropriate source address to communicate via a given provider. An 597 alternative is to deploy ULAs with a site and then use NPTv6 598 [RFC6296], a prefix translation-based mechanism, at the edge. This 599 obviously comes at some architectural cost, which is why approaches 600 such as [I-D.v6ops-multihoming-without-ipv6nat] have been suggested. 601 There has been much work on multihoming in the IETF, without (yet) 602 widespread deployment of proposed solutions. 604 Host-based methods such as Shim6 [RFC5533] have been defined, but of 605 course require support in the hosts. There are also application- 606 oriented approaches such as Happy Eyeballs 607 [I-D.ietf-v6ops-happy-eyeballs] exist; simplified versions of this 608 are implemented in some commonly used web browsers for example. 610 There are some other multihoming considerations for homenet 611 scenarios. First, it may be the case that multihoming applies due to 612 an ISP migration from a transition method to a native deployment, 613 e.g. a 6rd [RFC5969] sunset scenario. Second, one upstream may be a 614 "walled garden", and thus only appropriate to be used for 615 connectivity to the services of that provider. 617 If the homenet architecture supports multihoming, additional 618 requirements apply. The general multihoming problem is broad, and 619 solutions may include complex architectures for monitoring 620 connectivity, traffic engineering, identifier-locator separation, 621 connection survivability across multihoming events, and so on. This 622 implies that if there is any support for multihoming defined in the 623 homenet architecture it should be limited to a very small subset of 624 the overall problem. 626 The current set of assumptions and requirements proposed by the 627 homenet architecture team is: 629 MH1) The homenet WG should not try to make another attempt at 630 solving complex multihoming; we should prefer to support 631 scenarios for which solutions exist today. 633 MH2) Single CER Network Model C is in scope, and may be solved by 634 source routing at the CER. 636 MH3) The architecture does not support deployment of NPTv6 [RFC6296] 637 at the CER. Hosts should be multi-addressed with globally 638 unique prefixes from each ISP they may communicate with or 639 through. 641 MH4) Solutions that require host changes should be avoided, but 642 solutions which incrementally improve with host changes may be 643 acceptable. 645 MH5) Walled garden multihoming is in scope. 647 MH6) Transition method sunsetting is in scope. The topic of 648 multihoming with specific (6rd) transition coexistence is 649 discussed in [I-D.townsley-troan-ipv6-ce-transitioning]. 651 MH7) "Just" picking the right source address to use to fall foul of 652 ingress filtering on upstream ISP connections (as per Network 653 Model B) is not a trivial task. A solution is highly 654 desirable, but not required in the baseline homenet 655 architecture. 657 MH8) A multihoming model for multiple CERs based on 658 [I-D.baker-fun-multi-router] requires source routing throughout 659 the homenet and thus relatively significant routing changes to 660 "guarantee" routing the packet to the correct exit given the 661 source address. Thus this approach is currently out of scope 662 for homenet. 664 Thus the homenet multihoming support is focused on the single CER 665 model. 667 3.3.2. Quality of Service 669 Support for QoS in a multi-service homenet may be a requirement, e.g. 670 for a critical system (perhaps healthcare related), or for 671 differentiation between different types of traffic (file sharing, 672 cloud storage, live streaming, VoIP, etc). Different media types may 673 have different such properties or capabilities. 675 However, homenet scenarios should require no new QoS protocols. A 676 DiffServ [RFC2475] approach with a small number of predefined traffic 677 classes should generally be sufficient, though at present there is 678 little experience of QoS deployment in home networks. 680 There may also be complementary mechanisms that could be beneficial 681 to application performance and behaviour in the homenet domain, such 682 as ensuring proper buffering algorithms are used as described in 683 [Gettys11]. 685 3.3.3. Operations and Management 687 The homenet should be self-organising and configuring as far as 688 possible, and thus not be pro-actively managed by the home user. 689 Thus protocols to manage the network are not discussed in detail in 690 the architecture text. 692 However, users may be interested in the status of their networks and 693 devices on the network, in which case simplified monitoring 694 mechanisms may be desirable. It may also be the case that an ISP, or 695 a third party, might offer management of the homenet on behalf of a 696 user, in which case management protocols would be required. The 697 SNMPv3 family of protocols described in [RFC3411] and friends may be 698 appropriate (previous versions are not deemed secure and have been 699 marked as Historic by the IETF). 701 3.3.4. Privacy considerations 703 There are no specific privacy concerns discussed in this text. It 704 should be noted that many ISPs are expected to offer relatively 705 stable IPv6 prefixes to customers, and thus the network prefix 706 associated with the host addresses they use would not generally 707 change over a reasonable period of time. This exposure is similar to 708 IPv4 networks that expose the same IPv4 global address via use of 709 NAT, where the IPv4 address received from the ISP may change over 710 time. 712 3.4. Design Principles and Requirements 714 There is little that the Internet standards community can do about 715 the physical topologies or the need for some networks to be separated 716 at the network layer for policy or link layer compatibility reasons. 717 However, there is a lot of flexibility in using IP addressing and 718 inter-networking mechanisms. In this section we discuss how this 719 flexibility should be used to provide the best user experience and 720 ensure that the network can evolve with new applications in the 721 future. 723 The following principles should be followed when designing homenet 724 solutions. Where requirements are associated with those principles, 725 they are listed here. There is no implied priority by the order in 726 which the principles themselves are listed. 728 3.4.1. Reuse existing protocols 730 It is desirable to reuse existing protocols where possible, but at 731 the same time to avoid consciously precluding the introduction of new 732 or emerging protocols. A generally conservative approach, giving 733 weight to running code, is preferable. Where new protocols are 734 required, evidence of commitment to implementation by appropriate 735 vendors or development communities is highly desirable. Protocols 736 used should be backwardly compatible. 738 Where possible, changes to hosts should be minimised. Some changes 739 may be unavoidable however, e.g. signalling protocols to punch holes 740 in firewalls where "Simple Security" is deployed in a CER. Changes 741 to routers should also be minimised, e.g. 742 [I-D.baker-fun-routing-class] suggests introducing a routing protocol 743 that may route on both source and destination addresses, which would 744 be a significant change compared to current practices. 746 Liaisons with other appropriate standards groups and related 747 organisations is desirable, e.g. the IEEE and Wi-Fi Alliance. 749 RE1) Reuse existing protocols, giving weight to running code. 751 RE2) Minimise changes to hosts and routers. 753 RE3) Maintain backwards compatibility where possible. 755 3.4.2. Dual-stack Operation 757 The homenet architecture targets both IPv6-only and dual-stack 758 networks. While the CER requirements in RFC 6204 are aimed at IPv6- 759 only networks, it is likely that dual-stack homenets will be the norm 760 for some period of time. IPv6-only networking may first be deployed 761 in home networks in "greenfield" scenarios, or perhaps as one element 762 of an otherwise dual-stack network. The homenet architecture must 763 operate in the absence of IPv4, and IPv6 must work in the same 764 scenarios as IPv4 today. 766 Running IPv6-only may require documentation of additional 767 considerations such as: 769 o Ensuring there is a way to access content in the IPv4 Internet. 770 This can be arranged through incorporating NAT64 [RFC6144] and 771 DNS64 [RFC6145] functionality in the home gateway router, for 772 instance. 774 o DNS discovery mechanisms are enabled for IPv6. Both stateless 775 DHCPv6 [RFC3736] [RFC3646] and Router Advertisement options 776 [RFC6106] may have to be supported and turned on by default to 777 ensure maximum compatibility with all types of hosts in the 778 network. This requires, however, that a working DNS server is 779 known and addressable via IPv6. 781 o All nodes in the home network support operations in IPv6-only 782 mode. Some current devices work well with dual-stack but fail to 783 recognise connectivity when IPv4 DHCP fails, for instance. 785 In dual-stack networks, solutions for IPv6 should not adversely 786 affect IPv4 operation. It is likely that topologies of IPv4 and IPv6 787 networks would be as congruent as possible. 789 Note that specific transition tools, particularly those running on 790 the border CER to support transition tools being used inside the 791 homenet, are out of scope. Use of tools, such as 6rd, on the border 792 CER to support ISP access network transition are to be expected, but 793 not within scope of homenet, which focuses on the internal 794 networking. 796 DS1) The homenet must support IPv6-only or dual-stack operation; it 797 must thus operate in the absence of IPv4 and IPv6 must work in 798 the same scenarios as IPv4 today. 800 DS2) IPv6 solutions should not adversely affect IPv4 operation. 802 3.4.3. Largest Possible Subnets 804 Today's IPv4 home networks generally have a single subnet, and early 805 dual-stack deployments have a single congruent IPv6 subnet, possibly 806 with some bridging functionality. 808 Future home networks are highly likely to have one or more internal 809 routers and thus need multiple subnets, for the reasons described 810 earlier. As part of the self-organisation of the network, the 811 network should subdivide itself to the largest possible subnets that 812 can be constructed within the constraints of link layer mechanisms, 813 bridging, physical connectivity, and policy. For instance, separate 814 subnetworks are necessary where two different link layers cannot be 815 bridged, or when a policy requires the separation of private and 816 visitor parts of the network. 818 While it may be desirable to maximise the chance of link-local 819 protocols operating across a homenet by maximising the size of a 820 subnet across the homenet, multiple subnet home networks are 821 inevitable, so their support must be included. A general 822 recommendation is to follow the same topology for IPv6 as is used for 823 IPv4, but not to use NAT. Thus there should be routed IPv6 where an 824 IPv4 NAT is used, and where there is no NAT there should be bridging 825 if the link layer allows this. 827 In some cases IPv4 NAT home networks may feature cascaded NATs, e.g. 828 where NAT routers are included within VMs or Internet connection 829 services are used. IPv6 routed versions of such tools will be 830 required. 832 SN1) The network should subdivide itself to the largest possible 833 subnets that can be formed. 835 SN2) The IPv6 topology should follow the IPv4 topology, but not use 836 NAT, thus there should be routed IPv6 where IPv4 NAT is used. 838 3.4.4. Security vs Transparent, End-to-End Communications 840 An IPv6-based home network architecture should naturally offer a 841 transparent end-to-end communications model as described in 842 [RFC2775]. Each device should be addressable by a globally unique 843 address, and those addresses must not be altered in transit. 844 Security perimeters can of course restrict the end-to-end 845 communications, and thus while a host may be globally addressable it 846 may not be globally reachable. RFC 4864 sets a default deny "Simple 847 Security" model, in which filtering is to be expected (while host- 848 based IPv6 NAT is not). However, RFC 6092 states that while the 849 default should be default deny, CERs should also have an option to be 850 put into a "transparent" mode of operation which enables a default 851 allow model (in which case home devices must be independently 852 secure). Such end-to-end communications are important for their 853 robustness against failure of intermediate systems, where in contrast 854 NAT is dependent on state machines which are not self-healing. 856 In the presence of "Simple Security" the use of signalling protocols 857 such as UPnP IGD (Version 2) or PCP may be expected to punch holes in 858 the firewall (and be able to handle cases where there are multiple 859 CERs/firewall(s). When configuring holes in filters, protocols for 860 securely associating devices are desirable. 862 EE1) The homenet should embrace transparent, end-to-end 863 communications to, from and within the homenet. 865 EE2) The default security model at the homenet border is "Simple 866 Security" (default deny). 868 EE3) Where "Simple Security" is applied, there must be support for 869 an appropriate signalling protocol to open per-application 870 holes for communications. 872 EE4) The homenet should also support a "transparent" mode of 873 operation at its borders if configured to do so. 875 EE5) Users should have simple methods to associate devices to 876 services that are expected to operate through borders at which 877 "Simple Security" is applied. 879 3.4.5. IP Connectivity between All Nodes 881 A logical consequence of the end-to-end communications model is that 882 the network should by default attempt to provide IP-layer 883 connectivity between all internal parts as well as between the 884 internal parts and the Internet. This connectivity should be 885 established at the link layer, if possible, and using routing at the 886 IP layer otherwise. 888 Local addressing (ULAs) may be used within the scope of a home 889 network to provide a method to route between subnets. It would be 890 expected that ULAs may be used alongside one or more globally unique 891 ISP-provided addresses/prefixes in a homenet. ULAs may be used for 892 all devices, not just those intended to have internal connectivity 893 only. ULAs may then be used for stable internal communications 894 should the ISP-provided prefix (suddenly) change, or external 895 connectivity be temporarily lost. The use of ULAs should be 896 restricted to the homenet scope through filtering at the border(s) of 897 the homenet; thus "end-to-end" for ULAs is limited to the homenet. 899 In some cases full internal connectivity may not be desirable, e.g. 900 in certain utility networking scenarios, or where filtering is 901 required for policy reasons against guest network subnet(s). Certain 902 scenarios may require co-existence of ISP connectivity providing a 903 general Internet service with provider connectivity to a private 904 "walled garden" network. 906 Some home networking scenarios/models may involve isolated subnet(s) 907 with their own CERs. In such cases connectivity would only be 908 expected within each isolated network (though traffic may potentially 909 pass between them via external providers). 911 LLNs provide an example of where there may be secure perimeters 912 inside the homenet. Constrained LLN nodes may implement WPA-style 913 network key security but may depend on access policies enforced by 914 the LLN border router. 916 CN1) The homenet should utilise ULAs to provide stable addressing in 917 the event of there being no global prefix available or changes 918 in the global prefix. 920 CN2) ULAs must be filtered at the homenet site border(s). 922 CN3) Walled garden connectivity must be supported. 924 CN4) Isolated networks within the homenet must be supported. 926 3.4.6. Routing functionality 928 Routing functionality is required when there are multiple routers 929 deployed within the internal home network. This functionality could 930 be as simple as the current "default route is up" model of IPv4 NAT, 931 or it could involve running an appropriate routing protocol. 933 The homenet routing environment may include traditional IP networking 934 where existing link-state or distance-vector protocols may be used, 935 but also new LLN or other "constrained" networks where other 936 protocols may be more appropriate. IPv6 VM solutions may also add 937 additional routing requirements. Current home deployments use 938 largely different mechanisms in sensor and basic Internet 939 connectivity networks. 941 In this section we list the assumptions and requirements for routing 942 functionality within the homenet environment. 944 RT1) The protocol should preferably be an existing deployed 945 protocol that has been shown to be reliable and robust. 947 RT2) It is preferable that the protocol is "lightweight". 949 RT3) The protocol should be able to provide reachability between 950 all nodes in the homenet. 952 RT4) In general, LLN or other networks should be able to attach and 953 participate the same way as the main homenet, or alternatively 954 map/be gatewayed to the main homenet. 956 RT5) Multiple interface PHYs must be accounted for in the homenet 957 routed topology. Technologies such as Ethernet, WiFi, MoCA, 958 etc must be capable of coexisting in the same environment and 959 should be treated as part of any routed deployment. The 960 inclusion of the PHY layer characteristics including 961 bandwidth, loss, and latency in path computation should be 962 considered for optimising communication in the homenet. 964 RT6) Minimising convergence time should be a goal in any routed 965 environment, but as a guideline a maximum convergence time of 966 a couple of minutes should be the target. 968 RT7) It is desirable that the routing protocol has knowledge of the 969 homenet topology, which implies a link-state protocol may be 970 preferable. If so, it is also desirable that the 971 announcements and use of LSAs and RAs are appropriately 972 coordinated. 974 RT8) Any routed solution will require a means for determining the 975 boundaries of the homenet. Borders may include but are not 976 limited to the interface to the upstream ISP, a gateway device 977 to a separate home network such as a SmartGrid or similar LLN 978 network. In some cases there may be no border such as before 979 an upstream connection has been established. Devices in the 980 homenet must be able to find the path to the Internet as well 981 as other devices on the home intranet. The border discovery 982 functionality may be integrated into the routing protocol 983 itself, but may also be imported via a separate discovery 984 mechanism. 986 RT9) The routing environment should be self-configuring, as 987 discussed in the next subsection. An example of how OSPFv3 988 can be self-configuring in a homenet is described in 989 [I-D.acee-ospf-ospfv3-autoconfig]. An exception is 990 configuration of a "secret" for authentication methods. 992 RT10) The protocol should not require upstream ISP connectivity to 993 be established to continue routing within the homenet. 995 RT11) Multiple upstreams should be supported, as described in the 996 multihoming section earlier. The primary target for 997 multihoming support is the single CER case (where source 998 routing may assist path selection). 1000 RT12) To support multihoming within a homenet, a routing protocol 1001 that can make routing decisions based on source and 1002 destination addresses is desirable, to avoid upstream ISP 1003 ingress filtering problems. In general the routing protocol 1004 should support multiple ISP uplinks and delegated prefixes in 1005 concurrent use. 1007 RT13) Load-balancing to multiple providers is not a requirement, but 1008 failover from a primary to a backup link when available must 1009 be a requirement. 1011 RT14) It is assumed that the typical router designed for residential 1012 use does not contain the memory or CPU required to process a 1013 full Internet routing table this should not be a requirement 1014 for any homenet device. 1016 A new I-D has been published on homenet routing requirements, see 1017 [I-D.howard-homenet-routing-comparison] and evaluations of common 1018 routing protocols made against those requirements, see 1019 [I-D.howard-homenet-routing-requirements]. The requirements from the 1020 former document have been worked into this architecture text. 1022 3.4.7. Self-Organising 1024 A home network architecture should be naturally self-organising and 1025 self-configuring under different circumstances relating to the 1026 connectivity status to the Internet, number of devices, and physical 1027 topology. While the homenet should be self-organising, it should be 1028 possible to manually adjust (override) the current configuration. 1030 The homenet will need to be aware of the extent of its own "site". 1031 The homenet will have one or more borders, with external connectivity 1032 providers and potentially parts of the internal network (e.g. for 1033 policy-based reasons). It should be possible to automatically 1034 perform border discovery at least for the ISP borders. Such borders 1035 determine for example the scope of ULAs, service discovery 1036 boundaries, site scope multicast boundaries and where firewall 1037 policies may be applied. 1039 The most important function in this respect is prefix delegation and 1040 management. The assumptions and requirements for the prefix 1041 delegation function are summarised as follows: 1043 PD1) From the homenet perspective, a single prefix from each ISP 1044 should be received on the border CER [RFC3633]. The ISP 1045 should only see that aggregate, and not single /64 prefixes 1046 allocated within the homenet. 1048 PD2) Each link in the homenet should receive a prefix from within 1049 the ISP-provided prefix(es). 1051 PD3) Delegation should be autonomous, and not assume a flat or 1052 hierarchical model. 1054 PD4) The assignment mechanism should provide reasonable efficiency, 1055 so that typical home network prefix allocation sizes can 1056 accommodate all the necessary /64 allocations in most cases. 1057 A currently typical /60 allocation gives 16 /64 subnets. 1059 PD5) Duplicate assignment of multiple /64s to the same network 1060 should be avoided. 1062 PD6) The network should behave as gracefully as possible in the 1063 event of prefix exhaustion. The options in such cases may 1064 however be limited. 1066 PD7) Where multiple CERs exist with multiple ISP prefix pools, it 1067 is expected that routers within the homenet would assign 1068 themselves prefixes from each ISP they communicate with/ 1069 through. 1071 PD8) Where ULAs are used, most likely but not necessarily in 1072 parallel with global prefixes, one router will need to be 1073 elected to offer ULA prefixes for the homenet. The router 1074 should generate a /48 ULA for the site, and then delegate 1075 /64's from that ULA prefix to subnets. 1077 PD9) Delegation within the homenet should give each link a prefix 1078 that is persistent across reboots, power outages and similar 1079 short-term outages. 1081 PD10) Addition of a new routing device should not affect existing 1082 persistent prefixes, but persistence may not be expected in 1083 the face of significant "replumbing" of the homenet. 1085 PD11) Persistent prefixes should not depend on router boot order. 1087 PD12) Persistent prefixes may imply the need for stable storage on 1088 routing devices, and also a method for a home user to "reset" 1089 the stored prefix should a significant reconfiguration be 1090 required (though ideally the home user should not be involved 1091 at all). 1093 PD13) The delegation method should support "flash" renumbering. As 1094 a minimum, delegated ULA prefixes within the homenet should 1095 remain persistent through an ISP-driven renumbering event. 1097 Several proposals have been made for prefix delegation within a 1098 homenet. One group of proposals is based on DHCPv6 PD, as described 1099 in [I-D.baker-homenet-prefix-assignment], 1100 [I-D.chakrabarti-homenet-prefix-alloc], [RFC3315] and [RFC3633]. The 1101 other uses OSPFv3, as described in 1102 [I-D.arkko-homenet-prefix-assignment]. More detailed analysis of 1103 these approaches needs to be made against the requirements/ 1104 assumptions listed above. 1106 Other parameters of the network will need to be self-organising. The 1107 network elements will need to be integrated in a way that takes 1108 account of the various lifetimes on timers that are used on those 1109 different elements, e.g. DHCPv6 PD, router, valid prefix and 1110 preferred prefix timers. 1112 The network cannot be expected to be completely self-organising, e.g. 1113 some security parameters are likely to need manual configuration, 1114 e.g. WPA2 configuration for wireless access control. Some existing 1115 mechanisms exist to assist home users to associate devices as simply 1116 as possible, e.g. "connect" button support. 1118 ZC1) The homenet must as far as possible be self-organising and 1119 self-configuring. 1121 ZC2) Manual override of the configuration should be possible. 1123 ZC3) The homenet must be able to determine where its own borders 1124 lie. 1126 ZC4) The homenet "site" defines the borders for ULAs, site scope 1127 multicast, service discovery and security policies. 1129 ZC5) It is important that self-configuration with "unintended" 1130 devices is avoided. Methods are needed for devices to know 1131 whether they are intended to be part of the same homenet site 1132 or not. 1134 3.4.8. Fewest Topology Assumptions 1136 There should ideally be no built-in assumptions about the topology in 1137 home networks, as users are capable of connecting their devices in 1138 ingenious ways. Thus arbitrary topologies will need to be supported. 1140 It is important not to introduce new IPv6 scenarios that would break 1141 with IPv4+NAT, given that dual-stack homenets will be commonplace for 1142 some time. There may be IPv6-only topologies that work where IPv4 is 1143 not used or required. 1145 ZC1) Arbitrary topologies should be supported. 1147 3.4.9. Naming and Service Discovery 1149 The most natural way to think about naming and service discovery 1150 within a homenet is to enable it to work across the entire residence 1151 (site), disregarding technical borders such as subnets but respecting 1152 policy borders such as those between visitor and internal networks. 1154 Homenet naming systems will be required that work internally or 1155 externally, be the user within the homenet or outside it, though the 1156 domains used may be different from those different perspectives. It 1157 is possible that not all internal devices should be reflected by name 1158 in an external-facing domain. 1160 A desirable target may be a fully functional self-configuring secure 1161 local DNS service so that all devices can be referred to by name, and 1162 these FQDNs are resolved locally. This would make clean use of ULAs 1163 and multiple ISP-provided prefixes much easier. Such a local DNS 1164 service should be (by default) authoritative for the local name space 1165 in both IPv4 and IPv6. A dual-stack residential gateway should 1166 include a dual-stack DNS server. 1168 Consideration will also need to be given for existing protocols that 1169 may be used within a network, e.g. mDNS, and how these interact with 1170 unicast-based DNS services. 1172 With the introduction of new "dotless" top level domains, there is 1173 potential for ambiguity between for example a local host called apple 1174 and (if it is registered) an apple gTLD, so some local name space is 1175 probably required, which should also be configurable to something 1176 else by a home user, e.g. ".home", if desired. There is also 1177 potential ambiguity if, for example, a mobile device should move 1178 between two local name spaces called ".home". 1180 For service discovery, support may be required for IPv6 multicast 1181 across the scope of the home network. This would be the case if an 1182 approach to create Extended mDNS (xmDNS) is followed as described in 1183 [I-D.lynn-homenet-site-mdns]. 1185 SD1) The homenet must support naming and service discovery 1186 functions. 1188 SD2) All naming and service discovery functions should be able to 1189 function across the entire homenet site if required. 1191 SD3) Disconnected operation ("fate sharing"): name resolution for 1192 reachable devices continues if the local network is 1193 disconnected from the global Internet. 1195 SD4) Message utilisation should be efficient considering the network 1196 technologies the service may need to operate over. 1198 SD5) Devices represented in the homenet name space may also be 1199 represented in the global DNS namespace. 1201 SD6) Site scope IPv6 multicast should be supported across the 1202 homenet. 1204 3.4.10. Proxy or Extend? 1206 Related to the above, the architecture proposes that any existing 1207 protocols (e.g. service discovery) that are designed to only work 1208 within a subnet should be modified/extended to work across subnets, 1209 rather than defining proxy capabilities for each of those functions. 1211 Some protocols already have proxy functions defined and in use, e.g. 1212 DHCPv6 relays, in which case those protocols would be expected to 1213 continue to operate that way. 1215 Feedback is desirable on which other functions/protocols assume 1216 subnet-only operation, in the context of existing home networks. 1217 Some experience from enterprises may be relevant here. 1219 SD1) Prefer to extend protocols to site scope operation rather than 1220 providing proxy functions on subnet boundaries. 1222 3.4.11. Adapt to ISP constraints 1224 Different homenets may be subject to different behaviour by its 1225 ISP(s). The home network may receive an arbitrary length IPv6 prefix 1226 from its provider, e.g. /60 or /56. The offered prefix may be stable 1227 over time or change from time to time. Some ISPs may offer 1228 relatively stable prefixes, while others may change the prefix 1229 whenever the CER is reset. Some discussion of IPv6 prefix allocation 1230 policies is included in [RFC6177], which discusses why, for example, 1231 a one-size-fits-all /48 allocation is not appropriate. The home 1232 network needs to be adaptable to such ISP policies. 1234 The internal operation of the home network should also not depend on 1235 the availability of the ISP network at any given time, other than for 1236 connectivity to services or systems off the home network. This 1237 implies the use of ULAs as supported in RFC6204. If used, ULA 1238 addresses should be stable so that they can always be used 1239 internally, independent of the link to the ISP. 1241 It is expected that ISPs will deliver a relatively stable home prefix 1242 to customers. The norm for residential customers of large ISPs may 1243 be similar to their single IPv4 address provision; by default it is 1244 likely to remain persistent for some time, but changes in the ISP's 1245 own provisioning systems may lead to the customer's IP (and in the 1246 IPv6 case their prefix pool) changing. It is not expected that ISPs 1247 will support Provider Independent (PI) addressing in general 1248 residential homenets. 1250 When an ISP needs to restructure and in doing so renumber its 1251 customer homenets, "flash" renumbering is likely to be imposed. This 1252 implies a need for the homenet to be able to handle a sudden 1253 renumbering event which, unlike the process described in [RFC4192], 1254 would be a "flag day" event, which means that a graceful renumbering 1255 process moving through a state with two active prefixes in use would 1256 not be possible. While renumbering is an extended version of an 1257 initial numbering process, the difference between flash renumbering 1258 and an initial "cold start" is the need to provide service 1259 continuity. The customer may of course also choose to move to a new 1260 ISP, and thus begin using a new prefix, though in such cases the 1261 customer may expect a discontinuity. Regardless, it's desirable that 1262 homenet protocols support rapid renumbering and operational processes 1263 don't add unnecessary complexity for the renumbering process. 1265 The 6renum WG is studying IPv6 renumbering for enterprise networks. 1266 It is not currently targetting homenets, but may produce outputs that 1267 are relevant. 1269 AD1) The homenet should make no assumptions about the stability of 1270 the prefix received from an ISP, or the length of the prefix 1271 that may be offered. 1273 AD2) The operation of the homenet must not depend on the 1274 availability of the ISP connection. 1276 AD3) The homenet should support "flash" renumbering. Applications 1277 and services operating within or to/from the homenet should be 1278 as resilient as possible to an external change of delegated 1279 prefix(es). 1281 3.5. Implementing the Architecture on IPv6 1283 This architecture text encourages re-use of existing protocols. Thus 1284 the necessary mechanisms are largely already part of the IPv6 1285 protocol set and common implementations. There are though some 1286 exceptions. For automatic routing, it is expected that existing 1287 routing protocols can be used as is. However, a new mechanism may be 1288 needed in order to turn a selected protocol on by default. 1290 Some functionality, if required by the architecture, would add 1291 significant changes or require development of new protocols, e.g. 1292 support for multihoming with multiple exit routers would require 1293 extensions to support source and destination address based routing 1294 within the homenet. 1296 Some protocol changes are however required in the architecture, e.g. 1297 for name resolution and service discovery, extensions to existing 1298 multicast-based name resolution protocols are needed to enable them 1299 to work across subnets, within the scope of the home network site. 1301 Some of the hardest problems in developing solutions for home 1302 networking IPv6 architectures include discovering the right borders 1303 where the domain "home" ends and the service provider domain begins, 1304 deciding whether some of the necessary discovery mechanism extensions 1305 should affect only the network infrastructure or also hosts, and the 1306 ability to turn on routing, prefix delegation and other functions in 1307 a backwards compatible manner. 1309 4. Conclusions 1311 This text defines principles and requirements for a homenet 1312 architecture. (More to be added.) 1314 5. References 1316 5.1. Normative References 1318 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1319 E. Lear, "Address Allocation for Private Internets", 1320 BCP 5, RFC 1918, February 1996. 1322 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1323 (IPv6) Specification", RFC 2460, December 1998. 1325 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1326 and W. Weiss, "An Architecture for Differentiated 1327 Services", RFC 2475, December 1998. 1329 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1330 Address Translator (Traditional NAT)", RFC 3022, 1331 January 2001. 1333 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1334 and M. Carney, "Dynamic Host Configuration Protocol for 1335 IPv6 (DHCPv6)", RFC 3315, July 2003. 1337 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1338 Architecture for Describing Simple Network Management 1339 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1340 December 2002. 1342 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1343 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1344 December 2003. 1346 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1347 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1348 September 2005. 1350 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1351 Addresses", RFC 4193, October 2005. 1353 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1354 Architecture", RFC 4291, February 2006. 1356 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1357 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1358 May 2007. 1360 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1361 Extensions for Stateless Address Autoconfiguration in 1362 IPv6", RFC 4941, September 2007. 1364 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1365 Shim Protocol for IPv6", RFC 5533, June 2009. 1367 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1368 Infrastructures (6rd) -- Protocol Specification", 1369 RFC 5969, August 2010. 1371 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1372 Customer Premises Equipment (CPE) for Providing 1373 Residential IPv6 Internet Service", RFC 6092, 1374 January 2011. 1376 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1377 Troan, "Basic Requirements for IPv6 Customer Edge 1378 Routers", RFC 6204, April 2011. 1380 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1381 Translation", RFC 6296, June 2011. 1383 5.2. Informative References 1385 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1386 February 2000. 1388 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1389 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1390 December 2003. 1392 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1393 (DHCP) Service for IPv6", RFC 3736, April 2004. 1395 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1396 "IPv6 Router Advertisement Options for DNS Configuration", 1397 RFC 6106, November 2010. 1399 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1400 IPv4/IPv6 Translation", RFC 6144, April 2011. 1402 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1403 Algorithm", RFC 6145, April 2011. 1405 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1406 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 1408 [I-D.baker-fun-multi-router] 1409 Baker, F., "Exploring the multi-router SOHO network", 1410 draft-baker-fun-multi-router-00 (work in progress), 1411 July 2011. 1413 [I-D.lynn-homenet-site-mdns] 1414 Lynn, K. and D. Sturek, "Extended Multicast DNS", 1415 draft-lynn-homenet-site-mdns-00 (work in progress), 1416 March 2012. 1418 [I-D.townsley-troan-ipv6-ce-transitioning] 1419 Townsley, M. and O. Troan, "Basic Requirements for 1420 Customer Edge Routers - multihoming and transition", 1421 draft-townsley-troan-ipv6-ce-transitioning-02 (work in 1422 progress), December 2011. 1424 [I-D.baker-fun-routing-class] 1425 Baker, F., "Routing a Traffic Class", 1426 draft-baker-fun-routing-class-00 (work in progress), 1427 July 2011. 1429 [I-D.howard-homenet-routing-comparison] 1430 Howard, L., "Evaluation of Proposed Homenet Routing 1431 Solutions", draft-howard-homenet-routing-comparison-00 1432 (work in progress), December 2011. 1434 [I-D.howard-homenet-routing-requirements] 1435 Howard, L., "Homenet Routing Requirements", 1436 draft-howard-homenet-routing-requirements-00 (work in 1437 progress), December 2011. 1439 [I-D.herbst-v6ops-cpeenhancements] 1440 Herbst, T. and D. Sturek, "CPE Considerations in IPv6 1441 Deployments", draft-herbst-v6ops-cpeenhancements-00 (work 1442 in progress), October 2010. 1444 [I-D.vyncke-advanced-ipv6-security] 1445 Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced 1446 Security for IPv6 CPE", 1447 draft-vyncke-advanced-ipv6-security-03 (work in progress), 1448 October 2011. 1450 [I-D.ietf-v6ops-ipv6-cpe-router-bis] 1451 Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1452 Troan, "Advanced Requirements for IPv6 Customer Edge 1453 Routers", draft-ietf-v6ops-ipv6-cpe-router-bis-01 (work in 1454 progress), July 2011. 1456 [I-D.ietf-6man-rfc3484bis] 1457 Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 1458 "Default Address Selection for Internet Protocol version 6 1459 (IPv6)", draft-ietf-6man-rfc3484bis-01 (work in progress), 1460 March 2012. 1462 [I-D.v6ops-multihoming-without-ipv6nat] 1463 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 1464 Wing, "IPv6 Multihoming without Network Address 1465 Translation", draft-v6ops-multihoming-without-ipv6nat-00 1466 (work in progress), March 2011. 1468 [I-D.baker-homenet-prefix-assignment] 1469 Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small 1470 Networks", draft-baker-homenet-prefix-assignment-01 (work 1471 in progress), March 2012. 1473 [I-D.arkko-homenet-prefix-assignment] 1474 Arkko, J. and A. Lindem, "Prefix Assignment in a Home 1475 Network", draft-arkko-homenet-prefix-assignment-01 (work 1476 in progress), October 2011. 1478 [I-D.acee-ospf-ospfv3-autoconfig] 1479 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 1480 draft-acee-ospf-ospfv3-autoconfig-01 (work in progress), 1481 March 2012. 1483 [I-D.ietf-pcp-base] 1484 Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R. 1485 Penno, "Port Control Protocol (PCP)", 1486 draft-ietf-pcp-base-23 (work in progress), February 2012. 1488 [I-D.ietf-v6ops-happy-eyeballs] 1489 Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1490 Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-07 1491 (work in progress), December 2011. 1493 [I-D.chakrabarti-homenet-prefix-alloc] 1494 Nordmark, E., Chakrabarti, S., Krishnan, S., and W. 1495 Haddad, "Simple Approach to Prefix Distribution in Basic 1496 Home Networks", draft-chakrabarti-homenet-prefix-alloc-01 1497 (work in progress), October 2011. 1499 [I-D.arkko-homenet-physical-standard] 1500 Arkko, J. and A. Keranen, "Minimum Requirements for 1501 Physical Layout of Home Networks", 1502 draft-arkko-homenet-physical-standard-00 (work in 1503 progress), March 2012. 1505 [Gettys11] 1506 Gettys, J., "Bufferbloat: Dark Buffers in the Internet", 1507 March 2011, 1508 . 1510 [IGD-2] UPnP Gateway Committee, "Internet Gateway Device (IGD) V 1511 2.0", September 2010, . 1514 Appendix A. Acknowledgments 1516 The authors would like to thank Brian Carpenter, Mark Andrews, Fred 1517 Baker, Ray Bellis, Cameron Byrne, Brian Carpenter, Stuart Cheshire, 1518 Lorenzo Colitti, Ralph Droms, Lars Eggert, Jim Gettys, Wassim Haddad, 1519 Joel M. Halpern, David Harrington, Lee Howard, Ray Hunter, Joel 1520 Jaeggli, Heather Kirksey, Ted Lemon, Kerry Lynn, Erik Nordmark, 1521 Michael Richardson, Barbara Stark, Sander Steffann, Dave Thaler, JP 1522 Vasseur, Curtis Villamizar, Dan Wing, Russ White, and James Woodyatt 1523 for their contributions within homenet WG meetings and the mailing 1524 list, and Mark Townsley for being an initial editor/author of this 1525 text before taking his position as homenet WG co-chair. 1527 Appendix B. Changes 1529 This section will be removed in the final version of the text. 1531 B.1. Version 02 1533 Changes made include: 1535 o Made the IPv6 implications section briefer. 1537 o Changed Network Models section to describe properties of the 1538 homent with illustrative examples, rather than implying the number 1539 of models was fixed to the six shown in 01. 1541 o Text to state multihoming support focused on single CER model. 1542 Multiple CER support is desirable, but not required. 1544 o Stated that NPTv6 not supported. 1546 o Added considerations section for operations and management. 1548 o Added bullet point principles/requirements to Section 3.4. 1550 o Changed IPv6 solutions must not adversely affect IPv4 to should 1551 not. 1553 o End-to-end section expanded to talk about "Simple Security" and 1554 borders. 1556 o Extended text on naming and service discovery. 1558 o Added reference to RFC 2775, RFC 6177. 1560 o Added reference to the new xmDNS draft. 1562 o Added naming/SD requirements from Ralph Droms. 1564 Authors' Addresses 1566 Tim Chown (editor) 1567 University of Southampton 1568 Highfield 1569 Southampton, Hampshire SO17 1BJ 1570 United Kingdom 1572 Email: tjc@ecs.soton.ac.uk 1574 Jari Arkko 1575 Ericsson 1576 Jorvas 02420 1577 Finland 1579 Email: jari.arkko@piuha.net 1581 Anders Brandt 1582 Sigma Designs 1583 Emdrupvej 26A, 1 1584 Copenhagen DK-2100 1585 Denmark 1587 Email: abr@sdesigns.dk 1589 Ole Troan 1590 Cisco Systems, Inc. 1591 Drammensveien 145A 1592 Oslo N-0212 1593 Norway 1595 Email: ot@cisco.com 1596 Jason Weil 1597 Time Warner Cable 1598 13820 Sunrise Valley Drive 1599 Herndon, VA 20171 1600 USA 1602 Email: jason.weil@twcable.com