idnits 2.17.1 draft-fkhp-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 : ---------------------------------------------------------------------------- ** 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 (December 17, 2019) is 1584 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: June 19, 2020 Benu Networks 6 M. Hunek 7 Technical University of Liberec 8 Richard. Patterson 9 December 17, 2019 11 DHCPv6 Prefix Delegating relay 12 draft-fkhp-dhc-dhcpv6-pd-relay-requirements-03 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 June 19, 2020. 48 Copyright Notice 50 Copyright (c) 2019 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 . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 6 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 the redistribution of remote routes learnt via 112 DHCP PD is out of scope of the document. Multi-hop relaying is also 113 not considered as the functionality is solely required by a DHCP 114 relay agent that is co-located with the first-hop router that the 115 DHCPv6 client requesting the prefix is connected to. 117 The behavior defined in [RFC7283] is also applicable for DHCv6-PD- 118 relay deployments. 120 2. Terminology 122 2.1. General 124 This document uses the terminology defined in [RFC8415], however when 125 defining the functional elements for prefix delegation [RFC8415], 126 Section 4.2 defines the term 'delegating router' as: 128 "The router that acts as a DHCP server and responds to requests 129 for delegated prefixes." 131 This document is concerned with deployment scenarios in which the 132 DHCPv6 relay and DHCPv6 server functions are separated, so the term 133 'delegating router' is not used. Instead, a new term is introduced 134 to describe the relaying function: 136 Delegating relay A delegating relay acts as an intermediate device, 137 forwarding DHCPv6 messages containing IA_PD/IAPREFIX 138 options between the client and server. The 139 delegating relay does not implement a DHCPv6 server 140 function. The delegating relay is also responsible 141 for routing traffic for the delegated prefixes. 143 Where the term 'relay' is used on its own within this document, it 144 should be understand to be a delegating relay, unless specificcally 145 stated otherwise. 147 [RFC8415] defines the 'DHCP server', (or as 'server') as: 149 "A node that responds to requests from clients. It may or may not 150 be on the same link as the client(s). Depending on its 151 capabilities, if it supports prefix delegation it may also feature 152 the functionality of a delegating router. 154 This document serves the deployment cases where DHCPv6 server is not 155 located on the same link as the client (necessitating the delegating 156 relay). The server supports prefix delegation and is capable of 157 leasing prefixes to clients, but is not responsible for other 158 functions required of a delegating router, such as managing routes 159 for the delegated prefixes. 161 The term 'requesting router' has previously been used to describe the 162 DHCP client requesting prefixes for use. This document adopts the 163 [RFC8415] terminology and uses 'DHCP client' or 'client' 164 interchangeably for this element. 166 2.2. Topology 168 The following diagram shows the deployment topology relevant to this 169 document. 171 + _ ,--,_ 172 | +--------+ +------------+ _( `' )_ +--------+ 173 +---+ PD |----| Delegating |--( Operator )---| DHCPv6 | 174 | | Client | | relay | `(_ Network_)' | server | 175 | +--------+ +----------- + `--'`---' +--------+ 176 | 177 + 178 Client Network 180 Figure 1 182 The client request prefixes via the client facing interface of the 183 delegating relay. The resulting prefixes will be used for addressing 184 the client network. The delegating relay is responsible for 185 forwarding DHCP messages, including prefix delegation requests and 186 responses between the client and server. Messages are forwarded from 187 the delegating relay to the server using multicast or unicast via the 188 operator network facing interface. 190 The delegating relay provides the operator's Layer-3 edge towards the 191 client and is responsible for routing traffic to and from clients 192 connected to the client network using addresses from the delegated 193 prefixes. 195 2.3. Requirements Language 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in BCP 200 14 [RFC2119] [RFC8174] when, and only when, they appear in all 201 capitals, as shown here. This document uses these keywords not 202 strictly for the purpose of interoperability, but rather for the 203 purpose of establishing industry-common baseline functionality. As 204 such, the document points to several other specifications (preferably 205 in RFC or stable form) to provide additional guidance to implementers 206 regarding any protocol implementation required to produce a DHCP 207 relaying router that functions successfully with prefix delegation. 209 3. Problems Observed with Existing Delegating Relays Implementations 211 The following sections of the document describe problems that have 212 been observed with delegating relay implementations in commercially 213 available devices. 215 3.1. DHCP Messages not being Forwarded by the Delegating relay 217 Delegating relay implementations have been observed not to forward 218 messages between the client and server. This generally occurs if a 219 client sends a message which is unexpected by the delegating relay. 220 For example, the delegating router already has an active PD lease 221 entry for an existing client on a port. A new client is connected to 222 this port and sends a solicit message. The delegating relay then 223 drops the solicit messages until it receives either a DHCP release 224 message from the original client, or the existing lease times out. 225 This causes a particular problem when a client device needs to be 226 replaced due to a failure. 228 In addition to dropping messages, in some cases the delegating relay 229 will generate error messages and send them to the client, e.g. 230 'NoBinding' messages being sent in the event that the delegating 231 relay does not have an active delegated prefix lease. 233 3.2. Delegating Relay Loss of State on Reboot 235 For proper routing of client's traffic, the delegating relay requires 236 a corresponding routing table entry for each active prefix delegated 237 to a connected client. A delegating router which does not store this 238 state persistently across reboots will not be able to forward traffic 239 to client's delegated leases until the state is re-established 240 through new DHCP messages. 242 3.3. Multiple Simultaneous Delegated Prefixes for a Single DUID on a 243 Single Client 245 [RFC8415] allows for a client to include more than one instance of 246 OPTION_IA_PD in messages in order to request multiple prefix 247 delegations by the server. If configured for this, the server 248 supplies one instance of OPTION_IAPREFIX for each received instance 249 of OPTION_IA_PD, each containing information for a different 250 delegated prefix. 252 In some delegating relay implementations, only a single delegated 253 prefix per-DUID is supported. In those cases only one IPv6 route for 254 only one of the delegated router is installed; meaning that other 255 prefixes delegated to a client are unreachable. 257 3.4. Dropping Messages from Devices with Duplicate MAC addresses and 258 DUIDs 260 It is an unfortunate operational reality that client devices with 261 duplicate MAC addresses and/or DUIDs exist and have been deployed. 262 In this situation, the operational costs of locating and swapping out 263 such devices are prohibitive. 265 Delegating relays have been observed to restrict forwarding client 266 messages originating from one client DUID to a single interface. In 267 this case if the same client DUID appears from a second client on 268 another interface while there is already and active lease, messages 269 originating from the second client are dropped causing the second 270 client to be unable to obtain a prefix delegation. 272 4. Requirements for Delegating Relays 274 To resolve the problems described in Section 3 the following section 275 of the document describes a set of functional requirements for the 276 delegating relay. 278 4.1. General Requirements 280 G-1: The delegating router MUST forward messages bidirectionally 281 between the client and server without changing the contents 282 of the message. 284 G-2: As described in Section 16 of [RFC8415], in the event that a 285 received message contains a DHCPv6 option which the relay 286 does not implement, the message MUST be forwarded. 288 G-3: The relay MUST allow for multiple prefixes to be delegated 289 for the same client IA_PD. These delegations may have 290 different lifetimes. 292 G-4: The relay MUST allow for multiple prefixes with separate 293 IA_PDs to be delegated to a single client connected to a 294 single interface, identified by its DHCPv6 Client Identifier 295 (DUID). 297 G-5: The relay MUST allow the same client identifier (DUID) to 298 have active delegated prefix leases on more than one 299 interface simultaneously. This is to allow client devices 300 with duplicate DUIDs to function on separate broadcast 301 domains. 303 G-6: The maximum number of simultaneous prefixes delegated to a 304 single client MUST be configurable. 306 G-7: The relay MUST implement a mechanism to limit the maximum 307 number of active prefix delegations on a single port for all 308 client identifiers and IA_PDs. This value SHOULD be 309 configurable. 311 G-8: The delegating relay MUST synchronize the lifetimes of active 312 prefix delegation leases with server. 314 4.2. Routing Requirements 316 R-1: The relay MUST maintain a local routing table that is 317 dynamically updated with prefixes and the associated next- 318 hops as they are delegated to clients. When a delegated 319 prefix is released or expires, the associated route MUST be 320 removed from the relay's routing table. 322 R-2: The relay MUST provide a mechanism to dynamically update 323 access control lists permitting ingress traffic sourced from 324 clients' delegated prefixes. This is to implement anti- 325 spoofing as described in [BCP38]. 327 R-3: The relay MAY provide a mechanism to dynamically advertise 328 delegated prefixes into an routing protocol as they are 329 learnt. When a delegated prefix is released or expires, the 330 delegated route MUST be withdrawn from the routing protocol. 332 The mechanism using which the routes are inserted and deleted 333 is out of the scope of this document. 335 4.3. Service Continuity Requirements 337 S-1: In the event that the relay is restarted, active client 338 prefix delegations will be lost. This may result in clients 339 becoming unreachable. In order to mitigate this problem, it 340 is RECOMMENDED that the relay implements either of the 341 following: 343 The relay MAY implement DHCPv6 bulk lease query as 344 defined in [RFC5460]. 346 The relay SHOULD store active prefix delegations in 347 persistent storage so they can be re-read after the 348 reboot. 350 S-2: If a client's next-hop link-local address becomes unreachable 351 (e.g., due to a link-down event on the relevant physical 352 interface), routes for the client's delegated prefixes MUST 353 be retained by the delegating relay unless they are released 354 or removed due to expiring DHCP timers. This is to re- 355 establish routing for the delegated prefix if the client 356 next-hop becomes reachable without the relay needing to be 357 re-learnt. 359 S-3: The relay MAY implement DHCPv6 active lease query as defined 360 in [RFC7653] to keep the local lease database in sync with 361 the DHCPv6 server. 363 4.4. Operational Requirements 365 O-1: The relay SHOULD implement an interface allowing the operator 366 to view the active delegated prefixes. This SHOULD provide 367 information about the delegated lease and client details such 368 as client identifier, next-hop address, connected interface, 369 and remaining lifetimes. 371 O-2: The relay SHOULD provide a method for the operator to clear 372 active bindings for an individual lease, client or all 373 bindings on a port. 375 O-3: To facilitate troubleshooting of operational problems between 376 the delegating relay and other elements, it is RECOMMENDED 377 that the delegating relay's system time is synchronised with 378 the network. 380 5. Acknowledgements 382 The authors of this document would like to thank Bernie Volz for his 383 valuable comments. 385 6. IANA Considerations 387 This memo includes no request to IANA. 389 7. Security Considerations 391 If the delegating relay implements [BCP38] filtering, then the 392 filtering rules will need to be dynamically updated as delegated 393 prefixes are leased. 395 [RFC8213] describes a method for securing traffic between the relay 396 agent and server by sending DHCP messages over an IPSec tunnel. In 397 this case the IPSec tunnel is functionally the server-facing 398 interface and DHCPv6 message snooping can be carried out as 399 described. It is RECOMMENDED that this is implemented by the 400 delegating relay. 402 8. References 404 8.1. Normative References 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, 408 DOI 10.17487/RFC2119, March 1997, 409 . 411 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 412 DOI 10.17487/RFC5460, February 2009, 413 . 415 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 416 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 417 October 2015, . 419 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 420 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 421 May 2017, . 423 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 424 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 425 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 426 RFC 8415, DOI 10.17487/RFC8415, November 2018, 427 . 429 8.2. Informative References 431 [BCP38] IETF, "Network Ingress Filtering: Defeating Denial of 432 Service Attacks which employ IP Source Address Spoofing 433 https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38. 435 [RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 436 Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014, 437 . 439 [RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged 440 between Servers and Relay Agents", RFC 8213, 441 DOI 10.17487/RFC8213, August 2017, 442 . 444 Authors' Addresses 446 Ian Farrer 447 Deutsche Telekom AG 448 Landgrabenweg 151 449 Bonn, NRW 53227 450 DE 452 Email: ian.farrer@telekom.de 454 Naveen Kottapalli 455 Benu Networks 456 300 Concord Road 457 Billerica, MA 01821 458 US 460 Email: naveen.sarma@gmail.com 462 Martin Hunek 463 Technical University of Liberec 464 Studentska 1402/2 465 Liberec, L 46017 466 CZ 468 Email: martin.hunek@tul.cz 469 Richard Patterson 471 Email: richard@helix.net.nz