idnits 2.17.1 draft-ietf-dhc-dhcpv6-pd-relay-requirements-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 8, 2020) is 1417 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Work Group I. Farrer 3 Internet-Draft Deutsche Telekom AG 4 Intended status: Standards Track Naveen. Kottapalli 5 Expires: December 10, 2020 Benu Networks 6 M. Hunek 7 Technical University of Liberec 8 R. Patterson 9 Sky UK Ltd 10 June 8, 2020 12 DHCPv6 Prefix Delegating Relay 13 draft-ietf-dhc-dhcpv6-pd-relay-requirements-01 15 Abstract 17 Operational experience with DHCPv6 prefix delegation (PD) has shown 18 that when the DHCPv6 relay function is not co-located with the DHCPv6 19 server function, issues such as timer synchronization between the 20 DHCP functional elements, rejection of client's messages by the 21 relay, and other problems have been observed. These problems can 22 result in prefix delegation failing or traffic to/from clients 23 addressed from the delegated prefix not being routed. Although 24 RFC8415 mentions this deployment scenario, it does not provide 25 necessary detail on how the relay element should behave when used 26 with PD. 28 This document describes functional requirements for a DHCPv6 PD relay 29 when used for relaying prefixes delegated by a separate DHCPv6 30 server. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 10, 2020. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 71 3. Problems Observed with Existing Delegating Relay 72 Implementations . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1. DHCP Messages not being Forwarded by the Delegating Relay 5 74 3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 6 75 3.3. Multiple Delegated Prefixes for a Single Client . . . . . 6 76 3.4. Dropping Messages from Devices with Duplicate MAC 77 addresses and DUIDs . . . . . . . . . . . . . . . . 6 78 4. Requirements for Delegating Relays . . . . . . . . . . . . . 6 79 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7 80 4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 8 81 4.3. Service Continuity Requirements . . . . . . . . . . . . . 8 82 4.4. Operational Requirements . . . . . . . . . . . . . . . . 9 83 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 88 8.2. Informative References . . . . . . . . . . . . . . . . . 10 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 For Internet service providers that offer native IPv6 access with 94 prefix delegation to their customers, a common deployment 95 architecture is to have a DHCPv6 relay agent function located in the 96 ISP's Layer-3 customer edge device and separate, centralized DHCPv6 97 server infrastructure. [RFC8415] describes the functionality of a 98 DHCPv6 relay and Section 19.1.3 mentions the deployment scenario, but 99 does not provide detail for all of the functional requirements that 100 the relay needs to fulfill to operate deterministically in this 101 deployment scenario. 103 A DHCPv6 relay agent for prefix delegation is a function commonly 104 implemented in routing devices, but implementations vary in their 105 functionality and client/server inter-working. This can result in 106 operational problems such as messages not being forwarded by the 107 relay or unreachability of the delegated prefixes. This document 108 provides a set of requirements for devices implementing a relay 109 function for use with prefix delegation. 111 The mechanisms for a relay to inject routes (including aggregated 112 ones), on its network-facing interface based on prefixes learnt from 113 a server via DHCP-PD are out of scope of the document. 115 Multi-hop relaying is also not considered as the functionality is 116 solely required by a DHCP relay agent that is co-located with the 117 first-hop router that the DHCPv6 client requesting the prefix is 118 connected to. 120 The behavior for handling unknown messages defined in Section 19. of 121 [RFC8415] is also applicable for relay deployments. 123 2. Terminology 125 2.1. General 127 This document uses the terminology defined in [RFC8415], however when 128 defining the functional elements for prefix delegation [RFC8415], 129 Section 4.2 defines the term 'delegating router' as: 131 "The router that acts as a DHCP server and responds to requests 132 for delegated prefixes." 134 This document is concerned with deployment scenarios in which the 135 DHCPv6 relay and DHCPv6 server functions are separated, so the term 136 'delegating router' is not used. Instead, a new term is introduced 137 to describe the relaying function: 139 Delegating relay A delegating relay acts as an intermediate device, 140 forwarding DHCPv6 messages containing IA_PD/IAPREFIX 141 options between the client and server. The 142 delegating relay does not implement a DHCPv6 server 143 function. The delegating relay is also responsible 144 for routing traffic for the delegated prefixes. 146 Where the term 'relay' is used on its own within this document, it 147 should be understood to be a delegating relay, unless specifically 148 stated otherwise. 150 In CableLabs DOCSIS environments, the Cable Modem Termination System 151 (CMTS) would be considered a delegating relay with respect to 152 Customer Premises Devices (CPEs). A Broadband Network Gateway (BNG) 153 in a DSL based access network may be a delegating relay if it does 154 not implement a local DHCPv6 server function. 156 [RFC8415] defines the 'DHCP server', (or 'server') as: 158 "A node that responds to requests from clients. It may or may not 159 be on the same link as the client(s). Depending on its 160 capabilities, if it supports prefix delegation it may also feature 161 the functionality of a delegating router." 163 This document serves the deployment cases where a DHCPv6 server is 164 not located on the same link as the client (necessitating the 165 delegating relay). The server supports prefix delegation and is 166 capable of leasing prefixes to clients, but is not responsible for 167 other functions required of a delegating router, such as managing 168 routes for the delegated prefixes. 170 The term 'requesting router' has previously been used to describe the 171 DHCP client requesting prefixes for use. This document adopts the 172 [RFC8415] terminology and uses 'DHCP client' or 'client' 173 interchangeably for this element. 175 2.2. Topology 177 The following diagram shows the deployment topology relevant to this 178 document. 180 + _ ,--,_ 181 | +--------+ +------------+ _( `' )_ +--------+ 182 +---+ PD |----| Delegating |--( Operator )---| DHCPv6 | 183 | | Client | | relay | `(_ Network_)' | server | 184 | +--------+ +----------- + `--'`---' +--------+ 185 | 186 + 187 Client Network 189 Figure 1 191 The client request prefixes via the client facing interface of the 192 delegating relay. The resulting prefixes will be used for addressing 193 the client network. The delegating relay is responsible for 194 forwarding DHCP messages, including prefix delegation requests and 195 responses between the client and server. Messages are forwarded from 196 the delegating relay to the server using multicast or unicast via the 197 operator network facing interface. 199 The delegating relay provides the operator's Layer-3 edge towards the 200 client and is responsible for routing traffic to and from clients 201 connected to the client network using addresses from the delegated 202 prefixes. 204 2.3. Requirements Language 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 208 "OPTIONAL" in this document are to be interpreted as described in BCP 209 14 [RFC2119] [RFC8174] when, and only when, they appear in all 210 capitals, as shown here. This document uses these keywords not 211 strictly for the purpose of interoperability, but rather for the 212 purpose of establishing industry-common baseline functionality. As 213 such, the document points to several other specifications (preferably 214 in RFC or stable form) to provide additional guidance to implementers 215 regarding any protocol implementation required to produce a DHCP 216 relaying router that functions successfully with prefix delegation. 218 3. Problems Observed with Existing Delegating Relay Implementations 220 The following sections of the document describe problems that have 221 been observed with delegating relay implementations in commercially 222 available devices. 224 3.1. DHCP Messages not being Forwarded by the Delegating Relay 226 Delegating relay implementations have been observed not to forward 227 messages between the client and server. This generally occurs if a 228 client sends a message which is unexpected by the delegating relay. 229 For example, the delegating router already has an active PD lease 230 entry for an existing client on a port. A new client is connected to 231 this port and sends a Solicit message. The delegating relay then 232 drops the Solicit messages until it receives either a DHCP Release 233 message from the original client, or the existing lease times out. 234 This causes a particular problem when a client device needs to be 235 replaced due to a failure. 237 In addition to dropping messages, in some cases the delegating relay 238 will generate error messages and send them to the client, e.g. 239 'NoBinding' messages being sent in the event that the delegating 240 relay does not have an active delegated prefix lease. 242 3.2. Delegating Relay Loss of State on Reboot 244 For proper routing of client traffic, the delegating relay requires a 245 corresponding routing table entry for each active prefix delegated to 246 a connected client. A delegating router which does not store this 247 state persistently across reboots will not be able to forward traffic 248 to client's delegated leases until the state is re-established 249 through new DHCP messages. 251 3.3. Multiple Delegated Prefixes for a Single Client 253 [RFC8415] allows for a client to include more than one instance of 254 OPTION_IA_PD in messages in order to request multiple prefix 255 delegations by the server. If configured for this, the server 256 supplies one (or more) instance of OPTION_IAPREFIX for each received 257 instance of OPTION_IA_PD, each containing information for a different 258 delegated prefix. 260 In some delegating relay implementations, only a single delegated 261 prefix per-DUID is supported. In those cases only one IPv6 route for 262 one of the delegated prefixes is installed; meaning that other 263 prefixes delegated to a client are unreachable. 265 3.4. Dropping Messages from Devices with Duplicate MAC addresses and 266 DUIDs 268 It is an unfortunate operational reality that client devices with 269 duplicate MAC addresses and/or DUIDs exist and have been deployed. 270 In this situation, the operational costs of locating and swapping out 271 such devices are prohibitive. 273 Delegating relays have been observed to restrict forwarding client 274 messages originating from one client DUID to a single interface. In 275 this case if the same client DUID appears from a second client on 276 another interface while there is already an active lease, messages 277 originating from the second client are dropped causing the second 278 client to be unable to obtain a prefix delegation. 280 It should be noted that in some access networks, the MAC address and/ 281 or DUID are used as part of device identification and authentication. 282 In such networks, enforcing MAC address/DUID uniqueness is a 283 necessary function and not considered a problem. 285 4. Requirements for Delegating Relays 287 To resolve the problems described in Section 3 the following section 288 of the document describes a set of functional requirements for the 289 delegating relay. 291 4.1. General Requirements 293 G-1: The delegating router MUST forward messages bidirectionally 294 between the client and server without changing the contents 295 of the message. 297 G-2: As described in Section 16 of [RFC8415], in the event that a 298 received message contains a DHCPv6 option which the relay 299 does not implement, the message MUST be forwarded. 301 G-3: The relay MUST allow for multiple prefixes to be delegated 302 for the same client IA_PD. These delegations may have 303 different lifetimes. 305 G-4: The relay MUST allow for multiple prefixes (with or without 306 separate IA_PDs) to be delegated to a single client connected 307 to a single interface, identified by its DHCPv6 Client 308 Identifier (DUID). 310 G-5: If a device has multiple interfaces that implement a 311 delegating relay function, the device SHOULD allow the same 312 client identifier (DUID) to have active delegated prefix 313 leases on more than one interface simultaneously, unless 314 client DUID uniqueness is necessary for the functioning or 315 security of the network. This is to allow client devices 316 with duplicate DUIDs to function on separate broadcast 317 domains. 319 G-6: The maximum number of simultaneous prefixes delegated to a 320 single client MUST be configurable. 322 G-7: The relay MUST implement a mechanism to limit the maximum 323 number of active prefix delegations on a single port for all 324 client identifiers and IA_PDs. This value MUST be 325 configurable. 327 G-8: It is RECOMMENDED that delegating relays support at least 8 328 active delegated leases per client device and use this as the 329 default limit. 331 G-9: The delegating relay MUST update the lease lifetimes based on 332 the Client Reply messages it forwards to the client and only 333 expire the delegated prefixes when the valid lifetime has 334 elapsed. 336 G-10: On receipt of a Release message from the client, the 337 delegating relay MUST expire the active leases for each of 338 the IA_PDs in the message. 340 4.2. Routing Requirements 342 R-1: The relay MUST maintain a local routing table that is 343 dynamically updated with prefixes and the associated next- 344 hops as they are delegated to clients. When a delegated 345 prefix is Released or expires, the associated route MUST be 346 removed from the relay's routing table. 348 R-2: The relay MUST provide a mechanism to dynamically update 349 access control lists permitting ingress traffic sourced from 350 client delegated prefixes. This is to implement anti- 351 spoofing as described in [BCP38]. 353 R-3: The relay MAY provide a mechanism to dynamically advertise 354 delegated prefixes into an routing protocol as they are 355 learnt. When a delegated prefix is released or expires, the 356 delegated route MUST be withdrawn from the routing protocol. 357 The mechanism by which the routes are inserted and deleted is 358 out of the scope of this document. 360 R-4: If the relay has an existing route for a delegated prefix via 361 an interface, and receives ingress traffic on this interface 362 with a destination address from the delegated prefix (not 363 configured on the relay), then it MUST be dropped. 365 4.3. Service Continuity Requirements 367 S-1: In the event that the relay is restarted, active client 368 prefix delegations will be lost. This may result in clients 369 becoming unreachable. In order to mitigate this problem, it 370 is RECOMMENDED that the relay implements either of the 371 following: 373 * The relay MAY implement DHCPv6 bulk lease query as defined 374 in [RFC5460]. 376 * The relay SHOULD store active prefix delegations in 377 persistent storage so they can be re-read after the 378 reboot. 380 S-2: If a client's next-hop link-local address becomes unreachable 381 (e.g., due to a link-down event on the relevant physical 382 interface), routes for the client's delegated prefixes MUST 383 be retained by the delegating relay unless they are released 384 or removed due to expiring DHCP timers. This is to re- 385 establish routing for the delegated prefix if the client 386 next-hop becomes reachable without the delegated prefixes 387 needing to be re-learnt. 389 S-3: The relay MAY implement DHCPv6 active lease query as defined 390 in [RFC7653] to keep the local lease database in sync with 391 the DHCPv6 server. 393 4.4. Operational Requirements 395 O-1: The relay SHOULD implement an interface allowing the operator 396 to view the active delegated prefixes. This SHOULD provide 397 information about the delegated lease and client details such 398 as client identifier, next-hop address, connected interface, 399 and remaining lifetimes. 401 O-2: The relay SHOULD provide a method for the operator to clear 402 active bindings for an individual lease, client or all 403 bindings on a port. 405 O-3: To facilitate troubleshooting of operational problems between 406 the delegating relay and other elements, it is RECOMMENDED 407 that a time synchronization protocol is used by the 408 delegating routers and DHCP servers. 410 5. Acknowledgements 412 The authors of this document would like to thank Bernie Volz for his 413 valuable comments. 415 6. IANA Considerations 417 This memo includes no request to IANA. 419 7. Security Considerations 421 If the delegating relay implements [BCP38] filtering, then the 422 filtering rules will need to be dynamically updated as delegated 423 prefixes are leased. 425 [RFC8213] describes a method for securing traffic between the relay 426 agent and server by sending DHCP messages over an IPSec tunnel. In 427 this case the IPSec tunnel is functionally the server-facing 428 interface and DHCPv6 message snooping can be carried out as 429 described. It is RECOMMENDED that this is implemented by the 430 delegating relay. 432 8. References 433 8.1. Normative References 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, 437 DOI 10.17487/RFC2119, March 1997, 438 . 440 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 441 DOI 10.17487/RFC5460, February 2009, 442 . 444 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 445 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 446 October 2015, . 448 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 449 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 450 May 2017, . 452 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 453 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 454 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 455 RFC 8415, DOI 10.17487/RFC8415, November 2018, 456 . 458 8.2. Informative References 460 [BCP38] IETF, "Network Ingress Filtering: Defeating Denial of 461 Service Attacks which employ IP Source Address Spoofing 462 https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38. 464 [RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged 465 between Servers and Relay Agents", RFC 8213, 466 DOI 10.17487/RFC8213, August 2017, 467 . 469 Authors' Addresses 471 Ian Farrer 472 Deutsche Telekom AG 473 Landgrabenweg 151 474 Bonn, NRW 53227 475 DE 477 Email: ian.farrer@telekom.de 478 Naveen Kottapalli 479 Benu Networks 480 300 Concord Road 481 Billerica, MA 01821 482 US 484 Email: naveen.sarma@gmail.com 486 Martin Hunek 487 Technical University of Liberec 488 Studentska 1402/2 489 Liberec, L 46017 490 CZ 492 Email: martin.hunek@tul.cz 494 Richard Patterson 495 Sky UK Ltd 496 1 Brick Lane 497 London E1 6PU 498 UK 500 Email: richard.patterson@sky.uk