idnits 2.17.1 draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8415]), 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 (March 5, 2020) is 1506 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) -- Obsolete informational reference (is this intentional?): RFC 7283 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: September 6, 2020 Benu Networks 6 M. Hunek 7 Technical University of Liberec 8 Richard. Patterson 9 March 5, 2020 11 DHCPv6 Prefix Delegating Relay 12 draft-ietf-dhc-dhcpv6-pd-relay-requirements-00 14 Abstract 16 Operational experience with DHCPv6 prefix delegation has shown that 17 when the DHCPv6 relay function is not co-located with the DHCPv6 18 server function, issues such as timer synchronization between the 19 DHCP functional elements, rejection of client's messages by the 20 relay, and other problems have been observed. These problems can 21 result in prefix delegation failing or traffic to/from clients 22 addressed from the delegated prefix being unrouteable. Although 23 [RFC8415] mentions this deployment scenario, it does not provide 24 necessary detail on how the relay element should behave when used 25 with PD. 27 This document describes functional requirements for a DHCPv6 PD relay 28 when used for relaying prefixes delegated by a separate DHCPv6 29 server. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 6, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 70 3. Problems Observed with Existing Delegating Relays 71 Implementations . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. DHCP Messages not being Forwarded by the Delegating relay 5 73 3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 6 74 3.3. Multiple Simultaneous Delegated Prefixes for a Single 75 DUID on 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 . . . . . . . . . . . . . . . . . . 7 81 4.3. Service Continuity Requirements . . . . . . . . . . . . . 8 82 4.4. Operational Requirements . . . . . . . . . . . . . . . . 8 83 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 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 defined in [RFC7283] is also applicable for DHCv6-PD- 121 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 [RFC8415] defines the 'DHCP server', (or 'server') as: 152 "A node that responds to requests from clients. It may or may not 153 be on the same link as the client(s). Depending on its 154 capabilities, if it supports prefix delegation it may also feature 155 the functionality of a delegating router. 157 This document serves the deployment cases where a DHCPv6 server is 158 not located on the same link as the client (necessitating the 159 delegating relay). The server supports prefix delegation and is 160 capable of leasing prefixes to clients, but is not responsible for 161 other functions required of a delegating router, such as managing 162 routes for the delegated prefixes. 164 The term 'requesting router' has previously been used to describe the 165 DHCP client requesting prefixes for use. This document adopts the 166 [RFC8415] terminology and uses 'DHCP client' or 'client' 167 interchangeably for this element. 169 2.2. Topology 171 The following diagram shows the deployment topology relevant to this 172 document. 174 + _ ,--,_ 175 | +--------+ +------------+ _( `' )_ +--------+ 176 +---+ PD |----| Delegating |--( Operator )---| DHCPv6 | 177 | | Client | | relay | `(_ Network_)' | server | 178 | +--------+ +----------- + `--'`---' +--------+ 179 | 180 + 181 Client Network 183 Figure 1 185 The client request prefixes via the client facing interface of the 186 delegating relay. The resulting prefixes will be used for addressing 187 the client network. The delegating relay is responsible for 188 forwarding DHCP messages, including prefix delegation requests and 189 responses between the client and server. Messages are forwarded from 190 the delegating relay to the server using multicast or unicast via the 191 operator network facing interface. 193 The delegating relay provides the operator's Layer-3 edge towards the 194 client and is responsible for routing traffic to and from clients 195 connected to the client network using addresses from the delegated 196 prefixes. 198 2.3. Requirements Language 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 202 "OPTIONAL" in this document are to be interpreted as described in BCP 203 14 [RFC2119] [RFC8174] when, and only when, they appear in all 204 capitals, as shown here. This document uses these keywords not 205 strictly for the purpose of interoperability, but rather for the 206 purpose of establishing industry-common baseline functionality. As 207 such, the document points to several other specifications (preferably 208 in RFC or stable form) to provide additional guidance to implementers 209 regarding any protocol implementation required to produce a DHCP 210 relaying router that functions successfully with prefix delegation. 212 3. Problems Observed with Existing Delegating Relays 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's traffic, the delegating relay requires 239 a corresponding routing table entry for each active prefix delegated 240 to a connected client. A delegating router 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 Simultaneous Delegated Prefixes for a Single DUID on a 246 Single Client 248 [RFC8415] allows for a client to include more than one instance of 249 OPTION_IA_PD in messages in order to request multiple prefix 250 delegations by the server. If configured for this, the server 251 supplies one instance of OPTION_IAPREFIX for each received instance 252 of OPTION_IA_PD, each containing information for a different 253 delegated prefix. 255 In some delegating relay implementations, only a single delegated 256 prefix per-DUID is supported. In those cases only one IPv6 route for 257 only one of the delegated router is installed; meaning that other 258 prefixes delegated to a client are unreachable. 260 3.4. Dropping Messages from Devices with Duplicate MAC addresses and 261 DUIDs 263 It is an unfortunate operational reality that client devices with 264 duplicate MAC addresses and/or DUIDs exist and have been deployed. 265 In this situation, the operational costs of locating and swapping out 266 such devices are prohibitive. 268 Delegating relays have been observed to restrict forwarding client 269 messages originating from one client DUID to a single interface. In 270 this case if the same client DUID appears from a second client on 271 another interface while there is already an active lease, messages 272 originating from the second client are dropped causing the second 273 client to be unable to obtain a prefix delegation. 275 4. Requirements for Delegating Relays 277 To resolve the problems described in Section 3 the following section 278 of the document describes a set of functional requirements for the 279 delegating relay. 281 4.1. General Requirements 283 G-1: The delegating router MUST forward messages bidirectionally 284 between the client and server without changing the contents 285 of the message. 287 G-2: As described in Section 16 of [RFC8415], in the event that a 288 received message contains a DHCPv6 option which the relay 289 does not implement, the message MUST be forwarded. 291 G-3: The relay MUST allow for multiple prefixes to be delegated 292 for the same client IA_PD. These delegations may have 293 different lifetimes. 295 G-4: The relay MUST allow for multiple prefixes with separate 296 IA_PDs to be delegated to a single client connected to a 297 single interface, identified by its DHCPv6 Client Identifier 298 (DUID). 300 G-5: The relay MUST allow the same client identifier (DUID) to 301 have active delegated prefix leases on more than one 302 interface simultaneously. This is to allow client devices 303 with duplicate DUIDs to function on separate broadcast 304 domains. 306 G-6: The maximum number of simultaneous prefixes delegated to a 307 single client MUST be configurable. 309 G-7: The relay MUST implement a mechanism to limit the maximum 310 number of active prefix delegations on a single port for all 311 client identifiers and IA_PDs. This value SHOULD be 312 configurable. 314 G-8: The delegating relay MUST synchronize the lifetimes of active 315 prefix delegation leases with server. 317 4.2. Routing Requirements 319 R-1: The relay MUST maintain a local routing table that is 320 dynamically updated with prefixes and the associated next- 321 hops as they are delegated to clients. When a delegated 322 prefix is released or expires, the associated route MUST be 323 removed from the relay's routing table. 325 R-2: The relay MUST provide a mechanism to dynamically update 326 access control lists permitting ingress traffic sourced from 327 clients' delegated prefixes. This is to implement anti- 328 spoofing as described in [BCP38]. 330 R-3: The relay MAY provide a mechanism to dynamically advertise 331 delegated prefixes into an routing protocol as they are 332 learnt. When a delegated prefix is released or expires, the 333 delegated route MUST be withdrawn from the routing protocol. 334 The mechanism using which the routes are inserted and deleted 335 is out of the scope of this document. 337 4.3. Service Continuity Requirements 339 S-1: In the event that the relay is restarted, active client 340 prefix delegations will be lost. This may result in clients 341 becoming unreachable. In order to mitigate this problem, it 342 is RECOMMENDED that the relay implements either of the 343 following: 345 The relay MAY implement DHCPv6 bulk lease query as 346 defined in [RFC5460]. 348 The relay SHOULD store active prefix delegations in 349 persistent storage so they can be re-read after the 350 reboot. 352 S-2: If a client's next-hop link-local address becomes unreachable 353 (e.g., due to a link-down event on the relevant physical 354 interface), routes for the client's delegated prefixes MUST 355 be retained by the delegating relay unless they are released 356 or removed due to expiring DHCP timers. This is to re- 357 establish routing for the delegated prefix if the client 358 next-hop becomes reachable without the relay needing to be 359 re-learnt. 361 S-3: The relay MAY implement DHCPv6 active lease query as defined 362 in [RFC7653] to keep the local lease database in sync with 363 the DHCPv6 server. 365 4.4. Operational Requirements 367 O-1: The relay SHOULD implement an interface allowing the operator 368 to view the active delegated prefixes. This SHOULD provide 369 information about the delegated lease and client details such 370 as client identifier, next-hop address, connected interface, 371 and remaining lifetimes. 373 O-2: The relay SHOULD provide a method for the operator to clear 374 active bindings for an individual lease, client or all 375 bindings on a port. 377 O-3: To facilitate troubleshooting of operational problems between 378 the delegating relay and other elements, it is RECOMMENDED 379 that the delegating relay's system time is synchronised with 380 the network. 382 5. Acknowledgements 384 The authors of this document would like to thank Bernie Volz for his 385 valuable comments. 387 6. IANA Considerations 389 This memo includes no request to IANA. 391 7. Security Considerations 393 If the delegating relay implements [BCP38] filtering, then the 394 filtering rules will need to be dynamically updated as delegated 395 prefixes are leased. 397 [RFC8213] describes a method for securing traffic between the relay 398 agent and server by sending DHCP messages over an IPSec tunnel. In 399 this case the IPSec tunnel is functionally the server-facing 400 interface and DHCPv6 message snooping can be carried out as 401 described. It is RECOMMENDED that this is implemented by the 402 delegating relay. 404 8. References 406 8.1. Normative References 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, 410 DOI 10.17487/RFC2119, March 1997, 411 . 413 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 414 DOI 10.17487/RFC5460, February 2009, 415 . 417 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 418 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 419 October 2015, . 421 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 422 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 423 May 2017, . 425 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 426 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 427 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 428 RFC 8415, DOI 10.17487/RFC8415, November 2018, 429 . 431 8.2. Informative References 433 [BCP38] IETF, "Network Ingress Filtering: Defeating Denial of 434 Service Attacks which employ IP Source Address Spoofing 435 https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38. 437 [RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 438 Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014, 439 . 441 [RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged 442 between Servers and Relay Agents", RFC 8213, 443 DOI 10.17487/RFC8213, August 2017, 444 . 446 Authors' Addresses 448 Ian Farrer 449 Deutsche Telekom AG 450 Landgrabenweg 151 451 Bonn, NRW 53227 452 DE 454 Email: ian.farrer@telekom.de 456 Naveen Kottapalli 457 Benu Networks 458 300 Concord Road 459 Billerica, MA 01821 460 US 462 Email: naveen.sarma@gmail.com 464 Martin Hunek 465 Technical University of Liberec 466 Studentska 1402/2 467 Liberec, L 46017 468 CZ 470 Email: martin.hunek@tul.cz 471 Richard Patterson 473 Email: richard@helix.net.nz