< draft-fkhp-dhc-dhcpv6-pd-relay-requirements-01.txt		draft-fkhp-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: Informational Naveen. Kottapalli
	Expires: May 5, 2020 Benu Networks		Expires: May 21, 2020 Benu Networks
	M. Hunek		M. Hunek
	Technical University of Liberec		Technical University of Liberec
	Richard. Patterson		Richard. Patterson
	November 2, 2019		November 18, 2019
	DHCPv6 Prefix Delegating relay		DHCPv6 Prefix Delegating relay
	draft-fkhp-dhc-dhcpv6-pd-relay-requirements-01		draft-fkhp-dhc-dhcpv6-pd-relay-requirements-02
	Abstract		Abstract
	Operational experience with DHCPv6 prefix delegation has shown that		Operational experience with DHCPv6 prefix delegation has shown that
	when the DHCPv6 relay function is not co-located with the DHCPv6		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 being unrouteable. Although
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 5, 2020.		This Internet-Draft will expire on May 21, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 32 ¶		skipping to change at page 2, line 32 ¶
	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 Relays
	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 . . . . . . . . 5		3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 5
	3.3. Multiple Simultaneous Delegated Prefixes for a Single		3.3. Multiple Simultaneous Delegated Prefixes for a Single
	DUID on a Single Client . . . . . . . . . . . . . . 5		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 . . . . . . . . . . . . . . . . . . 6		4.1. General Requirements . . . . . . . . . . . . . . . . . . 6
	4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 7		4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 7
	4.3. Service Continuity Requirements . . . . . . . . . . . . . 7		4.3. Service Continuity Requirements . . . . . . . . . . . . . 8
	4.4. Operational Requirements . . . . . . . . . . . . . . . . 8		4.4. Operational Requirements . . . . . . . . . . . . . . . . 8
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		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 . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . 9		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
	DHCPv6 relay and Section 19.1.3 mentions the deployment scenario, but		DHCPv6 relay and Section 19.1.3 mentions the deployment scenario, but
	does not provide detail for all of the functional requirements that		does not provide detail for all of the functional requirements that
	the relay needs to fulfill to operate deterministically in this		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 these		provides a set of requirements for devices implementing a relay
	functions.		function for use with prefix delegation.
	This document does not cover the redistribution of the remote routes		The mechanisms for the redistribution of remote routes learnt via
	that have been are learnt from DHCP. Multi-hop relaying is also not		DHCP PD is out of scope of the document. Multi-hop relaying is also
	considered as the functionality is solely required by a DHCP relay		not considered as the functionality is solely required by a DHCP
	agent that is co-located with the first-hop router that the DHCPv6		relay agent that is co-located with the first-hop router that the
	client requesting the prefix is connected to.		DHCPv6 client requesting the prefix is connected to.
	The behavior defined in [RFC7283] is also applicable for DHCv6-PD-		The behavior defined in [RFC7283] is also applicable for DHCv6-PD-
	relay deployments.		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],
	skipping to change at page 3, line 48 ¶		skipping to change at page 3, line 48 ¶
	This document is concerned with deployment scenarios in which the		This document is concerned with deployment scenarios in which the
	DHCPv6 relay and DHCPv6 server functions are separated, so the term		DHCPv6 relay and DHCPv6 server functions are separated, so the term
	'delegating router' is not used. Instead, a new term is introduced		'delegating router' is not used. Instead, a new term is introduced
	to describe the relaying function:		to describe the relaying function:
	Delegating relay A delegating relay acts as an intermediate device,		Delegating relay A delegating relay acts as an intermediate device,
	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.		function. The delegating relay is also responsible
			for routing traffic for the delegated prefixes.
	The device functioning as the delegating relay is also responsible		Where the term 'relay' is used on its own within this document, it
	for routing traffic for the delegated prefixes.		should be understand to be a delegating relay, unless specificcally
			stated otherwise.
	[RFC8415] defines the 'DHCP server', (or as 'server') as:		[RFC8415] defines the 'DHCP server', (or as '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 DHCPv6 server is not		This document serves the deployment cases where DHCPv6 server is not
	located on the same link as the client (necessitating the delegating		located on the same link as the client (necessitating the delegating
	skipping to change at page 4, line 48 ¶		skipping to change at page 5, line 5 ¶
	Figure 1		Figure 1
	The client request prefixes via the client facing interface of the		The client request prefixes via the client facing 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 network facing 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
	"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.		capitals, as shown here. This document uses these keywords not
			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 Relays Implementations		3. Problems Observed with Existing Delegating Relays 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 6, line 16 ¶		skipping to change at page 6, line 27 ¶
	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		only one of the delegated router 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, DUIDs exist and have been deployed. In this		duplicate MAC addresses and/or DUIDs exist and have been deployed.
	situation, the operational costs of locating and swapping out such		In this situation, the operational costs of locating and swapping out
	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 and active lease, messages		another interface while there is already and 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.
	4. Requirements for Delegating Relays		4. Requirements for Delegating Relays
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 24 ¶
	IA_PDs to be delegated to a single client connected to a		IA_PDs to be delegated to a single client connected to a
	single interface, identified by its DHCPv6 Client Identifier		single interface, identified by its DHCPv6 Client Identifier
	(DUID).		(DUID).
	G-5: The relay MUST allow the same client identifier (DUID) to		G-5: The relay MUST allow the same client identifier (DUID) to
	have active delegated prefix leases on more than one		have active delegated prefix leases on more than one
	interface simultaneously. This is to allow client devices		interface simultaneously. 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 relay up on detecting that the current lease information		G-6: The maximum number of simultaneous prefixes delegated to a
	of any delegated prefix is no more valid, then the relay MUST
	deprecate the invalid prefixes as quick as possible so that
	the clients use a new prefix quickly.
	G-7: The maximum number of simultaneous prefixes delegated to a
	single client MUST be configurable.		single client MUST be configurable.
	G-8: 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 SHOULD be
	configurable.		configurable.
	G-9: The delegating relay MUST synchronize the lifetimes of active		G-8: The delegating relay MUST synchronize the lifetimes of active
	prefix delegation leases with server.		prefix delegation leases with server.
	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.
	skipping to change at page 7, line 44 ¶		skipping to change at page 8, line 4 ¶
	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-		clients' 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 using which the routes are inserted and deleted
	is out of the scope of this document.		is out of the scope of this document.
	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:		is RECOMMENDED that the relay implements either of the
			following:
	The relay MAY implement DHCPv6 bulk lease query as		The relay MAY implement DHCPv6 bulk lease query as
	defined in [RFC5460].		defined 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 client needing to send		next-hop becomes reachable without the relay needing to be
	any DHCP messages.		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
	skipping to change at page 10, line 10 ¶		skipping to change at page 10, line 22 ¶
	[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.
	[I-D.ietf-dhc-relay-server-security]		[I-D.ietf-dhc-relay-server-security]
	Volz, B. and Y. Pal, "Security of Messages Exchanged		Volz, B. and Y. Pal, "Security of Messages Exchanged
	Between Servers and Relay Agents", draft-ietf-dhc-relay-		Between Servers and Relay Agents", draft-ietf-dhc-relay-
	server-security-05 (work in progress), April 2017.		server-security-05 (work in progress), April 2017.
	[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
	DOI 10.17487/RFC2629, June 1999,
	<https://www.rfc-editor.org/info/rfc2629>.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,
	DOI 10.17487/RFC3552, July 2003,
	<https://www.rfc-editor.org/info/rfc3552>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 5226,
	DOI 10.17487/RFC5226, May 2008,
	<https://www.rfc-editor.org/info/rfc5226>.
	[RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6		[RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6
	Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014,		Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014,
	<https://www.rfc-editor.org/info/rfc7283>.		<https://www.rfc-editor.org/info/rfc7283>.
	Authors' Addresses		Authors' Addresses
	Ian Farrer		Ian Farrer
	Deutsche Telekom AG		Deutsche Telekom AG
	Landgrabenweg 151		Landgrabenweg 151
	Bonn, NRW 53227		Bonn, NRW 53227
End of changes. 23 change blocks.
	51 lines changed or deleted		42 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/