draft-ietf-dhc-dhcpv6-pd-relay-requirements-04.txt		draft-ietf-dhc-dhcpv6-pd-relay-requirements-05.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 N. Kottapalli
	Expires: June 3, 2021 Benu Networks		Expires: 8 July 2021 Benu Networks
	M. Hunek		M. Hunek
	Technical University of Liberec		Technical University of Liberec
	R. Patterson		R.P. Patterson
	Sky UK Ltd		Sky UK Ltd
	November 30, 2020		January 2021
	DHCPv6 Prefix Delegating Relay Requirements		DHCPv6 Prefix Delegating Relay Requirements
	draft-ietf-dhc-dhcpv6-pd-relay-requirements-04		draft-ietf-dhc-dhcpv6-pd-relay-requirements-05
	Abstract		Abstract
	This memo describes operational problems that are known to occur when		This document describes operational problems that are known to occur
	using DHCPv6 relays with Prefix Delegation. These problems can		when using DHCPv6 relays with Prefix Delegation. These problems can
	prevent successful delegation and result in routing failures. To		prevent successful delegation and result in routing failures. To
	address these problems, this memo provides necessary functional		address these problems, this document provides necessary functional
	requirements for operating DHCPv6 relays with Prefix Delegation.		requirements for operating DHCPv6 relays with Prefix Delegation.
	It is recommended that any network operator that is using DHCPv6		It is recommended that any network operator that is using DHCPv6
	prefix delegation with relays should ensure that these requirements		prefix delegation with relays should ensure that these requirements
	are followed on their networks.		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.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 3, 2021.		This Internet-Draft will expire on 5 July 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		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 . . . . . . . . . . . . . . . . . . . . . . . . 3
	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 Relay		3. Problems Observed with Existing Delegating Relay
	Implementations . . . . . . . . . . . . . . . . . . . . . . . 5		Implementations . . . . . . . . . . . . . . . . . . . . . 5
	3.1. DHCP Messages not being Forwarded by the Delegating		3.1. DHCP Messages not being Forwarded by the Delegating
	Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 5		Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 5		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
	addresses and DUIDs . . . . . . . . . . . . . . . . . . . 6		and DUIDs . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.5. Forwarding Loops between Client and Relay . . . . . . . . 6		3.5. Forwarding Loops between Client and Relay . . . . . . . . 7
	4. Requirements for Delegating Relays . . . . . . . . . . . . . 7		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 . . . . . . . . . . . . . 9		4.3. Service Continuity Requirements . . . . . . . . . . . . . 9
	4.4. Operational Requirements . . . . . . . . . . . . . . . . 9		4.4. Operational Requirements . . . . . . . . . . . . . . . . 10
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. Normative References . . . . . . . . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . 11
	8.2. Informative References . . . . . . . . . . . . . . . . . 11		8.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	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 this deployment scenario,		DHCPv6 relay and Section 19.1.3 mentions this deployment scenario,
	but does not provide detail for all of the functional requirements		but does not provide details for all of the functional requirements
	that 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 un-reachability of the delegated prefixes. This document		relay or un-reachability 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.
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 39 ¶
	Multi-hop DHCPv6 relaying is not affected. The requirements in this		Multi-hop DHCPv6 relaying is not affected. The requirements in this
	document are solely applicable to the DHCP relay agent co-located		document are solely applicable to the DHCP relay agent co-located
	with the first-hop router that the DHCPv6 client requesting the		with the first-hop router that the DHCPv6 client requesting the
	prefix is connected to, so no changes to any subsequent relays in the		prefix is connected to, so no changes to any subsequent relays in the
	path are needed.		path are needed.
	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,
	defining the functional elements for prefix delegation [RFC8415],		when defining the functional elements for prefix delegation
	Section 4.2 defines the term 'delegating router' as:		[RFC8415], 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
	for delegated prefixes."		for delegated prefixes."
	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 and
	options between the client and server. The		IAPREFIX 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		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
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 50 ¶
	In some delegating relay implementations, only a single delegated		In some delegating relay implementations, only a single delegated
	prefix per-DUID is supported. In those cases only one IPv6 route for		prefix per-DUID is supported. In those cases only one IPv6 route for
	one of the delegated prefixes is installed; meaning that other		one of the delegated prefixes is installed; meaning that other
	prefixes delegated to a client are unreachable.		prefixes delegated to a client are unreachable.
	3.4. Dropping Messages from Devices with Duplicate MAC addresses and		3.4. Dropping Messages from Devices with Duplicate MAC addresses and
	DUIDs		DUIDs
	It is an operational reality that client devices with duplicate MAC		It is an operational reality that client devices with duplicate MAC
	addresses and/or DUIDs exist and have been deployed. In this		addresses and/or DUIDs exist and have been deployed. In some
	situation, the operational costs of locating and swapping out such		networks, the operational costs of locating and swapping out such
	devices are prohibitive.		devices are prohibitive.
	Delegating relays have been observed to restrict forwarding client		Delegating relays have been observed to restrict forwarding client
	messages originating from one client DUID to a single interface. In		messages originating from one client DUID to a single interface. In
	this case if the same client DUID appears from a second client on		this case if the same client DUID appears from a second client on
	another interface while there is already an active lease, messages		another interface while there is already an active lease, messages
	originating from the second client are dropped causing the second		originating from the second client are dropped causing the second
	client to be unable to obtain a prefix delegation.		client to be unable to obtain a prefix delegation.
	It should be noted that in some access networks, the MAC address and/		It should be noted that in some access networks, the MAC address and/
	or DUID are used as part of device identification and authentication.		or DUID are used as part of device identification and authentication.
	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		3.5. Forwarding Loops between Client and Relay
	If the client loses information about a prefix that it is delegated		If the client loses information about an active prefix lease it has
	while the lease entry and associated route is still active in the		been delegated while the lease entry and associated route is still
	delegating relay, then the relay will forward traffic to the client		active in the delegating relay, then the relay will forward traffic
	which the client will return to the relay (which is the client's		to the client which the client will return to the relay (which is the
	default gateway (learned via an RA)). The loop will continue until		client's default gateway (learned via an RA)). The loop will
	either the client is successfully re-provisioned via DHCP, or the		continue until either the client is successfully re-provisioned via
	lease ages out in the relay.		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 and pre-empt other		To resolve the problems described in Section 3 and pre-empt other
	undesirable behavior, the following section of the document describes		undesirable behavior, the following section of the document describes
	a set of functional requirements for the delegating relay.		a set of functional requirements for the delegating relay.
	In addition, relay implementers are reminded that [RFC8415] makes it		In addition, relay implementers are reminded that [RFC8415] makes it
	clear that relays MUST forward packets that either contain message		clear that relays MUST forward packets that either contain message
	codes (Section 19 of [RFC8415]) it may not understand, or contain		codes (Section 19 of [RFC8415]) it may not understand, or contain
	skipping to change at page 8, line 6 ¶		skipping to change at page 8, line 29 ¶
	G-6: 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-7: 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-8: 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's reply messages it forwards to the client and
	expire the delegated prefixes when the valid lifetime has		only expire the delegated prefixes when the valid lifetime
	elapsed.		has elapsed.
	G-9: 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 leases and the associated next-hops		dynamically updated with leases and the associated next-hops
	as they are delegated to clients. When a delegated prefix is		as they are delegated to clients. When a delegated prefix is
	skipping to change at page 8, line 35 ¶		skipping to change at page 9, line 13 ¶
	R-3: The relay MUST provide a mechanism to dynamically update		R-3: The relay MUST provide a mechanism to dynamically update
	ingress filters permitting ingress traffic sourced from		ingress filters permitting ingress traffic sourced from
	client delegated leases and blocking packets from invalid		client delegated leases and blocking packets from invalid
	source prefixes. This is to implement anti-spoofing as		source prefixes. This is to implement anti-spoofing as
	described in [BCP38]. The delegating relay's ingress filter		described in [BCP38]. The delegating relay's ingress filter
	entry MUST use the same prefix length for the delegated		entry MUST use the same prefix length for the delegated
	prefix as given in the IA_PD.		prefix as given in the IA_PD.
	R-4: The relay MAY provide a mechanism to dynamically advertise		R-4: The relay MAY provide a mechanism to dynamically advertise
	delegated leases into a routing protocol as they are learned.		delegated leases into a routing protocol as they are learned.
	When a delegated lease is released or expires, the delegated		If such a mechanism is implemented, when a delegated lease is
	route MUST be withdrawn from the routing protocol. The		released or expires, the delegated route MUST be withdrawn
	mechanism by which the routes are inserted and deleted is out		from the routing protocol. The mechanism by which the routes
	of the scope of this document.		are inserted and deleted is out of the scope of this
			document.
	R-5: To prevent routing loops, the relay SHOULD implement a		R-5: To prevent routing loops, the relay SHOULD implement a
	configurable policy to drop potential looping packets		configurable policy to drop potential looping packets
	received on any DHCP-PD client facing interfaces.		received on any DHCP-PD client facing interfaces.
	The policy SHOULD be configurable on a per-client or per-		The policy SHOULD be configurable on a per-client or per-
	destination basis.		destination basis.
	Looping packets are those with a destination address in a		Looping packets are those with a destination address in a
	prefix delegated to a client connected to that interface, as		prefix delegated to a client connected to that interface, as
	skipping to change at page 10, line 19 ¶		skipping to change at page 10, line 47 ¶
	The authors of this document would like to thank Bernie Volz, Ted		The authors of this document would like to thank Bernie Volz, Ted
	Lemon, and Michael Richardson for their valuable comments.		Lemon, and Michael Richardson 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		This document does not add any new security considerations beyond
	those mentioned in Section 22 of [RFC8213].		those mentioned in Section 4 of [RFC8213] and Section 22 of
			[RFC8415].
	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. It
	this case the IPsec tunnel is functionally the server-facing		is RECOMMENDED that this is implemented by the delegating relay.
	interface and DHCPv6 message snooping can be carried out as
	described. It is RECOMMENDED that this is implemented by the		Failure to implement requirement G-6 may have specific security
	delegating relay.		implications, such as a resource depletion attack on the relay.
			The operational requirements in Section Section 4.4 may introduce
			additional security considerations. It is RECOMMENDED that the
			operational security practices described in [RFC4778] are
			implemented.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[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>.
			[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
			Control Message Protocol (ICMPv6) for the Internet
			Protocol Version 6 (IPv6) Specification", STD 89,
			RFC 4443, DOI 10.17487/RFC4443, March 2006,
			<https://www.rfc-editor.org/info/rfc4443>.
			[RFC4778] Kaeo, M., "Operational Security Current Practices in
			Internet Service Provider Environments", RFC 4778,
			DOI 10.17487/RFC4778, January 2007,
			<https://www.rfc-editor.org/info/rfc4778>.
	[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		[RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6
	Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,		Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,
	October 2015, <https://www.rfc-editor.org/info/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>.
			[RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged
			between Servers and Relay Agents", RFC 8213,
			DOI 10.17487/RFC8213, August 2017,
			<https://www.rfc-editor.org/info/rfc8213>.
	[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>.
	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,
			<https://www.rfc-editor.org/rfc/rfc2827>.
	[DOCSIS_3.1]		[DOCSIS_3.1]
	CableLabs, "MAC and Upper Layer Protocols Interface		CableLabs, "MAC and Upper Layer Protocols Interface
	Specification", DOCSIS 3.1, January, 2017",		Specification", DOCSIS 3.1, January, 2017",
	<https://apps.cablelabs.com/specification/CM-SP-MULPIv3.>.		<https://apps.cablelabs.com/specification/CM-SP-MULPIv3.>.
	[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
	Control Message Protocol (ICMPv6) for the Internet
	Protocol Version 6 (IPv6) Specification", STD 89,
	RFC 4443, DOI 10.17487/RFC4443, March 2006,
	<https://www.rfc-editor.org/info/rfc4443>.
	[RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged
	between Servers and Relay Agents", RFC 8213,
	DOI 10.17487/RFC8213, August 2017,
	<https://www.rfc-editor.org/info/rfc8213>.
	[TR-092] Broadband Forum, "Broadband Remote Access Server (BRAS)		[TR-092] Broadband Forum, "Broadband Remote Access Server (BRAS)
	Requirements Document, August, 2004",		Requirements Document, August, 2004",
	<https://www.broadband-forum.org/download/TR-092.pdf>.		<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		53227 Bonn
	DE		Germany
	Email: ian.farrer@telekom.de		Email: ian.farrer@telekom.de
	Naveen Kottapalli		Naveen Kottapalli
	Benu Networks		Benu Networks
	300 Concord Road		154 Middlesex Turnpike
	Billerica, MA 01821		Burlington, MA 01803
	US		United States of America
	Email: naveen.sarma@gmail.com		Email: nkottapalli@benunets.com
	Martin Hunek		Martin Hunek
	Technical University of Liberec		Technical University of Liberec
	Studentska 1402/2		Studentska 1402/2
	Liberec, L 46017		46017 Liberec
	CZ		Czechia
	Email: martin.hunek@tul.cz		Email: martin.hunek@tul.cz
	Richard Patterson		Richard Patterson
	Sky UK Ltd		Sky UK Ltd
	1 Brick Lane		1 Brick Lane
	London E1 6PU		London
	UK		E1 6PU
			United Kingdom
	Email: richard.patterson@sky.uk		Email: richard.patterson@sky.uk
End of changes. 35 change blocks.
	83 lines changed or deleted		96 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/