draft-ietf-dhc-dhcpv6-pd-relay-requirements-01.txt   draft-ietf-dhc-dhcpv6-pd-relay-requirements-02.txt 
DHC Work Group I. Farrer DHC Work Group I. Farrer
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Standards Track Naveen. Kottapalli Intended status: Standards Track Naveen. Kottapalli
Expires: December 10, 2020 Benu Networks Expires: April 10, 2021 Benu Networks
M. Hunek M. Hunek
Technical University of Liberec Technical University of Liberec
R. Patterson R. Patterson
Sky UK Ltd Sky UK Ltd
June 8, 2020 October 7, 2020
DHCPv6 Prefix Delegating Relay DHCPv6 Prefix Delegating Relay
draft-ietf-dhc-dhcpv6-pd-relay-requirements-01 draft-ietf-dhc-dhcpv6-pd-relay-requirements-02
Abstract Abstract
Operational experience with DHCPv6 prefix delegation (PD) has shown This memo describes operational problems that are known to occur when
that when the DHCPv6 relay function is not co-located with the DHCPv6 using DHCPv6 relays with Prefix Delegation. These problems can
server function, issues such as timer synchronization between the prevent successful delegation and result in routing failures. To
DHCP functional elements, rejection of client's messages by the address these problems, this memo provides necessary functional
relay, and other problems have been observed. These problems can requirements for operating DHCPv6 relays with Prefix Delegation.
result in prefix delegation failing or traffic to/from clients
addressed from the delegated prefix not being routed. Although
RFC8415 mentions this deployment scenario, it does not provide
necessary detail on how the relay element should behave when used
with PD.
This document describes functional requirements for a DHCPv6 PD relay It is recommended that any network operator that is using DHCPv6
when used for relaying prefixes delegated by a separate DHCPv6 prefix delegation with relays should ensure that these requirements
server. are followed on their networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 10, 2020. This Internet-Draft will expire on April 10, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 29
2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Problems Observed with Existing Delegating Relay 3. Problems Observed with Existing Delegating Relay
Implementations . . . . . . . . . . . . . . . . . . . . . . . 5 Implementations . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. DHCP Messages not being Forwarded by the Delegating Relay 5 3.1. DHCP Messages not being Forwarded by the Delegating Relay 5
3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 6 3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 6
3.3. Multiple Delegated Prefixes for a Single Client . . . . . 6 3.3. Multiple Delegated Prefixes for a Single Client . . . . . 6
3.4. Dropping Messages from Devices with Duplicate MAC 3.4. Dropping Messages from Devices with Duplicate MAC
addresses and DUIDs . . . . . . . . . . . . . . . . 6 addresses and DUIDs . . . . . . . . . . . . . . . . 6
4. Requirements for Delegating Relays . . . . . . . . . . . . . 6 3.5. Forwarding Loops between Client and Relay . . . . . . . . 6
4. Requirements for Delegating Relays . . . . . . . . . . . . . 7
4.1. General Requirements . . . . . . . . . . . . . . . . . . 7 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7
4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 8 4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 8
4.3. Service Continuity Requirements . . . . . . . . . . . . . 8 4.3. Service Continuity Requirements . . . . . . . . . . . . . 9
4.4. Operational Requirements . . . . . . . . . . . . . . . . 9 4.4. Operational Requirements . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 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 the deployment scenario, but DHCPv6 relay and Section 19.1.3 mentions this deployment scenario,
does not provide detail for all of the functional requirements that but does not provide detail for all of the functional requirements
the relay needs to fulfill to operate deterministically in this that the relay needs to fulfill to operate deterministically in this
deployment scenario. 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 inter-working. 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 unreachability 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 learnt from ones), on its network-facing interface based on prefixes learnt from
a server via DHCP-PD are out of scope of the document. a server via DHCP-PD are out of scope of the document.
Multi-hop relaying is also not considered as the functionality is Multi-hop DHCPv6 relaying is not affected, as the requirements in
solely required by a DHCP relay agent that is co-located with the this document are solely applicable to the DHCP relay agent co-
first-hop router that the DHCPv6 client requesting the prefix is located with the first-hop router that the DHCPv6 client requesting
connected to. the prefix is connected to, no changes to any subsequent relays in
the path are needed.
The behavior for handling unknown messages defined in Section 19. of
[RFC8415] is also applicable for relay deployments.
2. Terminology 2. Terminology
2.1. General 2.1. General
This document uses the terminology defined in [RFC8415], however when This document uses the terminology defined in [RFC8415], however when
defining the functional elements for prefix delegation [RFC8415], defining the functional elements for prefix delegation [RFC8415],
Section 4.2 defines the term 'delegating router' as: 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
skipping to change at page 4, line 11 skipping to change at page 4, line 7
delegating relay does not implement a DHCPv6 server delegating relay does not implement a DHCPv6 server
function. The delegating relay is also responsible 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). A Broadband Network Gateway (BNG) Customer Premises Devices (CPEs) [DOCSIS_3.1], Section 5.2.7.2. A
in a DSL based access network may be a delegating relay if it does Broadband Network Gateway (BNG) in a DSL based access network may be
not implement a local DHCPv6 server function. 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: [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
skipping to change at page 4, line 39 skipping to change at page 4, line 36
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' [RFC8415] terminology 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 ------>
+---+ PD |----| Delegating |--( Operator )---| DHCPv6 | | _ ,--,_
| | Client | | relay | `(_ Network_)' | server | | +--------+ +------------+ _( `' )_ +--------+
| +--------+ +----------- + `--'`---' +--------+ +---+ PD |-------| Delegating |--( Operator )---| DHCPv6 |
| | | Client | | relay | `(_ Network_)' | server |
+ | +--------+ +----------- + `--'`---' +--------+
Client Network |
| <----- downlink ------
+ (client facing)
Client
Network
Figure 1 Figure 1: Topology overview
The client request prefixes via the client facing 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 network facing 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
skipping to change at page 6, line 9 skipping to change at page 6, line 9
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 router which does not store this a connected client. A delegating relay which 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 client's delegated leases until the state is re-established
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 [RFC8415] allows for 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
skipping to change at page 6, line 48 skipping to change at page 6, line 48
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 MAC address/DUID uniqueness is a
necessary function and not considered a problem. necessary function and not considered a problem.
3.5. Forwarding Loops between Client and Relay
If the client loses information about a prefix that it is delegated
while the lease entry and associated route is still active in the
delegating relay, then the relay will forward traffic to the client
which the client will return to the relay (which is the client's
default gateway (learnt via an RA). The loop will continue until
either the client is successfully reprovisioned via DHCP, or the
lease ages out in the relay.
4. Requirements for Delegating Relays 4. Requirements for Delegating Relays
To resolve the problems described in Section 3 the following section To resolve the problems described in Section 3 and pre-empt other
of the document describes a set of functional requirements for the undesirable behavior, the following section of the document describes
delegating relay. a set of functional requirements for the delegating relay.
In addition, relay implementers are reminded that [RFC8415] makes it
clear that relays MUST NOT drop (and hence not relay) packets that
either contain message codes (Section 19 of [RFC8415]) it may not
understand, or contain options that it does not understand
(Section 19 of [RFC8415]).
4.1. General Requirements 4.1. General Requirements
G-1: The delegating router 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 the message. of the message.
G-2: As described in Section 16 of [RFC8415], in the event that a G-2: The relay MUST allow for multiple prefixes to be delegated
received message contains a DHCPv6 option which the relay
does not implement, the message MUST be forwarded.
G-3: The relay MUST allow for multiple prefixes to be delegated
for the same client IA_PD. These delegations may have for the same client IA_PD. These delegations may have
different lifetimes. different lifetimes.
G-4: 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-5: If a device has multiple interfaces that implement a G-4: A delegating relay may have one or more interfaces on which
delegating relay function, the device SHOULD allow the same it acts as a relay, as well as one or more interfaces on
client identifier (DUID) to have active delegated prefix which it does not (for example, in an ISP, it might act as a
leases on more than one interface simultaneously, unless relay on all southbound interfaces, but not on the northbound
client DUID uniqueness is necessary for the functioning or interfaces). The relay SHOULD allow the same client
security of the network. This is to allow client devices identifier (DUID) to have active delegated prefix leases on
with duplicate DUIDs to function on separate broadcast more than one interface simultaneously, unless client DUID
domains. 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-6: 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-7: 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-8: 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-9: The delegating relay MUST update the lease lifetimes based on G-8: The delegating relay MUST update the lease lifetimes based on
the Client Reply messages it forwards to the client and only the Client Reply messages it forwards to the client and only
expire the delegated prefixes when the valid lifetime has expire the delegated prefixes when the valid lifetime has
elapsed. elapsed.
G-10: On receipt of a Release message from the client, the G-9: On receipt of a Release message from the client, the
delegating relay MUST expire the active leases for each of delegating relay MUST expire the active leases for each of
the IA_PDs in the message. the IA_PDs in 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 prefixes and the associated next- dynamically updated with leases and the associated next-hops
hops as they are delegated to clients. When a delegated as they are delegated to clients. When a delegated prefix is
prefix is Released or expires, the associated route MUST be Released or expires, the associated route MUST be removed
removed from the relay's routing table. from the relay's routing table.
R-2: The relay MUST provide a mechanism to dynamically update R-2: The relay MUST provide a mechanism to dynamically update
access control lists permitting ingress traffic sourced from ingress filters permitting ingress traffic sourced from
client delegated prefixes. This is to implement anti- client delegated leases and blocking packets from invalid
spoofing as described in [BCP38]. source prefixes. This is to implement anti-spoofing as
described in [BCP38].
R-3: The relay MAY provide a mechanism to dynamically advertise R-3: The relay MAY provide a mechanism to dynamically advertise
delegated prefixes into an routing protocol as they are delegated leases into a routing protocol as they are learnt.
learnt. When a delegated prefix is released or expires, the When a delegated lease is released or expires, the delegated
delegated route MUST be withdrawn from the routing protocol. route MUST be withdrawn from the routing protocol. The
The mechanism by which the routes are inserted and deleted is mechanism by which the routes are inserted and deleted is out
out of the scope of this document. of the scope of this document.
R-4: If the relay has an existing route for a delegated prefix via R-4: If the relay has learned a route for a delegated prefix via a
an interface, and receives ingress traffic on this interface given interface, and receives traffic on this interface with
with a destination address from the delegated prefix (not a destination address within the delegated prefix (that is
configured on the relay), then it MUST be dropped. not an on-link prefix for the relay), then it MUST be
dropped. This is to prevent routing loops. An ICMPv6 Type
1, Code 6 (Destination Unreachable, reject route to
destination) error message MAY be sent back to the client.
The ICMP policy SHOULD be configurable.
R-5: The delegating relay's routing entry MUST use the same prefix
length for the delegated prefix as given in the IA_PD.
4.3. Service Continuity Requirements 4.3. Service Continuity Requirements
S-1: In the event that the relay is restarted, active client S-1: In the event that the relay is restarted, active client
prefix delegations will be lost. This may result in clients prefix delegations will be lost. This may result in clients
becoming unreachable. In order to mitigate this problem, it becoming unreachable. In order to mitigate this problem, the
is RECOMMENDED that the relay implements either of the relay SHOULD implement at least one following:
following:
* The relay MAY implement DHCPv6 bulk lease query as defined * Implement DHCPv6 bulk lease query as defined in
in [RFC5460]. [RFC5460].
* The relay SHOULD store active prefix delegations in * Store active prefix delegations in persistent
persistent storage so they can be re-read after the storage so they can be re-read after the reboot.
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 retained by the delegating relay unless they are released be retained by the delegating relay unless they are released
or removed due to expiring DHCP timers. This is to re- or removed due to expiring DHCP timers. This is to re-
establish routing for the delegated prefix if the client establish routing for the delegated prefix if the client
next-hop becomes reachable without the delegated prefixes next-hop becomes reachable without the delegated prefixes
needing to be re-learnt. needing to be re-learnt.
S-3: The relay MAY implement DHCPv6 active lease query as defined S-3: The relay SHOULD implement DHCPv6 active lease query as
in [RFC7653] to keep the local lease database in sync with defined in [RFC7653] to keep the local lease database in sync
the DHCPv6 server. with the 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 client identifier, next-hop address, connected interface,
and remaining lifetimes. and remaining lifetimes.
O-2: The relay SHOULD provide a method for the operator to clear O-2: The relay SHOULD provide a method for the operator to clear
active bindings for an individual lease, client or all active bindings for an individual lease, client or all
bindings on a port. bindings on a port.
O-3: To facilitate troubleshooting of operational problems between O-3: To facilitate troubleshooting of operational problems between
the delegating relay and other elements, it is RECOMMENDED the delegating relay and other elements, it is RECOMMENDED
that a time synchronization protocol is used by the that a time synchronization protocol is used by the
delegating routers and DHCP servers. delegating relays and DHCP servers.
5. Acknowledgements 5. Acknowledgements
The authors of this document would like to thank Bernie Volz for his The authors of this document would like to thank Bernie Volz and Ted
valuable comments. Lemon for their valuable comments.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 7. Security Considerations
This document does not add any new security considerations beyond
those mentioned in Section 22 of [RFC8213].
If the delegating relay implements [BCP38] filtering, then the 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. In agent and server by sending DHCP messages over an IPSec tunnel. In
this case the IPSec tunnel is functionally the server-facing this case the IPSec tunnel is functionally the server-facing
interface and DHCPv6 message snooping can be carried out as interface and DHCPv6 message snooping can be carried out as
described. It is RECOMMENDED that this is implemented by the described. It is RECOMMENDED that this is implemented by the
delegating relay. delegating relay.
skipping to change at page 10, line 35 skipping to change at page 11, line 17
"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 8.2. Informative References
[BCP38] IETF, "Network Ingress Filtering: Defeating Denial of [BCP38] IETF, "Network Ingress Filtering: Defeating Denial of
Service Attacks which employ IP Source Address Spoofing 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",
<https://apps.cablelabs.com/specification/CM-SP-MULPIv3.>.
[RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged [RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged
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>.
[TR-092] Broadband Forum, "Broadband Remote Access Server (BRAS)
Requirements Document, August, 2004",
<https://www.broadband-forum.org/download/TR-092.pdf>.
Authors' Addresses Authors' Addresses
Ian Farrer Ian Farrer
Deutsche Telekom AG Deutsche Telekom AG
Landgrabenweg 151 Landgrabenweg 151
Bonn, NRW 53227 Bonn, NRW 53227
DE DE
Email: ian.farrer@telekom.de Email: ian.farrer@telekom.de
Naveen Kottapalli Naveen Kottapalli
Benu Networks Benu Networks
300 Concord Road 300 Concord Road
Billerica, MA 01821 Billerica, MA 01821
US US
Email: naveen.sarma@gmail.com Email: naveen.sarma@gmail.com
Martin Hunek Martin Hunek
Technical University of Liberec Technical University of Liberec
Studentska 1402/2 Studentska 1402/2
Liberec, L 46017 Liberec, L 46017
CZ CZ
Email: martin.hunek@tul.cz Email: martin.hunek@tul.cz
Richard Patterson Richard Patterson
Sky UK Ltd Sky UK Ltd
 End of changes. 44 change blocks. 
104 lines changed or deleted 135 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/