idnits 2.17.00 (12 Aug 2021) /tmp/idnits53237/draft-jvkjjmb-home-networking-incremental-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 163 has weird spacing: '... Router a n...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 4, 2013) is 3236 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.arkko-homenet-prefix-assignment' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-homenet-prefix-assignment' is defined on line 920, but no explicit reference was found in the text == Unused Reference: 'I-D.haddad-homenet-multihomed' is defined on line 925, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-homenet-arch' is defined on line 930, but no explicit reference was found in the text == Unused Reference: 'I-D.troan-homenet-sadr' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'I-D.xu-rtgwg-twod-ip-routing' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 964, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-haddad-homenet-multihomed-01 == Outdated reference: draft-ietf-homenet-arch has been published as RFC 7368 == Outdated reference: A later version (-01) exists of draft-troan-homenet-sadr-00 == Outdated reference: A later version (-01) exists of draft-xu-rtgwg-twod-ip-routing-00 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Kuarsingh, Ed. 3 Internet-Draft Rogers Communications 4 Intended status: Informational J. Brzozowski 5 Expires: January 5, 2014 Comcast Cable Communications 6 C. Grundemann 7 CableLabs 8 J. McQueen 9 Broadcom Corporation 10 July 4, 2013 12 An incremental solution to advanced home networking 13 draft-jvkjjmb-home-networking-incremental-00 15 Abstract 17 The home network is an environment subject to ongoing evolution and 18 change. Many home networks today are simplistic in nature, often 19 comprising of a single router/gateway. The expectation over time is 20 predicated on the notion that the home network will be more complex 21 servicing many in-home and Internet functions. The home network will 22 evolve necessitating the replacement and update to current hardware 23 and software to more advanced devices and software capable of 24 operating in more complex environments. This document provides a 25 view on how the home network can progress from today's foundational 26 form, to a more advanced environment, using progressive technological 27 capabilities. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 5, 2014. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Home Network Progression and Dynamics . . . . . . . . . . . . 6 72 3.1. Early Home Networks . . . . . . . . . . . . . . . . . . . 6 73 3.2. Home Network Upgrades and Evolution . . . . . . . . . . . 7 74 3.3. Home Networking Progression Considerations . . . . . . . . 7 75 3.4. Described Phases . . . . . . . . . . . . . . . . . . . . . 9 76 4. Phase 1: Elementary Network . . . . . . . . . . . . . . . . . 9 77 4.1. Service Potential . . . . . . . . . . . . . . . . . . . . 9 78 4.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 10 80 4.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 5. Phase 2: Medius Network . . . . . . . . . . . . . . . . . . . 11 82 5.1. Service Potential . . . . . . . . . . . . . . . . . . . . 11 83 5.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 5.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 13 85 5.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 6. Phase 3: Provectus Network . . . . . . . . . . . . . . . . . . 14 87 6.1. Service Service Potential . . . . . . . . . . . . . . . . 15 88 6.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 6.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 15 90 6.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 7. Phase 4: Posterus Network . . . . . . . . . . . . . . . . . . 18 92 7.1. Service Potential . . . . . . . . . . . . . . . . . . . . 18 93 7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 7.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 20 95 7.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 101 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 104 1. Introduction 106 The progression of the home IP network to more advanced states will 107 require an evolution from more primitive topologies and protocol 108 support to the eventual advanced topologies with more robust protocol 109 support. Home networks continue to advance from environments 110 originally intended to connect multiple subscriber hosts to a common 111 Internet connection to future environments where Internet, 112 teleworking, home automation, and other functions become common. 114 In support of this evolution, this document outlines an incremental 115 approach which begins with basic functionality laid out in [RFC6204] 116 and culminates with more advanced topologies and functions. The more 117 advanced home network would align well with the homenet architecture 118 as described in [draft-ietf-homenet-arch] along with potential 119 supporting technologies and concepts like Source Address Routing 120 [draft-troan-homenet-sadr], multi-homing 121 [draft-haddad-homenet-multihomed], IGP based prefix assignment 122 [draft-arkko-homenet-prefix-assignment] and/or 123 [draft-baker-homenet-prefix-assignment]. 125 The criticality and evolution of the customer premises or home 126 network is growing in complexity and importance as the variety and 127 quantity of services being delivered using the Internet Protocol 128 continues to increase. Coupled with these growing needs and the 129 deployment of IPv6 an opportunity exists to advance the state of home 130 networking in an incremental fashion. The introduction of IPv6 131 support within the home today to facilitate the transition allows for 132 basic Internet access over IPv6, however, this is simply inadequate 133 long term. Home networking technology must advance beyond providing 134 access to Internet content, it must evolve with the goal to improve 135 the customer experience and ensure that the in home network 136 infrastructure is robust and reliable enough to support next 137 generation services. 139 As part of the evolution and the introduction of IPv6 support the 140 home network support for IPv4 must not be overlooked. Support for 141 IPv4 will remain in devices for years to come and IPv4 will likely 142 continue to be used within the home as IPv4 connectivity to the 143 Internet undergoes dramatic change during the transition to IPv6. As 144 such it is essential that efforts to modernize home networking not 145 only account for both IPv4 and IPv6, these activities must also allow 146 for an incremental approach that does not require flash upgrades of 147 the home networking infrastructure and technology or hardware 148 replacement. 150 Finally, as home networking technology continues to advance long term 151 the intermediate phases must strive for interoperability to help 152 ensure a seamless transition and to act as an enabler. This is 153 particular importance for brownfield adopters. 155 1.1. Requirements Language 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 2. Terminology 163 Home IP Network Router a node intended for home or small-office 164 use that forwards packets not explicitly 165 addressed to itself. 167 Customer Edge Router (CER) a router that connects the end-user 168 network to a service provider network. 170 Internal Router an additional router deployed in the home 171 or small-office network that is not 172 attached to a service provider network. 173 Note that this is a functional role; it is 174 expected that there will not be a 175 difference in hardware or software between 176 a CER and IR, except in such cases when a 177 CER has a dedicated non-Ethernet WAN 178 interface (e.g. DSL/cable/ LTE modem) that 179 would preclude it from operating as an IR. 181 Down Interface a router's attachment to a link in the end- 182 user network on which it distributes 183 addresses and/or prefixes. Examples are 184 Ethernet (simple or bridged), 802.11 185 wireless, or other LAN technologies. A 186 router may have one or more network-layer 187 down interfaces. 189 Service Provider an entity that provides access to the 190 Internet. In this document, a service 191 provider specifically offers Internet 192 access using IPv6, and may also offer IPv4 193 Internet access. The service provider can 194 provide such access over a variety of 195 different transport methods such as DSL, 196 cable, wireless, and others. 198 Up Interface a router's attachment to a link where it 199 receives one or more IP addresses and/or 200 prefixes. This is also the link to which a 201 CER or IR points its default route. 203 depth the number of layers of routers in a 204 network. A single router network would 205 have a depth of 1, while a router behind a 206 router behind a router would have a depth 207 of 3. 209 width The number of routers that can be directly 210 subtended to an upstream router. A network 211 with three directly attached routers behind 212 the CER would have a width of 3. 214 3. Home Network Progression and Dynamics 216 3.1. Early Home Networks 218 Early home networks, as those observed as of the writing of this 219 document, tend to be comprised of few routing zones and layer 3 220 boundaries. Most home networks attached to operator networks are 221 comprised of a single home LAN segment, or may often have a guest 222 network based on default capabilities of off the shelf vendor 223 platforms. 225 The object of early home network environments was closely related to 226 providing basic Internet connectivity for subscribers. This trend 227 started back in the late 90's and early 2000s when traditional 228 dial-up connections were replaced with more robust broadband 229 connections. These newer and faster connections provided the 230 bandwidth and flexibility to power home networks which typically used 231 a single gateway towards the Operator's network and Internet. 233 From an IPv6 perspective this approach was also adopted to ensure 234 that the transition from the use of IPv4 to IPv6 could begin. The 235 objective here has been to enable as long a period of time as 236 possible to encourage the incremental transition to the use of IPv6 237 while avoiding or delaying the use impactful and costly transition 238 technologies. 240 Subscriber expectations during the early network phases were to 241 connect multiple machines to the Internet over a single connection. 242 Early Internet services were often traditional web (HTTP), Mail 243 (SMPT/POP3/IMAP) and news (NNTP) among others. Most services other 244 then the Internet were often supported by legacy technologies. Such 245 other services may have included legacy Video (Cable and/or Satellite 246 TV), Voice (PSTN) and the like. 248 3.2. Home Network Upgrades and Evolution 250 The home network, although originally used for very basic Internet 251 connectivity, is now beginning to expand to support many more 252 services. Some of the historical expansion within the home includes 253 the use of the home network for Media like Photo viewing, Movies 254 viewing and communications between in-home devices. During the 255 2000s, the home network also saw a strong growth on how it was used 256 for more commercial functions such as online video streaming, peer to 257 peer communications, remote teleworking, and social networking. 259 The expansion to date did not necessarily require more complex home 260 networks, but did expand the use of the common IP connection provided 261 to subscribers. Some historical expansion within the home networks 262 were related to advancement of legacy services such as voice which 263 has transformed to VoIP in recent years. Operators often used 264 technological frameworks, such as Packet Cable [PacketCable], to 265 enable legacy services over IP. These newer functions expanded the 266 home network or at times the gateway functions attaching to the 267 operator's network. Future expansion and/or enhancements similar to 268 VoIP in some operator networks include IPTV. 270 The evolution of the home network continues as subscribers are 271 beginning to use the home network to connect many new IP enabled 272 devices. These new IP enabled devices include home security 273 endpoints, sensors, appliances, home electronics among many others. 274 As these new uses become prevalent in the home network, so do the 275 needs of the attached devices, and the somewhat arbitrary ecosystem 276 that is used to attach them. It is the expectation that this 277 expanding ecosystem will create more robust and topologically complex 278 home networks. It is not well understood how long or fast this 279 evolutionary path will take, but the evolution has started. 281 The topological attachment and addressing needs within the home 282 network will need to be supported by the infrastructure which 283 comprises the home network. The upstream operators will need to be 284 cognizant of this need such as to provide the correct address sizes 285 and/or address elements. The underlay routing platforms will also 286 need to support the evolving home network to allow for growth and 287 robust home network environment. 289 3.3. Home Networking Progression Considerations 291 Evolving from basic to intermediate or advanced home networks there 292 are a number of considerations. These considerations range from 293 technical matters specific to implementation to operational and 294 deployment considerations. 296 Unlike green field deployments most operators and customers must take 297 into consideration that existing products and services must continue 298 to be supported. It is also important to note that the process to 299 upgrade must be seamless and non-disruptive. Disruption during the 300 upgrade process will not only have direct impact to the customers of 301 the same, but also directly impact the operators who deliver the 302 same. Support call volumes and impacts to operator infrastructure 303 must be factored in to the process of new technology introduction 304 whether it is basic support for IPv6 Internet connectivity or 305 intermediate/advanced home networking. 307 While most modern home network devices are software upgradeable to 308 introduce new functionality, some feature and enhancements exceed 309 device capabilities. Further there is a large population of home 310 networking devices that are based on an earlier generation of 311 technology as such may not be upgradeable to even the most basic form 312 of home networking. Fortunately operators actively work to ensure 313 their infrastructure is modernized to ensure the greatest feature set 314 and performance are available to their customers. 316 For those platforms that are upgradeable, which is a non trivial 317 population for most operators, the implementation process can be 318 complex. Complexity is presented in many forms ranging from the 319 technical details to integration with other essential features that 320 must be supported. Technical functionality must be balanced with 321 simplicity. Features that are overly complex impact implementers, 322 customers, and operators. As such it is essential that technical 323 solutions be implementable and supportable by vendors, deployable by 324 operators, and usable by customers. Testing and interoperability are 325 critical aspects of advancing any technology; this is especially the 326 case with home networking largely due to the significant quantity of 327 unique devices that are in use with broadband enabled home networks. 328 The quantity and types of devices that are connected today are vast 329 and unique, there are probably very few home networks that are alike 330 today. As such innovators of the home network must ensure that they 331 develop the technologies with support for legacy devices while laying 332 the ground work for the next generation of connected devices and the 333 services that they enable. 335 Continued support for IPv4 to the Internet is a must at the time this 336 document was written. While efforts advance to someday enable IPv6 337 only with consumer electronics and content providers support for IPv4 338 remains essential and cannot be ignored or forgotten. Further, at 339 the time IPv6 only becomes a reality, it is likely that IPv4 (even 340 for dual stack in home devices) will continue to be used, possibly 341 for decades to comes. Since it is difficult to determine if or when 342 IPv4 will no longer be required operators and innovators must ensure 343 that IPv4 continues to be supported. 345 3.4. Described Phases 347 The phases described below are intended to provide a descriptive of 348 how the the overall transition from early home networks can evolve to 349 advanced home networks that support more complex functions. These 350 phases are labeled as "Elementary" (Initial), "Medius" (Middle), 351 "Provectus" (Advanced) and "Posterus" (Subsequent). The phase labels 352 chosen are for reference purposes only within this document and do 353 not hold any significance for global meaning. 355 4. Phase 1: Elementary Network 357 The Elementary network phase is closely associated to the basic 358 environment described in section two of this document. The phase is 359 based on basic connectivity from a simple home network toward the 360 Internet. As a starting point, future phases are built assuming this 361 phase was generally present. While some greenfield environments may 362 emerge, most future more advanced home networks will expand out of a 363 basic home network. 365 The Elementary network will likely have basic functionality at the 366 operator/Internet edge (subscriber's point of reference) as outlined 367 in [RFC6204]. In addition to IPv4 legacy functionality, [RFC6204] 368 lays out basic requirements for IPv6 connectivity. With reference to 369 IPv6, the main emphasis was the attachment of the home network to the 370 IPv6 Internet, along with any legacy attachment to the IPv4 Internet. 372 4.1. Service Potential 374 In the Elementary network, as noted, connectivity is quite basic and 375 allows a simple home network to connect to the IPv4 and/or IPv6 376 Internet. Services envisioned to be used in this phase are very 377 similar to those which are already well established. Such services 378 include traditional Internet services such as web (HTTP), mail, news, 379 ftp, peer to peer, social networking, teleworking among many others. 381 Given the simplistic topological nature of this phase, there is less 382 flexibility for downstream segments to be attached, and the in-home 383 environment that is supported is assumed to be flat in nature (single 384 layer 2 domain, with a potential secondary environment such as a 385 guest net). Attaching networks, like a sensor net may not be well 386 serviced in such a model since such environments may require layer 3 387 separation and/or advanced device functionality. 389 4.2. Topology 391 The topology in the Elementary phase is basic in nature and often 392 assumed to be flat with some exceptions for additional segments like 393 a guest net. The topology in this phase may bridge multiple switched 394 and WiFi environments. It is possible that tandem routers may show 395 up in the Elementary phase, and those environments would 396 topologically be downstream sub-network environments with little 397 integration with the upstream IPv4 environment and likely no support 398 for IPv6 on the sub-network/tandem LAN network (not shown in Figure 1 399 below). 401 +-------+-------+ \ 402 | Service | \ 403 | Provider | | Service 404 | Router | | Provider 405 +-------+-------+ | network 406 | / 407 | Customer / 408 | Internet connection / 409 | 410 +------+--------+ \ 411 | IPv6 | \ 412 | Customer Edge | \ 413 | Router | / 414 +---+-------+-+-+ / 415 Network A | | Network B (Guest) | End-User 416 ---+-------------+----+- --+--+-------------+--- | network(s) 417 | | | | \ 418 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 419 | Host | | Host | | Host | | Host | / 420 | | | | | | | | / 421 +----------+ +-----+----+ +----------+ +----------+ / 423 Figure 1: Basic Home Network 425 4.3. Addressing 427 Addressing in the Elementary phase will be supported by legacy IPv4 428 addressing behaviours and IPv6 addressing behaviours as described in 429 [RFC6204]. IPv4 would operate much like it has for many years using 430 [RFC1918] addressing in the home network and translating (NAT44) 431 traffic flows to/from the Internet using a single IPv4 global address 432 assigned to the subscriber's gateway (operating facing interface). 433 IPv6 is expected to utilize a prefix delegation as described in 434 [RFC6204] and allow addresses from within the delegated prefix to be 435 assigned to hosts (or auto-configured by hosts using announced 436 prefix) on the guest network. 438 For cases where the operator supplies a single /64, only a single 439 segment can be supported on the home network. In cases where larger 440 prefixes are assigned to the subscriber's gateway, additional 441 segments can receive a /64 assignment for use on those segments. For 442 the most part, those segments are assumed to be attached directly off 443 the customer's edge router. Network side addressing will typically 444 be provided by DHCPv6 [RFC3633] or RADIUS [RFC4818]. 446 4.4. Routing 448 Routing in the Elementary network is also quite basic in nature. 449 Since the layer 3 segments are typically attached to a single 450 gateway, routing is conducted by the single gateway which uses a 451 default route pointing to the upstream provider. The provider will 452 have gleaned routing state which is gleaned from the DHCPv6 453 transaction and/or RADIUS addressing as stated in the section above. 455 5. Phase 2: Medius Network 457 The Medius network extends and builds upon the concepts established 458 in the Elementary phase. The Medius network is intended to 459 incrementally enable and evolve the home network by going beyond 460 basic IPv4 and/or IPv6 access to the Internet. In the Medius phase, 461 the objective are to go beyond basic access to content and services 462 on the Internet. Medius leverages the basic concepts established in 463 the Elementary phase as building blocks for more advanced in home 464 functionality while acting as a foundation for future iterations of 465 home networking. Medius will not only act as an enabler but will 466 also provide criticality required transition capabilities to ensure 467 advanced phases can also be deployed seamlessly to both customers and 468 operators with minimal disruption. 470 5.1. Service Potential 472 Medius enables natively routable IP within a home or customer 473 premise. Leveraging mostly existing techniques and technology, 474 Medius fortifies and advances the home network to support the 475 delivery of next generation content and services while maintaining 476 balance from an implementation and deployment point of view. A 477 Medius home network alleviates the notion of nest IPv4 address and 478 port translation within a home or premises so that both IPv4 and IPv6 479 communications are high performance and reliable. Next generation 480 applications, services, and content will benefit greatly from a 481 native environment within the home as it is well known that address 482 and port translation not only introduce latency and delays but also 483 hamper the premise wide experience for customers. A native 484 environment will allow customers to take full advantage of all 485 devices and applications that are and will appear throughout their 486 home networks. 488 5.2. Topology 490 The topology of a Medius home network, unlike that of the Elementary 491 phase, will be that of a native IP network in that there is expected 492 to be no translation within the premises. The only place where 493 translation is likely to occur is at the premises edge facing the 494 Internet or service provider and will be for IPv4 only, which is 495 common place today for most home networks. Non-Medius devices will 496 continue to be supported, however, the experience and functionality 497 of a Medius environment may not be fully achievable. The Medius 498 network will leverage a tree topology and can support flexibility in 499 how sub-tended devices are connected and provisioned. However, while 500 the Medius topology can support sub-tended devices the expectation 501 here is that the advanced home networking phase will introduce 502 support for greater flexibility as the need arises. The flexibility 503 of the Medius topology meets the near to mid term flexibility 504 requirements for the customer premises. In a Medius home network 505 interface detection is supported allowing for devices to be connected 506 and reconnected to one another in a manner that will enable each to 507 be reconfigured along with any connected devices. Unlike the 508 Elementary phase, Medius will support multiple routed segments and a 509 home network hierarchy not just a primary segment and guest segment 510 providing greater flexibility in how devices within the customer 511 premises connect and access content and services over the internal 512 segments and on the Internet. 514 +-------+-------+ \ 515 | Service | \ 516 | Provider | | Service 517 | Router | | Provider 518 +-------+-------+ | network 519 | / 520 | Customer / 521 | Internet connection / 522 | 523 +------+--------+ \ 524 | IPv6 | \ 525 | Customer Edge | \ 526 | Router | / 527 +---+-------+-+-+ / 528 Network A | | Network B | End-User 529 ---+-------------+----+- --+--+-------------+--- | network(s) 530 | | | | \ 531 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 532 | Host | |Internal | | Host| |Internal | / 533 | | | Router | | | | Router | / 534 +----------+ +-----+----+ +----------+ +----------+ / 535 Network C | Network D | | 536 ---+-------------+----+- --+--+-------------+--- | 537 | | | | \ 538 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 539 | Host | | Host | | Host| | Host | / 540 | | | | | | | | / 541 +----------+ +-----+----+ +----------+ +----------+ / 543 Figure 2: Progressive Home Network 545 5.3. Addressing 547 The Medius network assumes greater flexibility and extensibility, and 548 as such, the addressing within the premises must be comparable. 549 Nodes or endpoints will be able to leverage all common techniques for 550 both IPv4 and IPv6 addresses. For IPv4, DHCP and static addressing 551 will be supported, however, dynamic addressing techniques are 552 preferred. For IPv6, stateless auto-configuration with [RFC6106] 553 support, stateless and stateful DHCPv6, and static addressing are all 554 supported. Stateful DHCPv6 includes support for IPv6 prefix 555 delegation [RFC3633]. For IPv6, all forms of dynamic addressing are 556 preferred over any form of static assignments. 558 Sub-tended routing devices in a Medius home network will leverage 559 IPv6 prefix delegation [RFC3633]. The width and depth of the duo 560 home network will provide the guidance required to determine the size 561 of sub-delegated prefixes to ensure the greatest depth and width for 562 a Medius home network. While Medius home networks have flexibility 563 for sub-delegated networks, it is expected that the typical Medius 564 home network will have a limited quantity of connected, sub-tended 565 devices. The overarching objective of the Medius network is to 566 alleviate overly flat home networks while enabling high performance, 567 reliably home networks that can be used to provide service to and 568 support next generation content, services, and applications. 570 In a Medius home network, IPv6 techniques can be leveraged to 571 bootstrap the provisioning and enablement of IPv4 natively. The 572 provisioning and enablement of IPv4 care of IPv6 enables congruent 573 IPv4 and IPv6 topologies and routing within a customer premises. 574 Congruent IPv4 and IPv6 help to ensure that ideal conditions are in 575 place within the home to enable the greatest performance, 576 reliability, and stability by dynamically altering security and 577 routing configurations. The details of IPv6 bootstrapped IPv4 578 provisioning is out of scope for this document. 580 5.4. Routing 582 The Medius home network does not currently require a dynamic routing 583 protocols for routing or provisioning purposes. Provisioning 584 techniques specified for Medius home networks are outlined in the 585 addressing section above. Routing for duo home networks is governed 586 by each routing device. The customer or premise edge router (facing 587 the Internet or service provider) is aware of both IPv4 and IPv6 588 routing information, care of the provisioning process, for sub-tended 589 device. Each router in a duo home network will act as a default 590 route for all connected devices. If a routing device supports 591 multiple connected, routed segments, routing information for all 592 connected segments will be known inherently by the device, otherwise, 593 the device will send all traffic to its own default route learned 594 from its "up" interface. 596 The Medius topology, addressing, and routing collectively act as 597 foundational elements for future states of the home network. In 598 fact, advanced home networking techniques may not be achievable 599 without aspects of Mediux being deployed in customer premises 600 networks. 602 6. Phase 3: Provectus Network 604 The Provectus phase is a progressive option beyond the Medius network 605 with the option to turn on a routing protocol. Efficiency can be 606 gained here while keeping addressing common from the previous model. 607 This model effectively allows for a routing protocol to be added 608 (will be explained in routing section below in more detail) allowing 609 for better flow efficiency in-home, likely helping more advanced home 610 networks where there are more in-home services/operations. 612 A routing protocol can be added to an existing Medius Network as an 613 "add on" feature. Among the advantages of having a routing protocol 614 enabled is that it provides an efficient and dynamic network topology 615 in the home. With respect to efficiency, a routing protocol will aid 616 in maintaining a routing table with the sense of metric or hops to 617 destinations. Additionally, a routing protocol can aid in the 618 network dynamic scalability. 620 The details of which specific routing protocol to use are out of 621 scope for this text; however, we will discuss how some of the common 622 routing protocols could help improve on an existing Medius Network. 624 6.1. Service Service Potential 626 The main service advantage of a Provectus Network is that it will 627 provide more seamless flexibility and transition when routers in the 628 home are either added, removed, or moved to a different location in 629 the network. Additionally, a routing protocol can provide a more 630 seamless transition upon IP configuration changes. It is important 631 to note that the added flexibility and efficiency may be lost when 632 there are inline routers which do not support or enable the same 633 routing protocol. In such a case, the system may revert to the 634 Medius network operation (not as efficient, but functional). 636 6.2. Topology 638 The topology for the Provectus network phase is expected to be 639 similar to that of the Medius network phase. 641 6.3. Addressing 643 The Provectus Network IP addressing considerations match those of the 644 Medius phase with all IP addressing adhering to the HIPNet DHCPv6 and 645 recursive prefix delegation model described above. 647 All downstream routers to the CER will request an IPv6 prefix (IA_PD) 648 via DHCPv6 along with an IPv6 address (IA_NA). DHCPv6 will provide 649 address and prefix information for a specific lifetime. 651 Upstream routers are able to create a routing table based on the 652 address and prefix information provided to downstream routers while 653 the DHCP lease is active. Without a routing protocol, upstream 654 routers will not be instantly aware of when a downstream router is 655 being removed from or moved within the home network. The upstream 656 routers will eventually learn of a removed or moved router when the 657 DHCPv6 lifetime expires or if the router imposes other gleaning or 658 keep alive logic to track router movement. 660 In another scenario, an upstream HIPnet router's width or depth could 661 be presently maximized and there is the need to replace one router 662 connected on the width or depth with another router. The upstream 663 router will be unable to provision the new router on the network 664 until it detects that the previous router has been removed from the 665 network. Without a routing protocol, the time needed to discover 666 this topology change will most likely be longer and it places a 667 dependency on the router which is not implementing a routing protocol 668 to assure that it cleans up its own routing table when DHCP leases 669 expire. 671 6.4. Routing 673 A routing protocol provides either instant and/or periodic 674 notification of the addition and deletion of downstream routers. 676 HIPNet-based upstream routers are aware of the prefixes that are 677 provisioned to the downstream routers and on which interface that 678 prefix route is associated. The downstream routers will refresh 679 and/or update that initial routing configuration. 681 A routing protocol simplifies the efforts needed by HIPNet routers 682 not implementing a routing protocol by eliminating the probing of 683 routing information with DHCPv6 and perhaps, Neighbor Discovery 684 [RFC4861] messages of downstream routers. 686 Additionally, a routing protocol could help support a router with 687 manual IPv6 prefix configuration. In a HIPNet router configuration, 688 recursive prefix delegation is assumed to cascade prefix information 689 to sub-tending downstream routers. However, with a routing protocol, 690 it could support a directly connected router or line of routers with 691 manual prefix configuration. 693 The routing protocol detailed here is assumed to be carrying only 694 route information and does not consider the presence of any other 695 configuration data. 697 Initially, it should also be assumed that the same routing protocol 698 is used within the home network and there would not be the need for 699 redistributing between multiple routing protocols. 701 Additionally, it is assumed that there will be no configuration 702 information passed along within the routing protocol for the 703 Provectus phase. That is, the routing protocol will simply be used 704 to maintain and update routing tables. 706 Some standard routing protocols to be considered for a Provectus 707 network (but not limited to) are: 709 - RIPng [RFC2080] 711 - OSPFv2 [RFC2328] and/or OSPFv3 [RFC5340] / [RFC5838] 713 - IS-IS (may also be candidate for phase 4 with multihoming) [ISO- 714 ISIS] 716 RIPng 718 - Distance vector protocol (hop count based) 720 - UDP protocol, port 521 722 - Multicast based messaging0 724 - Authentication done by IPv6 IPSEC layer 726 Advantages of RIPng 728 - Simple in design/implementation 730 - Supported a network topology change immediate route update 732 Disadvantages of RIPng 734 - Naturally converges slowly with default 30 second reporting 735 interval 737 - Multicast advertisement of complete routing table on every 738 reporting interval 740 - Hop Limit max of 15, 16 means infinity and considered 741 unreachable 743 - Requires split horizon to report only those routes not sourced 744 by the destination router. 746 OSPF 748 - Link state protocol (route cost based) 750 - IP based protocol 752 - Authentication done by IPv6 IPSEC layer 754 Advantages of OSPF 756 - Only updates when change in route table occurs - low network 757 overhead 759 - Limited only by size of routing table 761 - Low convergence time 763 Disadvantages of OSPF 765 - More complex in design/implementation 767 - May be difficult to configure 769 7. Phase 4: Posterus Network 771 The Posterus phase of home network development looks beyond many of 772 the current home networking paradigms and allows more dramatic 773 changes to surface. This phase can be characterized by two general 774 enhancements over previous phases; IGP enhancements allowing things 775 like prefix distribution and better multihoming capabilities, 776 possibly through source address route selection as described in 777 documents like [draft-troan-homenet-sadr] . The Posterus phase is 778 the focus of much of the current work of the Homenet working group. 780 Because the Posterus phase is the furthest into the future, it has 781 the most potential to change over time. As such, this document 782 captures current ideas and thinking but should not be seen as 783 limiting in any way the potential for future progress within home 784 networks. Additionally, many of the more dramatic changes currently 785 envisioned for this phase (e.g. IGP prefix distribution) are not 786 backwards compatible with existing home routers, nor those that are 787 likely to emerge in the Medius and Provectus phases. This 788 fundamental principle may restrain the Posterus phase deployments to 789 those home networks which actively require the added functionality 790 and efficiency. 792 7.1. Service Potential 794 The primary and most obvious service enhancement of the Posterus 795 phase is the enhancement of multihoming, connecting the home network 796 to multiple ISPs simultaneously for added bandwidth and/or enhanced 797 resiliency to WAN connectivity outages. Of course, multihoming isn't 798 limited only to multiple ISP connections, it could also enable the 799 connection of multiple discreet home networks thus enabling new 800 services related to local content sharing and caching. Also, as this 801 phase leverages routing protocols specifically tailored to home 802 networking, further service enhancements may be possible. Service 803 discovery is one area which may benefit from such enhancements if 804 these routing protocols are extended to share such information. 806 7.2. Topology 808 Posterus supports longer term, advanced home network topologies. As 809 mentioned above, this is primarily focused on enabling multiple ISP 810 connections, which is illustrated in figure 3, below. Other 811 topological changes in this phase may include connections to other, 812 non-ISP networks and other more complex home network topologies. 814 +-------+-------+ \ 815 | Service | \ 816 | Provider | | Service 817 | Router | | Provider 818 +-------+-------+ | network 819 +------------+ | / 820 | ISP 2 | | Customer / 821 +------------+ | Internet connection / 822 | | 823 | +------+--------+ \ 824 | | IPv6 | \ 825 | | Customer Edge | \ 826 | | Router | / 827 | +---+-------+---+ / 828 | Network A | | Network B | End-User 829 | -------+----+- --+--+-------------+--- | network(s) 830 | | | | \ 831 | +-----+----+ +----+-----+ +-----+----+ \ 832 +-----|Secondary | | Host 1| |Internal | / 833 | CER | | | | Router | / 834 +-----+----+ +----------+ +----------+ / 835 Network C | Network D | | 836 ---+-------------+----+- --+--+-------------+--- | 837 | | | | \ 838 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 839 | Host 2| | Host 3 | | Host 4| | Host 5 | / 840 | | | | | | | | / 841 +----------+ +-----+----+ +----------+ +----------+ / 843 Figure 3: Complex Network with Two ISP Connections 845 7.3. Addressing 847 Posterus has the potential to see the most dramatic shift in 848 addressing of all the phases documented here. As described in 849 [draft-arkko-homenet-prefix-assignment], one of the key enhancements 850 in this phase may be the distribution of prefix information through 851 an enhanced IGP. The use of IGP prefix distribution has the distinct 852 advantage of breaking from the hierarchical prefix distribution 853 mechanisms introduced in the Medius phase, enabling much more 854 efficient use of the prefix' available to the home network. This is 855 a significant advantage in home networks that are allocated a small 856 prefix, such as a /60. Also, while the "Link ID" concept introduced 857 in the Medius phase will allow for the use of multiple address 858 families and multiple distinct prefixes within the home network, the 859 IGP prefix distribution also promises to further facilitate the use 860 of prefix' from more than one ISP. 862 The inherent complication introduced by IGP prefix distribution is 863 one of backwards compatibility. Home routers in the Elementary, 864 Medius and Provectus phase, in addition to all current home routers, 865 use DHCPv6 PD [RFC3633] exclusively for prefix distribution within 866 the home. A home router designed to use DHCP [RFC3633] will be able 867 to provide a prefix to a downstream Posterus phase router, but would 868 be unable to accept a prefix delegated from an upstream Posterus 869 phase router via an enhanced IGP. 871 7.4. Routing 873 Routing in Posterus will likely introduce source address route 874 selection, currently described in [draft-troan-homenet-sadr] and 875 [draft-xu-rtgwg-twod-ip-routing]. Source address route selection 876 uses both the source and destination addresses when determining the 877 proper routing of packets leaving the home network. This will 878 greatly enhance the multihoming capabilities of home networks by 879 ensuring that communications initiated within the home network will 880 always use the proper upstream ISP, avoiding ingress filtering 881 present on most residential broadband access networks like [RFC2827]. 883 In addition to enhanced multihoming capabilities, source address 884 route selection may also be leveraged for access control within home 885 networks. Since each layer 3 domain within a home network can be 886 identified by the specific prefix' being used on that segment, source 887 address based access control provides an effective means of 888 implementing policy in routing. 890 8. IANA Considerations 892 This document makes no request of IANA. 894 Note to RFC Editor: this section may be removed on publication as an 895 RFC. 897 9. Security Considerations 899 No security considerations noted at this time. 901 10. Acknowledgements 903 Special thanks for the following people for their contributions. 905 11. References 907 11.1. Normative References 909 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 910 Requirement Levels", BCP 14, RFC 2119, March 1997. 912 11.2. Informative References 914 [I-D.arkko-homenet-prefix-assignment] 915 Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment 916 in a Home Network", 917 draft-arkko-homenet-prefix-assignment-04 (work in 918 progress), May 2013. 920 [I-D.baker-homenet-prefix-assignment] 921 Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small 922 Networks", draft-baker-homenet-prefix-assignment-01 (work 923 in progress), March 2012. 925 [I-D.haddad-homenet-multihomed] 926 Haddad, W. and D. Saucez, "Multihoming in Homenet", 927 draft-haddad-homenet-multihomed-01 (work in progress), 928 March 2013. 930 [I-D.ietf-homenet-arch] 931 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 932 "Home Networking Architecture for IPv6", 933 draft-ietf-homenet-arch-08 (work in progress), May 2013. 935 [I-D.troan-homenet-sadr] 936 Troan, O. and L. Colitti, "IPv6 Multihoming with Source 937 Address Dependent Routing (SADR)", 938 draft-troan-homenet-sadr-00 (work in progress), 939 February 2013. 941 [I-D.xu-rtgwg-twod-ip-routing] 942 Xu, M., Wu, J., Yang, S., and D. Wang, "Two Dimensional IP 943 Routing Architecture", draft-xu-rtgwg-twod-ip-routing-00 944 (work in progress), March 2012. 946 [ISO-ISIS] 947 "ISO/IEC 10589:2002 Intermediate System to Intermediate 948 System intra-domain routeing information exchange 949 protocol", 3 2008, . 952 [PacketCable] 953 CableLabs, "Packet CableTM 2.0 Architecture Framework 954 Technical Report", May 2009, . 957 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 958 E. Lear, "Address Allocation for Private Internets", 959 BCP 5, RFC 1918, February 1996. 961 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 962 January 1997. 964 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 965 RFC 2131, March 1997. 967 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 969 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 970 Defeating Denial of Service Attacks which employ IP Source 971 Address Spoofing", BCP 38, RFC 2827, May 2000. 973 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 974 Host Configuration Protocol (DHCP) version 6", RFC 3633, 975 December 2003. 977 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 978 Attribute", RFC 4818, April 2007. 980 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 981 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 982 September 2007. 984 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 985 for IPv6", RFC 5340, July 2008. 987 [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 988 Aggarwal, "Support of Address Families in OSPFv3", 989 RFC 5838, April 2010. 991 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 992 "IPv6 Router Advertisement Options for DNS Configuration", 993 RFC 6106, November 2010. 995 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 996 Troan, "Basic Requirements for IPv6 Customer Edge 997 Routers", RFC 6204, April 2011. 999 Authors' Addresses 1001 Victor Kuarsingh (editor) 1002 Rogers Communications 1003 8200 Dixie Road 1004 Brampton, ON L6T 0C1 1005 Canada 1007 Email: victor@jvknet.com 1009 John Jason Brzozowski 1010 Comcast Cable Communications 1011 1306 Goshen Parkway 1012 Chester, PA 19380 1013 USA 1015 Email: john_brzozowski@cable.comcast.com 1017 Chris Grundemann 1018 CableLabs 1019 858 Coal Creek Circle 1020 Louisville, CO 80027 1021 USA 1023 Email: c.grundemann@cablelabs.com 1024 John McQueen 1025 Broadcom Corporation 1026 16340 West Bernardo Drive 1027 San Diego, CA 92127 1028 USA 1030 Email: jmcqueen@broadcom.com