idnits 2.17.1 draft-arkko-townsley-homenet-arch-00.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.) == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2011) is 4650 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 6204 (Obsoleted by RFC 7084) == Outdated reference: A later version (-03) exists of draft-vyncke-advanced-ipv6-security-01 == Outdated reference: A later version (-01) exists of draft-ietf-v6ops-ipv6-cpe-router-bis-00 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational M. Townsley 5 Expires: January 6, 2012 Cisco 6 July 5, 2011 8 Home Networking Architecture for IPv6 9 draft-arkko-townsley-homenet-arch-00 11 Abstract 13 This memo focuses on the evolving networking technology within and 14 among relatively small "residential home" networks. The goal of this 15 memo is to define the architecture for IPv6-based home networking 16 that supports the demands placed on it. This architecture shows how 17 standard IPv6 mechanisms and addressing can be employed in home 18 networking, and outlines the need for specific protocol extensions 19 for certain additional functionality. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 6, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . . 3 57 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 59 3.2. Principles . . . . . . . . . . . . . . . . . . . . . . . . 9 60 3.3. Implementing the Architecture on IPv6 . . . . . . . . . . 10 61 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 4.1. Normative References . . . . . . . . . . . . . . . . . . . 11 63 4.2. Informative References . . . . . . . . . . . . . . . . . . 11 64 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 67 1. Introduction 69 This memo focuses on the evolving networking technology within and 70 among relatively small "residential home" networks and the associated 71 challenges. For example, an obvious trend in home networking is the 72 proliferation of networking technology in an increasingly broad range 73 and number of devices. This evolution in scale and diversity sets 74 some requirements on IETF protocols. Some of these requirements 75 relate to the need for supporting multiple subnets for private and 76 guest networks, the introduction of IPv6, and the introduction of 77 specialized networks for home automation and sensors. 79 While many advanced home networks have been built, most operate based 80 on IPv4, employ solutions that we would like to avoid such as network 81 address translation (NAT), or require an expert assistance to set up. 82 The architectural constructs in this document are focused on the 83 problems to be solved when introducing IPv6 with a eye towards a 84 better result than what we have today with IPv4, as well as a better 85 result than if the IETF had not given this specific guidance. 87 This architecture document aims to provide the basis for how standard 88 IPv6 mechanisms and addressing [RFC2460] [RFC4291] can be employed in 89 home networking, while coexisting with existing IPv4 mechanisms that 90 are widely deployed. 92 2. Effects of IPv6 on Home Networking 94 Service providers are deploying IPv6, widely accessed content is 95 becoming available on IPv6, and support for IPv6 is increasingly 96 available in devices and software used in the home. While IPv6 97 resembles IPv4 in many ways, it changes address allocation principles 98 and allows direct IP addressability and routing to devices in the 99 home from the Internet. Following is an overview of some of the 100 areas of that are both promising and problematic: 102 Multiple segments 104 While less complex L3-topologies involving as few subnets as 105 possible are preferred in home networks for a variety of reasons 106 including simpler management and service discovery, incorporation 107 of dedicated segments remain necessary for some cases. For 108 instance, a common feature in modern home routers in the ability 109 to support both guest and private network segments. Also, link 110 layer networking technology is poised to become more 111 heterogeneous, as networks begin to employ both traditional 112 Ethernet technology and link layers designed for low-powered 113 sensor networks. Finally, similar needs for segmentation may 114 occur in other cases, such as separating building control or 115 corporate extensions from the Internet access network. Different 116 segments may be associated with subnets that have different 117 routing and security policies. 119 Documents that provide some more specific background and depth on 120 this topic include: [I-D.herbst-v6ops-cpeenhancements], r 121 [I-D.baker-fun-multi-router], and [I-D.baker-fun-routing-class]. 123 In addition to routing, rather than natting, between subnets, 124 there are issues of when and how to extend mechanisms such as 125 service discovery which currently rely on link-local addressing to 126 limit scope. 128 Security, Borders, and the elimination of NAT 130 The End-to-end communication that is promised with IPv6 is both an 131 incredible opportunity for innovation and easy of network 132 operation, but it is also a concern as it it exposes nodes in the 133 internal networks to receipt of otherwise unwanted traffic from 134 the Internet. Firewalls that restrict incoming connections may be 135 used to prevent exposure, however, this reduces the efficacy of 136 end-to-end connectivity that IPv6 has the potential to restore. 137 [RFC6092] provides recommendations for an IPv6 firewall that 138 applies "limitations on end-to-end transparency where security 139 considerations are deemed important to promote local and Internet 140 security." The firewall operation is "Simple" in that there is an 141 assumption that traffic which is to be blocked by default is 142 defined in the RFC and not expected to be updated by the user or 143 otherwise. Advanced Security for IPv6 CPE 144 [I-D.vyncke-advanced-ipv6-security] takes the approach that in 145 order to provide the greatest end-to-end transparency as well as 146 security, security polices must be updated by a trusted party 147 which can provide intrusion signatures an other "active" 148 information on security threats. This is much like a virus- 149 scanning tool which must receive updates in order to detect and/or 150 neutralize the latest attacks as they arrive. As the name implies 151 "Advanced" security requires significantly more resources and 152 infrastructure (including a source for attack signatures) vs. 153 "Simple" security. 155 In addition to the security mechanisms themselves, it is important 156 to know where to enable them. If there is some indication as to 157 which router is connected to the "outside" of the home network, 158 this is feasible. Otherwise, it can be difficult to know which 159 security policies to apply where. Further, security policies may 160 be different for various address ranges if ULA addressing is setup 161 to only operate within the homenet itself and not be routed to the 162 Internet at large. 164 Naming, and manual configuration of IP addresses 166 In IPv4, it is common practice to reach a router for 167 configuration, DNS resolver functions, or otherwise via 168 192.168.1.1 or some other well-known RFC 1918 address. In IPv6, 169 there is no such address space available, and generally IPv6 170 addresses are more cumbersome for humans to manually configure. 171 As such, even for the simplest of functions, naming and the 172 associated discovery of service is imperative for an easy to 173 administer homenet. 175 3. Architecture 177 An architecture outlines how to construct home networks involving 178 multiple routers and subnets. In the following this memo presents a 179 few typical home network topology models, followed by architectural 180 principles that govern how the various nodes should work together. 181 Finally, some guidelines are given for realizing the architecture 182 with the IPv6 addressing architecture, prefix delegation, global and 183 ULA addresses, source address selection rules and other existing 184 components of the IPv6 architecture. The architecture also drives 185 what protocols extensions are necessary, as will be discussed in 186 Section 3.3. 188 Figure 1 shows the simplest possible home network topology, involving 189 just one router, a local area network, and a set of hosts. Setting 190 up such networks is well understood today [RFC6204]. 192 +-------+-------+ \ 193 | Service | \ 194 | Provider | | Service 195 | Router | | Provider 196 +-------+-------+ | network 197 | / 198 | Customer / 199 | Internet connection / 200 | 201 +------+--------+ \ 202 | IPv6 | \ 203 | Customer Edge | \ 204 | Router | / 205 +------+--------+ / 206 | | End-User 207 Local Network | | network(s) 208 ---+-----+-------+--- \ 209 | | \ 210 +----+-----+ +-----+----+ \ 211 |IPv6 Host | |IPv6 Host | / 212 | | | | / 213 +----------+ +-----+----+ / 215 Figure 1 217 Figure 2 shows another network that now introduces multiple local 218 area networks. These may be needed for reasons relating to different 219 link layer technology or for policy reasons. Note that a common 220 arrangement is to have different link types supported on the same 221 router, bridged together. For the purposes of this memo and IP layer 222 operation this arrangement is considered equivalent to the topology 223 in Figure 1. This topology is also relatively well understood today 224 [RFC6204], though it certainly presents additional demands with 225 regards suitable firewall policies and limits the operation of 226 certain applications and discovery mechanisms. 228 +-------+-------+ \ 229 | Service | \ 230 | Provider | | Service 231 | Router | | Provider 232 +------+--------+ | network 233 | / 234 | Customer / 235 | Internet connection / 236 | 237 +------+--------+ \ 238 | IPv6 | \ 239 | Customer Edge | \ 240 | Router | / 241 +----+-------+--+ / 242 Network A | | Network B | End-User 243 ---+-------------+----+- --+--+-------------+--- | network(s) 244 | | | | \ 245 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 246 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 247 | | | | | | | | / 248 +----------+ +-----+----+ +----------+ +----------+ / 250 Figure 2 252 ... 254 Figure 3 shows a little bit more complex network with two routers and 255 eight devices connected to one ISP. This network is similar to the 256 one discussed in [I-D.ietf-v6ops-ipv6-cpe-router-bis]. The main 257 complication in this topology compared to the ones described earlier 258 is that there is no longer a single router that a priori understand 259 the entire topology. The topology itself may also be complex, it may 260 not be possible to assume a pure tree form, for instance. 262 +-------+-------+ \ 263 | Service | \ 264 | Provider | | Service 265 | Router | | Provider 266 +-------+-------+ | network 267 | / 268 | Customer / 269 | Internet connection 270 | 271 +------+--------+ \ 272 | IPv6 | \ 273 | Customer Edge | \ 274 | Router | | 275 +----+-+---+----+ | 276 Network A | | | Network B/E | 277 ----+-------------+----+ | +---+-------------+------+ | 278 | | | | | | | | 279 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | | 280 |IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | | 281 | | | | | | | | | | | 282 +----------+ +-----+----+ | +----------+ +----------+ | | 283 | | | | | 284 | ---+------+------+-----+ | 285 | | Network B/E | 286 +------+--------+ | | End-User 287 | IPv6 | | | networks 288 | Interior +------+ | 289 | Router | | 290 +---+-------+-+-+ | 291 Network C | | Network D | 292 ----+-------------+---+- --+---+-------------+--- | 293 | | | | | 294 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 295 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 296 | | | | | | | | / 297 +----------+ +-----+----+ +----------+ +----------+ / 299 Figure 3 301 3.1. Requirements 303 [RFC6204] defines "Basic" requirements for IPv6 Customer Edge 304 Routers, while [I-D.ietf-v6ops-ipv6-cpe-router-bis] describes 305 "advanced" features. In general, home network equipment needs to 306 cope with different types of network topologies discussed above. 307 Manual configuration is rarely, if at all, possible. The equipment 308 needs to be prepared to handle at least 309 o prefix configuration for routers 311 o managing routing 313 o name resolution 315 o service discovery 317 o network security 319 Additional requirements may stem from support for multi-homing or 320 multiple exit routers [I-D.baker-fun-multi-router]. 322 3.2. Principles 324 There is little that the Internet standards community can do about 325 the physical topologies or the need for some networks to be separated 326 at the network layer for policy or link layer compatibility reasons. 327 However, there is a lot of flexibility in using IP addressing and 328 internetworking mechanisms. It would be desirable to provide some 329 guidance on how this flexibility should be used to provide the best 330 user experience and ensure that the network can evolve with new 331 applications in the future. 333 The authors believe that the following principles guide us in 334 designing these networks in the correct manner: 336 Largest Possible Subnets 338 As part of the self-organization of the netowrk, the network 339 should subdivide itself to the largest possible subnets that can 340 be constructed with the constraints of link layer mechanisms, 341 bridging, physical connectivity, and policy. For instance, 342 separate subnetworks are necessary where two different links 343 cannot be bridged, or when a policy requires the separation of a 344 private and visitor parts of the network. 346 Transparent End-to-End Communications 348 An IPv6-based home network architecture should naturally offer a 349 transparent end-to-end communications model. Each device should 350 be addressable by a unique address. Security perimeters can of 351 course restrict the end-to-end communications, but it is much 352 easier to block certain nodes from communicating than it is to re- 353 enable nodes to communicate if they have been hidden behind local 354 addressing domains and address translation. 356 IP Connectivity between All Nodes 358 A logical consequence of the end-to-end communications model is 359 that the network should attempt to provide IP-layer connectivity 360 between all internal parts as well as between the internal parts 361 and the Internet. This connectivity should be established at the 362 link layer, if possible, and using routing at the IP layer 363 otherwise. 365 Self-Organization 367 A home network architecture should be naturally self-organizing 368 and self-configuring under different circumstances relating to 369 connectivity status to the Internet, number of devices, and 370 physical topology. 372 Least Topology Assumptions 374 There should be ideally no built-in assumptions about the topology 375 in home networks, as users area capable of connecting their 376 devices in ingenious ways. 378 Discovery 380 The most natural way to think about name and service discovery 381 within a home is to enable it to work across the entire residence, 382 disregarding technical borders such as subnets but respecting 383 policy borders such as those between visitor and internal 384 networks. 386 Intelligent Policy 388 As the Internet continues to evolve, no part of the architecture 389 or security design should depend on hardcoding acceptable or 390 unacceptable traffic patterns into the devices. Rather, these 391 traffic patterns should be driven off up-to-date databases in the 392 Internet. 394 3.3. Implementing the Architecture on IPv6 396 The necessary mechanisms are largely already part of the IPv6 397 protocol set and common implementations. The few known counter- 398 examples are discussed in the following. For prefix configuration, 399 existing protocols are likely sufficient, but may at worst may need 400 some small enhancements, such as new options. For automatic routing, 401 it is expected that existing routing protocols can be used as is, 402 however, a new mechanism may be needed in order to turn a selected 403 protocol on by default. Support for multiple exit routers and multi- 404 homing would also require extensions. For name resolution and 405 service discovery, extensions to existing multicast-based name 406 resolution protocols are needed to enable them to work across 407 subnets. 409 The hardest problems in developing solutions for home networking IPv6 410 architectures include discovering the right borders where the domain 411 "home" ends and the service provider domain begins, deciding whether 412 some of necessary discovery mechanism extensions should affect only 413 the network infrastructure or also hosts, and the ability to turn on 414 routing, prefix delegation and other functions in a backwards 415 compatible manner. 417 4. References 419 4.1. Normative References 421 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 422 (IPv6) Specification", RFC 2460, December 1998. 424 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 425 Architecture", RFC 4291, February 2006. 427 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 428 Customer Premises Equipment (CPE) for Providing 429 Residential IPv6 Internet Service", RFC 6092, 430 January 2011. 432 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 433 Troan, "Basic Requirements for IPv6 Customer Edge 434 Routers", RFC 6204, April 2011. 436 4.2. Informative References 438 [I-D.baker-fun-multi-router] 439 Baker, F., "Exploring the multi-router SOHO network", 440 draft-baker-fun-multi-router-00 (work in progress), 441 July 2011. 443 [I-D.baker-fun-routing-class] 444 Baker, F., "Routing a Traffic Class", 445 draft-baker-fun-routing-class-00 (work in progress), 446 July 2011. 448 [I-D.herbst-v6ops-cpeenhancements] 449 Herbst, T. and D. Sturek, "CPE Considerations in IPv6 450 Deployments", draft-herbst-v6ops-cpeenhancements-00 (work 451 in progress), October 2010. 453 [I-D.vyncke-advanced-ipv6-security] 454 Vyncke, E. and M. Townsley, "Advanced Security for IPv6 455 CPE", draft-vyncke-advanced-ipv6-security-01 (work in 456 progress), March 2010. 458 [I-D.ietf-v6ops-ipv6-cpe-router-bis] 459 Singh, H., Beebee, W., Donley, C., Stark, B., and O. 460 Troan, "Advanced Requirements for IPv6 Customer Edge 461 Routers", draft-ietf-v6ops-ipv6-cpe-router-bis-00 (work in 462 progress), March 2011. 464 Appendix A. Acknowledgments 466 The authors would like to thank to Stuart Cheshire, James Woodyatt, 467 Ole Troan, Lars Eggert, Ray Bellis, David Harrington, Wassim Haddad, 468 Heather Kirksey, Dave Thaler, Fred Baker, and Ralph Droms for 469 interesting discussions in this problem space. 471 Authors' Addresses 473 Jari Arkko 474 Ericsson 475 Jorvas 02420 476 Finland 478 Email: jari.arkko@piuha.net 480 Mark Townsley 481 Cisco 482 Paris 75006 483 France 485 Email: townsley@cisco.com