idnits 2.17.1 draft-fkhp-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 : ---------------------------------------------------------------------------- ** 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 (November 2, 2019) is 1637 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) == Unused Reference: 'RFC2629' is defined on line 435, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 444, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7283 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 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: May 5, 2020 Benu Networks 6 M. Hunek 7 Technical University of Liberec 8 Richard. Patterson 9 November 2, 2019 11 DHCPv6 Prefix Delegating relay 12 draft-fkhp-dhc-dhcpv6-pd-relay-requirements-01 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 May 5, 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 . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . 7 82 4.4. Operational Requirements . . . . . . . . . . . . . . . . 8 83 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 88 8.2. Informative References . . . . . . . . . . . . . . . . . 9 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 these 109 functions. 111 This document does not cover the redistribution of the remote routes 112 that have been are learnt from DHCP. Multi-hop relaying is also not 113 considered as the functionality is solely required by a DHCP relay 114 agent that is co-located with the first-hop router that the DHCPv6 115 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. 142 The device functioning as the delegating relay is also responsible 143 for routing traffic for the delegated prefixes. 145 [RFC8415] defines the 'DHCP server', (or as 'server') as: 147 "A node that responds to requests from clients. It may or may not 148 be on the same link as the client(s). Depending on its 149 capabilities, if it supports prefix delegation it may also feature 150 the functionality of a delegating router. 152 This document serves the deployment cases where DHCPv6 server is not 153 located on the same link as the client (necessitating the delegating 154 relay). The server supports prefix delegation and is capable of 155 leasing prefixes to clients, but is not responsible for other 156 functions required of a delegating router, such as managing routes 157 for the delegated prefixes. 159 The term 'requesting router' has previously been used to describe the 160 DHCP client requesting prefixes for use. This document adopts the 161 [RFC8415] terminology and uses 'DHCP client' or 'client' 162 interchangeably for this element. 164 2.2. Topology 166 The following diagram shows the deployment topology relevant to this 167 document. 169 + _ ,--,_ 170 | +--------+ +------------+ _( `' )_ +--------+ 171 +---+ PD |----| Delegating |--( Operator )---| DHCPv6 | 172 | | Client | | relay | `(_ Network_)' | server | 173 | +--------+ +----------- + `--'`---' +--------+ 174 | 175 + 176 Client Network 178 Figure 1 180 The client request prefixes via the client facing interface of the 181 delegating relay. The resulting prefixes will be used for addressing 182 the client network. The delegating relay is responsible for 183 forwarding DHCP messages, including prefix delegation requests and 184 responses between the client and server. Messages are forwarded from 185 the delegating relay to the server using multicast or unicast via the 186 operator network facing interface. 188 The delegating relay provides the operator's layer-3 edge towards the 189 client and is responsible for routing traffic to and from clients 190 connected to the client network using addresses from the delegated 191 prefixes. 193 2.3. Requirements Language 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 197 "OPTIONAL" in this document are to be interpreted as described in BCP 198 14 [RFC2119] [RFC8174] when, and only when, they appear in all 199 capitals, as shown here. 201 3. Problems Observed with Existing Delegating Relays Implementations 203 The following sections of the document describe problems that have 204 been observed with delegating relay implementations in commercially 205 available devices. 207 3.1. DHCP Messages not being Forwarded by the Delegating relay 209 Delegating relay implementations have been observed not to forward 210 messages between the client and server. This generally occurs if a 211 client sends a message which is unexpected by the delegating relay. 212 For example, the delegating router already has an active PD lease 213 entry for an existing client on a port. A new client is connected to 214 this port and sends a solicit message. The delegating relay then 215 drops the solicit messages until it receives either a DHCP release 216 message from the original client, or the existing lease times out. 217 This causes a particular problem when a client device needs to be 218 replaced due to a failure. 220 In addition to dropping messages, in some cases the delegating relay 221 will generate error messages and send them to the client, e.g. 222 'NoBinding' messages being sent in the event that the delegating 223 relay does not have an active delegated prefix lease. 225 3.2. Delegating Relay Loss of State on Reboot 227 For proper routing of client's traffic, the delegating relay requires 228 a corresponding routing table entry for each active prefix delegated 229 to a connected client. A delegating router which does not store this 230 state persistently across reboots will not be able to forward traffic 231 to client's delegated leases until the state is re-established 232 through new DHCP messages. 234 3.3. Multiple Simultaneous Delegated Prefixes for a Single DUID on a 235 Single Client 237 [RFC8415] allows for a client to include more than one instance of 238 OPTION_IA_PD in messages in order to request multiple prefix 239 delegations by the server. If configured for this, the server 240 supplies one instance of OPTION_IAPREFIX for each received instance 241 of OPTION_IA_PD, each containing information for a different 242 delegated prefix. 244 In some delegating relay implementations, only a single delegated 245 prefix per-DUID is supported. In those cases only one IPv6 route for 246 only one of the delegated router is installed; meaning that other 247 prefixes delegated to a client are unreachable. 249 3.4. Dropping Messages from Devices with Duplicate MAC addresses and 250 DUIDs 252 It is an unfortunate operational reality that client devices with 253 duplicate MAC addresses, DUIDs exist and have been deployed. In this 254 situation, the operational costs of locating and swapping out such 255 devices are prohibitive. 257 Delegating relays have been observed to restrict forwarding client 258 messages originating from one client DUID to a single interface. In 259 this case if the same client DUID appears from a second client on 260 another interface while there is already and active lease, messages 261 originating from the second client are dropped causing the second 262 client to be unable to obtain a prefix delegation. 264 4. Requirements for Delegating Relays 266 To resolve the problems described in Section 3 the following section 267 of the document describes a set of functional requirements for the 268 delegating relay. 270 4.1. General Requirements 272 G-1: The delegating router MUST forward messages bidirectionally 273 between the client and server without changing the contents 274 of the message. 276 G-2: As described in Section 16 of [RFC8415], in the event that a 277 received message contains a DHCPv6 option which the relay 278 does not implement, the message MUST be forwarded. 280 G-3: The relay MUST allow for multiple prefixes to be delegated 281 for the same client IA_PD. These delegations may have 282 different lifetimes. 284 G-4: The relay MUST allow for multiple prefixes with separate 285 IA_PDs to be delegated to a single client connected to a 286 single interface, identified by its DHCPv6 Client Identifier 287 (DUID). 289 G-5: The relay MUST allow the same client identifier (DUID) to 290 have active delegated prefix leases on more than one 291 interface simultaneously. This is to allow client devices 292 with duplicate DUIDs to function on separate broadcast 293 domains. 295 G-6: The relay up on detecting that the current lease information 296 of any delegated prefix is no more valid, then the relay MUST 297 deprecate the invalid prefixes as quick as possible so that 298 the clients use a new prefix quickly. 300 G-7: The maximum number of simultaneous prefixes delegated to a 301 single client MUST be configurable. 303 G-8: The relay MUST implement a mechanism to limit the maximum 304 number of active prefix delegations on a single port for all 305 client identifiers and IA_PDs. This value SHOULD be 306 configurable. 308 G-9: The delegating relay MUST synchronize the lifetimes of active 309 prefix delegation leases with server. 311 4.2. Routing Requirements 313 R-1: The relay MUST maintain a local routing table that is 314 dynamically updated with prefixes and the associated next- 315 hops as they are delegated to clients. When a delegated 316 prefix is released or expires, the associated route MUST be 317 removed from the relay's routing table. 319 R-2: The relay MUST provide a mechanism to dynamically update 320 access control lists permitting ingress traffic sourced from 321 clients' delegated prefixes. This is to implement anti- 322 spoofing as described in [BCP38]. 324 R-3: The relay MAY provide a mechanism to dynamically advertise 325 delegated prefixes into an routing protocol as they are 326 learnt. When a delegated prefix is released or expires, the 327 delegated route MUST be withdrawn from the routing protocol. 328 The mechanism using which the routes are inserted and deleted 329 is out of the scope of this document. 331 4.3. Service Continuity Requirements 333 S-1: In the event that the relay is restarted, active client 334 prefix delegations will be lost. This may result in clients 335 becoming unreachable. In order to mitigate this problem, it 336 is RECOMMENDED that the relay implements either: 338 The relay MAY implement DHCPv6 bulk lease query as 339 defined in [RFC5460]. 341 The relay SHOULD store active prefix delegations in 342 persistent storage so they can be re-read after the 343 reboot. 345 S-2: If a client's next-hop link-local address becomes unreachable 346 (e.g., due to a link-down event on the relevant physical 347 interface), routes for the client's delegated prefixes MUST 348 be retained by the delegating relay unless they are released 349 or removed due to expiring DHCP timers. This is to re- 350 establish routing for the delegated prefix if the client 351 next-hop becomes reachable without the client needing to send 352 any DHCP messages. 354 S-3: The relay MAY implement DHCPv6 active lease query as defined 355 in [RFC7653] to keep the local lease database in sync with 356 the DHCPv6 server. 358 4.4. Operational Requirements 360 O-1: The relay SHOULD implement an interface allowing the operator 361 to view the active delegated prefixes. This SHOULD provide 362 information about the delegated lease and client details such 363 as client identifier, next-hop address, connected interface, 364 and remaining lifetimes. 366 O-2: The relay SHOULD provide a method for the operator to clear 367 active bindings for an individual lease, client or all 368 bindings on a port. 370 O-3: To facilitate troubleshooting of operational problems between 371 the delegating relay and other elements, it is RECOMMENDED 372 that the delegating relay's system time is synchronised with 373 the network. 375 5. Acknowledgements 377 The authors of this document would like to thank Bernie Volz for his 378 valuable comments. 380 6. IANA Considerations 382 This memo includes no request to IANA. 384 7. Security Considerations 386 If the delegating relay implements [BCP38] filtering, then the 387 filtering rules will need to be dynamically updated as delegated 388 prefixes are leased. 390 [I-D.ietf-dhc-relay-server-security] describes a method for securing 391 traffic between the relay agent and server by sending DHCP messages 392 over an IPSec tunnel. In this case the IPSec tunnel is functionally 393 the server-facing interface and DHCPv6 message snooping can be 394 carried out as described. It is RECOMMENDED that this is implemented 395 by the delegating relay. 397 8. References 399 8.1. Normative References 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, 403 DOI 10.17487/RFC2119, March 1997, 404 . 406 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 407 DOI 10.17487/RFC5460, February 2009, 408 . 410 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 411 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 412 October 2015, . 414 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 415 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 416 May 2017, . 418 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 419 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 420 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 421 RFC 8415, DOI 10.17487/RFC8415, November 2018, 422 . 424 8.2. Informative References 426 [BCP38] IETF, "Network Ingress Filtering: Defeating Denial of 427 Service Attacks which employ IP Source Address Spoofing 428 https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38. 430 [I-D.ietf-dhc-relay-server-security] 431 Volz, B. and Y. Pal, "Security of Messages Exchanged 432 Between Servers and Relay Agents", draft-ietf-dhc-relay- 433 server-security-05 (work in progress), April 2017. 435 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 436 DOI 10.17487/RFC2629, June 1999, 437 . 439 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 440 Text on Security Considerations", BCP 72, RFC 3552, 441 DOI 10.17487/RFC3552, July 2003, 442 . 444 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 445 IANA Considerations Section in RFCs", RFC 5226, 446 DOI 10.17487/RFC5226, May 2008, 447 . 449 [RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 450 Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014, 451 . 453 Authors' Addresses 455 Ian Farrer 456 Deutsche Telekom AG 457 Landgrabenweg 151 458 Bonn, NRW 53227 459 DE 461 Email: ian.farrer@telekom.de 463 Naveen Kottapalli 464 Benu Networks 465 300 Concord Road 466 Billerica, MA 01821 467 US 469 Email: naveen.sarma@gmail.com 470 Martin Hunek 471 Technical University of Liberec 472 Studentska 1402/2 473 Liberec, L 46017 474 CZ 476 Email: martin.hunek@tul.cz 478 Richard Patterson 480 Email: richard@helix.net.nz