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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/