idnits 2.17.1 draft-ietf-dhc-dhcpv6-pd-relay-requirements-05.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 (January 2021) is 1198 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) ** Downref: Normative reference to an Informational RFC: RFC 4778 Summary: 1 error (**), 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 N. Kottapalli 5 Expires: 8 July 2021 Benu Networks 6 M. Hunek 7 Technical University of Liberec 8 R.P. Patterson 9 Sky UK Ltd 10 January 2021 12 DHCPv6 Prefix Delegating Relay Requirements 13 draft-ietf-dhc-dhcpv6-pd-relay-requirements-05 15 Abstract 17 This document describes operational problems that are known to occur 18 when using DHCPv6 relays with Prefix Delegation. These problems can 19 prevent successful delegation and result in routing failures. To 20 address these problems, this document provides necessary functional 21 requirements for operating DHCPv6 relays with Prefix Delegation. 23 It is recommended that any network operator that is using DHCPv6 24 prefix delegation with relays should ensure that these requirements 25 are followed on their networks. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 5 July 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 65 3. Problems Observed with Existing Delegating Relay 66 Implementations . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. DHCP Messages not being Forwarded by the Delegating 68 Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 6 70 3.3. Multiple Delegated Prefixes for a Single Client . . . . . 6 71 3.4. Dropping Messages from Devices with Duplicate MAC addresses 72 and DUIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.5. Forwarding Loops between Client and Relay . . . . . . . . 7 74 4. Requirements for Delegating Relays . . . . . . . . . . . . . 7 75 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7 76 4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 8 77 4.3. Service Continuity Requirements . . . . . . . . . . . . . 9 78 4.4. Operational Requirements . . . . . . . . . . . . . . . . 10 79 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 8.2. Informative References . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 For internet service providers that offer native IPv6 access with 90 prefix delegation to their customers, a common deployment 91 architecture is to have a DHCPv6 relay agent function located in the 92 ISP's Layer-3 customer edge device and separate, centralized DHCPv6 93 server infrastructure. [RFC8415] describes the functionality of a 94 DHCPv6 relay and Section 19.1.3 mentions this deployment scenario, 95 but does not provide details for all of the functional requirements 96 that the relay needs to fulfill to operate deterministically in this 97 deployment scenario. 99 A DHCPv6 relay agent for prefix delegation is a function commonly 100 implemented in routing devices, but implementations vary in their 101 functionality and client/server inter-working. This can result in 102 operational problems such as messages not being forwarded by the 103 relay or un-reachability of the delegated prefixes. This document 104 provides a set of requirements for devices implementing a relay 105 function for use with prefix delegation. 107 The mechanisms for a relay to inject routes (including aggregated 108 ones), on its network-facing interface based on prefixes learned from 109 a server via DHCP-PD are out of scope of the document. 111 Multi-hop DHCPv6 relaying is not affected. The requirements in this 112 document are solely applicable to the DHCP relay agent co-located 113 with the first-hop router that the DHCPv6 client requesting the 114 prefix is connected to, so no changes to any subsequent relays in the 115 path are needed. 117 2. Terminology 119 2.1. General 121 This document uses the terminology defined in [RFC8415], however, 122 when defining the functional elements for prefix delegation 123 [RFC8415], Section 4.2 defines the term 'delegating router' as: 125 "The router that acts as a DHCP server and responds to requests 126 for delegated prefixes." 128 This document is concerned with deployment scenarios in which the 129 DHCPv6 relay and DHCPv6 server functions are separated, so the term 130 'delegating router' is not used. Instead, a new term is introduced 131 to describe the relaying function: 133 Delegating relay A delegating relay acts as an intermediate device, 134 forwarding DHCPv6 messages containing IA_PD and 135 IAPREFIX options between the client and server. The 136 delegating relay does not implement a DHCPv6 server 137 function. The delegating relay is also responsible 138 for routing traffic for the delegated prefixes. 140 Where the term 'relay' is used on its own within this document, it 141 should be understood to be a delegating relay, unless specifically 142 stated otherwise. 144 In CableLabs DOCSIS environments, the Cable Modem Termination System 145 (CMTS) would be considered a delegating relay with respect to 146 Customer Premises Devices (CPEs) [DOCSIS_3.1], Section 5.2.7.2. A 147 Broadband Network Gateway (BNG) in a DSL based access network may be 148 a delegating relay if it does not implement a local DHCPv6 server 149 function [TR-092], Section 4.10. 151 [RFC8415] defines the 'DHCP server', (or 'server') as: 153 "A node that responds to requests from clients. It may or may not 154 be on the same link as the client(s). Depending on its 155 capabilities, if it supports prefix delegation it may also feature 156 the functionality of a delegating router." 158 This document serves the deployment cases where a DHCPv6 server is 159 not located on the same link as the client (necessitating the 160 delegating relay). The server supports prefix delegation and is 161 capable of leasing prefixes to clients, but is not responsible for 162 other functions required of a delegating router, such as managing 163 routes for the delegated prefixes. 165 The term 'requesting router' has previously been used to describe the 166 DHCP client requesting prefixes for use. This document adopts the 167 [RFC8415] terminology and uses 'DHCP client' or 'client' 168 interchangeably for this element. 170 2.2. Topology 172 The following diagram shows the deployment topology relevant to this 173 document. 175 + 176 | ------- uplink ------> 177 | _ ,--,_ 178 | +--------+ +------------+ _( `' )_ +--------+ 179 +---+ PD |-------| Delegating |--( Operator )---| DHCPv6 | 180 | | Client | | relay | `(_ Network_)' | server | 181 | +--------+ +----------- + `--'`---' +--------+ 182 | 183 | <----- downlink ------ 184 + (client facing) 185 Client 186 Network 188 Figure 1: Topology overview 190 The client requests prefixes via the downlink interface of the 191 delegating relay. The resulting prefixes will be used for addressing 192 the client network. The delegating relay is responsible for 193 forwarding DHCP messages, including prefix delegation requests and 194 responses between the client and server. Messages are forwarded from 195 the delegating relay to the server using multicast or unicast via the 196 operator uplink interface. 198 The delegating relay provides the operator's Layer-3 edge towards the 199 client and is responsible for routing traffic to and from clients 200 connected to the client network using addresses from the delegated 201 prefixes. 203 2.3. Requirements Language 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 207 "OPTIONAL" in this document are to be interpreted as described in BCP 208 14 [RFC2119] [RFC8174] when, and only when, they appear in all 209 capitals, as shown here. 211 3. Problems Observed with Existing Delegating Relay Implementations 213 The following sections of the document describe problems that have 214 been observed with delegating relay implementations in commercially 215 available devices. 217 3.1. DHCP Messages not being Forwarded by the Delegating Relay 219 Delegating relay implementations have been observed not to forward 220 messages between the client and server. This generally occurs if a 221 client sends a message which is unexpected by the delegating relay. 222 For example, the delegating relay already has an active PD lease 223 entry for an existing client on a port. A new client is connected to 224 this port and sends a Solicit message. The delegating relay then 225 drops the Solicit messages until it receives either a DHCP Release 226 message from the original client, or the existing lease times out. 227 This causes a particular problem when a client device needs to be 228 replaced due to a failure. 230 In addition to dropping messages, in some cases the delegating relay 231 will generate error messages and send them to the client, e.g. 232 'NoBinding' messages being sent in the event that the delegating 233 relay does not have an active delegated prefix lease. 235 3.2. Delegating Relay Loss of State on Reboot 237 For proper routing of client traffic, the delegating relay requires a 238 corresponding routing table entry for each active prefix delegated to 239 a connected client. A delegating relay which does not store this 240 state persistently across reboots will not be able to forward traffic 241 to client's delegated leases until the state is re-established 242 through new DHCP messages. 244 3.3. Multiple Delegated Prefixes for a Single Client 246 [RFC8415] allows for a client to include more than one instance of 247 OPTION_IA_PD in messages in order to request multiple prefix 248 delegations by the server. If configured for this, the server 249 supplies one (or more) instance of OPTION_IAPREFIX for each received 250 instance of OPTION_IA_PD, each containing information for a different 251 delegated prefix. 253 In some delegating relay implementations, only a single delegated 254 prefix per-DUID is supported. In those cases only one IPv6 route for 255 one of the delegated prefixes is installed; meaning that other 256 prefixes delegated to a client are unreachable. 258 3.4. Dropping Messages from Devices with Duplicate MAC addresses and 259 DUIDs 261 It is an operational reality that client devices with duplicate MAC 262 addresses and/or DUIDs exist and have been deployed. In some 263 networks, the operational costs of locating and swapping out such 264 devices are prohibitive. 266 Delegating relays have been observed to restrict forwarding client 267 messages originating from one client DUID to a single interface. In 268 this case if the same client DUID appears from a second client on 269 another interface while there is already an active lease, messages 270 originating from the second client are dropped causing the second 271 client to be unable to obtain a prefix delegation. 273 It should be noted that in some access networks, the MAC address and/ 274 or DUID are used as part of device identification and authentication. 275 In such networks, enforcing MAC address/DUID uniqueness is a 276 necessary function and not considered a problem. 278 3.5. Forwarding Loops between Client and Relay 280 If the client loses information about an active prefix lease it has 281 been delegated while the lease entry and associated route is still 282 active in the delegating relay, then the relay will forward traffic 283 to the client which the client will return to the relay (which is the 284 client's default gateway (learned via an RA)). The loop will 285 continue until either the client is successfully re-provisioned via 286 DHCP, or the lease ages out in the relay. 288 4. Requirements for Delegating Relays 290 To resolve the problems described in Section 3 and pre-empt other 291 undesirable behavior, the following section of the document describes 292 a set of functional requirements for the delegating relay. 294 In addition, relay implementers are reminded that [RFC8415] makes it 295 clear that relays MUST forward packets that either contain message 296 codes (Section 19 of [RFC8415]) it may not understand, or contain 297 options that it does not understand (Section 16 of [RFC8415]). 299 4.1. General Requirements 301 G-1: The delegating relay MUST forward messages bidirectionally 302 between the client and server without changing the contents 303 of the message. 305 G-2: The relay MUST allow for multiple prefixes to be delegated 306 for the same client IA_PD. These delegations may have 307 different lifetimes. 309 G-3: The relay MUST allow for multiple prefixes (with or without 310 separate IA_PDs) to be delegated to a single client connected 311 to a single interface, identified by its DHCPv6 Client 312 Identifier (DUID). 314 G-4: A delegating relay may have one or more interfaces on which 315 it acts as a relay, as well as one or more interfaces on 316 which it does not (for example, in an ISP, it might act as a 317 relay on all southbound interfaces, but not on the northbound 318 interfaces). The relay SHOULD allow the same client 319 identifier (DUID) to have active delegated prefix leases on 320 more than one interface simultaneously, unless client DUID 321 uniqueness is necessary for the functioning or security of 322 the network. This is to allow client devices with duplicate 323 DUIDs to function on separate broadcast domains. 325 G-5: The maximum number of simultaneous prefixes delegated to a 326 single client MUST be configurable. 328 G-6: The relay MUST implement a mechanism to limit the maximum 329 number of active prefix delegations on a single port for all 330 client identifiers and IA_PDs. This value MUST be 331 configurable. 333 G-7: It is RECOMMENDED that delegating relays support at least 8 334 active delegated leases per client device and use this as the 335 default limit. 337 G-8: The delegating relay MUST update the lease lifetimes based on 338 the client's reply messages it forwards to the client and 339 only expire the delegated prefixes when the valid lifetime 340 has elapsed. 342 G-9: On receipt of a Release message from the client, the 343 delegating relay MUST expire the active leases for each of 344 the IA_PDs in the message. 346 4.2. Routing Requirements 348 R-1: The relay MUST maintain a local routing table that is 349 dynamically updated with leases and the associated next-hops 350 as they are delegated to clients. When a delegated prefix is 351 Released or expires, the associated route MUST be removed 352 from the relay's routing table. 354 R-2: The delegating relay's routing entry MUST use the same prefix 355 length for the delegated prefix as given in the IA_PD. 357 R-3: The relay MUST provide a mechanism to dynamically update 358 ingress filters permitting ingress traffic sourced from 359 client delegated leases and blocking packets from invalid 360 source prefixes. This is to implement anti-spoofing as 361 described in [BCP38]. The delegating relay's ingress filter 362 entry MUST use the same prefix length for the delegated 363 prefix as given in the IA_PD. 365 R-4: The relay MAY provide a mechanism to dynamically advertise 366 delegated leases into a routing protocol as they are learned. 367 If such a mechanism is implemented, when a delegated lease is 368 released or expires, the delegated route MUST be withdrawn 369 from the routing protocol. The mechanism by which the routes 370 are inserted and deleted is out of the scope of this 371 document. 373 R-5: To prevent routing loops, the relay SHOULD implement a 374 configurable policy to drop potential looping packets 375 received on any DHCP-PD client facing interfaces. 377 The policy SHOULD be configurable on a per-client or per- 378 destination basis. 380 Looping packets are those with a destination address in a 381 prefix delegated to a client connected to that interface, as 382 follows: 384 * For point-to-point links, when the packet's ingress and 385 egress interfaces match. 387 * For multi-access links, when the packet's ingress and 388 egress interface match, and the source link-layer and 389 next-hop link-layer addresses match. 391 An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject 392 route to destination) error message MAY be sent as per 393 [RFC4443], section 3.1. The ICMP policy SHOULD be 394 configurable. 396 4.3. Service Continuity Requirements 398 S-1: To preserve active client prefix delegations across relay 399 restarts, the relay SHOULD implement at least one of the 400 following: 402 * Implement DHCPv6 bulk lease query as defined in [RFC5460]. 404 * Store active prefix delegations in persistent storage so 405 they can be re-read after the reboot. 407 S-2: If a client's next-hop link-local address becomes unreachable 408 (e.g., due to a link-down event on the relevant physical 409 interface), routes for the client's delegated prefixes MUST 410 be retained by the delegating relay unless they are released 411 or removed due to expiring DHCP timers. This is to re- 412 establish routing for the delegated prefix if the client 413 next-hop becomes reachable without the delegated prefixes 414 needing to be re-learned. 416 S-3: The relay SHOULD implement DHCPv6 active lease query as 417 defined in [RFC7653] to keep the local lease database in sync 418 with the DHCPv6 server. 420 4.4. Operational Requirements 422 O-1: The relay SHOULD implement an interface allowing the operator 423 to view the active delegated prefixes. This SHOULD provide 424 information about the delegated lease and client details such 425 as client identifier, next-hop address, connected interface, 426 and remaining lifetimes. 428 O-2: The relay SHOULD provide a method for the operator to clear 429 active bindings for an individual lease, client or all 430 bindings on a port. 432 O-3: To facilitate troubleshooting of operational problems between 433 the delegating relay and other elements, it is RECOMMENDED 434 that a time synchronization protocol is used by the 435 delegating relays and DHCP servers. 437 5. Acknowledgements 439 The authors of this document would like to thank Bernie Volz, Ted 440 Lemon, and Michael Richardson for their valuable comments. 442 6. IANA Considerations 444 This memo includes no request to IANA. 446 7. Security Considerations 448 This document does not add any new security considerations beyond 449 those mentioned in Section 4 of [RFC8213] and Section 22 of 450 [RFC8415]. 452 If the delegating relay implements [BCP38] filtering, then the 453 filtering rules will need to be dynamically updated as delegated 454 prefixes are leased. 456 [RFC8213] describes a method for securing traffic between the relay 457 agent and server by sending DHCP messages over an IPsec tunnel. It 458 is RECOMMENDED that this is implemented by the delegating relay. 460 Failure to implement requirement G-6 may have specific security 461 implications, such as a resource depletion attack on the relay. 463 The operational requirements in Section Section 4.4 may introduce 464 additional security considerations. It is RECOMMENDED that the 465 operational security practices described in [RFC4778] are 466 implemented. 468 8. References 470 8.1. Normative References 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, 474 DOI 10.17487/RFC2119, March 1997, 475 . 477 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 478 Control Message Protocol (ICMPv6) for the Internet 479 Protocol Version 6 (IPv6) Specification", STD 89, 480 RFC 4443, DOI 10.17487/RFC4443, March 2006, 481 . 483 [RFC4778] Kaeo, M., "Operational Security Current Practices in 484 Internet Service Provider Environments", RFC 4778, 485 DOI 10.17487/RFC4778, January 2007, 486 . 488 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 489 DOI 10.17487/RFC5460, February 2009, 490 . 492 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 493 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 494 October 2015, . 496 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 497 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 498 May 2017, . 500 [RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged 501 between Servers and Relay Agents", RFC 8213, 502 DOI 10.17487/RFC8213, August 2017, 503 . 505 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 506 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 507 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 508 RFC 8415, DOI 10.17487/RFC8415, November 2018, 509 . 511 8.2. Informative References 513 [BCP38] IETF, "Network Ingress Filtering: Defeating Denial of 514 Service Attacks which employ IP Source Address Spoofing 515 https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38, 516 . 518 [DOCSIS_3.1] 519 CableLabs, "MAC and Upper Layer Protocols Interface 520 Specification", DOCSIS 3.1, January, 2017", 521 . 523 [TR-092] Broadband Forum, "Broadband Remote Access Server (BRAS) 524 Requirements Document, August, 2004", 525 . 527 Authors' Addresses 529 Ian Farrer 530 Deutsche Telekom AG 531 Landgrabenweg 151 532 53227 Bonn 533 Germany 535 Email: ian.farrer@telekom.de 537 Naveen Kottapalli 538 Benu Networks 539 154 Middlesex Turnpike 540 Burlington, MA 01803 541 United States of America 543 Email: nkottapalli@benunets.com 545 Martin Hunek 546 Technical University of Liberec 547 Studentska 1402/2 548 46017 Liberec 549 Czechia 550 Email: martin.hunek@tul.cz 552 Richard Patterson 553 Sky UK Ltd 554 1 Brick Lane 555 London 556 E1 6PU 557 United Kingdom 559 Email: richard.patterson@sky.uk