idnits 2.17.1 draft-winters-homenet-sper-interaction-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7084]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3716 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 438, but no explicit reference was found in the text == Unused Reference: 'I-D.donley-dhc-cer-id-option' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-homenet-arch' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-ospfv3-autoconfig' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'I-D.stenberg-homenet-dnssdext-hybrid-proxy-ospf' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 496, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-donley-dhc-cer-id-option-02 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-11 == Outdated reference: A later version (-15) exists of draft-ietf-ospf-ospfv3-autoconfig-05 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6204 (Obsoleted by RFC 7084) Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Homenet T. Winters, Ed. 3 Internet-Draft UNH-IOL 4 Intended status: Informational February 14, 2014 5 Expires: August 16, 2014 7 Service Provider Edge Router Interaction 8 draft-winters-homenet-sper-interaction-01 10 Abstract 12 This document describes the interaction between a Service Provider 13 Gateway fixed at the home edge, and the Home Networking interior 14 routers. It assesses the interactions between existing routers 15 implementing [RFC7084] and the Home Networking routers. The document 16 will also define the interactions between other Service Provider Edge 17 Router (eg. HIPnet) and Home Networking router. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 16, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Border Discovery . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. All Ports Discovery . . . . . . . . . . . . . . . . . . . 3 58 3.2. WAN Port defined As External . . . . . . . . . . . . . . . 4 59 4. Home Networking Scenarios . . . . . . . . . . . . . . . . . . 4 60 4.1. 7084 to Homenet . . . . . . . . . . . . . . . . . . . . . 4 61 4.1.1. Addressing . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1.3. Border . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1.4. Service Discovery into the Homenet . . . . . . . . . . 5 65 4.2. Homenet to 7084 . . . . . . . . . . . . . . . . . . . . . 5 66 4.2.1. Addressing . . . . . . . . . . . . . . . . . . . . . . 6 67 4.2.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2.3. Border . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.2.4. Service Discovery into the Homenet . . . . . . . . . . 6 70 4.3. Service Provider Edge Router (SPER) to Homenet . . . . . . 7 71 4.3.1. Addressing . . . . . . . . . . . . . . . . . . . . . . 7 72 4.3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.3.3. Border . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.3.4. Service Discovery . . . . . . . . . . . . . . . . . . 8 75 4.4. Homenet to SPER . . . . . . . . . . . . . . . . . . . . . 8 76 4.4.1. Addressing . . . . . . . . . . . . . . . . . . . . . . 8 77 4.4.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.4.3. Border . . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.4.4. Service Discovery into the Homenet . . . . . . . . . . 9 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 This document defines the interactions between the future Homenet 91 network and 7084 Routers and Service Provider Edge Routers (SPER). 92 In the future the SPER will be full Homenet routers but there will be 93 a period of transition. This document specifies how currently 94 deployed SPER will interact with Homenet architecture [I-D.ietf- 95 homenet-arch]. The goal of this document is to make recommendations 96 on issues uncovered to make the devices work with the future Homenet. 97 These recommendations may result in requirements for the Homenet 98 routers. 100 1.1. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 2. Terminology 108 For purposes of this report the Design Team adopts the following 109 terminology. 111 o Border: a point, typically resident on a router, between two 112 networks. A basic example is between the main internal homenet 113 and a guest network. This also defines point(s) at which 114 filtering and forwarding policies for different types of traffic 115 may be applied. For the purpose of this document we use the 116 Default Border Definition [I-D.kline-homenet-default-perimeter] to 117 describe how the Border is discovered. 119 o SPER: Service Provider Edge Router: A border router intended for 120 home or small-office use that forwards packet explicitly addressed 121 as defined [I-D.grundemann-homenet-hipnet] or [BBF.TR124] 122 connecting the homenet to a service provider network. 124 o Homenet: Home network consisting of routers interacting with each 125 other using a dynamic routing protocol for prefix allocation and 126 reachability. Examples include Prefix Assignment [I-D.arkko- 127 homenet-prefix-assignment] and OSPFv3 Auto-Configuration [I-D 128 .ietf-ospf-ospfv3-autoconfig] 130 o Homenet Naming and Service Discovery: The Homenet supports the 131 ability for users and devices to be able to discover devices and 132 services available in the Homenet. Currently the mechanism is 133 undefined but methods such as DNSSD [RFC6763], [SSDP], Hybrid 134 model using [I-D.cheshire-dnssd-hybrid] or DNS-Based Service 135 Discovery using OSPFv3 [I-D.stenberg-homenet-dnssdext-hybrid- 136 proxy-ospf] could be used to solve this issue. 138 o Internet Service Provider (ISP): An entity that provides access to 139 the Internet. In this document, a service provider specifically 140 offers Internet access using IPv6, and may also offer IPv4 141 Internet access. The service provider can provide such access 142 over a variety of different transport methods such as DSL, cable, 143 wireless, and others. 145 o 7084: A router intended for home or small-office use that forwards 146 packet explicitly addressed to itself as defined in [RFC7084] 148 3. Border Discovery 150 According to [I-D.kline-homenet-default-perimeter] there are 3 types 151 of product interfaces: external, internal, and mixed. Border 152 Discovery is the process of discovering the interface types. Below 153 we describe the the 3 choices. 155 3.1. All Ports Discovery 157 Border Discovery must be performed on all interfaces. Legacy Routers 158 that don't support Homenet will not participate in Border Discovery 159 and are considered to be external to the Homenet Border. 161 3.2. WAN Port defined As External 163 WAN ports are permanently defined as external requiring no discovery. 164 LAN ports perform Border Discovery. This requires that the user 165 connect the WAN interface to the ISP or SPER defining the boundary. 166 All other ports are in border discovery mode. The advantage of this 167 approach is that it allows the Homenet to have multiple egress ports. 169 4. Home Networking Scenarios 171 4.1. 7084 to Homenet 173 +-----------+ 174 | Service | 175 | Provider | 176 | Router | 177 +-----+-----+ 178 | 179 | 180 | Customer 181 | Internet Connection 182 | 183 +-----v-----+ 184 | 7084 | 185 | Router | 186 | | 187 +-----+-----+ 188 | 189 +----+-+-------+ 190 | | 191 | | 192 +---+----+ +-----+------+ 193 | IPv6 | | Homenet | 194 | Host | | Router | 195 | | | | 196 +--------+ +------------+ 198 4.1.1. Addressing 200 A 7084 Router acquires addresses to provision the LAN through DHCP 201 Prefix Delegation [RFC3633]. A 7084 Router will assign a separate / 202 64 from the set of delegated prefix(es) for each LAN interfaces. 203 The Router can assign addresses to the LAN hosts using either SLAAC 204 or DHCP. There is no requirement for redistributing any unused 205 prefix(es) that were delegated to the 7084 Router. Support of IA_PD 206 on the LAN interface is not required for a 7084 Router. If a 7084 207 Router does not support IA_PD on the LAN interface the Homenet will 208 not receive a prefix allocation, and therefore will not have global 209 addressing for the entire Homenet. 211 4.1.2. Routing 212 A 7084 Router learns default routes through Router Advertisements on 213 the WAN interface. Routes are installed when a prefix is assigned to 214 a LAN interface. All other Home Routing information requires user 215 configuration. 217 A 7084 Router will NOT forward packets from an unrecognized source 218 address. Any IPv6 packets routed from the Homenet would receive an 219 ICMPv6 Destination Unreachable message. This restricts the Homenet 220 to internal communications only. Packets with unrecognized 221 destination addresses in the Homenet MAY pass thru a 7084 Router if 222 configured. This configuration might be done thru the mechanism such 223 a IA_PD or direct configuration. 225 4.1.3. Border 227 A 7084 Router does not have a method for participating in Homenet 228 border discovery. A 7084 Router and any hosts connected to the 229 Router are considered to be as External to the Homenet. A Homenet 230 Router is recommended to support a configuration method that will 231 allow the border to include the 7084 Router as Internal to the 232 Homenet. 234 4.1.4. Service Discovery into the Homenet 236 For service discovery to works routers need to forward multicast 237 traffic appropriately enabling server discovery across the home 238 network. A 7084 Router does not have any requirements for supporting 239 multicast forwarding. Based on this knowledge it is unlikely that 240 Service Discovery between the 7084 and Homemnet will work. 242 4.2. Homenet to 7084 243 +-----------+ 244 | Service | 245 | Provider | 246 | Router | 247 +-----+-----+ 248 | 249 | 250 | Customer 251 | Internet Connection 252 | 253 +-----v-----+ 254 | Homenet | 255 | Router | 256 | | 257 +-----+-----+ 258 | 259 +----+-+-------+ 260 | | 261 | | 262 +---+----+ +-----+------+ 263 | IPv6 | | 7084 | 264 | Host | | Router | 265 | | | | 266 +--------+ +------------+ 268 4.2.1. Addressing 270 A 7084 Router needs to receive an IA_PD to allow devices on LAN 271 interfaces to be addressed. For addressing to work properly the 272 Homenet must provide IA_PDs when requested. 274 4.2.2. Routing 276 When a Homenet Router is assigned an IA_PD it MUST install routes for 277 the prefixes into the Homenet Routing infrastructure. This will 278 allow packets to be routed from the Homenet to the 7084 Router. A 279 7084 Router only needs a Router Advertisement with a valid Router 280 Lifetime to route into the Homenet. 282 4.2.3. Border 284 A Homenet Router with the firewall on might not allow valid traffic 285 from devices connected to the 7084 Router. When a Homenet Router is 286 assigned an IA_PD there needs to be a secure way for the Homenet 287 Border to allow IPv6 traffic to flow from the 7084 router into the 288 Homenet or Internet. 290 4.2.4. Service Discovery into the Homenet 291 For service discovery to work routers need to forward multicast 292 traffic appropriately enabling server discovery across the home 293 network. A 7084 Router does not have any requirements for supporting 294 multicast forwarding. Based on this knowledge it is unlikely that 295 Service Discovery between the 7084 and Homemnet will work. 297 4.3. Service Provider Edge Router (SPER) to Homenet 299 +-----------+ 300 | Service | 301 | Provider | 302 | Router | 303 +-----+-----+ 304 | 305 | 306 | Customer 307 | Internet Connection 308 | 309 +-----+-----+ 310 | SPER | 311 | | 312 | | 313 +-----+-----+ 314 | 315 +----+-+-------+ 316 | | 317 | | 318 +---+----+ +-----+------+ 319 | IPv6 | | Homenet | 320 | Host | | | 321 | | | | 322 +--------+ +------------+ 324 4.3.1. Addressing 326 SPERs use DHCPv6 prefix sub-delegation to build the network [I-D 327 .grundemann-homenet-hipnet]. If the prefix is larger then a single / 328 64 prefix the SPER will subdivide the IPv6 prefix received via DHCPv6 329 [RFC3315]. Using Recursive Prefix Delegation allows the Homenet to 330 receive prefixes that can be used to address the network. 332 4.3.2. Routing 334 Leveraging the recursive prefix delegation method described above, a 335 SPER installs a route to the WAN interface of the router which 336 delegated the prefixes. With this routing information the SPER is 337 able to properly route packets to and from the Homenet. 339 4.3.3. Border 340 A SPER implements a stateful [RFC6092] firewall which may be have it 341 enabled. This stateful firewall will allow homenet traffic to leave 342 the network. It is limited to only returning traffic originated from 343 the Homenet. No connections can be originated from outside of the 344 Homenet. 346 A Homenet Router with the firewall on might not allow valid traffic 347 from devices connected to the HIPnet SPER. A Homenet Router will be 348 able to detect a SPER based on a CER_ID, [I-D.donley-dhc-cer-id- 349 option], SPER MUST include an CER_ID option with an address that is 350 not the unspecified address (::). This allows for the Homenet 351 Router to detect a SPER allowing native IPv6 traffic through the 352 firewall so that traffic can flow between the SPER and Homenet. 354 4.3.4. Service Discovery 356 Both the Homenet and SPER have several common protocols that can be 357 used for service discovery such as mDNS [RFC6762], DNS-SD [RFC6763], 358 and [SSDP]. Both the SPER and Homenet Routers may have host 359 directly connected that are using them as DNS servers. If the SPER 360 advertises itself as the DNS-SD server for connected host, the host 361 could query the SPER. The issue that arises with this configuration 362 is the HIPnet Router currently has no method for finding the Homenet 363 router to query when trying to resolve DNS. 365 4.4. Homenet to SPER 367 +-----------+ 368 | Service | 369 | Provider | 370 | Router | 371 +-----+-----+ 372 | 373 | 374 | Customer 375 | Internet Connection 376 | 377 +-----+-----+ 378 | Homenet | 379 | | 380 | | 381 +-----+-----+ 382 | 383 +------+-------+ 384 | | 385 | | 386 +---+----+ +-----+------+ 387 | IPv6 | | SPER | 388 | Host | | | 389 | | | | 390 +--------+ +------------+ 392 4.4.1. Addressing 393 A SPER needs to receive an IA_PD to address IPv6 host and routers 394 behind it. If a large enough prefix is assigned, /56 for example, 395 the SPER will attempt further sub-delegation. This will not be 396 optimized for the network but will still function properly. For 397 addressing between the SPER and Homenet to work properly the Homenet 398 must provide IA_PDs when requested. 400 4.4.2. Routing 402 When a Homenet Router assigns an IA_PD to the SPER it MUST install 403 routes for the prefixes into the Homenet Routing infrastructure. 404 This will allow packets to be routed from the Homenet to the SPER. If 405 there are two ingress paths to the SPER, the sub-optimal path will be 406 choosen based on the interface that assigned the IA_PD. 408 4.4.3. Border 410 A Homenet Router with the firewall enabled might not allow valid 411 traffic from devices connected to the SPER or addressed by the SPER 412 to enter the Homenet. When a Homenet Router assigns an IA_PD there 413 needs to be a secure way for the Homenet Border to allow IPv6 traffic 414 to flow from the SPER into the Homenet or Internet. 416 4.4.4. Service Discovery into the Homenet 418 For service discovery to work routers need to forward multicast 419 traffic appropriately enabling server discovery across the home 420 network. 422 5. Security Considerations 424 6. IANA Considerations 426 This document makes no request of IANA. 428 7. Acknowledgements 430 The Homenet Design Team: Mikael Abrahamsson, Ray Bellis, John 431 Brzozowski, Lorenzo Colitti, Tim Chown, Chris Donley, Markus 432 Stenberg, Andrew Yourtchecko, Erik Kline 434 8. References 436 8.1. Normative References 438 [I-D.arkko-homenet-prefix-assignment] 439 Arkko, J., Lindem, A. and B. Paterson, "Prefix Assignment 440 in a Home Network", Internet-Draft draft-arkko-homenet- 441 prefix-assignment-04, May 2013. 443 [I-D.cheshire-dnssd-hybrid] 444 Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service 445 Discovery", Internet-Draft draft-cheshire-dnssd-hybrid-01, 446 January 2014. 448 [I-D.donley-dhc-cer-id-option] 449 Donley, C., Kloberdans, M., Brzozowski, J. and C. 450 Grundemann, "Customer Edge Router Identification Option", 451 Internet-Draft draft-donley-dhc-cer-id-option-02, January 452 2014. 454 [I-D.grundemann-homenet-hipnet] 455 Grundemann, C., Donley, C., Brzozowski, J., Howard, L. and 456 V. Kuarsingh, "A Near Term Solution for Home IP Networking 457 (HIPnet)", Internet-Draft draft-grundemann-homenet- 458 hipnet-01, February 2013. 460 [I-D.ietf-homenet-arch] 461 Chown, T., Arkko, J., Brandt, A., Troan, O. and J. Weil, 462 "IPv6 Home Networking Architecture Principles", Internet- 463 Draft draft-ietf-homenet-arch-11, October 2013. 465 [I-D.ietf-ospf-ospfv3-autoconfig] 466 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 467 Internet-Draft draft-ietf-ospf-ospfv3-autoconfig-05, 468 October 2013. 470 [I-D.kline-homenet-default-perimeter] 471 Kline, E., "Default Border Definition", Internet-Draft 472 draft-kline-homenet-default-perimeter-00, March 2013. 474 [I-D.stenberg-homenet-dnssdext-hybrid-proxy-ospf] 475 Stenberg, M., "Hybrid Unicast/Multicast DNS-Based Service 476 Discovery Auto-Configuration Using OSPFv3", Internet-Draft 477 draft-stenberg-homenet-dnssdext-hybrid-proxy-ospf-00, June 478 2013. 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, March 1997. 483 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 484 M. Carney, "Dynamic Host Configuration Protocol for IPv6 485 (DHCPv6)", RFC 3315, July 2003. 487 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 488 Host Configuration Protocol (DHCP) version 6", RFC 3633, 489 December 2003. 491 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 492 Customer Premises Equipment (CPE) for Providing 493 Residential IPv6 Internet Service", RFC 6092, January 494 2011. 496 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B. and O. Troan, 497 "Basic Requirements for IPv6 Customer Edge Routers", RFC 498 6204, April 2011. 500 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 501 Discovery", RFC 6763, February 2013. 503 [RFC7084] Singh, H., Beebee, W., Donley, C. and B. Stark, "Basic 504 Requirements for IPv6 Customer Edge Routers", RFC 7084, 505 November 2013. 507 8.2. Informative References 509 [BBF.TR124] 510 Broadband Forum, "TR-124: Functional Requirements for 511 Broadband Residental Gateways Devices", August 2012. 513 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 514 February 2013. 516 [SSDP] UPnP Forum, "Univeral Plug and Play (UPnP) Device 517 Architecture 1.1", November 2008. 519 Author's Address 521 Timothy Winters, editor 522 UNH-IOL 523 Durham, NH 525 Email: twinters@iol.unh.edu