draft-ietf-dhc-dhcpv6-pd-relay-requirements-02.txt   draft-ietf-dhc-dhcpv6-pd-relay-requirements-03.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: April 10, 2021 Benu Networks Expires: May 20, 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
October 7, 2020 November 16, 2020
DHCPv6 Prefix Delegating Relay DHCPv6 Prefix Delegating Relay Requirements
draft-ietf-dhc-dhcpv6-pd-relay-requirements-02 draft-ietf-dhc-dhcpv6-pd-relay-requirements-03
Abstract Abstract
This memo describes operational problems that are known to occur when This memo describes operational problems that are known to occur when
using DHCPv6 relays with Prefix Delegation. These problems can 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 memo provides necessary functional address these problems, this memo 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 that is using DHCPv6
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 April 10, 2021. This Internet-Draft will expire on May 20, 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 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
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
3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 6 Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 5
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
3.5. Forwarding Loops between Client and Relay . . . . . . . . 6 3.5. Forwarding Loops between Client and Relay . . . . . . . . 6
4. Requirements for Delegating Relays . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . 9 4.3. Service Continuity Requirements . . . . . . . . . . . . . 9
4.4. Operational Requirements . . . . . . . . . . . . . . . . 9 4.4. Operational Requirements . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 11 skipping to change at page 3, line 11
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 mentions this deployment scenario,
but does not provide detail for all of the functional requirements but does not provide detail for all of the functional requirements
that 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 un-reachability 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 learned 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 DHCPv6 relaying is not affected, as the requirements in Multi-hop DHCPv6 relaying is not affected. The requirements in this
this document are solely applicable to the DHCP relay agent co- document are solely applicable to the DHCP relay agent co-located
located with the first-hop router that the DHCPv6 client requesting with the first-hop router that the DHCPv6 client requesting the
the prefix is connected to, no changes to any subsequent relays in prefix is connected to, so no changes to any subsequent relays in the
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 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 5, line 21 skipping to change at page 5, line 21
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. This document uses these keywords not capitals, as shown here.
strictly for the purpose of interoperability, but rather for the
purpose of establishing industry-common baseline functionality. As
such, the document points to several other specifications (preferably
in RFC or stable form) to provide additional guidance to implementers
regarding any protocol implementation required to produce a DHCP
relaying router that functions successfully with prefix delegation.
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
skipping to change at page 7, line 5 skipping to change at page 6, line 48
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 3.5. Forwarding Loops between Client and Relay
If the client loses information about a prefix that it is delegated If the client loses information about a prefix that it is delegated
while the lease entry and associated route is still active in the while the lease entry and associated route is still active in the
delegating relay, then the relay will forward traffic to the client delegating relay, then the relay will forward traffic to the client
which the client will return to the relay (which is the client's which the client will return to the relay (which is the client's
default gateway (learnt via an RA). The loop will continue until default gateway (learned via an RA)). The loop will continue until
either the client is successfully reprovisioned via DHCP, or the either the client is successfully re-provisioned via DHCP, or the
lease ages out in the relay. 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 pre-empt 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 NOT drop (and hence not relay) packets that clear that relays MUST NOT drop (and hence not relay) packets that
skipping to change at page 8, line 35 skipping to change at page 8, line 33
Released or expires, the associated route MUST be removed Released or expires, the associated route MUST be 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
ingress filters permitting ingress traffic sourced from ingress filters permitting ingress traffic sourced from
client delegated leases and blocking packets from invalid client delegated leases and blocking packets from invalid
source prefixes. This is to implement anti-spoofing as source prefixes. This is to implement anti-spoofing as
described in [BCP38]. 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 leases into a routing protocol as they are learnt. delegated leases into a routing protocol as they are learned.
When a delegated lease is released or expires, the delegated When a delegated lease is released or expires, the delegated
route MUST be withdrawn from the routing protocol. The route MUST be withdrawn from the routing protocol. The
mechanism by which the routes are inserted and deleted is out mechanism by which the routes are inserted and deleted is out
of the scope of this document. of the scope of this document.
R-4: If the relay has learned a route for a delegated prefix via a R-4: To prevent routing loops, the relay SHOULD implement a
given interface, and receives traffic on this interface with configurable policy to drop potential looping packets
a destination address within the delegated prefix (that is received on any DHCP-PD client facing interfaces.
not an on-link prefix for the relay), then it MUST be
dropped. This is to prevent routing loops. An ICMPv6 Type The policy SHOULD be configurable on a per-client or per-
1, Code 6 (Destination Unreachable, reject route to destination basis.
destination) error message MAY be sent back to the client.
The ICMP policy SHOULD be configurable. Looping packets are those with a destination address in a
prefix delegated to a client connected to that interface, as
follows:
* For point-to-point links, when the packet's ingress and
egress interfaces match.
* For multi-access links, when the packet's ingress and
egress interface match, and the source link-layer and
next-hop link-layer addresses match.
An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject
route to destination) error message MAY be sent as per
[RFC4443], section 3.1. The ICMP policy SHOULD be
configurable.
R-5: The delegating relay's routing entry MUST use the same prefix R-5: 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.
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, the becoming unreachable. In order to mitigate this problem, the
relay SHOULD implement at least one following: relay SHOULD implement at least only following:
* Implement DHCPv6 bulk lease query as defined in * Implement DHCPv6 bulk lease query as defined in [RFC5460].
[RFC5460].
* Store active prefix delegations in persistent * Store active prefix delegations in persistent storage so
storage so they can be re-read after the reboot. they can be re-read 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 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-learned.
S-3: The relay SHOULD implement DHCPv6 active lease query as S-3: The relay SHOULD implement DHCPv6 active lease query as
defined in [RFC7653] to keep the local lease database in sync defined in [RFC7653] to keep the local lease database in sync
with 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
skipping to change at page 10, line 7 skipping to change at page 10, line 12
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 relays and DHCP servers. delegating relays and DHCP servers.
5. Acknowledgements 5. Acknowledgements
The authors of this document would like to thank Bernie Volz and Ted The authors of this document would like to thank Bernie Volz, Ted
Lemon for their valuable comments. Lemon, and Michael Richardson 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 This document does not add any new security considerations beyond
those mentioned in Section 22 of [RFC8213]. 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.
8. References 8. References
8.1. Normative References 8.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,
skipping to change at page 11, line 22 skipping to change at page 11, line 26
[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] [DOCSIS_3.1]
CableLabs, "MAC and Upper Layer Protocols Interface CableLabs, "MAC and Upper Layer Protocols Interface
Specification", DOCSIS 3.1, January, 2017", Specification", DOCSIS 3.1, January, 2017",
<https://apps.cablelabs.com/specification/CM-SP-MULPIv3.>. <https://apps.cablelabs.com/specification/CM-SP-MULPIv3.>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[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) [TR-092] Broadband Forum, "Broadband Remote Access Server (BRAS)
Requirements Document, August, 2004", Requirements Document, August, 2004",
<https://www.broadband-forum.org/download/TR-092.pdf>. <https://www.broadband-forum.org/download/TR-092.pdf>.
Authors' Addresses Authors' Addresses
 End of changes. 20 change blocks. 
43 lines changed or deleted 57 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/