draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt		draft-ietf-dhc-dhcpv6-pd-relay-requirements-01.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: September 6, 2020 Benu Networks		Expires: December 10, 2020 Benu Networks
	M. Hunek		M. Hunek
	Technical University of Liberec		Technical University of Liberec
	Richard. Patterson		R. Patterson
	March 5, 2020		Sky UK Ltd
			June 8, 2020
	DHCPv6 Prefix Delegating Relay		DHCPv6 Prefix Delegating Relay
	draft-ietf-dhc-dhcpv6-pd-relay-requirements-00		draft-ietf-dhc-dhcpv6-pd-relay-requirements-01
	Abstract		Abstract
	Operational experience with DHCPv6 prefix delegation has shown that		Operational experience with DHCPv6 prefix delegation (PD) has shown
	when the DHCPv6 relay function is not co-located with the DHCPv6		that when the DHCPv6 relay function is not co-located with the DHCPv6
	server function, issues such as timer synchronization between the		server function, issues such as timer synchronization between the
	DHCP functional elements, rejection of client's messages by the		DHCP functional elements, rejection of client's messages by the
	relay, and other problems have been observed. These problems can		relay, and other problems have been observed. These problems can
	result in prefix delegation failing or traffic to/from clients		result in prefix delegation failing or traffic to/from clients
	addressed from the delegated prefix being unrouteable. Although		addressed from the delegated prefix not being routed. Although
	[RFC8415] mentions this deployment scenario, it does not provide		RFC8415 mentions this deployment scenario, it does not provide
	necessary detail on how the relay element should behave when used		necessary detail on how the relay element should behave when used
	with PD.		with PD.
	This document describes functional requirements for a DHCPv6 PD relay		This document describes functional requirements for a DHCPv6 PD relay
	when used for relaying prefixes delegated by a separate DHCPv6		when used for relaying prefixes delegated by a separate DHCPv6
	server.		server.
	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
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 48 ¶
	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 September 6, 2020.		This Internet-Draft will expire on December 10, 2020.
	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 27 ¶		skipping to change at page 2, line 27 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	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 Relays		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 Simultaneous Delegated Prefixes for a Single		3.3. Multiple Delegated Prefixes for a Single Client . . . . . 6
	DUID on 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		4. Requirements for Delegating Relays . . . . . . . . . . . . . 6
	4.1. General Requirements . . . . . . . . . . . . . . . . . . 7		4.1. General Requirements . . . . . . . . . . . . . . . . . . 7
	4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 7		4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 8
	4.3. Service Continuity Requirements . . . . . . . . . . . . . 8		4.3. Service Continuity Requirements . . . . . . . . . . . . . 8
	4.4. Operational Requirements . . . . . . . . . . . . . . . . 8		4.4. Operational Requirements . . . . . . . . . . . . . . . . 9
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative References . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	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
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 27 ¶
	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 relaying is also not considered as the functionality is
	solely required by a DHCP relay agent that is co-located with the		solely required by a DHCP relay agent that is co-located with the
	first-hop router that the DHCPv6 client requesting the prefix is		first-hop router that the DHCPv6 client requesting the prefix is
	connected to.		connected to.
	The behavior defined in [RFC7283] is also applicable for DHCv6-PD-		The behavior for handling unknown messages defined in Section 19. of
	relay deployments.		[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 9 ¶
	forwarding DHCPv6 messages containing IA_PD/IAPREFIX		forwarding DHCPv6 messages containing IA_PD/IAPREFIX
	options between the client and server. The		options between the client and server. The
	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
			(CMTS) would be considered a delegating relay with respect to
			Customer Premises Devices (CPEs). A Broadband Network Gateway (BNG)
			in a DSL based access network may be a delegating relay if it does
			not implement a local DHCPv6 server function.
	[RFC8415] defines the 'DHCP server', (or 'server') as:		[RFC8415] defines the 'DHCP server', (or 'server') as:
	"A node that responds to requests from clients. It may or may not		"A node that responds to requests from clients. It may or may not
	be on the same link as the client(s). Depending on its		be on the same link as the client(s). Depending on its
	capabilities, if it supports prefix delegation it may also feature		capabilities, if it supports prefix delegation it may also feature
	the functionality of a delegating router.		the functionality of a delegating router."
	This document serves the deployment cases where a DHCPv6 server is		This document serves the deployment cases where a DHCPv6 server is
	not located on the same link as the client (necessitating the		not located on the same link as the client (necessitating the
	delegating relay). The server supports prefix delegation and is		delegating relay). The server supports prefix delegation and is
	capable of leasing prefixes to clients, but is not responsible for		capable of leasing prefixes to clients, but is not responsible for
	other functions required of a delegating router, such as managing		other functions required of a delegating router, such as managing
	routes for the delegated prefixes.		routes for the delegated prefixes.
	The term 'requesting router' has previously been used to describe the		The term 'requesting router' has previously been used to describe the
	DHCP client requesting prefixes for use. This document adopts the		DHCP client requesting prefixes for use. This document adopts the
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 28 ¶
	"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. This document uses these keywords not
	strictly for the purpose of interoperability, but rather for the		strictly for the purpose of interoperability, but rather for the
	purpose of establishing industry-common baseline functionality. As		purpose of establishing industry-common baseline functionality. As
	such, the document points to several other specifications (preferably		such, the document points to several other specifications (preferably
	in RFC or stable form) to provide additional guidance to implementers		in RFC or stable form) to provide additional guidance to implementers
	regarding any protocol implementation required to produce a DHCP		regarding any protocol implementation required to produce a DHCP
	relaying router that functions successfully with prefix delegation.		relaying router that functions successfully with prefix delegation.
	3. Problems Observed with Existing Delegating Relays Implementations		3. Problems Observed with Existing Delegating Relay Implementations
	The following sections of the document describe problems that have		The following sections of the document describe problems that have
	been observed with delegating relay implementations in commercially		been observed with delegating relay implementations in commercially
	available devices.		available devices.
	3.1. DHCP Messages not being Forwarded by the Delegating relay		3.1. DHCP Messages not being Forwarded by the Delegating Relay
	Delegating relay implementations have been observed not to forward		Delegating relay implementations have been observed not to forward
	messages between the client and server. This generally occurs if a		messages between the client and server. This generally occurs if a
	client sends a message which is unexpected by the delegating relay.		client sends a message which is unexpected by the delegating relay.
	For example, the delegating router already has an active PD lease		For example, the delegating router 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
	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's traffic, the delegating relay requires		For proper routing of client traffic, the delegating relay requires a
	a corresponding routing table entry for each active prefix delegated		corresponding routing table entry for each active prefix delegated to
	to a connected client. A delegating router which does not store this		a connected client. A delegating router 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 Simultaneous Delegated Prefixes for a Single DUID on a		3.3. Multiple Delegated Prefixes for a Single Client
	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 instance of OPTION_IAPREFIX for each received instance		supplies one (or more) instance of OPTION_IAPREFIX for each received
	of OPTION_IA_PD, each containing information for a different		instance of OPTION_IA_PD, each containing information for a different
	delegated prefix.		delegated prefix.
	In some delegating relay implementations, only a single delegated		In some delegating relay implementations, only a single delegated
	prefix per-DUID is supported. In those cases only one IPv6 route for		prefix per-DUID is supported. In those cases only one IPv6 route for
	only one of the delegated router 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 unfortunate operational reality that client devices with
	duplicate MAC addresses and/or DUIDs exist and have been deployed.		duplicate MAC addresses and/or DUIDs exist and have been deployed.
	In this situation, the operational costs of locating and swapping out		In this situation, the operational costs of locating and swapping out
	such devices are prohibitive.		such devices are prohibitive.
	Delegating relays have been observed to restrict forwarding client		Delegating relays have been observed to restrict forwarding client
	messages originating from one client DUID to a single interface. In		messages originating from one client DUID to a single interface. In
	this case if the same client DUID appears from a second client on		this case if the same client DUID appears from a second client on
	another interface while there is already an active lease, messages		another interface while there is already an active lease, messages
	originating from the second client are dropped causing the second		originating from the second client are dropped causing the second
	client to be unable to obtain a prefix delegation.		client to be unable to obtain a prefix delegation.
			It should be noted that in some access networks, the MAC address and/
			or DUID are used as part of device identification and authentication.
			In such networks, enforcing MAC address/DUID uniqueness is a
			necessary function and not considered a problem.
	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 the following section
	of the document describes a set of functional requirements for the		of the document describes a set of functional requirements for the
	delegating relay.		delegating relay.
	4.1. General Requirements		4.1. General Requirements
	G-1: The delegating router MUST forward messages bidirectionally		G-1: The delegating router 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: As described in Section 16 of [RFC8415], in the event that a
	received message contains a DHCPv6 option which the relay		received message contains a DHCPv6 option which the relay
	does not implement, the message MUST be forwarded.		does not implement, the message MUST be forwarded.
	G-3: The relay MUST allow for multiple prefixes to be delegated		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 separate		G-4: The relay MUST allow for multiple prefixes (with or without
	IA_PDs to be delegated to a single client connected to a		separate IA_PDs) to be delegated to a single client connected
	single interface, identified by its DHCPv6 Client Identifier		to a single interface, identified by its DHCPv6 Client
	(DUID).		Identifier (DUID).
	G-5: The relay MUST allow the same client identifier (DUID) to		G-5: If a device has multiple interfaces that implement a
	have active delegated prefix leases on more than one		delegating relay function, the device SHOULD allow the same
	interface simultaneously. This is to allow client devices		client identifier (DUID) to have active delegated prefix
			leases on more than one interface simultaneously, unless
			client DUID 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		with duplicate DUIDs to function on separate broadcast
	domains.		domains.
	G-6: The maximum number of simultaneous prefixes delegated to a		G-6: 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-7: 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 SHOULD be		client identifiers and IA_PDs. This value MUST be
	configurable.		configurable.
	G-8: The delegating relay MUST synchronize the lifetimes of active		G-8: It is RECOMMENDED that delegating relays support at least 8
	prefix delegation leases with server.		active delegated leases per client device and use this as the
			default limit.
			G-9: The delegating relay MUST update the lease lifetimes based on
			the Client Reply messages it forwards to the client and only
			expire the delegated prefixes when the valid lifetime has
			elapsed.
			G-10: On receipt of a Release message from the client, the
			delegating relay MUST expire the active leases for each of
			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 prefixes and the associated next-
	hops as they are delegated to clients. When a delegated		hops as they are delegated to clients. When a delegated
	prefix is released or expires, the associated route MUST be		prefix is Released or expires, the associated route MUST be
	removed from the relay's routing table.		removed 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		access control lists permitting ingress traffic sourced from
	clients' delegated prefixes. This is to implement anti-		client delegated prefixes. This is to implement anti-
	spoofing as described in [BCP38].		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 prefixes into an routing protocol as they are
	learnt. When a delegated prefix is released or expires, the		learnt. When a delegated prefix is released or expires, the
	delegated route MUST be withdrawn from the routing protocol.		delegated route MUST be withdrawn from the routing protocol.
	The mechanism using which the routes are inserted and deleted		The mechanism by which the routes are inserted and deleted is
	is out of the scope of this document.		out of the scope of this document.
			R-4: If the relay has an existing route for a delegated prefix via
			an interface, and receives ingress traffic on this interface
			with a destination address from the delegated prefix (not
			configured on the relay), then it MUST be dropped.
	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, it
	is RECOMMENDED that the relay implements either of the		is RECOMMENDED that the relay implements either of the
	following:		following:
	The relay MAY implement DHCPv6 bulk lease query as		* The relay MAY implement DHCPv6 bulk lease query as defined
	defined in [RFC5460].		in [RFC5460].
	The relay SHOULD store active prefix delegations in		* The relay SHOULD store active prefix delegations in
	persistent storage so they can be re-read after the		persistent 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 relay needing to be		next-hop becomes reachable without the delegated prefixes
	re-learnt.		needing to be re-learnt.
	S-3: The relay MAY implement DHCPv6 active lease query as defined		S-3: The relay MAY implement DHCPv6 active lease query as defined
	in [RFC7653] to keep the local lease database in sync with		in [RFC7653] to keep the local lease database in sync with
	the DHCPv6 server.		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 the delegating relay's system time is synchronised with		that a time synchronization protocol is used by the
	the network.		delegating routers 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 for his
	valuable comments.		valuable comments.
	6. IANA Considerations		6. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	skipping to change at page 10, line 17 ¶		skipping to change at page 10, line 35 ¶
	"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.
	[RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6
	Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014,
	<https://www.rfc-editor.org/info/rfc7283>.
	[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>.
	Authors' Addresses		Authors' Addresses
	Ian Farrer		Ian Farrer
	Deutsche Telekom AG		Deutsche Telekom AG
	Landgrabenweg 151		Landgrabenweg 151
	skipping to change at page 11, line 4 ¶		skipping to change at page 11, line 19 ¶
	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
			1 Brick Lane
			London E1 6PU
			UK
	Email: richard@helix.net.nz		Email: richard.patterson@sky.uk
End of changes. 38 change blocks.
	58 lines changed or deleted		87 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/