idnits 2.17.1 draft-ietf-dhc-dhcpv6-pd-relay-requirements-03.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 (November 16, 2020) is 1228 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: May 20, 2021 Benu Networks 6 M. Hunek 7 Technical University of Liberec 8 R. Patterson 9 Sky UK Ltd 10 November 16, 2020 12 DHCPv6 Prefix Delegating Relay Requirements 13 draft-ietf-dhc-dhcpv6-pd-relay-requirements-03 15 Abstract 17 This memo describes operational problems that are known to occur when 18 using DHCPv6 relays with Prefix Delegation. These problems can 19 prevent successful delegation and result in routing failures. To 20 address these problems, this memo 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 May 20, 2021. 44 Copyright Notice 46 Copyright (c) 2020 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 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 66 3. Problems Observed with Existing Delegating Relay 67 Implementations . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. DHCP Messages not being Forwarded by the Delegating 69 Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 5 71 3.3. Multiple Delegated Prefixes for a Single Client . . . . . 6 72 3.4. Dropping Messages from Devices with Duplicate MAC 73 addresses and DUIDs . . . . . . . . . . . . . . . . . . . 6 74 3.5. Forwarding Loops between Client and Relay . . . . . . . . 6 75 4. Requirements for Delegating Relays . . . . . . . . . . . . . 7 76 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7 77 4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 8 78 4.3. Service Continuity Requirements . . . . . . . . . . . . . 9 79 4.4. Operational Requirements . . . . . . . . . . . . . . . . 9 80 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 8.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 For Internet service providers that offer native IPv6 access with 91 prefix delegation to their customers, a common deployment 92 architecture is to have a DHCPv6 relay agent function located in the 93 ISP's Layer-3 customer edge device and separate, centralized DHCPv6 94 server infrastructure. [RFC8415] describes the functionality of a 95 DHCPv6 relay and Section 19.1.3 mentions this deployment scenario, 96 but does not provide detail for all of the functional requirements 97 that the relay needs to fulfill to operate deterministically in this 98 deployment scenario. 100 A DHCPv6 relay agent for prefix delegation is a function commonly 101 implemented in routing devices, but implementations vary in their 102 functionality and client/server inter-working. This can result in 103 operational problems such as messages not being forwarded by the 104 relay or un-reachability of the delegated prefixes. This document 105 provides a set of requirements for devices implementing a relay 106 function for use with prefix delegation. 108 The mechanisms for a relay to inject routes (including aggregated 109 ones), on its network-facing interface based on prefixes learned from 110 a server via DHCP-PD are out of scope of the document. 112 Multi-hop DHCPv6 relaying is not affected. The requirements in this 113 document are solely applicable to the DHCP relay agent co-located 114 with the first-hop router that the DHCPv6 client requesting the 115 prefix is connected to, so no changes to any subsequent relays in the 116 path are needed. 118 2. Terminology 120 2.1. General 122 This document uses the terminology defined in [RFC8415], however when 123 defining the functional elements for prefix delegation [RFC8415], 124 Section 4.2 defines the term 'delegating router' as: 126 "The router that acts as a DHCP server and responds to requests 127 for delegated prefixes." 129 This document is concerned with deployment scenarios in which the 130 DHCPv6 relay and DHCPv6 server functions are separated, so the term 131 'delegating router' is not used. Instead, a new term is introduced 132 to describe the relaying function: 134 Delegating relay A delegating relay acts as an intermediate device, 135 forwarding DHCPv6 messages containing IA_PD/IAPREFIX 136 options between the client and server. The 137 delegating relay does not implement a DHCPv6 server 138 function. The delegating relay is also responsible 139 for routing traffic for the delegated prefixes. 141 Where the term 'relay' is used on its own within this document, it 142 should be understood to be a delegating relay, unless specifically 143 stated otherwise. 145 In CableLabs DOCSIS environments, the Cable Modem Termination System 146 (CMTS) would be considered a delegating relay with respect to 147 Customer Premises Devices (CPEs) [DOCSIS_3.1], Section 5.2.7.2. A 148 Broadband Network Gateway (BNG) in a DSL based access network may be 149 a delegating relay if it does not implement a local DHCPv6 server 150 function [TR-092], Section 4.10. 152 [RFC8415] defines the 'DHCP server', (or 'server') as: 154 "A node that responds to requests from clients. It may or may not 155 be on the same link as the client(s). Depending on its 156 capabilities, if it supports prefix delegation it may also feature 157 the functionality of a delegating router." 159 This document serves the deployment cases where a DHCPv6 server is 160 not located on the same link as the client (necessitating the 161 delegating relay). The server supports prefix delegation and is 162 capable of leasing prefixes to clients, but is not responsible for 163 other functions required of a delegating router, such as managing 164 routes for the delegated prefixes. 166 The term 'requesting router' has previously been used to describe the 167 DHCP client requesting prefixes for use. This document adopts the 168 [RFC8415] terminology and uses 'DHCP client' or 'client' 169 interchangeably for this element. 171 2.2. Topology 173 The following diagram shows the deployment topology relevant to this 174 document. 176 + 177 | ------- uplink ------> 178 | _ ,--,_ 179 | +--------+ +------------+ _( `' )_ +--------+ 180 +---+ PD |-------| Delegating |--( Operator )---| DHCPv6 | 181 | | Client | | relay | `(_ Network_)' | server | 182 | +--------+ +----------- + `--'`---' +--------+ 183 | 184 | <----- downlink ------ 185 + (client facing) 186 Client 187 Network 189 Figure 1: Topology overview 191 The client requests prefixes via the downlink 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 uplink 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. 212 3. Problems Observed with Existing Delegating Relay Implementations 214 The following sections of the document describe problems that have 215 been observed with delegating relay implementations in commercially 216 available devices. 218 3.1. DHCP Messages not being Forwarded by the Delegating Relay 220 Delegating relay implementations have been observed not to forward 221 messages between the client and server. This generally occurs if a 222 client sends a message which is unexpected by the delegating relay. 223 For example, the delegating router already has an active PD lease 224 entry for an existing client on a port. A new client is connected to 225 this port and sends a Solicit message. The delegating relay then 226 drops the Solicit messages until it receives either a DHCP Release 227 message from the original client, or the existing lease times out. 228 This causes a particular problem when a client device needs to be 229 replaced due to a failure. 231 In addition to dropping messages, in some cases the delegating relay 232 will generate error messages and send them to the client, e.g. 233 'NoBinding' messages being sent in the event that the delegating 234 relay does not have an active delegated prefix lease. 236 3.2. Delegating Relay Loss of State on Reboot 238 For proper routing of client traffic, the delegating relay requires a 239 corresponding routing table entry for each active prefix delegated to 240 a connected client. A delegating relay which does not store this 241 state persistently across reboots will not be able to forward traffic 242 to client's delegated leases until the state is re-established 243 through new DHCP messages. 245 3.3. Multiple Delegated Prefixes for a Single Client 247 [RFC8415] allows for a client to include more than one instance of 248 OPTION_IA_PD in messages in order to request multiple prefix 249 delegations by the server. If configured for this, the server 250 supplies one (or more) instance of OPTION_IAPREFIX for each received 251 instance of OPTION_IA_PD, each containing information for a different 252 delegated prefix. 254 In some delegating relay implementations, only a single delegated 255 prefix per-DUID is supported. In those cases only one IPv6 route for 256 one of the delegated prefixes is installed; meaning that other 257 prefixes delegated to a client are unreachable. 259 3.4. Dropping Messages from Devices with Duplicate MAC addresses and 260 DUIDs 262 It is an unfortunate operational reality that client devices with 263 duplicate MAC addresses and/or DUIDs exist and have been deployed. 264 In this situation, the operational costs of locating and swapping out 265 such devices are prohibitive. 267 Delegating relays have been observed to restrict forwarding client 268 messages originating from one client DUID to a single interface. In 269 this case if the same client DUID appears from a second client on 270 another interface while there is already an active lease, messages 271 originating from the second client are dropped causing the second 272 client to be unable to obtain a prefix delegation. 274 It should be noted that in some access networks, the MAC address and/ 275 or DUID are used as part of device identification and authentication. 276 In such networks, enforcing MAC address/DUID uniqueness is a 277 necessary function and not considered a problem. 279 3.5. Forwarding Loops between Client and Relay 281 If the client loses information about a prefix that it is delegated 282 while the lease entry and associated route is still active in the 283 delegating relay, then the relay will forward traffic to the client 284 which the client will return to the relay (which is the client's 285 default gateway (learned via an RA)). The loop will continue until 286 either the client is successfully re-provisioned via DHCP, or the 287 lease ages out in the relay. 289 4. Requirements for Delegating Relays 291 To resolve the problems described in Section 3 and pre-empt other 292 undesirable behavior, the following section of the document describes 293 a set of functional requirements for the delegating relay. 295 In addition, relay implementers are reminded that [RFC8415] makes it 296 clear that relays MUST NOT drop (and hence not relay) packets that 297 either contain message codes (Section 19 of [RFC8415]) it may not 298 understand, or contain options that it does not understand 299 (Section 19 of [RFC8415]). 301 4.1. General Requirements 303 G-1: The delegating relay MUST forward messages bidirectionally 304 between the client and server without changing the contents 305 of the message. 307 G-2: The relay MUST allow for multiple prefixes to be delegated 308 for the same client IA_PD. These delegations may have 309 different lifetimes. 311 G-3: The relay MUST allow for multiple prefixes (with or without 312 separate IA_PDs) to be delegated to a single client connected 313 to a single interface, identified by its DHCPv6 Client 314 Identifier (DUID). 316 G-4: A delegating relay may have one or more interfaces on which 317 it acts as a relay, as well as one or more interfaces on 318 which it does not (for example, in an ISP, it might act as a 319 relay on all southbound interfaces, but not on the northbound 320 interfaces). The relay SHOULD allow the same client 321 identifier (DUID) to have active delegated prefix leases on 322 more than one interface simultaneously, unless client DUID 323 uniqueness is necessary for the functioning or security of 324 the network. This is to allow client devices with duplicate 325 DUIDs to function on separate broadcast domains. 327 G-5: The maximum number of simultaneous prefixes delegated to a 328 single client MUST be configurable. 330 G-6: The relay MUST implement a mechanism to limit the maximum 331 number of active prefix delegations on a single port for all 332 client identifiers and IA_PDs. This value MUST be 333 configurable. 335 G-7: It is RECOMMENDED that delegating relays support at least 8 336 active delegated leases per client device and use this as the 337 default limit. 339 G-8: The delegating relay MUST update the lease lifetimes based on 340 the Client Reply messages it forwards to the client and only 341 expire the delegated prefixes when the valid lifetime has 342 elapsed. 344 G-9: On receipt of a Release message from the client, the 345 delegating relay MUST expire the active leases for each of 346 the IA_PDs in the message. 348 4.2. Routing Requirements 350 R-1: The relay MUST maintain a local routing table that is 351 dynamically updated with leases and the associated next-hops 352 as they are delegated to clients. When a delegated prefix is 353 Released or expires, the associated route MUST be removed 354 from the relay's routing table. 356 R-2: The relay MUST provide a mechanism to dynamically update 357 ingress filters permitting ingress traffic sourced from 358 client delegated leases and blocking packets from invalid 359 source prefixes. This is to implement anti-spoofing as 360 described in [BCP38]. 362 R-3: The relay MAY provide a mechanism to dynamically advertise 363 delegated leases into a routing protocol as they are learned. 364 When a delegated lease is released or expires, the delegated 365 route MUST be withdrawn from the routing protocol. The 366 mechanism by which the routes are inserted and deleted is out 367 of the scope of this document. 369 R-4: To prevent routing loops, the relay SHOULD implement a 370 configurable policy to drop potential looping packets 371 received on any DHCP-PD client facing interfaces. 373 The policy SHOULD be configurable on a per-client or per- 374 destination basis. 376 Looping packets are those with a destination address in a 377 prefix delegated to a client connected to that interface, as 378 follows: 380 * For point-to-point links, when the packet's ingress and 381 egress interfaces match. 383 * For multi-access links, when the packet's ingress and 384 egress interface match, and the source link-layer and 385 next-hop link-layer addresses match. 387 An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject 388 route to destination) error message MAY be sent as per 389 [RFC4443], section 3.1. The ICMP policy SHOULD be 390 configurable. 392 R-5: The delegating relay's routing entry MUST use the same prefix 393 length for the delegated prefix as given in the IA_PD. 395 4.3. Service Continuity Requirements 397 S-1: In the event that the relay is restarted, active client 398 prefix delegations will be lost. This may result in clients 399 becoming unreachable. In order to mitigate this problem, the 400 relay SHOULD implement at least only 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 22 of [RFC8213]. 451 If the delegating relay implements [BCP38] filtering, then the 452 filtering rules will need to be dynamically updated as delegated 453 prefixes are leased. 455 [RFC8213] describes a method for securing traffic between the relay 456 agent and server by sending DHCP messages over an IPsec tunnel. In 457 this case the IPsec tunnel is functionally the server-facing 458 interface and DHCPv6 message snooping can be carried out as 459 described. It is RECOMMENDED that this is implemented by the 460 delegating relay. 462 8. References 464 8.1. Normative References 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, 468 DOI 10.17487/RFC2119, March 1997, 469 . 471 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 472 DOI 10.17487/RFC5460, February 2009, 473 . 475 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 476 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 477 October 2015, . 479 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 480 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 481 May 2017, . 483 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 484 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 485 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 486 RFC 8415, DOI 10.17487/RFC8415, November 2018, 487 . 489 8.2. Informative References 491 [BCP38] IETF, "Network Ingress Filtering: Defeating Denial of 492 Service Attacks which employ IP Source Address Spoofing 493 https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38. 495 [DOCSIS_3.1] 496 CableLabs, "MAC and Upper Layer Protocols Interface 497 Specification", DOCSIS 3.1, January, 2017", 498 . 500 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 501 Control Message Protocol (ICMPv6) for the Internet 502 Protocol Version 6 (IPv6) Specification", STD 89, 503 RFC 4443, DOI 10.17487/RFC4443, March 2006, 504 . 506 [RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged 507 between Servers and Relay Agents", RFC 8213, 508 DOI 10.17487/RFC8213, August 2017, 509 . 511 [TR-092] Broadband Forum, "Broadband Remote Access Server (BRAS) 512 Requirements Document, August, 2004", 513 . 515 Authors' Addresses 517 Ian Farrer 518 Deutsche Telekom AG 519 Landgrabenweg 151 520 Bonn, NRW 53227 521 DE 523 Email: ian.farrer@telekom.de 524 Naveen Kottapalli 525 Benu Networks 526 300 Concord Road 527 Billerica, MA 01821 528 US 530 Email: naveen.sarma@gmail.com 532 Martin Hunek 533 Technical University of Liberec 534 Studentska 1402/2 535 Liberec, L 46017 536 CZ 538 Email: martin.hunek@tul.cz 540 Richard Patterson 541 Sky UK Ltd 542 1 Brick Lane 543 London E1 6PU 544 UK 546 Email: richard.patterson@sky.uk