idnits 2.17.1 draft-fkhp-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 (June 25, 2019) is 1765 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 422, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 431, 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: December 27, 2019 Benu Networks 6 M. Hunek 7 Technical University of Liberec 8 Richard. Patterson 9 June 25, 2019 11 DHCPv6 Prefix Delegating relay 12 draft-fkhp-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 December 27, 2019. 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 . . . . . . . . . . . . . . . . . . . 8 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 maximum number of simultaneous prefixes delegated to a 296 single client MUST be configurable. 298 G-7: The relay MUST implement a mechanism to limit the maximum 299 number of active prefix delegations on a single port for all 300 client identifiers and IA_PDs. This value SHOULD be 301 configurable. 303 G-8: The delegating relay MUST synchronize the lifetimes of active 304 prefix delegation leases with server. 306 4.2. Routing Requirements 308 R-1: The relay MUST maintain a local routing table that is 309 dynamically updated with prefixes and the associated next- 310 hops as they are delegated to clients. When a delegated 311 prefix is released or expires, the associated route MUST be 312 removed from the relay's routing table. 314 R-2: The relay MUST provide a mechanism to dynamically update 315 access control lists permitting ingress traffic sourced from 316 clients' delegated prefixes. This is to implement anti- 317 spoofing as described in [BCP38]. 319 R-3: The relay MAY provide a mechanism to dynamically advertise 320 delegated prefixes into an routing protocol as they are 321 learnt. When a delegated prefix is released or expires, the 322 delegated route MUST be withdrawn from the routing protocol. 323 The mechanism using which the routes are inserted and deleted 324 is out of the scope of this document. 326 4.3. Service Continuity Requirements 328 S-1: In the event that the relay is restarted, active client 329 prefix delegations will be lost. This may result in clients 330 becoming unreachable. In order to mitigate this problem, it 331 is RECOMMENDED that the relay implements either: 333 The relay MAY implement DHCPv6 bulk lease query as 334 defined in [RFC5460]. 336 The relay MAY store active prefix delegations in 337 persistent storage so they can be re-read after the 338 reboot. 340 S-2: If a client's next-hop link-local address becomes unreachable 341 (e.g., due to a link-down event on the relevant physical 342 interface), routes for the client's delegated prefixes MUST 343 be retained by the delegating relay unless they are released 344 or removed due to expiring DHCP timers. This is to re- 345 establish routing for the delegated prefix if the client 346 next-hop becomes reachable without the client needing to send 347 any DHCP messages. 349 4.4. Operational Requirements 351 O-1: The relay SHOULD implement an interface allowing the operator 352 to view the active delegated prefixes. This SHOULD provide 353 information about the delegated lease and client details such 354 as client identifier, next-hop address, connected interface, 355 and remaining lifetimes. 357 O-2: The relay SHOULD provide a method for the operator to clear 358 active bindings for an individual lease, client or all 359 bindings on a port. 361 O-3: To facilitate troubleshooting of operational problems between 362 the delegating relay and other elements, it is RECOMMENDED 363 that the delegating relay's system time is synchronised with 364 the network. 366 5. Acknowledgements 368 This template was derived from an initial version written by Pekka 369 Savola and contributed by him to the xml2rfc project. 371 6. IANA Considerations 373 This memo includes no request to IANA. 375 7. Security Considerations 377 If the delegating relay implements [BCP38] filtering, then the 378 filtering rules will need to be dynamically updated as delegated 379 prefixes are leased. 381 [I-D.ietf-dhc-relay-server-security] describes a method for securing 382 traffic between the relay agent and server by sending DHCP messages 383 over an IPSec tunnel. In this case the IPSec tunnel is functionally 384 the server-facing interface and DHCPv6 message snooping can be 385 carried out as described. It is RECOMMENDED that this is implemented 386 by the delegating relay. 388 8. References 390 8.1. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, 394 DOI 10.17487/RFC2119, March 1997, 395 . 397 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 398 DOI 10.17487/RFC5460, February 2009, 399 . 401 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 402 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 403 May 2017, . 405 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 406 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 407 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 408 RFC 8415, DOI 10.17487/RFC8415, November 2018, 409 . 411 8.2. Informative References 413 [BCP38] IETF, "Network Ingress Filtering: Defeating Denial of 414 Service Attacks which employ IP Source Address Spoofing 415 https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38. 417 [I-D.ietf-dhc-relay-server-security] 418 Volz, B. and Y. Pal, "Security of Messages Exchanged 419 Between Servers and Relay Agents", draft-ietf-dhc-relay- 420 server-security-05 (work in progress), April 2017. 422 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 423 DOI 10.17487/RFC2629, June 1999, 424 . 426 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 427 Text on Security Considerations", BCP 72, RFC 3552, 428 DOI 10.17487/RFC3552, July 2003, 429 . 431 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 432 IANA Considerations Section in RFCs", RFC 5226, 433 DOI 10.17487/RFC5226, May 2008, 434 . 436 [RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 437 Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014, 438 . 440 Authors' Addresses 442 Ian Farrer 443 Deutsche Telekom AG 444 Landgrabenweg 151 445 Bonn, NRW 53227 446 DE 448 Email: ian.farrer@telekom.de 450 Naveen Kottapalli 451 Benu Networks 452 300 Concord Road 453 Billerica, MA 01821 454 US 456 Email: naveen.sarma@gmail.com 458 Martin Hunek 459 Technical University of Liberec 460 Studentska 1402/2 461 Liberec, L 46017 462 CZ 464 Email: martin.hunek@tul.cz 466 Richard Patterson 468 Email: richard@helix.net.nz