idnits 2.17.1 draft-chown-homenet-arch-01.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 (October 31, 2011) is 4554 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 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) == Outdated reference: A later version (-03) exists of draft-vyncke-advanced-ipv6-security-02 == Outdated reference: A later version (-05) exists of draft-ietf-6man-rfc3484-revise-04 == Outdated reference: A later version (-04) exists of draft-ietf-dhc-pd-exclude-03 == Outdated reference: A later version (-12) exists of draft-ietf-mif-dns-server-selection-07 == Outdated reference: A later version (-05) exists of draft-ietf-mif-dhcpv6-route-option-03 == Outdated reference: A later version (-01) exists of draft-baker-homenet-prefix-assignment-00 == Outdated reference: A later version (-04) exists of draft-arkko-homenet-prefix-assignment-00 == Outdated reference: A later version (-03) exists of draft-acee-ospf-ospfv3-autoconfig-00 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-16 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). 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 T. Chown 5 Expires: May 3, 2012 University of Southampton 6 J. Weil 7 Time Warner Cable 8 O. Troan 9 Cisco Systems, Inc. 10 October 31, 2011 12 Home Networking Architecture for IPv6 13 draft-chown-homenet-arch-01 15 Abstract 17 This text describes evolving networking technology within small 18 "residential home" networks. The goal of this memo is to define the 19 architecture for IPv6-based home networking and the associated 20 principles and considerations. The text highlights the impact of 21 IPv6 on home networking, illustrates topology scenarios, and shows 22 how standard IPv6 mechanisms and addressing can be employed in home 23 networking. The architecture describes the need for specific 24 protocol extensions for certain additional functionality. It is 25 assumed that the IPv6 home network runs as an IPv6-only or dual-stack 26 network, but there are no recommendations in this memo for the IPv4 27 part of the network. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 3, 2012. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . . 3 65 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Network Models . . . . . . . . . . . . . . . . . . . . . . 8 67 3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 12 68 3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 13 69 3.4. Principles . . . . . . . . . . . . . . . . . . . . . . . . 15 70 3.5. Summary of Homenet Architecture Recommendations . . . . . 21 71 3.6. Implementing the Architecture on IPv6 . . . . . . . . . . 22 72 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 73 4.1. Normative References . . . . . . . . . . . . . . . . . . . 22 74 4.2. Informative References . . . . . . . . . . . . . . . . . . 23 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 25 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 78 1. Introduction 80 This memo focuses on evolving networking technology within small 81 "residential home" networks and the associated challenges. For 82 example, a trend in home networking is the proliferation of 83 networking technology in an increasingly broad range of devices and 84 media. This evolution in scale and diversity sets requirements on 85 IETF protocols. Some of these requirements relate to the need for 86 multiple subnets, for example for private and guest networks, the 87 introduction of IPv6, and the introduction of specialized networks 88 for home automation and sensors. 90 While advanced home networks have been built, most operate based on 91 IPv4, employ solutions that we would like to avoid such as (cascaded) 92 network address translation (NAT), or require expert assistance to 93 set up. The architectural constructs in this document are focused on 94 the problems to be solved when introducing IPv6 with a eye towards a 95 better result than what we have today with IPv4, as well as a better 96 result than if the IETF had not given this specific guidance. 98 This architecture document aims to provide the basis and guiding 99 principles for how standard IPv6 mechanisms and addressing [RFC2460] 100 [RFC4291] can be employed in home networking, while coexisting with 101 existing IPv4 mechanisms. In emerging dual-stack home networks it is 102 vital that introducing IPv6 does not adversely affect IPv4 operation. 103 Future deployments, or specific subnets within an otherwise dual- 104 stack home network, may be IPv6-only. 106 [RFC6204] defines basic requirements for customer edge routers 107 (CPEs). The scope of this text is the homenet, and thus the internal 108 facing interface described that RFC as well as other components 109 within the home network. While the network may be dual-stack or 110 IPv6-only, specific transition tools on the CPE are out of scope of 111 this text, as is any advice regarding architecture of the IPv4 part 112 of the network. We assume that IPv4 network architecture in home 113 networks is what it is, and can not be affected by new 114 recommendations. 116 2. Effects of IPv6 on Home Networking 118 Service providers are deploying IPv6, content is becoming available 119 on IPv6, and support for IPv6 is increasingly available in devices 120 and software used in the home. While IPv6 resembles IPv4 in many 121 ways, it changes address allocation principles, makes multi- 122 addressing the norm, and allows direct IP addressability and routing 123 to devices in the home from the Internet. This section presents an 124 overview of some of the key areas impacted by the implementation of 125 IPv6 into the home network that are both promising and problematic: 127 Multiple segments and routers 129 Simple layer 3 topologies involving as few subnets as possible are 130 preferred in home networks for a variety of reasons including 131 simpler management and service discovery. However, the 132 incorporation of dedicated (routed) segments remains necessary for 133 a variety of reasons. 135 For instance, a common feature in modern home routers is the 136 ability to support both guest and private network segments. Also, 137 link layer networking technology is poised to become more 138 heterogeneous, as networks begin to employ both traditional 139 Ethernet technology and link layers designed for low-powered and 140 lossy networks (LLNs) such as those used for certain types of 141 sensor devices. Similar needs for segmentation may occur in other 142 cases, such as separating building control or corporate extensions 143 from the Internet access network. Also, different segments may be 144 associated with subnets that have different routing and security 145 policies. 147 Documents that provide some more specific background and depth on 148 this topic include: [I-D.herbst-v6ops-cpeenhancements], 149 [I-D.baker-fun-multi-router], and [I-D.baker-fun-routing-class]. 151 In addition to routing, rather than NATing, between subnets, there 152 are issues of when and how to extend mechanisms such as service 153 discovery which currently rely on link-local addressing to limit 154 scope. 156 The presence of a multiple segment, multi-router network implies 157 that there is some kind of automatic routing mechanism in place. 158 In advanced configurations similar to those used in multihomed 159 corporate networks, there may also be a need to discover border 160 router(s) by an appropriate mechanism. 162 Multi-Addressing of devices 164 In an IPv6 network, devices may acquire multiple addresses, 165 typically at least a link-local address and a globally unique 166 address. Thus it should be considered the norm for devices on 167 IPv6 home networks to be multi-addressed, and to also have an IPv4 168 address where the network is dual-stack. Default address 169 selection mechanisms [I-D.ietf-6man-rfc3484-revise] allow a node 170 to select appropriate src/dst address pairs for communications, 171 though such selection may face problems in the event of 172 multihoming, where nodes will be configured with one address from 173 each upstream ISP prefix, and the presence of upstream ingress 174 filtering thus requires multi-addressed nodes to select the right 175 source address to be used for the corresponding uplink. 177 Unique Local Addresses (ULAs) 179 [RFC4193] defines Unique Local Addresses (ULAs) for IPv6 that may 180 be used to address devices within the scope of a single site. 181 Support for ULAs for IPv6 CPEs is described in [RFC6204]. A home 182 network running IPv6 may deploy ULAs for communication between 183 devices within the network. ULAs have the potential to be used 184 for stable addressing in a home network where the externally 185 allocated global prefix changes over time or where external 186 connectivity is temporarily unavailable. However, it is 187 undesirable to aggressively deprecate global prefixes for 188 temporary loss of connectivity, so for this to matter there would 189 have to be a connection breakage longer than the lease period, and 190 even then, deprecating prefixes when there is no connectivity may 191 not be advisable. However, while setting a network up there may 192 be a period with no connectivity. 194 Another possible reason for using ULAs would be to provide an 195 indication to applications that the traffic is local. This could 196 then be used with security settings to designate where a 197 particular application is allowed to connect to. 199 Address selection mechanisms should ensure a ULA source address is 200 used to communicate with ULA destination addresses. The use of 201 ULAs does not imply IPv6 NAT, rather that external communications 202 should use a node's global IPv6 source address. 204 Security, Borders, and the elimination of NAT 206 Current IPv4 home networks typically receive a single global IPv4 207 address from their ISP and use NAT with private [RFC1918]. 208 addressing for devices within the network. An IPv6 home network 209 removes the need to use NAT given the ISP offers a sufficiently 210 large IPv6 prefix to the homenet, allowing every device on every 211 link to be assigned a globally unique IPv6 address. 213 The end-to-end communication that is potentially enabled with IPv6 214 is both an incredible opportunity for innovation and simpler 215 network operation, but it is also a concern as it exposes nodes in 216 the internal networks to receipt of otherwise unwanted traffic 217 from the Internet. 219 In IPv4 NAT networks, the NAT provides an implicit firewall 220 function. [RFC4864] suggests that IPv6 networks with global 221 addresses utilise "Simple Security" in border firewalls to 222 restrict incoming connections through a default deny policy. 223 Applications or hosts wanting to accept inbound connections then 224 need to signal that desire through a protocol such as uPNP or PCP 225 [I-D.ietf-pcp-base]. 227 Such an approach would reduces the efficacy of end-to-end 228 connectivity that IPv6 has the potential to restore, since the 229 need for IPv4 NAT traversal is replaced by a need to use a 230 signalling protocol to request a firewall hole be opened. 231 [RFC6092] provides recommendations for an IPv6 firewall that 232 applies "limitations on end-to-end transparency where security 233 considerations are deemed important to promote local and Internet 234 security." The firewall operation is "simple" in that there is an 235 assumption that traffic which is to be blocked by default is 236 defined in the RFC and not expected to be updated by the user or 237 otherwise. The RFC does however state that CPEs should have an 238 option to be put into a "transparent mode" of operation. 240 It is important to distinguish between addressability and 241 reachability; i.e. IPv6 through use of globally unique addressing 242 in the home makes all devices potentially reachable from anywhere. 243 Whether they are or not should depend on firewall or filtering 244 configuration, and not the presence or use of NAT. 246 Advanced Security for IPv6 CPE [I-D.vyncke-advanced-ipv6-security] 247 takes the approach that in order to provide the greatest end-to- 248 end transparency as well as security, security polices must be 249 updated by a trusted party which can provide intrusion signatures 250 and other "active" information on security threats. This is much 251 like a virus-scanning tool which must receive updates in order to 252 detect and/or neutralize the latest attacks as they arrive. As 253 the name implies "advanced" security requires significantly more 254 resources and infrastructure (including a source for attack 255 signatures) in comparision to "simple" security. 257 In addition to establishing the security mechanisms themselves, it 258 is important to know where to enable them. If there is some 259 indication as to which router is connected to the "outside" of the 260 home network, this is feasible. Otherwise, it can be difficult to 261 know which security policies to apply where. Further, security 262 policies may be different for various address ranges if ULA 263 addressing is setup to only operate within the homenet itself and 264 not be routed to the Internet at large. Finally, such policies 265 must be able to be applied by typical home users, e.g. to give a 266 visitor in a "guest" network access to media services in the home. 268 It may be useful to classify the border of the home network as a 269 unique logical interface separating the home network from service 270 provider network/s. This border interface may be a single 271 physical interface to a single service provider, multiple layer 2 272 sub-interfaces to a single service provider, or multiple 273 connections to a single or multiple providers. This border is 274 useful for describing edge operations and interface requirements 275 across multiple functional areas including security, routing, 276 service discovery, and router discovery. 278 Naming, and manual configuration of IP addresses 280 In IPv4, a single subnet NATed home network environment is 281 currently the norm. As a result, it is for example common 282 practice for users to be able to connect to a router for 283 configuration via a literal address such as 192.168.1.1 or some 284 other commonly used RFC 1918 address. In IPv6, while ULAs exist 285 and could potentially be used to address internally-reachable 286 services, little deployment experience exists to date. Given a 287 true ULA prefix is effectively a random 48-bit prefix, it is not 288 reasonable to expect users to manually enter such address literals 289 for configuration or other purposes. As such, even for the 290 simplest of functions, naming and the associated discovery of 291 services is imperative for an easy to administer homenet. 293 In a multi-subnet homenet, naming and service discovery should be 294 expected to operate across the scope of the entire home network, 295 and thus be able to cross subnet boundaries. It should be noted 296 that in IPv4, such services do not generally function across home 297 router NAT boundaries, so this is one area where there is scope 298 for an improvement in IPv6. 300 3. Architecture 302 An architecture outlines how to construct home networks involving 303 multiple routers and subnets. In this section, we present a set of 304 typical home network topology models/scenarios, followed by a list of 305 topics that may influence the architecture discussions, and a set of 306 architectural principles that govern how the various nodes should 307 work together. Finally, some guidelines are given for realizing the 308 architecture with the IPv6 addressing, prefix delegation, global and 309 ULA addresses, source address selection rules and other existing 310 components of the IPv6 architecture. The architecture also drives 311 what protocol extensions are necessary, as will be discussed in 312 Section 3.6. 314 3.1. Network Models 316 Figure 1 shows the simplest possible home network topology, involving 317 just one router, a local area network, and a set of hosts. Setting 318 up such networks is in principle well understood today [RFC6204]. 320 +-------+-------+ \ 321 | Service | \ 322 | Provider | | Service 323 | Router | | Provider 324 +-------+-------+ | network 325 | / 326 | Customer / 327 demarc #1 --> | Internet connection / 328 | 329 +------+--------+ \ 330 | IPv6 | \ 331 | Customer Edge | \ 332 | Router | / 333 +------+--------+ / 334 | | 335 demarc #2 --> | | End-User 336 | Local network | network(s) 337 ---+-----+-------+--- \ 338 | | \ 339 +----+-----+ +-----+----+ \ 340 |IPv6 Host | |IPv6 Host | / 341 | | | | / 342 +----------+ +-----+----+ / 344 Figure 1 346 Two possible demarcation points are illustrated in Figure 1, which 347 indicate which party is responsible for configuration or 348 autoconfiguration. Demarcation #1 makes the Customer Edge Router the 349 responsibility of the customer. This is only practical if the 350 Customer Edge Router can function with factory defaults installed. 351 The Customer Edge Router may be pre-configured by the ISP, or by some 352 suitably simple method by the home customer. Demarcation #2 makes 353 the Customer Edge Router the responsibility of the provider. Both 354 models of operation must be supported in the homenet architecture, 355 including the scenarios below with multiple ISPs and demarcation 356 points. 358 Figure 2 shows another network that now introduces multiple local 359 area networks. These may be needed for reasons relating to different 360 link layer technologies in use or for policy reasons. Note that a 361 common arrangement is to have different link types supported on the 362 same router, bridged together. 364 This topology is also relatively well understood today [RFC6204], 365 though it certainly presents additional demands with regards suitable 366 firewall policies and limits the operation of certain applications 367 and discovery mechanisms (which may typically today only succeed 368 within a single subnet). 370 +-------+-------+ \ 371 | Service | \ 372 | Provider | | Service 373 | Router | | Provider 374 +------+--------+ | network 375 | / 376 | Customer / 377 | Internet connection / 378 | 379 +------+--------+ \ 380 | IPv6 | \ 381 | Customer Edge | \ 382 | Router | / 383 +----+-------+--+ / 384 Network A | | Network B | End-User 385 ---+-------------+----+- --+--+-------------+--- | network(s) 386 | | | | \ 387 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 388 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 389 | | | | | | | | / 390 +----------+ +-----+----+ +----------+ +----------+ / 392 Figure 2 394 Figure 3 shows a little bit more complex network with two routers and 395 eight devices connected to one ISP. This network is similar to the 396 one discussed in [I-D.ietf-v6ops-ipv6-cpe-router-bis]. The main 397 complication in this topology compared to the ones described earlier 398 is that there is no longer a single router that a priori understands 399 the entire topology. The topology itself may also be complex. It 400 may not be possible to assume a pure tree form, for instance. This 401 would be a consideration if there was an assumption that home users 402 may plug routers together to form arbitrary topologies. 404 +-------+-------+ \ 405 | Service | \ 406 | Provider | | Service 407 | Router | | Provider 408 +-------+-------+ | network 409 | / 410 | Customer / 411 | Internet connection 412 | 413 +------+--------+ \ 414 | IPv6 | \ 415 | Customer Edge | \ 416 | Router | | 417 +----+-+---+----+ | 418 Network A | | | Network B/E | 419 ----+-------------+----+ | +---+-------------+------+ | 420 | | | | | | | | 421 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | | 422 |IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | | 423 | | | | | | | | | | | 424 +----------+ +-----+----+ | +----------+ +----------+ | | 425 | | | | | 426 | ---+------+------+-----+ | 427 | | Network B/E | 428 +------+--------+ | | End-User 429 | IPv6 | | | networks 430 | Interior +------+ | 431 | Router | | 432 +---+-------+-+-+ | 433 Network C | | Network D | 434 ----+-------------+---+- --+---+-------------+--- | 435 | | | | | 436 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 437 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 438 | | | | | | | | / 439 +----------+ +-----+----+ +----------+ +----------+ / 441 Figure 3 443 +-------+-------+ +-------+-------+ \ 444 | Service | | Service | \ 445 | Provider A | | Provider B | | Service 446 | Router | | Router | | Provider 447 +------+--------+ +-------+-------+ | network 448 | | / 449 | Customer | / 450 | Internet connections | / 451 | | 452 +------+--------+ +-------+-------+ \ 453 | IPv6 | | IPv6 | \ 454 | Customer Edge | | Customer Edge | \ 455 | Router 1 | | Router 2 | / 456 +------+--------+ +-------+-------+ / 457 | | / 458 | | | End-User 459 ---+---------+---+---------------+--+----------+--- | network(s) 460 | | | | \ 461 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 462 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 463 | | | | | | | | / 464 +----------+ +-----+----+ +----------+ +----------+ 466 Figure 4 468 Figure 4 illustrates a multihomed home network model, where the 469 customer has connectivity via CPE1 to ISP A and via CPE2 to ISP B. 470 This example shows one shared subnet where IPv6 nodes would 471 potentially be multihomed and receive multiple IPv6 global addresses, 472 one per ISP. This model may also be combined with that shown in 473 Figure 3 for example to create a more complex scenario. 475 +-------+-------+ +-------+-------+ \ 476 | Service | | Service | \ 477 | Provider A | | Provider B | | Service 478 | Router | | Router | | Provider 479 +-------+-------+ +-------+-------+ | network 480 | | / 481 | Customer | / 482 | Internet | / 483 | connections | | 484 +---------+---------+ \ 485 | IPv6 | \ 486 | Customer Edge | \ 487 | Router 1 | / 488 +---------+---------+ / 489 | | / 490 | | | End-User 491 ---+---------+---+-- --+--+----------+--- | network(s) 492 | | | | \ 493 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 494 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 495 | | | | | | | | / 496 +----------+ +-----+----+ +----------+ +----------+ 498 Figure 5 500 Figure 5 illustrates a model where a home network may have multiple 501 connections to multiple providers or multiple logical connections to 502 the same provider, but the associated subnet(s) are isolated. Some 503 deployment scenarios may require this model. 505 3.2. Requirements 507 [RFC6204] defines "basic" requirements for IPv6 Customer Edge 508 Routers, while [I-D.ietf-v6ops-ipv6-cpe-router-bis] describes 509 "advanced" features. In general, home network equipment needs to 510 cope with the different types of network topologies discussed above. 511 Manual configuration is rarely, if at all, possible, given the 512 knowledge lying with typical home users. The equipment needs to be 513 prepared to handle at least 515 o Prefix configuration for routers 517 o Managing routing 519 o Name resolution 521 o Service discovery 522 o Network security 524 3.3. Considerations 526 This section lists some considerations for home networking that may 527 affect the architecture and associated requirements. 529 Multihoming 531 A homenet may be multihomed to multiple providers. This may 532 either take a form where there are multiple isolated networks 533 within the home or a more integrated network where the 534 connectivity selection is dynamic. Current practice is typically 535 of the former kind, but the latter is expected to become more 536 commonplace. 538 In an integrated network, specific appliances or applications may 539 use their own external connectivity, or the entire network may 540 change its connectivity based on the status of the different 541 upstream connections. Many general solutions for IPv6 multihoming 542 have been worked on for years in the IETF, though to date there is 543 little deployment of these mechanisms. While an argument can be 544 made that home networking standards should not make another 545 attempt at this, the obvious counter-argument is that multihoming 546 support will be necessary for many deployment situations. 548 One such approach is the use of NPTv6 [RFC6296], which is a prefix 549 translation-based mechanism. An alternative is presented in 550 [I-D.v6ops-multihoming-without-ipv6nat]. Host-based methods such 551 as Shim6 [RFC5533] have also been defined. 553 In any case, if multihoming is supported additional requirements 554 are necessary. The general multihoming problem is broad, and 555 solutions may include complex architectures for monitoring 556 connectivity, traffic engineering, identifier-locator separation, 557 connection survivability across multihoming events, and so on. 558 However, there is a general agreement that for the home case, if 559 there is any support for multihoming it should be limited to a 560 very small subset of the overall problem. Specifically, multi- 561 addressed hosts selecting the right source address to avoid 562 falling foul of ingress filtering on upstream ISP connections 563 [I-D.baker-fun-multi-router]. A solution to this particular 564 problem is desirable. 566 Some similar multihoming issues have already been teased out in 567 the work described in [I-D.ietf-mif-dns-server-selection], which 568 has led to the definition of a DHCPv6 route option 569 [I-D.ietf-mif-dhcpv6-route-option]. 571 One could also argue that a "happy eyeballs" approach, not too 572 dissimilar to that proposed for multiple interface (mif) 573 scenarios, is also acceptable if such support becomes commonplace 574 in hosts and applications. 576 A further consideration and complexity here is that at least one 577 upstream may be a "walled garden", and thus only appropriate to be 578 used for connectivity to the services of that provider. 580 Quality of Service in multi-service home networks 582 Support for QoS in a multi-service homenet may be a requirement, 583 e.g. for a critical system (perhaps healthcare related), or for 584 differentiation between different types of traffic (file sharing, 585 cloud storage, live streaming, VoIP, etc). Different media types 586 may have different QoS properties or capabilities. 588 However, homenet scenarios should require no new QoS protocols. A 589 DiffServ [RFC2475] approach with a small number of predefined 590 traffic classes should generally be sufficient, though at present 591 there is little experience of QoS deployment in home networks. 592 There may also be complementary mechanisms that could be 593 beneficial in the homenet domain, such as ensuring proper 594 buffering algorithms are used as described in [Gettys11]. 596 DNS services 598 A desirable target may be a fully functional self-configuring 599 secure local DNS service so that all devices are referred to by 600 name, and these FQDNs are resolved locally. This will make clean 601 use of ULAs and multiple ISP-provided prefixes much easier. The 602 local DNS service should be (by default) authoritative for the 603 local name space in both IPv4 and IPv6. A dual-stack residential 604 gateway should include a dual-stack DNS server. 606 Consideration will also need to be given for existing protocols 607 that may be used within a network, e.g. mDNS, and how these 608 interact with unicast-based DNS services. 610 With the introduction of new top level domains, there is potential 611 for ambiguity between for example a local host called apple and 612 (if it is registered) an apple gTLD, so some local name space is 613 probably required, which should also be configurable to something 614 else by a home user if desired. 616 Privacy considerations 618 There are no specific privacy concerns for this text. It should 619 be noted that most ISPs are expected to offer static IPv6 prefixes 620 to customers, and thus the addresses they use would not generally 621 change over time. 623 3.4. Principles 625 There is little that the Internet standards community can do about 626 the physical topologies or the need for some networks to be separated 627 at the network layer for policy or link layer compatibility reasons. 628 However, there is a lot of flexibility in using IP addressing and 629 inter-networking mechanisms. In this section we provide some 630 guidance on how this flexibility should be used to provide the best 631 user experience and ensure that the network can evolve with new 632 applications in the future. 634 The following principles should be used as a guide in designing these 635 networks in the correct manner. There is no implied priority by the 636 order in which the principles are listed. 638 Reuse existing protocols 640 It is desirable to reuse existing protocols where possible, but at 641 the same time to avoid consciously precluding the introduction of 642 new or emerging protocols. For example, 643 [I-D.baker-fun-routing-class] suggests introducing a routing 644 protocol that may may route on both source and destination 645 addresses. 647 A generally conservative approach, giving weight to running code, 648 is preferable. Where new protocols are required, evidence of 649 commitment to implementation by appropriate vendors or development 650 communities is highly desirable. Protocols used should be 651 backwardly compatible. 653 Where possible, changes to hosts should be minimised. Some 654 changes may be unavoidable however, e.g. signalling protocols to 655 punch holes in firewalls where "Simple Security" is deployed in a 656 CPE. 658 Liaisons with other appropriate standards groups and related 659 organisations is desirable, e.g. the IEEE and Wi-Fi Alliance. 661 Dual-stack Operation 663 The homenet architecture targets both IPv6-only and dual-stack 664 networks. While the CPE requirements in RFC 6204 are targeted at 665 IPv6-only networks, it is likely that dual-stack homenets will be 666 the norm for some period of time. IPv6-only networking may first 667 be deployed in home networks in "greenfield" scenarios, or perhaps 668 as one element of an otherwise dual-stack network. The homenet 669 architecture must operate in the absence of IPv4, and IPv6 must 670 work in the same scenarios as IPv4 today. Running IPv6-only may 671 require documentation of additional considerations such as: 673 Ensuring there is a way to access content in the IPv4 Internet. 674 This can be arranged through incorporating NAT64 [RFC6144] 675 functionality in the home gateway router, for instance. 677 DNS discovery mechanisms are enabled even for IPv6. Both 678 stateless DHCPv6 [RFC3736] [RFC3646] and Router Advertisement 679 options [RFC6106] may have to be supported and turned on by 680 default to ensure maximum compatibility with all types of hosts 681 in the network. This requires, however, that a working DNS 682 server is known and addressable via IPv6. 684 All nodes in the home network support operations in IPv6-only 685 mode. Some current devices work well with dual-stack but fail 686 to recognize connectivity when IPv4 DHCP fails, for instance. 688 In dual-stack networks, solutions for IPv6 must not adversely 689 affect IPv4 operation. It is likely that topologies of IPv4 and 690 IPv6 networks would be as congruent as possible. 692 Note that specific transition tools, particularly those running on 693 the border CPE, are out of scope. The homenet architecture 694 focuses on the internal home network. 696 Largest Possible Subnets 698 Today's IPv4 home networks generally have a single subnet, and 699 early dual-stack deployments have a single congruent IPv6 subnet, 700 possibly with some bridging functionality. 702 Future home networks are highly likely to need multiple subnets, 703 for the reasons described earlier. As part of the self- 704 organisation of the network, the network should subdivide itself 705 to the largest possible subnets that can be constructed within the 706 constraints of link layer mechanisms, bridging, physical 707 connectivity, and policy. For instance, separate subnetworks are 708 necessary where two different links cannot be bridged, or when a 709 policy requires the separation of a private and visitor parts of 710 the network. 712 While it may be desirable to maximise the chance of link-local 713 protocols succeeding, multiple subnet home networks are 714 inevitable, so their support must be included. A general 715 recommendation is to follow the same topology for IPv6 as is used 716 for IPv4, but not to use NAT. Thus there should be routed IPv6 717 where an IPv4 NAT is used, and where there is no NAT there should 718 be bridging. 720 In some cases IPv4 NAT home networks may feature cascaded NATs, 721 e.g. where NAT routers are included within VMs or Internet 722 connection services are used. IPv6 routed versions of such tools 723 will be required. 725 Transparent End-to-End Communications 727 An IPv6-based home network architecture should naturally offer a 728 transparent end-to-end communications model. Each device should 729 be addressable by a unique address. Security perimeters can of 730 course restrict the end-to-end communications, but it is simpler 731 given the availability of globally unique addresses to block 732 certain nodes from communicating by use of an appropriate 733 filtering device than to configure the address translation device 734 to enable appropriate address/port forwarding in the presence of a 735 NAT. 737 As discussed previously, it is important to note the difference 738 between hosts being addressable and reachable. Thus filtering is 739 to be expected, while IPv6 NAT is not. End-to-end communications 740 are important for their robustness to failure of intermediate 741 systems, where in contrast NAT is dependent on state machines 742 which are not self-healing. 744 When configuring filters, protocols for securely associating 745 devices are desirable. In the presence of "Simple Security" the 746 use of signalling protocols such as uPnP or PCP may be expected to 747 punch holes in the firewall. Alternatively, RFC 6092 supports the 748 option for a border CPE to run in "transparent mode", in which 749 case a protocol like PCP is not required, but the security model 750 is more open. 752 IP Connectivity between All Nodes 754 A logical consequence of the end-to-end communications model is 755 that the network should by default attempt to provide IP-layer 756 connectivity between all internal parts as well as between the 757 internal parts and the Internet. This connectivity should be 758 established at the link layer, if possible, and using routing at 759 the IP layer otherwise. 761 Local addressing (ULAs) may be used within the scope of a home 762 network. It would be expected that ULAs may be used alongside one 763 or more globally unique ISP-provided addresses/prefixes in a 764 homenet. ULAs may be used for all devices, not just those 765 intended to have internal connectivity only. ULAs may then be 766 used for stable internal communications should the ISP-provided 767 prefix change, or external connectivity be temporarily lost. The 768 use of ULAs should be restricted to the homenet scope through 769 filtering at the border(s) of the homenet; thus "end-to-end" for 770 ULAs is limited to the homenet. 772 In some cases full internal connectivity may not be desirable, 773 e.g. in certain utility networking scenarios, or where filtering 774 is required for policy reasons against guest network subnet(s). 775 Note that certain scenarios may require co-existence of ISP 776 connectivity providing a general Internet service with provider 777 connectivity to a private "walled garden" network. 779 Some home networking scenarios/models may involve isolated 780 subnet(s) with their own CPEs. In such cases connectivity would 781 only be expected within each isolated network (though traffic may 782 potentially pass between them via external providers). 784 Routing functionality 786 Routing functionality is required when multiple subnets are in 787 use. This functionality could be as simple as the current 788 "default route is up" model of IPv4 NAT, or it could involve 789 running an appropriate routing protocol. 791 The homenet routing environment may include traditional IP 792 networking where existing link-state or distance-vector protocols 793 may be used, but also new LLN or other "constrained" networks 794 where other protocols may be more appropriate. IPv6 VM solutions 795 may also add additional routing requirements. Current home 796 deployments use largely different mechanisms in sensor and basic 797 Internet connectivity networks. In general, LLN or other networks 798 should be able to attach and participate the same way or map/be 799 gatewayed to the main homenet. 801 It is desirable that the routing protocol has knowledge of the 802 homenet topology, which implies a link-state protocol may be 803 preferable. If so, it is also desirable that the announcements 804 and use of LSAs and RAs are appropriately coordinated. 806 The routing environment should be self-configuring, as discussed 807 in the next subsection. An example of how OSPFv3 can be self- 808 configuring in a homenet is described in 809 [I-D.acee-ospf-ospfv3-autoconfig]. It is important that self- 810 configuration with "unintended" devices is avoided. 812 To support multihoming within a homenet, a routing protocol that 813 can make routing decisions based on source and destination 814 addresses is desirable, to avoid upstream ISP ingress filtering 815 problems. In general the routing protocol should support multiple 816 ISP uplinks and prefixes in concurrent use. 818 Self-Organisation 820 A home network architecture should be naturally self-organising 821 and self-configuring under different circumstances relating to the 822 connectivity status to the Internet, number of devices, and 823 physical topology. 825 The most important function in this respect is prefix delegation 826 and management. Delegation should be autonomous, and not assume a 827 flat or hierarchical model. From the homenet perspective, a 828 single prefix should be received on the border CPE from the 829 upstream ISP, via [RFC3363]. The ISP should only see that 830 aggregate, and not single /64 prefixes allocated within the 831 homenet. 833 Each link in the homenet should receive a prefix from within the 834 ISP-provided prefix. Delegation within the homenet should give 835 each link a prefix that is persistent across reboots, power 836 outages and similar short-term outages. Addition of a new routing 837 device should not affect existing persistent prefixes, but 838 persistence may not be expected in the face of significant 839 "replumbing" of the homenet. Persistence should not depend on 840 router boot order. Persistent prefixes may imply the need for 841 stable storage on routing devices, and also a method for a home 842 user to "reset" the stored prefix should a significant 843 reconfiguration be required. 845 The assignment mechanism should provide reasonable efficiency, so 846 that typical home network prefix allocation sizes can accommodate 847 all the necessary /64 allocations in most cases. For instance, 848 duplicate assignment of multiple /64s to the same network should 849 be avoided. 851 Several proposals have been made for prefix delegation within a 852 homenet. One group of proposals is based on DHCPv6 PD, as 853 described in [I-D.baker-homenet-prefix-assignment], 854 [I-D.chakrabarti-homenet-prefix-alloc], [RFC3315] and [RFC3363]. 855 The other uses OSPFv3, as described in 856 [I-D.arkko-homenet-prefix-assignment]. 858 While the homenet should be self-organising, it should be possible 859 to manually adjust (override) the current configuration. The 860 network should also cope gracefully in the event of prefix 861 exhaustion. 863 The network elements will need to be integrated in a way that 864 takes account of the various lifetimes on timers that are used, 865 e.g. DHCPv6 PD, router, valid prefix and preferred prefix timers. 867 The homenet will have one or more borders, with external 868 connectivity providers and potentially parts of the internal 869 network (e.g. for policy-based reasons). It should be possible to 870 automatically perform border discovery at least for the ISP 871 borders. Such borders determine for example the scope of ULAs, 872 site scope multicast boundaries and where firewall policies may be 873 applied. 875 The network cannot be expected to be completely self-organising, 876 e.g. some security parameters are likely to need manual 877 configuration, e.g. WPA2 configuration for wireless access 878 control. 880 Fewest Topology Assumptions 882 There should be ideally no built-in assumptions about the topology 883 in home networks, as users are capable of connecting their devices 884 in ingenious ways. Thus arbitrary topologies will need to be 885 supported. 887 It is important not to introduce new IPv6 scenarios that would 888 break with IPv4+NAT, given dual-stack homenets will be commonplace 889 for some time. There may be IPv6-only topologies that work where 890 IPv4 is not used or required. 892 Naming and Service Discovery 894 The most natural way to think about naming and service discovery 895 within a home is to enable it to work across the entire residence, 896 disregarding technical borders such as subnets but respecting 897 policy borders such as those between visitor and internal 898 networks. 900 This may imply support is required for IPv6 multicast across the 901 scope of the home network, and thus at least all routing devices 902 in the network. 904 Homenet naming systems will be required that work internally or 905 externally, though the domains used may be different in each case. 907 Proxy or Extend? 909 Related to the above, we believe that general existing discovery 910 protocols that are designed to only work within a subnet are 911 modified/extended to work across subnets, rather than defining 912 proxy capabilities for those functions. 914 We may need to do more analysis (a survey?) on which functions/ 915 protocols assume subnet-only operation, in the context of existing 916 home networks. Some experience from enterprises may be relevant 917 here. 919 Adapt to ISP constraints 921 The home network may receive an arbitrary length IPv6 prefix from 922 its provider, e.g. /60 or /56. The offered prefix may be static 923 or dynamic. The home network needs to be adaptable to such ISP 924 policies, e.g. on constraints placed by the size of prefix offered 925 by the ISP. The ISP may use [I-D.ietf-dhc-pd-exclude] for 926 example. 928 The internal operation of the home network should not also depend 929 on the availability of the ISP network at any given time, other 930 than for connectivity to services or systems off the home network. 931 This implies the use of ULAs as supported in RFC6204. If used, 932 ULA addresses should be stable so that they can always be used 933 internally, independent of the link to the ISP. 935 It is expected that ISPs will deliver a static home prefix to 936 customers. However, it is possible, however unlikely, that an ISP 937 may need to restructure and in doing so renumber its customer 938 homenets. In such cases "flash" renumbering may be imposed. Thus 939 it's desirable that homenet protocols or operational processes 940 don't add unnecessary complexity for renumbering. 942 3.5. Summary of Homenet Architecture Recommendations 944 In this section we present a summary of the homenet architecture 945 recommendations that were discussed in more detail in the previous 946 sections. 948 (Bullet points to be added in next version) 950 3.6. Implementing the Architecture on IPv6 952 The necessary mechanisms are largely already part of the IPv6 953 protocol set and common implementations, though there are some 954 exceptions. For automatic routing, it is expected that existing 955 routing protocols can be used as is. However, a new mechanism may be 956 needed in order to turn a selected protocol on by default. Support 957 for multiple exit routers and multi-homing would also require 958 extensions, even if focused on the problem of multi-addressed hosts 959 selecting the right source address to avoid falling foul of ingress 960 filtering on upstream ISP connections. 962 For name resolution and service discovery, extensions to existing 963 multicast-based name resolution protocols are needed to enable them 964 to work across subnets, within the scope of the home network. 966 The hardest problems in developing solutions for home networking IPv6 967 architectures include discovering the right borders where the domain 968 "home" ends and the service provider domain begins, deciding whether 969 some of necessary discovery mechanism extensions should affect only 970 the network infrastructure or also hosts, and the ability to turn on 971 routing, prefix delegation and other functions in a backwards 972 compatible manner. 974 4. References 976 4.1. Normative References 978 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 979 E. Lear, "Address Allocation for Private Internets", 980 BCP 5, RFC 1918, February 1996. 982 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 983 (IPv6) Specification", RFC 2460, December 1998. 985 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 986 and W. Weiss, "An Architecture for Differentiated 987 Services", RFC 2475, December 1998. 989 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 990 and M. Carney, "Dynamic Host Configuration Protocol for 991 IPv6 (DHCPv6)", RFC 3315, July 2003. 993 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 994 Hain, "Representing Internet Protocol version 6 (IPv6) 995 Addresses in the Domain Name System (DNS)", RFC 3363, 996 August 2002. 998 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 999 Addresses", RFC 4193, October 2005. 1001 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1002 Architecture", RFC 4291, February 2006. 1004 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1005 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1006 May 2007. 1008 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1009 Shim Protocol for IPv6", RFC 5533, June 2009. 1011 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1012 Customer Premises Equipment (CPE) for Providing 1013 Residential IPv6 Internet Service", RFC 6092, 1014 January 2011. 1016 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1017 Troan, "Basic Requirements for IPv6 Customer Edge 1018 Routers", RFC 6204, April 2011. 1020 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1021 Translation", RFC 6296, June 2011. 1023 4.2. Informative References 1025 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1026 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1027 December 2003. 1029 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1030 (DHCP) Service for IPv6", RFC 3736, April 2004. 1032 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1033 "IPv6 Router Advertisement Options for DNS Configuration", 1034 RFC 6106, November 2010. 1036 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1037 IPv4/IPv6 Translation", RFC 6144, April 2011. 1039 [I-D.baker-fun-multi-router] 1040 Baker, F., "Exploring the multi-router SOHO network", 1041 draft-baker-fun-multi-router-00 (work in progress), 1042 July 2011. 1044 [I-D.baker-fun-routing-class] 1045 Baker, F., "Routing a Traffic Class", 1046 draft-baker-fun-routing-class-00 (work in progress), 1047 July 2011. 1049 [I-D.herbst-v6ops-cpeenhancements] 1050 Herbst, T. and D. Sturek, "CPE Considerations in IPv6 1051 Deployments", draft-herbst-v6ops-cpeenhancements-00 (work 1052 in progress), October 2010. 1054 [I-D.vyncke-advanced-ipv6-security] 1055 Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced 1056 Security for IPv6 CPE", 1057 draft-vyncke-advanced-ipv6-security-02 (work in progress), 1058 July 2011. 1060 [I-D.ietf-v6ops-ipv6-cpe-router-bis] 1061 Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1062 Troan, "Advanced Requirements for IPv6 Customer Edge 1063 Routers", draft-ietf-v6ops-ipv6-cpe-router-bis-01 (work in 1064 progress), July 2011. 1066 [I-D.ietf-6man-rfc3484-revise] 1067 Matsumoto, A., Kato, J., Fujisaki, T., and T. Chown, 1068 "Update to RFC 3484 Default Address Selection for IPv6", 1069 draft-ietf-6man-rfc3484-revise-04 (work in progress), 1070 July 2011. 1072 [I-D.ietf-dhc-pd-exclude] 1073 Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1074 "Prefix Exclude Option for DHCPv6-based Prefix 1075 Delegation", draft-ietf-dhc-pd-exclude-03 (work in 1076 progress), August 2011. 1078 [I-D.v6ops-multihoming-without-ipv6nat] 1079 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 1080 Wing, "IPv6 Multihoming without Network Address 1081 Translation", draft-v6ops-multihoming-without-ipv6nat-00 1082 (work in progress), March 2011. 1084 [I-D.ietf-mif-dns-server-selection] 1085 Savolainen, T., Kato, J., and T. Lemon, "Improved DNS 1086 Server Selection for Multi-Interfaced Nodes", 1087 draft-ietf-mif-dns-server-selection-07 (work in progress), 1088 October 2011. 1090 [I-D.ietf-mif-dhcpv6-route-option] 1091 Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6 1092 Route Options", draft-ietf-mif-dhcpv6-route-option-03 1093 (work in progress), September 2011. 1095 [I-D.baker-homenet-prefix-assignment] 1096 Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small 1097 Networks", draft-baker-homenet-prefix-assignment-00 (work 1098 in progress), October 2011. 1100 [I-D.arkko-homenet-prefix-assignment] 1101 Arkko, J. and A. Lindem, "Prefix Assignment in a Home 1102 Network", draft-arkko-homenet-prefix-assignment-00 (work 1103 in progress), October 2011. 1105 [I-D.acee-ospf-ospfv3-autoconfig] 1106 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 1107 draft-acee-ospf-ospfv3-autoconfig-00 (work in progress), 1108 October 2011. 1110 [I-D.ietf-pcp-base] 1111 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1112 Selkirk, "Port Control Protocol (PCP)", 1113 draft-ietf-pcp-base-16 (work in progress), October 2011. 1115 [I-D.chakrabarti-homenet-prefix-alloc] 1116 Nordmark, E., Chakrabarti, S., Krishnan, S., and W. 1117 Haddad, "Simple Approach to Prefix Distribution in Basic 1118 Home Networks", draft-chakrabarti-homenet-prefix-alloc-01 1119 (work in progress), October 2011. 1121 [Gettys11] 1122 Gettys, J., "Bufferbloat: Dark Buffers in the Internet", 1123 March 2011, 1124 . 1126 Appendix A. Acknowledgments 1128 The authors would like to thank Brian Carpenter, Mark Andrews, Fred 1129 Baker, Ray Bellis, Cameron Byrne, Stuart Cheshire, Lorenzo Colitti, 1130 Ralph Droms, Lars Eggert, Jim Gettys, Wassim Haddad, Joel M. Halpern, 1131 David Harrington, Lee Howard, Ray Hunter, Joel Jaeggli, Heather 1132 Kirksey, Ted Lemon, Erik Nordmark, Michael Richardson, Barbara Stark, 1133 Sander Steffann, Dave Thaler, JP Vasseur, Curtis Villamizar, Russ 1134 White, and James Woodyatt for their contributions within homenet WG 1135 meetings and the mailing list, and Mark Townsley for being an initial 1136 editor/author of this text before taking his position as homenet WG 1137 co-chair. 1139 Authors' Addresses 1141 Jari Arkko 1142 Ericsson 1143 Jorvas 02420 1144 Finland 1146 Email: jari.arkko@piuha.net 1148 Tim Chown 1149 University of Southampton 1150 Highfield 1151 Southampton, Hampshire SO17 1BJ 1152 United Kingdom 1154 Email: tjc@ecs.soton.ac.uk 1156 Jason Weil 1157 Time Warner Cable 1158 13820 Sunrise Valley Drive 1159 Herndon, VA 20171 1160 USA 1162 Email: jason.weil@twcable.com 1164 Ole Troan 1165 Cisco Systems, Inc. 1166 Drammensveien 145A 1167 Oslo N-0212 1168 Norway 1170 Email: ot@cisco.com