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/