--- 1/draft-ietf-dhc-dhcpv6-pd-relay-requirements-04.txt 2021-01-04 02:13:58.771297324 -0800 +++ 2/draft-ietf-dhc-dhcpv6-pd-relay-requirements-05.txt 2021-01-04 02:14:05.527468422 -0800 @@ -1,30 +1,30 @@ DHC Work Group I. Farrer Internet-Draft Deutsche Telekom AG -Intended status: Standards Track Naveen. Kottapalli -Expires: June 3, 2021 Benu Networks +Intended status: Standards Track N. Kottapalli +Expires: 8 July 2021 Benu Networks M. Hunek Technical University of Liberec - R. Patterson + R.P. Patterson Sky UK Ltd - November 30, 2020 + January 2021 DHCPv6 Prefix Delegating Relay Requirements - draft-ietf-dhc-dhcpv6-pd-relay-requirements-04 + draft-ietf-dhc-dhcpv6-pd-relay-requirements-05 Abstract - This memo describes operational problems that are known to occur when - using DHCPv6 relays with Prefix Delegation. These problems can + 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 memo provides necessary functional + address these problems, this document provides necessary functional requirements for operating DHCPv6 relays with Prefix Delegation. It is recommended that any network operator that is using DHCPv6 prefix delegation with relays should ensure that these requirements are followed on their networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -32,75 +32,74 @@ 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 June 3, 2021. + This Internet-Draft will expire on 5 July 2021. Copyright Notice - Copyright (c) 2020 IETF Trust and the persons identified as the + 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. + 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 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 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 + Implementations . . . . . . . . . . . . . . . . . . . . . 5 3.1. DHCP Messages not being Forwarded by the Delegating - Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 5 + Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 6 3.3. Multiple Delegated Prefixes for a Single Client . . . . . 6 - 3.4. Dropping Messages from Devices with Duplicate MAC - addresses and DUIDs . . . . . . . . . . . . . . . . . . . 6 - 3.5. Forwarding Loops between Client and Relay . . . . . . . . 6 + 3.4. Dropping Messages from Devices with Duplicate MAC addresses + and DUIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.5. Forwarding Loops between Client and Relay . . . . . . . . 7 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 + 4.4. Operational Requirements . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 - 8.2. Informative References . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 8.2. Informative References . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction - For Internet service providers that offer native IPv6 access with + 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 separate, centralized DHCPv6 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 + but 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 inter-working. This can result in operational problems such as messages not being forwarded by the 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. @@ -112,35 +111,35 @@ 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: + 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/IAPREFIX - options between the client and server. The + 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 @@ -253,45 +252,45 @@ In some delegating relay implementations, only a single delegated prefix per-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 MAC - addresses and/or DUIDs exist and have been deployed. In this - situation, the operational costs of locating and swapping out such + 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 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 (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. + If the client loses information about an active prefix lease it has + been 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 (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 forward packets that either contain message codes (Section 19 of [RFC8415]) it may not understand, or contain @@ -329,23 +328,23 @@ 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 Reply messages it forwards to the client and only - expire the delegated prefixes when the valid lifetime has - elapsed. + 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 @@ -358,24 +357,25 @@ 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. - 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. + 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 @@ -439,108 +439,121 @@ 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]. + 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. 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. + agent and server by sending DHCP messages over an IPsec tunnel. It + is RECOMMENDED that this is 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 Section 4.4 may introduce + additional security considerations. It is RECOMMENDED that the + operational security practices described in [RFC4778] are + implemented. 8. References 8.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, . 8.2. Informative References [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. + 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 Ian Farrer Deutsche Telekom AG Landgrabenweg 151 - Bonn, NRW 53227 - DE + 53227 Bonn + Germany Email: ian.farrer@telekom.de + Naveen Kottapalli Benu Networks - 300 Concord Road - Billerica, MA 01821 - US + 154 Middlesex Turnpike + Burlington, MA 01803 + United States of America - Email: naveen.sarma@gmail.com + Email: nkottapalli@benunets.com Martin Hunek Technical University of Liberec Studentska 1402/2 - Liberec, L 46017 - CZ - + 46017 Liberec + Czechia Email: martin.hunek@tul.cz Richard Patterson Sky UK Ltd 1 Brick Lane - London E1 6PU - UK + London + E1 6PU + United Kingdom Email: richard.patterson@sky.uk