From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8987.txt | 566 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 566 insertions(+) create mode 100644 doc/rfc/rfc8987.txt (limited to 'doc/rfc/rfc8987.txt') diff --git a/doc/rfc/rfc8987.txt b/doc/rfc/rfc8987.txt new file mode 100644 index 0000000..5f62044 --- /dev/null +++ b/doc/rfc/rfc8987.txt @@ -0,0 +1,566 @@ + + + + +Internet Engineering Task Force (IETF) I. Farrer +Request for Comments: 8987 Deutsche Telekom AG +Category: Standards Track N. Kottapalli +ISSN: 2070-1721 Benu Networks + M. Hunek + Technical University of Liberec + R. Patterson + Sky UK Ltd. + February 2021 + + + DHCPv6 Prefix Delegating Relay Requirements + +Abstract + + This document describes operational problems that are known to occur + when using DHCPv6 relays with prefix delegation. These problems can + prevent successful delegation and result in routing failures. To + address these problems, this document provides necessary functional + requirements for operating DHCPv6 relays with prefix delegation. + + It is recommended that any network operator using DHCPv6 prefix + delegation with relays ensure that these requirements are followed on + their networks. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8987. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 2.1. General + 2.2. Topology + 2.3. Requirements Language + 3. Problems Observed with Existing Delegating Relay + Implementations + 3.1. DHCP Messages Not Being Forwarded by the Delegating Relay + 3.2. Delegating Relay Loss of State on Reboot + 3.3. Multiple Delegated Prefixes for a Single Client + 3.4. Dropping Messages from Devices with Duplicate MAC Addresses + and DUIDs + 3.5. Forwarding Loops between Client and Relay + 4. Requirements for Delegating Relays + 4.1. General Requirements + 4.2. Routing Requirements + 4.3. Service Continuity Requirements + 4.4. Operational Requirements + 5. IANA Considerations + 6. Security Considerations + 7. References + 7.1. Normative References + 7.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + For Internet service providers that offer native IPv6 access with + prefix delegation to their customers, a common deployment + architecture is to have a DHCPv6 relay agent function located in the + ISP's Layer 3 customer edge device and a separate, centralized DHCPv6 + server infrastructure. [RFC8415] describes the functionality of a + DHCPv6 relay, and Section 19.1.3 of [RFC8415] mentions this + deployment scenario, but it does not provide details for all of the + functional requirements that the relay needs to fulfill to operate + deterministically in this deployment scenario. + + A DHCPv6 relay agent for prefix delegation is a function commonly + implemented in routing devices, but implementations vary in their + functionality and client/server interworking. This can result in + operational problems such as messages not being forwarded by the + relay or unreachability of the delegated prefixes. This document + provides a set of requirements for devices implementing a relay + function for use with prefix delegation. + + The mechanisms for a relay to inject routes (including aggregated + ones) on its network-facing interface based on prefixes learned from + a server via DHCP prefix delegation (DHCP-PD) are out of scope of the + document. + + Multi-hop DHCPv6 relaying is not affected. The requirements in this + document are solely applicable to the DHCP relay agent co-located + with the first-hop router to which the DHCPv6 client requesting the + prefix is connected, so no changes to any subsequent relays in the + path are needed. + +2. Terminology + +2.1. General + + This document uses the terminology defined in [RFC8415]. However, + when defining the functional elements for prefix delegation, + [RFC8415], Section 4.2 defines the term "delegating router" as: + + | The router that acts as a DHCP server and responds to requests for + | delegated prefixes. + + This document is concerned with deployment scenarios in which the + DHCPv6 relay and DHCPv6 server functions are separated, so the term + "delegating router" is not used. Instead, a new term is introduced + to describe the relaying function: + + Delegating relay: + A delegating relay acts as an intermediate device, forwarding + DHCPv6 messages containing IA_PD and IAPREFIX options between the + client and server. The delegating relay does not implement a + DHCPv6 server function. The delegating relay is also responsible + for routing traffic for the delegated prefixes. + + Where the term "relay" is used on its own within this document, it + should be understood to be a delegating relay unless specifically + stated otherwise. + + In CableLabs DOCSIS environments, the Cable Modem Termination System + (CMTS) would be considered a delegating relay with respect to + Customer Premises Devices (CPEs) ([DOCSIS_3.1], Section 5.2.7.2). A + Broadband Network Gateway (BNG) in a DSL-based access network may be + a delegating relay if it does not implement a local DHCPv6 server + function ([TR-092], Section 4.10). + + [RFC8415] defines the "DHCP server" (or "server") as: + + | A node that responds to requests from clients. It may or may not + | be on the same link as the client(s). Depending on its + | capabilities, if it supports prefix delegation it may also feature + | the functionality of a delegating router. + + This document serves the deployment cases where a DHCPv6 server is + not located on the same link as the client (necessitating the + delegating relay). The server supports prefix delegation and is + capable of leasing prefixes to clients, but it is not responsible for + other functions required of a delegating router, such as managing + routes for the delegated prefixes. + + The term "requesting router" has previously been used to describe the + DHCP client requesting prefixes for use. This document adopts the + terminology of [RFC8415] and uses "DHCP client" or "client" + interchangeably for this element. + +2.2. Topology + + The following diagram shows the deployment topology relevant to this + document. + + + + | ------- uplink ------> + | _ ,--,_ + | +--------+ +------------+ _( `' )_ +--------+ + +---+ PD |-------| Delegating |--( Operator )---| DHCPv6 | + | | Client | | relay | `(_ Network_)' | server | + | +--------+ +----------- + `--'`---' +--------+ + | + | <----- downlink ------ + + (client facing) + Client + Network + + Figure 1: Topology Overview + + The client requests prefixes via the downlink interface of the + delegating relay. The resulting prefixes will be used for addressing + the client network. The delegating relay is responsible for + forwarding DHCP messages, including prefix delegation requests and + responses between the client and server. Messages are forwarded from + the delegating relay to the server using multicast or unicast via the + operator uplink interface. + + The delegating relay provides the operator's Layer 3 edge towards the + client and is responsible for routing traffic to and from clients + connected to the client network using addresses from the delegated + prefixes. + +2.3. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Problems Observed with Existing Delegating Relay Implementations + + The following sections of the document describe problems that have + been observed with delegating relay implementations in commercially + available devices. + +3.1. DHCP Messages Not Being Forwarded by the Delegating Relay + + Delegating relay implementations have been observed not to forward + messages between the client and server. This generally occurs if a + client sends a message that is unexpected by the delegating relay. + For example, the delegating relay already has an active PD lease + entry for an existing client on a port. A new client is connected to + this port and sends a Solicit message. The delegating relay then + drops the Solicit messages until either it receives a DHCP Release + message from the original client or the existing lease times out. + This causes a particular problem when a client device needs to be + replaced due to a failure. + + In addition to dropping messages, in some cases, the delegating relay + will generate error messages and send them to the client, e.g., + "NoBinding" messages being sent in the event that the delegating + relay does not have an active delegated prefix lease. + +3.2. Delegating Relay Loss of State on Reboot + + For proper routing of client traffic, the delegating relay requires a + corresponding routing table entry for each active prefix delegated to + a connected client. A delegating relay that does not store this + state persistently across reboots will not be able to forward traffic + to the client's delegated leases until the state is reestablished + through new DHCP messages. + +3.3. Multiple Delegated Prefixes for a Single Client + + DHCPv6 [RFC8415] allows a client to include more than one instance of + OPTION_IA_PD in messages in order to request multiple prefix + delegations by the server. If configured for this, the server + supplies one (or more) instance of OPTION_IAPREFIX for each received + instance of OPTION_IA_PD, each containing information for a different + delegated prefix. + + In some delegating relay implementations, only a single delegated + prefix per DHCP Unique Identifier (DUID) is supported. In those + cases, only one IPv6 route for one of the delegated prefixes is + installed, meaning that other prefixes delegated to a client are + unreachable. + +3.4. Dropping Messages from Devices with Duplicate MAC Addresses and + DUIDs + + It is an operational reality that client devices with duplicate Media + Access Control (MAC) addresses and/or DUIDs exist and have been + deployed. In some networks, the operational costs of locating and + swapping out such devices are prohibitive. + + Delegating relays have been observed to restrict forwarding client + messages originating from one client DUID to a single interface. In + this case, if the same client DUID appears from a second client on + another interface while there is already an active lease, messages + originating from the second client are dropped, causing the second + client to be unable to obtain a prefix delegation. + + It should be noted that in some access networks, the MAC address and/ + or DUID are used as part of device identification and authentication. + In such networks, enforcing uniqueness of the MAC address and/or DUID + is a necessary function and is not considered a problem. + +3.5. Forwarding Loops between Client and Relay + + If the client loses information about an active prefix lease it has + been delegated while the lease entry and associated route are still + active in the delegating relay, then the relay will forward traffic + to the client. The client will return this traffic to the relay, + which is the client's default gateway (learned via a Router + Advertisement (RA)). The loop will continue until either the client + is successfully reprovisioned via DHCP or the lease ages out in the + relay. + +4. Requirements for Delegating Relays + + To resolve the problems described in Section 3 and to preempt other + undesirable behavior, the following section of the document describes + a set of functional requirements for the delegating relay. + + In addition, relay implementers are reminded that [RFC8415] makes it + clear that relays MUST forward packets that either contain message + codes it may not understand (Section 19 of [RFC8415]) or options that + it does not understand (Section 16 of [RFC8415]). + +4.1. General Requirements + + G-1: The delegating relay MUST forward messages bidirectionally + between the client and server without changing the contents of + the message. + + G-2: The relay MUST allow for multiple prefixes to be delegated for + the same client IA_PD. These delegations may have different + lifetimes. + + G-3: The relay MUST allow for multiple prefixes (with or without + separate IA_PDs) to be delegated to a single client connected + to a single interface, identified by its DHCPv6 Client + Identifier (DUID). + + G-4: A delegating relay may have one or more interfaces on which it + acts as a relay, as well as one or more interfaces on which it + does not (for example, in an ISP, it might act as a relay on + all southbound interfaces but not on the northbound + interfaces). The relay SHOULD allow the same client identifier + (DUID) to have active delegated prefix leases on more than one + interface simultaneously unless client DUID uniqueness is + necessary for the functioning or security of the network. This + is to allow client devices with duplicate DUIDs to function on + separate broadcast domains. + + G-5: The maximum number of simultaneous prefixes delegated to a + single client MUST be configurable. + + G-6: The relay MUST implement a mechanism to limit the maximum + number of active prefix delegations on a single port for all + client identifiers and IA_PDs. This value MUST be + configurable. + + G-7: It is RECOMMENDED that delegating relays support at least 8 + active delegated leases per client device and use this as the + default limit. + + G-8: The delegating relay MUST update the lease lifetimes based on + the client's reply messages it forwards to the client and only + expire the delegated prefixes when the valid lifetime has + elapsed. + + G-9: On receipt of a Release message from the client, the delegating + relay MUST expire the active leases for each of the IA_PDs in + the message. + +4.2. Routing Requirements + + R-1: The relay MUST maintain a local routing table that is + dynamically updated with leases and the associated next hops as + they are delegated to clients. When a delegated prefix is + released or expires, the associated route MUST be removed from + the relay's routing table. + + R-2: The delegating relay's routing entry MUST use the same prefix + length for the delegated prefix as given in the IA_PD. + + R-3: The relay MUST provide a mechanism to dynamically update + ingress filters permitting ingress traffic sourced from client + delegated leases and blocking packets from invalid source + prefixes. This is to implement anti-spoofing as described in + [BCP38]. The delegating relay's ingress filter entry MUST use + the same prefix length for the delegated prefix as given in the + IA_PD. + + R-4: The relay MAY provide a mechanism to dynamically advertise + delegated leases into a routing protocol as they are learned. + If such a mechanism is implemented, when a delegated lease is + released or expires, the delegated route MUST be withdrawn from + the routing protocol. The mechanism by which the routes are + inserted and deleted is out of the scope of this document. + + R-5: To prevent routing loops, the relay SHOULD implement a + configurable policy to drop potential looping packets received + on any DHCP-PD client-facing interfaces. + + The policy SHOULD be configurable on a per-client or per- + destination basis. + + Looping packets are those with a destination address in a + prefix delegated to a client connected to that interface, as + follows: + + * For point-to-point links, when the packet's ingress and + egress interfaces match. + + * For multi-access links, when the packet's ingress and egress + interface match, and the source link-layer and next-hop + link-layer addresses match. + + An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route + to destination) error message MAY be sent as per [RFC4443], + Section 3.1. The ICMP policy SHOULD be configurable. + +4.3. Service Continuity Requirements + + S-1: To preserve active client prefix delegations across relay + restarts, the relay SHOULD implement at least one of the + following: + + * Implement DHCPv6 Bulk Leasequery as defined in [RFC5460]. + + * Store active prefix delegations in persistent storage so + they can be reread after the reboot. + + S-2: If a client's next-hop link-local address becomes unreachable + (e.g., due to a link-down event on the relevant physical + interface), routes for the client's delegated prefixes MUST be + retained by the delegating relay unless they are released or + removed due to expiring DHCP timers. This is to reestablish + routing for the delegated prefix if the client next hop becomes + reachable without the delegated prefixes needing to be + relearned. + + S-3: The relay SHOULD implement DHCPv6 Active Leasequery as defined + in [RFC7653] to keep the local lease database in sync with the + DHCPv6 server. + +4.4. Operational Requirements + + O-1: The relay SHOULD implement an interface allowing the operator + to view the active delegated prefixes. This SHOULD provide + information about the delegated lease and client details such + as the client identifier, next-hop address, connected + interface, and remaining lifetimes. + + O-2: The relay SHOULD provide a method for the operator to clear + active bindings for an individual lease, client, or all + bindings on a port. + + O-3: To facilitate troubleshooting of operational problems between + the delegating relay and other elements, it is RECOMMENDED that + a time synchronization protocol be used by the delegating + relays and DHCP servers. + +5. IANA Considerations + + This document has no IANA actions. + +6. Security Considerations + + This document does not add any new security considerations beyond + those mentioned in Section 4 of [RFC8213] and Section 22 of + [RFC8415]. + + If the delegating relay implements [BCP38] filtering, then the + filtering rules will need to be dynamically updated as delegated + prefixes are leased. + + [RFC8213] describes a method for securing traffic between the relay + agent and server by sending DHCP messages over an IPsec tunnel. It + is RECOMMENDED that this be implemented by the delegating relay. + + Failure to implement requirement G-6 may have specific security + implications, such as a resource depletion attack on the relay. + + The operational requirements in Section 4.4 may introduce additional + security considerations. It is RECOMMENDED that the operational + security practices described in [RFC4778] be implemented. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet + Control Message Protocol (ICMPv6) for the Internet + Protocol Version 6 (IPv6) Specification", STD 89, + RFC 4443, DOI 10.17487/RFC4443, March 2006, + . + + [RFC4778] Kaeo, M., "Operational Security Current Practices in + Internet Service Provider Environments", RFC 4778, + DOI 10.17487/RFC4778, January 2007, + . + + [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, + DOI 10.17487/RFC5460, February 2009, + . + + [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 + Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, + October 2015, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged + between Servers and Relay Agents", RFC 8213, + DOI 10.17487/RFC8213, August 2017, + . + + [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., + Richardson, M., Jiang, S., Lemon, T., and T. Winters, + "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", + RFC 8415, DOI 10.17487/RFC8415, November 2018, + . + +7.2. Informative References + + [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", BCP 38, RFC 2827, May 2000. + + + + [DOCSIS_3.1] + CableLabs, "MAC and Upper Layer Protocols Interface + Specification", Version 10, DOCSIS 3.1, January 2017, + . + + [TR-092] Broadband Forum, "Broadband Remote Access Server (BRAS) + Requirements Document", Technical Report TR-092, August + 2004, + . + +Acknowledgements + + The authors of this document would like to thank Bernie Volz, Ted + Lemon, and Michael Richardson for their valuable comments. + +Authors' Addresses + + Ian Farrer + Deutsche Telekom AG + Landgrabenweg 151 + 53227 Bonn + Germany + + Email: ian.farrer@telekom.de + + + Naveen Kottapalli + Benu Networks + WeWork Galaxy, 43 Residency Road + Bangalore 560025 + Karnataka + India + + Email: nkottapalli@benunets.com + + + Martin Hunek + Technical University of Liberec + Studentska 1402/2 + 46017 Liberec + Czech Republic + + Email: martin.hunek@tul.cz + + + Richard Patterson + Sky UK Ltd. + 1 Brick Lane + London + E1 6PU + United Kingdom + + Email: richard.patterson@sky.uk -- cgit v1.2.3