DHCPv6 Prefix Delegating Relay RequirementsDeutsche Telekom AGLandgrabenweg 151Bonn53227Germanyian.farrer@telekom.deBenu NetworksWeWork Galaxy, 43 Residency RoadBangalore560025KarnatakaIndiankottapalli@benunets.comTechnical University of LiberecStudentska 1402/2Liberec46017Czech Republicmartin.hunek@tul.czSky UK Ltd.1 Brick LaneLondonE1 6PUUnited Kingdomrichard.patterson@sky.uk
Internet
DHC Work GroupPrefix DelegationDHCPv6 relayDelegating routerRequesting routerDelegating relayThis 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
.
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
() 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
. Introduction
. Terminology
. General
. Topology
. Requirements Language
. Problems Observed with Existing Delegating Relay Implementations
. DHCP Messages Not Being Forwarded by the Delegating Relay
. Delegating Relay Loss of State on Reboot
. Multiple Delegated Prefixes for a Single Client
. Dropping Messages from Devices with Duplicate MAC Addresses and DUIDs
. Forwarding Loops between Client and Relay
. Requirements for Delegating Relays
. General Requirements
. Routing Requirements
. Service Continuity Requirements
. Operational Requirements
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
IntroductionFor 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. describes
the functionality of a DHCPv6 relay, and 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.TerminologyGeneralThis document uses the terminology defined in . However, when defining the functional
elements for prefix delegation, 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) (, 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 (, Section 4.10).
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 and
uses "DHCP client" or "client" interchangeably for this element.
TopologyThe following diagram shows the deployment topology relevant
to this document.
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.
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
when, and only when, they appear in all capitals, as shown here.
Problems Observed with Existing Delegating Relay ImplementationsThe following sections of the document describe problems that
have been observed with delegating relay implementations in
commercially available devices.
DHCP Messages Not Being Forwarded by the Delegating RelayDelegating 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.
Delegating Relay Loss of State on RebootFor 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.
Multiple Delegated Prefixes for a Single ClientDHCPv6 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.
Dropping Messages from Devices with Duplicate MAC Addresses and DUIDsIt 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.
Forwarding Loops between Client and RelayIf 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.
Requirements for Delegating RelaysTo resolve the problems described in
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
makes it clear that relays MUST forward
packets that either contain message codes it may not understand () or options that it does not understand ().General Requirements
The delegating relay MUST forward messages
bidirectionally between the client and server without
changing the contents of the message.
The relay MUST allow for multiple prefixes
to be delegated for the same client IA_PD. These delegations
may have different lifetimes.
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).
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.
The maximum number of simultaneous prefixes
delegated to a single client MUST be configurable.
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.
It is RECOMMENDED that delegating relays
support at least 8 active delegated leases per client device
and use this as the default limit.
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.
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.
Routing Requirements
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.
The delegating relay's routing entry MUST
use the same prefix length for the delegated prefix as
given in the IA_PD.
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 . The
delegating relay's ingress filter entry MUST use the same
prefix length for the delegated prefix as given in the
IA_PD.
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.
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 .
The ICMP policy SHOULD be configurable.
Service Continuity Requirements
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
.
Store active prefix delegations in persistent storage
so they can be reread after the reboot.
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.
The relay SHOULD implement DHCPv6 Active Leasequery as defined in to keep
the local lease database in sync with the DHCPv6 server.
Operational Requirements
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.
The relay SHOULD provide a method for the
operator to clear active bindings for an individual lease,
client, or all bindings on a port.
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.
IANA ConsiderationsThis document has no IANA actions.Security ConsiderationsThis document does not add any new security considerations
beyond those mentioned in
and .
If the delegating relay implements
filtering, then the filtering rules will need to be dynamically
updated as delegated prefixes are leased.
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
may introduce additional security considerations. It is
RECOMMENDED that the operational security practices described
in be implemented.
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) SpecificationThis document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]Operational Security Current Practices in Internet Service Provider EnvironmentsThis document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments. This memo provides information for the Internet community.DHCPv6 Bulk LeasequeryThe Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. [STANDARDS-TRACK]DHCPv6 Active LeasequeryThe Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv6 bindings. That mechanism is limited to queries for DHCPv6 binding data updates prior to the time the DHCPv6 server receives the Leasequery request. Continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv6 Leasequery protocol and allows for active transfer of real-time DHCPv6 binding information data via TCP. This document also updates DHCPv6 Bulk Leasequery (RFC 5460) by adding new options.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Security of Messages Exchanged between Servers and Relay AgentsThe Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents but does not require encryption. With recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay-to-relay and relay-to-server communication for DHCPv6 and relay-to-server communication for DHCPv4.Dynamic Host Configuration Protocol for IPv6 (DHCPv6)This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.Informative ReferencesNetwork Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address SpoofingThis paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.MAC and Upper Layer Protocols Interface SpecificationCableLabsBroadband Remote Access Server (BRAS) Requirements DocumentBroadband ForumAcknowledgementsThe authors of this document would like to thank ,
, and for their valuable comments.
Authors' AddressesDeutsche Telekom AGLandgrabenweg 151Bonn53227Germanyian.farrer@telekom.deBenu NetworksWeWork Galaxy, 43 Residency RoadBangalore560025KarnatakaIndiankottapalli@benunets.comTechnical University of LiberecStudentska 1402/2Liberec46017Czech Republicmartin.hunek@tul.czSky UK Ltd.1 Brick LaneLondonE1 6PUUnited Kingdomrichard.patterson@sky.uk