draft-ietf-dhc-dhcpv6-pd-relay-requirements-03.txt   draft-ietf-dhc-dhcpv6-pd-relay-requirements-04.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: May 20, 2021 Benu Networks Expires: June 3, 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
November 16, 2020 November 30, 2020
DHCPv6 Prefix Delegating Relay Requirements DHCPv6 Prefix Delegating Relay Requirements
draft-ietf-dhc-dhcpv6-pd-relay-requirements-03 draft-ietf-dhc-dhcpv6-pd-relay-requirements-04
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 May 20, 2021. This Internet-Draft will expire on June 3, 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 5, line 34 skipping to change at page 5, line 34
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 which is unexpected by the delegating relay.
For example, the delegating router 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 it receives either 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
skipping to change at page 6, line 25 skipping to change at page 6, line 25
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-DUID is supported. In those cases only one IPv6 route for
one of the delegated prefixes is installed; meaning that other one of the delegated prefixes is installed; meaning that other
prefixes delegated to a client are unreachable. 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 unfortunate operational reality that client devices with It is an operational reality that client devices with duplicate MAC
duplicate MAC addresses and/or DUIDs exist and have been deployed. addresses and/or DUIDs exist and have been deployed. In this
In this situation, the operational costs of locating and swapping out situation, the operational costs of locating and swapping out such
such devices are prohibitive. 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.
skipping to change at page 7, line 12 skipping to change at page 7, line 12
either the client is successfully re-provisioned 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 forward packets that either contain message
either contain message codes (Section 19 of [RFC8415]) it may not codes (Section 19 of [RFC8415]) it may not understand, or contain
understand, or contain options that it does not understand options that it does not understand (Section 16 of [RFC8415]).
(Section 19 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 the message. of 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 the same client IA_PD. These delegations may have for the same client IA_PD. These delegations may have
different lifetimes. different lifetimes.
skipping to change at page 8, line 26 skipping to change at page 8, line 22
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 leases and the associated next-hops dynamically updated with leases and the associated next-hops
as they are delegated to clients. When a delegated prefix is as 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 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 delegating relay's routing entry MUST use the same prefix
length for the delegated prefix as given in the IA_PD.
R-3: The relay MUST provide a mechanism to dynamically update
ingress filters permitting ingress traffic sourced from 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]. The delegating relay's ingress filter
entry MUST use the same prefix length for the delegated
prefix as given in the IA_PD.
R-3: 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.
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: 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 on any DHCP-PD client facing interfaces. received 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:
skipping to change at page 9, line 14 skipping to change at page 9, line 14
* For multi-access links, when the packet's ingress and * For multi-access links, when the packet's ingress and
egress interface match, and the source link-layer and egress interface match, and the source link-layer and
next-hop link-layer addresses match. next-hop link-layer addresses match.
An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject
route to destination) error message MAY be sent as per route to destination) error message MAY be sent as per
[RFC4443], section 3.1. The ICMP policy SHOULD be [RFC4443], section 3.1. The ICMP policy SHOULD be
configurable. 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: To preserve active client prefix delegations across relay
prefix delegations will be lost. This may result in clients restarts, the relay SHOULD implement at least one of the
becoming unreachable. In order to mitigate this problem, the following:
relay SHOULD implement at least only following:
* Implement DHCPv6 bulk lease query as defined in [RFC5460]. * Implement DHCPv6 bulk lease query 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 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
 End of changes. 13 change blocks. 
24 lines changed or deleted 24 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/