< draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00.txt		draft-fkhp-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: December 27, 2019 Benu Networks		Expires: May 5, 2020 Benu Networks
	M. Hunek		M. Hunek
	Technical University of Liberec		Technical University of Liberec
	Richard. Patterson		Richard. Patterson
	June 25, 2019		November 2, 2019
	DHCPv6 Prefix Delegating relay		DHCPv6 Prefix Delegating relay
	draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00		draft-fkhp-dhc-dhcpv6-pd-relay-requirements-01
	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 December 27, 2019.		This Internet-Draft will expire on May 5, 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 42 ¶		skipping to change at page 2, line 42 ¶
	DUID on a Single Client . . . . . . . . . . . . . . 5		DUID on a Single Client . . . . . . . . . . . . . . 5
	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 . . . . . . . . . . . . . 7
	4.4. Operational Requirements . . . . . . . . . . . . . . . . 8		4.4. Operational Requirements . . . . . . . . . . . . . . . . 8
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		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 . . . . . . . . . . . . . . . . . 9
	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
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 11 ¶
	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 maximum number of simultaneous prefixes delegated to a		G-6: The relay up on detecting that the current lease information
			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-7: The relay MUST implement a mechanism to limit the maximum		G-8: 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-8: The delegating relay MUST synchronize the lifetimes of active		G-9: 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 8, line 5 ¶		skipping to change at page 8, line 8 ¶
	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:
	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 MAY 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 client needing to send
	any DHCP messages.		any DHCP messages.
			S-3: The relay MAY implement DHCPv6 active lease query as defined
			in [RFC7653] to keep the local lease database in sync 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 the delegating relay's system time is synchronised with		that the delegating relay's system time is synchronised with
	the network.		the network.
	5. Acknowledgements		5. Acknowledgements
	This template was derived from an initial version written by Pekka		The authors of this document would like to thank Bernie Volz for his
	Savola and contributed by him to the xml2rfc project.		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
	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.
	skipping to change at page 9, line 21 ¶		skipping to change at page 9, line 31 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,		[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
	DOI 10.17487/RFC5460, February 2009,		DOI 10.17487/RFC5460, February 2009,
	<https://www.rfc-editor.org/info/rfc5460>.		<https://www.rfc-editor.org/info/rfc5460>.
			[RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6
			Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,
			October 2015, <https://www.rfc-editor.org/info/rfc7653>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,		[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
	Richardson, M., Jiang, S., Lemon, T., and T. Winters,		Richardson, M., Jiang, S., Lemon, T., and T. Winters,
	"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>.
End of changes. 12 change blocks.
	11 lines changed or deleted		24 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/