--- 1/draft-ietf-dhc-dhcpv6-pd-relay-requirements-02.txt 2020-11-16 00:13:12.998209439 -0800 +++ 2/draft-ietf-dhc-dhcpv6-pd-relay-requirements-03.txt 2020-11-16 00:13:13.026210150 -0800 @@ -1,23 +1,23 @@ DHC Work Group I. Farrer Internet-Draft Deutsche Telekom AG Intended status: Standards Track Naveen. Kottapalli -Expires: April 10, 2021 Benu Networks +Expires: May 20, 2021 Benu Networks M. Hunek Technical University of Liberec R. Patterson Sky UK Ltd - October 7, 2020 + November 16, 2020 - DHCPv6 Prefix Delegating Relay - draft-ietf-dhc-dhcpv6-pd-relay-requirements-02 + DHCPv6 Prefix Delegating Relay Requirements + draft-ietf-dhc-dhcpv6-pd-relay-requirements-03 Abstract This memo 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 memo provides necessary functional requirements for operating DHCPv6 relays with Prefix Delegation. It is recommended that any network operator that is using DHCPv6 @@ -32,21 +32,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 10, 2021. + This Internet-Draft will expire on May 20, 2021. Copyright Notice Copyright (c) 2020 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 @@ -58,25 +58,26 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 3. Problems Observed with Existing Delegating Relay Implementations . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1. DHCP Messages not being Forwarded by the Delegating Relay 5 - 3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 6 + 3.1. DHCP Messages not being Forwarded by the Delegating + Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 5 3.3. Multiple Delegated Prefixes for a Single Client . . . . . 6 3.4. Dropping Messages from Devices with Duplicate MAC - addresses and DUIDs . . . . . . . . . . . . . . . . 6 + addresses and DUIDs . . . . . . . . . . . . . . . . . . . 6 3.5. Forwarding Loops between Client and Relay . . . . . . . . 6 4. Requirements for Delegating Relays . . . . . . . . . . . . . 7 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7 4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 8 4.3. Service Continuity Requirements . . . . . . . . . . . . . 9 4.4. Operational Requirements . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 @@ -93,33 +94,33 @@ server infrastructure. [RFC8415] describes the functionality of a DHCPv6 relay and Section 19.1.3 mentions this deployment scenario, but does not provide detail 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 inter-working. This can result in operational problems such as messages not being forwarded by the - relay or unreachability of the delegated prefixes. This document + relay or un-reachability 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 learnt from + ones), on its network-facing interface based on prefixes learned from a server via DHCP-PD are out of scope of the document. - Multi-hop DHCPv6 relaying is not affected, as the requirements in - this document are solely applicable to the DHCP relay agent co- - located with the first-hop router that the DHCPv6 client requesting - the prefix is connected to, no changes to any subsequent relays in - the path are needed. + 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 that the DHCPv6 client requesting the + prefix is connected to, 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 @@ -199,27 +200,21 @@ 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. This document uses these keywords not - strictly for the purpose of interoperability, but rather for the - purpose of establishing industry-common baseline functionality. As - such, the document points to several other specifications (preferably - in RFC or stable form) to provide additional guidance to implementers - regarding any protocol implementation required to produce a DHCP - relaying router that functions successfully with prefix delegation. + 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 @@ -280,22 +275,22 @@ or DUID are used as part of device identification and authentication. In such networks, enforcing MAC address/DUID uniqueness is a necessary function and not considered a problem. 3.5. Forwarding Loops between Client and Relay If the client loses information about a prefix that it is delegated while the lease entry and associated route is still active in the delegating relay, then the relay will forward traffic to the client which the client will return to the relay (which is the client's - default gateway (learnt via an RA). The loop will continue until - either the client is successfully reprovisioned via DHCP, or the + default gateway (learned via an RA)). The loop will continue until + either the client is successfully re-provisioned via DHCP, or the lease ages out in the relay. 4. Requirements for Delegating Relays To resolve the problems described in Section 3 and pre-empt 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 NOT drop (and hence not relay) packets that @@ -358,59 +353,72 @@ Released or expires, the associated route MUST be removed from the relay's routing table. R-2: 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]. R-3: The relay MAY provide a mechanism to dynamically advertise - delegated leases into a routing protocol as they are learnt. + delegated leases into a routing protocol as they are learned. 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-4: If the relay has learned a route for a delegated prefix via a - given interface, and receives traffic on this interface with - a destination address within the delegated prefix (that is - not an on-link prefix for the relay), then it MUST be - dropped. This is to prevent routing loops. An ICMPv6 Type - 1, Code 6 (Destination Unreachable, reject route to - destination) error message MAY be sent back to the client. - The ICMP policy SHOULD be configurable. + R-4: 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. R-5: The delegating relay's routing entry MUST use the same prefix length for the delegated prefix as given in the IA_PD. 4.3. Service Continuity Requirements S-1: In the event that the relay is restarted, active client prefix delegations will be lost. This may result in clients becoming unreachable. In order to mitigate this problem, the - relay SHOULD implement at least one following: + relay SHOULD implement at least only following: - * Implement DHCPv6 bulk lease query as defined in - [RFC5460]. + * Implement DHCPv6 bulk lease query as defined in [RFC5460]. - * Store active prefix delegations in persistent - storage so they can be re-read after the reboot. + * Store active prefix delegations in persistent storage so + they can be re-read 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 re- establish routing for the delegated prefix if the client next-hop becomes reachable without the delegated prefixes - needing to be re-learnt. + needing to be re-learned. S-3: The relay SHOULD implement DHCPv6 active lease query 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 @@ -421,39 +429,39 @@ 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 is used by the delegating relays and DHCP servers. 5. Acknowledgements - The authors of this document would like to thank Bernie Volz and Ted - Lemon for their valuable comments. + The authors of this document would like to thank Bernie Volz, Ted + Lemon, and Michael Richardson for their valuable comments. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations This document does not add any new security considerations beyond those mentioned in Section 22 of [RFC8213]. 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. In - this case the IPSec tunnel is functionally the server-facing + agent and server by sending DHCP messages over an IPsec tunnel. In + this case the IPsec tunnel is functionally the server-facing interface and DHCPv6 message snooping can be carried out as described. It is RECOMMENDED that this is implemented by the delegating relay. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, @@ -482,20 +490,26 @@ [BCP38] IETF, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38. [DOCSIS_3.1] CableLabs, "MAC and Upper Layer Protocols Interface Specification", DOCSIS 3.1, January, 2017", . + [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, + . + [RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged between Servers and Relay Agents", RFC 8213, DOI 10.17487/RFC8213, August 2017, . [TR-092] Broadband Forum, "Broadband Remote Access Server (BRAS) Requirements Document, August, 2004", . Authors' Addresses