doc: Add RFC documents

1 files changed, 566 insertions, 0 deletions

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,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc4443>.
+
+   [RFC4778]  Kaeo, M., "Operational Security Current Practices in
+              Internet Service Provider Environments", RFC 4778,
+              DOI 10.17487/RFC4778, January 2007,
+              <https://www.rfc-editor.org/info/rfc4778>.
+
+   [RFC5460]  Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
+              DOI 10.17487/RFC5460, February 2009,
+              <https://www.rfc-editor.org/info/rfc5460>.
+
+   [RFC7653]  Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6
+              Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,
+              October 2015, <https://www.rfc-editor.org/info/rfc7653>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8213]  Volz, B. and Y. Pal, "Security of Messages Exchanged
+              between Servers and Relay Agents", RFC 8213,
+              DOI 10.17487/RFC8213, August 2017,
+              <https://www.rfc-editor.org/info/rfc8213>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc8415>.
+
+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.
+
+              <https://www.rfc-editor.org/info/bcp38>
+
+   [DOCSIS_3.1]
+              CableLabs, "MAC and Upper Layer Protocols Interface
+              Specification", Version 10, DOCSIS 3.1, January 2017,
+              <https://www.cablelabs.com/specification/CM-SP-MULPIv3.1>.
+
+   [TR-092]   Broadband Forum, "Broadband Remote Access Server (BRAS)
+              Requirements Document", Technical Report TR-092, August
+              2004,
+              <https://www.broadband-forum.org/download/TR-092.pdf>.
+
+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