< draft-ietf-manet-dlep-24.txt		draft-ietf-manet-dlep-25.txt >
	Mobile Ad hoc Networks Working Group S. Ratliff		Mobile Ad hoc Networks Working Group S. Ratliff
	Internet-Draft VT iDirect		Internet-Draft VT iDirect
	Intended status: Standards Track S. Jury		Intended status: Standards Track S. Jury
	Expires: January 26, 2017 Cisco Systems		Expires: May 1, 2017 Cisco Systems
	D. Satterwhite		D. Satterwhite
	Broadcom		Broadcom
	R. Taylor		R. Taylor
	Airbus Defence & Space		Airbus Defence & Space
	B. Berry		B. Berry
	July 25, 2016		October 28, 2016
	Dynamic Link Exchange Protocol (DLEP)		Dynamic Link Exchange Protocol (DLEP)
	draft-ietf-manet-dlep-24		draft-ietf-manet-dlep-25
	Abstract		Abstract
	When routing devices rely on modems to effect communications over		When routing devices rely on modems to effect communications over
	wireless links, they need timely and accurate knowledge of the		wireless links, they need timely and accurate knowledge of the
	characteristics of the link (speed, state, etc.) in order to make		characteristics of the link (speed, state, etc.) in order to make
	routing decisions. In mobile or other environments where these		routing decisions. In mobile or other environments where these
	characteristics change frequently, manual configurations or the		characteristics change frequently, manual configurations or the
	inference of state through routing or transport protocols does not		inference of state through routing or transport protocols does not
	allow the router to make the best decisions. A bidirectional, event-		allow the router to make the best decisions. A bidirectional, event-
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 January 26, 2017.		This Internet-Draft will expire on May 1, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 35 ¶		skipping to change at page 2, line 35 ¶
	3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 9		3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 9		3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 9
	4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 11		5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 11
	5.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 11		5.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 11
	5.2. Session Initialization State . . . . . . . . . . . . . . 12		5.2. Session Initialization State . . . . . . . . . . . . . . 12
	5.3. In-Session State . . . . . . . . . . . . . . . . . . . . 13		5.3. In-Session State . . . . . . . . . . . . . . . . . . . . 13
	5.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 13		5.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 13
	5.4. Session Termination State . . . . . . . . . . . . . . . . 14		5.4. Session Termination State . . . . . . . . . . . . . . . . 14
	5.5. Session Reset state . . . . . . . . . . . . . . . . . . . 14		5.5. Session Reset state . . . . . . . . . . . . . . . . . . . 14
	5.5.1. Unexpected TCP connection termination . . . . . . . . 14		5.5.1. Unexpected TCP connection termination . . . . . . . . 15
	6. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 15		6. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 15
	7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 15		7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 16		7.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 16
	8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 16		8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9. DLEP Signal and Message Structure . . . . . . . . . . . . . . 17		9. DLEP Signal and Message Structure . . . . . . . . . . . . . . 17
	9.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 17		9.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 17
	9.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 18		9.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 18
	9.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 18		9.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 19
	10. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 19		10. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 19
	10.1. General Processing Rules . . . . . . . . . . . . . . . . 19		10.1. General Processing Rules . . . . . . . . . . . . . . . . 19
	10.2. Status code processing . . . . . . . . . . . . . . . . . 20		10.2. Status code processing . . . . . . . . . . . . . . . . . 20
	10.3. Peer Discovery Signal . . . . . . . . . . . . . . . . . 20		10.3. Peer Discovery Signal . . . . . . . . . . . . . . . . . 21
	10.4. Peer Offer Signal . . . . . . . . . . . . . . . . . . . 21		10.4. Peer Offer Signal . . . . . . . . . . . . . . . . . . . 21
	10.5. Session Initialization Message . . . . . . . . . . . . . 21		10.5. Session Initialization Message . . . . . . . . . . . . . 22
	10.6. Session Initialization Response Message . . . . . . . . 22		10.6. Session Initialization Response Message . . . . . . . . 23
	10.7. Session Update Message . . . . . . . . . . . . . . . . . 24		10.7. Session Update Message . . . . . . . . . . . . . . . . . 24
	10.8. Session Update Response Message . . . . . . . . . . . . 25		10.8. Session Update Response Message . . . . . . . . . . . . 26
	10.9. Session Termination Message . . . . . . . . . . . . . . 25		10.9. Session Termination Message . . . . . . . . . . . . . . 26
	10.10. Session Termination Response Message . . . . . . . . . . 25		10.10. Session Termination Response Message . . . . . . . . . . 26
	10.11. Destination Up Message . . . . . . . . . . . . . . . . . 26		10.11. Destination Up Message . . . . . . . . . . . . . . . . . 27
	10.12. Destination Up Response Message . . . . . . . . . . . . 27		10.12. Destination Up Response Message . . . . . . . . . . . . 28
	10.13. Destination Announce Message . . . . . . . . . . . . . . 28		10.13. Destination Announce Message . . . . . . . . . . . . . . 29
	10.14. Destination Announce Response Message . . . . . . . . . 28		10.14. Destination Announce Response Message . . . . . . . . . 29
	10.15. Destination Down Message . . . . . . . . . . . . . . . . 30		10.15. Destination Down Message . . . . . . . . . . . . . . . . 31
	10.16. Destination Down Response Message . . . . . . . . . . . 30		10.16. Destination Down Response Message . . . . . . . . . . . 31
	10.17. Destination Update Message . . . . . . . . . . . . . . . 31		10.17. Destination Update Message . . . . . . . . . . . . . . . 31
	10.18. Link Characteristics Request Message . . . . . . . . . . 32		10.18. Link Characteristics Request Message . . . . . . . . . . 33
	10.19. Link Characteristics Response Message . . . . . . . . . 33		10.19. Link Characteristics Response Message . . . . . . . . . 33
	10.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . 34		10.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . 34
	11. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 34		11. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 35
	11.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 35		11.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 36
	11.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 37		11.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 39
	11.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 38		11.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 40
	11.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 39		11.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 41
	11.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 40		11.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 41
	11.6. Extensions Supported . . . . . . . . . . . . . . . . . . 41		11.6. Extensions Supported . . . . . . . . . . . . . . . . . . 42
	11.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 41		11.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 42
	11.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 42		11.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 43
	11.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 43		11.8.1. IPv4 Address Processing . . . . . . . . . . . . . . 44
	11.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 44		11.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 45
	11.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 45		11.9.1. IPv6 Address Processing . . . . . . . . . . . . . . 46
	11.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 46		11.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 47
	11.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 46		11.10.1. IPv4 Attached Subnet Processing . . . . . . . . . . 48
	11.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 47		11.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 48
	11.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 48		11.11.1. IPv6 Attached Subnet Processing . . . . . . . . . . 50
	11.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 48		11.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 50
	11.17. Resources . . . . . . . . . . . . . . . . . . . . . . . 49		11.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 51
	11.18. Relative Link Quality (Receive) . . . . . . . . . . . . 50		11.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 52
	11.19. Relative Link Quality (Transmit) . . . . . . . . . . . . 51		11.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 52
	11.20. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 52		11.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 53
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 52		11.17. Resources . . . . . . . . . . . . . . . . . . . . . . . 54
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53		11.18. Relative Link Quality (Receive) . . . . . . . . . . . . 55
	13.1. Registrations . . . . . . . . . . . . . . . . . . . . . 53		11.19. Relative Link Quality (Transmit) . . . . . . . . . . . . 55
	13.2. Signal Type Registration . . . . . . . . . . . . . . . . 53		11.20. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 56
	13.3. Message Type Registration . . . . . . . . . . . . . . . 53		12. Security Considerations . . . . . . . . . . . . . . . . . . . 57
	13.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 54		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
	13.5. DLEP Status Code Registrations . . . . . . . . . . . . . 55		13.1. Registrations . . . . . . . . . . . . . . . . . . . . . 57
	13.6. DLEP Extensions Registrations . . . . . . . . . . . . . 56		13.2. Signal Type Registration . . . . . . . . . . . . . . . . 57
	13.7. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 56		13.3. Message Type Registration . . . . . . . . . . . . . . . 58
	13.8. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 57		13.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 59
	13.9. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 57		13.5. DLEP Status Code Registrations . . . . . . . . . . . . . 59
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57		13.6. DLEP Extensions Registrations . . . . . . . . . . . . . 60
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 57		13.7. DLEP IPv4 Connection Point Flags . . . . . . . . . . . . 60
	15.1. Normative References . . . . . . . . . . . . . . . . . . 57		13.8. DLEP IPv6 Connection Point Flags . . . . . . . . . . . . 61
	15.2. Informative References . . . . . . . . . . . . . . . . . 57		13.9. DLEP IPv4 Address Flag . . . . . . . . . . . . . . . . . 61
			13.10. DLEP IPv6 Address Flag . . . . . . . . . . . . . . . . . 61
	Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 58		13.11. DLEP IPv4 Attached Subnet Flag . . . . . . . . . . . . . 62
	Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 59		13.12. DLEP IPv6 Attached Subnet Flag . . . . . . . . . . . . . 62
	B.1. Session Initialization . . . . . . . . . . . . . . . . . 59		13.13. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 62
	B.2. Session Initialization - Refused . . . . . . . . . . . . 59		13.14. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 63
	B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 60		13.15. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 63
	B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 60		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63
	B.5. Router Terminates Session . . . . . . . . . . . . . . . . 61		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 63
	B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 61		15.1. Normative References . . . . . . . . . . . . . . . . . . 63
	B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 62		15.2. Informative References . . . . . . . . . . . . . . . . . 63
	B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 63		Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 64
	B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 64		Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 65
	Appendix C. Destination Specific Message Flows . . . . . . . . . 64		B.1. Session Initialization . . . . . . . . . . . . . . . . . 65
	C.1. Common Destination Notification . . . . . . . . . . . . . 64		B.2. Session Initialization - Refused . . . . . . . . . . . . 65
	C.2. Multicast Destination Notification . . . . . . . . . . . 65		B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 66
	C.3. Link Characteristics Request . . . . . . . . . . . . . . 66		B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 66
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67		B.5. Router Terminates Session . . . . . . . . . . . . . . . . 67
			B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 67
			B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 68
			B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 69
			B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 70
			Appendix C. Destination Specific Message Flows . . . . . . . . . 70
			C.1. Common Destination Notification . . . . . . . . . . . . . 70
			C.2. Multicast Destination Notification . . . . . . . . . . . 71
			C.3. Link Characteristics Request . . . . . . . . . . . . . . 72
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73
	1. Introduction		1. Introduction
	There exist today a collection of modem devices that control links of		There exist today a collection of modem devices that control links of
	variable datarate and quality. Examples of these types of links		variable datarate and quality. Examples of these types of links
	include line-of-sight (LOS) terrestrial radios, satellite terminals,		include line-of-sight (LOS) terrestrial radios, satellite terminals,
	and broadband modems. Fluctuations in speed and quality of these		and broadband modems. Fluctuations in speed and quality of these
	links can occur due to configuration, or on a moment-to-moment basis,		links can occur due to configuration, or on a moment-to-moment basis,
	due to physical phenomena like multipath interference, obstructions,		due to physical phenomena like multipath interference, obstructions,
	rain fade, etc. It is also quite possible that link quality and		rain fade, etc. It is also quite possible that link quality and
	skipping to change at page 9, line 31 ¶		skipping to change at page 9, line 31 ¶
	14, RFC 2119 [RFC2119].		14, RFC 2119 [RFC2119].
	DLEP MUST be implemented on a single Layer 2 domain. The protocol		DLEP MUST be implemented on a single Layer 2 domain. The protocol
	identifies next-hop destinations by using the MAC address for		identifies next-hop destinations by using the MAC address for
	delivering data traffic. No manipulation or substitution is		delivering data traffic. No manipulation or substitution is
	performed; the MAC address supplied in all DLEP Messages is used as		performed; the MAC address supplied in all DLEP Messages is used as
	the Destination MAC address for frames emitted by the participating		the Destination MAC address for frames emitted by the participating
	router. MAC addresses MUST be unique within the context of router-		router. MAC addresses MUST be unique within the context of router-
	modem session.		modem session.
			To enforce the single Layer 2 domain, implementations MUST support
			The Generalized TTL Security Mechanism [RFC5082].
	DLEP specifies UDP multicast for single-hop discovery signaling, and		DLEP specifies UDP multicast for single-hop discovery signaling, and
	TCP for transport of the Messages. Modems and routers participating		TCP for transport of the Messages. Modems and routers participating
	in DLEP sessions MUST have topologically consistent IP addresses		in DLEP sessions MUST have topologically consistent IP addresses
	assigned. It is RECOMMENDED that DLEP implementations utilize IPv6		assigned. It is RECOMMENDED that DLEP implementations utilize IPv6
	link-local addresses to reduce the administrative burden of address		link-local addresses to reduce the administrative burden of address
	assignment.		assignment. If the router and modem support both IPv4 and IPv6, the
			IPv6 transport MUST be used for the DLEP session.
	To enforce the single Layer 2 domain for DLEP Messages,		To enforce the single Layer 2 domain for DLEP Messages,
	implementations MUST adhere to the Generalized TTL Security Mechanism		implementations MUST adhere to the Generalized TTL Security Mechanism
	documented in [RFC5082] for all TCP-based DLEP Messages.		documented in [RFC5082] for all TCP-based DLEP Messages.
	In order to keep the DLEP discovery Signals, which are multicast UDP-		In order to keep the DLEP discovery Signals, which are multicast UDP-
	based, limited to the same Layer 2 domain, implementations MUST set		based, limited to the same Layer 2 domain, implementations MUST set
	the TTL of all DLEP Signals to 1, and MUST check for TTL = 1 on		the TTL of all DLEP Signals to 1, and MUST check for TTL = 1 on
	receipt of DLEP Signals. Any signal received with a TTL not equal to		receipt of DLEP Signals. Any signal received with a TTL not equal to
	1 MUST be discarded.		1 MUST be discarded.
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 9 ¶
	The router implementation then waits for a Peer Offer Signal		The router implementation then waits for a Peer Offer Signal
	(Section 10.4) response from a potential DLEP modem. While in the		(Section 10.4) response from a potential DLEP modem. While in the
	Peer Discovery state, Peer Discovery Signals MUST be sent repeatedly		Peer Discovery state, Peer Discovery Signals MUST be sent repeatedly
	by a DLEP router, at regular intervals. The interval MUST be a		by a DLEP router, at regular intervals. The interval MUST be a
	minimum of one second; it SHOULD be a configurable parameter. Note		minimum of one second; it SHOULD be a configurable parameter. Note
	that this operation (sending Peer Discovery and waiting for Peer		that this operation (sending Peer Discovery and waiting for Peer
	Offer) is outside the DLEP Transaction Model (Section 6), as the		Offer) is outside the DLEP Transaction Model (Section 6), as the
	Transaction Model only describes Messages on a TCP session.		Transaction Model only describes Messages on a TCP session.
	Routers MUST use one or more of each of the modem address/port		Routers receiving a Peer Offer Signal MUST use one of the modem
	combinations from the Peer Offer Signal or, when no Connection Point		address/port combinations from the Peer Offer Signal to establish a
	Data Items are present, from a priori configuration to establish a		TCP connection to the modem, even if a priori configuration exists.
	new TCP connection to the modem. If more than one modem address/port		If multiple connection point Data Items exist in the received Peer
	combinations is provided, router implementations MAY use their own		Offer Signal, routers MUST prioritize IPv6 connection points over
	heuristics to determine the order in which they are tried. If a TCP		IPv4 connection points. If multiple connection points exist with the
	connection cannot be achieved using any of the address/port		same transport (e.g. IPv6 or IPv4), implementations MAY use their
			own heuristics to determine the order in which they are tried. If a
			TCP connection cannot be achieved using any of the address/port
	combinations and the Discovery mechanism is in use, then the router		combinations and the Discovery mechanism is in use, then the router
	SHOULD resume issuing Peer Discovery Signals. If no Connection Point		SHOULD resume issuing Peer Discovery Signals. If no Connection Point
	Data Items are included in the Peer Offer Signal, the router MUST use		Data Items are included in the Peer Offer Signal, the router MUST use
	the source address of the UDP packet containing the Peer Offer Signal		the source address of the UDP packet containing the Peer Offer Signal
	as the IP address, and the DLEP well-known port number.		as the IP address, and the DLEP well-known port number.
	In the Peer Discovery state, the modem implementation MUST listen for		In the Peer Discovery state, the modem implementation MUST listen for
	incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or		incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or
	IPv4 link-local multicast address and port. On receipt of a valid		IPv4 link-local multicast address and port. On receipt of a valid
	Peer Discovery Signal, it MUST reply with a Peer Offer Signal.		Peer Discovery Signal, it MUST reply with a Peer Offer Signal.
	skipping to change at page 15, line 21 ¶		skipping to change at page 15, line 27 ¶
	receives a request for a destination for which there is already an		receives a request for a destination for which there is already an
	outstanding request, the implementation MUST terminate the session by		outstanding request, the implementation MUST terminate the session by
	issuing a Session Termination Message (Section 10.9) containing a		issuing a Session Termination Message (Section 10.9) containing a
	Status Data Item (Section 11.1) with status code set to 129		Status Data Item (Section 11.1) with status code set to 129
	'Unexpected Message', see Table 2, and transition to the Session		'Unexpected Message', see Table 2, and transition to the Session
	Termination state. There is no restriction to the total number of		Termination state. There is no restriction to the total number of
	Message transactions in progress at a time, as long as each		Message transactions in progress at a time, as long as each
	transaction refers to a different destination.		transaction refers to a different destination.
	It should be noted that some requests may take a considerable amount		It should be noted that some requests may take a considerable amount
	of time for some DLEP participants to complete, for example a modem		of time for some DLEP participants to complete, for example, a modem
	handling a multicast destination up request may have to perform a		handling a multicast destination up request may have to perform a
	complex network reconfiguration. A sending implementation MUST be		complex network reconfiguration. A sending implementation MUST be
	able to handle such long running transactions gracefully.		able to handle such long running transactions gracefully.
	Additionally, only one session request, e.g. a Session Initialization		Additionally, only one session request, e.g. a Session Initialization
	Message (Section 10.5), may be in progress at a time per session. As		Message (Section 10.5), may be in progress at a time per session. As
	above, a session transaction is considered complete when a response		above, a session transaction is considered complete when a response
	matching a previously issued request is received. If a DLEP		matching a previously issued request is received. If a DLEP
	participant receives a session request while there is already a		participant receives a session request while there is already a
	session request in progress, it MUST terminate the session by issuing		session request in progress, it MUST terminate the session by issuing
	skipping to change at page 20, line 10 ¶		skipping to change at page 20, line 27 ¶
	unannounced destination MUST terminate the session by issuing a		unannounced destination MUST terminate the session by issuing a
	Session Termination Message containing a Status Data Item with status		Session Termination Message containing a Status Data Item with status
	code set to 131 'Invalid Destination', and transition to the Session		code set to 131 'Invalid Destination', and transition to the Session
	Termination state.		Termination state.
	After exchanging Destination Down (Section 10.15) and Destination		After exchanging Destination Down (Section 10.15) and Destination
	Down Response (Section 10.16) Messages, no Messages concerning a		Down Response (Section 10.16) Messages, no Messages concerning a
	destination may be a sent until a new Destination Up or Destination		destination may be a sent until a new Destination Up or Destination
	Announce Message is sent. An implementation receiving a Message		Announce Message is sent. An implementation receiving a Message
	about a destination previously announced as 'down' MUST terminate the		about a destination previously announced as 'down' MUST terminate the
	session by issuing a Session Termination Message with a Status Data		session by issuing a Session Termination Message containing a Status
	Item with status code set to 131 'Invalid Destination', and		Data Item with status code set to 131 'Invalid Destination', and
	transition to the Session Termination state.		transition to the Session Termination state.
	10.2. Status code processing		10.2. Status code processing
	The behaviour of a DLEP participant receiving a Message containing a		The behaviour of a DLEP participant receiving a Message containing a
	Status Data Item (Section 11.1) is defined by the failure mode		Status Data Item (Section 11.1) is defined by the failure mode
	associated with the value of the status code field, see Table 2. All		associated with the value of the status code field, see Table 2. All
	status code values less than 100 have a failure mode of 'Continue',		status code values less than 100 have a failure mode of 'Continue',
	all other status codes have a failure mode of 'Terminate'.		all other status codes have a failure mode of 'Terminate'.
	skipping to change at page 22, line 4 ¶		skipping to change at page 22, line 23 ¶
	in the Message Header is set to 1 (see Message Type Registration		in the Message Header is set to 1 (see Message Type Registration
	(Section 13.3)).		(Section 13.3)).
	The Session Initialization Message MUST contain a Heartbeat Interval		The Session Initialization Message MUST contain a Heartbeat Interval
	Data Item (Section 11.5).		Data Item (Section 11.5).
	The Session Initialization Message MAY contain one of each of the		The Session Initialization Message MAY contain one of each of the
	following Data Items:		following Data Items:
	o Peer Type (Section 11.4)		o Peer Type (Section 11.4)
	o Extensions Supported (Section 11.6)		o Extensions Supported (Section 11.6)
			The Session Initialization Message MAY contain one or more of each of
			the following Data Items, with different values, and the data item
			Add flag set to 1:
			o IPv4 Address (Section 11.8)
			o IPv6 Address (Section 11.9)
			o IPv4 Attached Subnet (Section 11.10)
			o IPv6 Attached Subnet (Section 11.11)
	If any optional extensions are supported by the implementation, they		If any optional extensions are supported by the implementation, they
	MUST be enumerated in the Extensions Supported Data Item. If an		MUST be enumerated in the Extensions Supported Data Item. If an
	Extensions Supported Data Item does not exist in a Session		Extensions Supported Data Item does not exist in a Session
	Initialization Message, the modem MUST conclude that there is no		Initialization Message, the modem MUST conclude that there is no
	support for extensions in the router.		support for extensions in the router.
	DLEP Heartbeats are not fully established until receipt of the		DLEP Heartbeats are not fully established until receipt of the
	Session Initialization Response Message (Section 10.6), and therefore		Session Initialization Response Message (Section 10.6), and therefore
	implementations MUST use their own timeout and retry heuristics for		implementations MUST use their own timeout and retry heuristics for
	this Message.		this Message.
	As an exception to the general rule governing an implementation		As an exception to the general rule governing an implementation
	receiving an unrecognized Data Item in a Message, see Section 10.1,		receiving an unrecognized Data Item in a Message, see Section 10.1,
	if a Session Initialization Message contains one or more Extension		if a Session Initialization Message contains one or more Extension
	Supported Data Items announcing support for extensions that the		Supported Data Items announcing support for extensions that the
	implementation does not recognize, then the implementation MAY ignore		implementation does not recognize, then the implementation MAY ignore
	Data Items it does not recognize.		Data Items it does not recognize.
	10.6. Session Initialization Response Message		10.6. Session Initialization Response Message
	A Session Initialization Response Message MUST be sent in response to		A Session Initialization Response Message MUST be sent by a DLEP
	a received Session Initialization Message (Section 10.5).		modem in response to a received Session Initialization Message
			(Section 10.5).
	To construct a Session Initialization Response Message, the Message		To construct a Session Initialization Response Message, the Message
	Type value in the Message Header is set to 2 (see Message Type		Type value in the Message Header is set to 2 (see Message Type
	Registration (Section 13.3)).		Registration (Section 13.3)).
	The Session Initialization Response Message MUST contain one of each		The Session Initialization Response Message MUST contain one of each
	of the following Data Items:		of the following Data Items:
	o Status (Section 11.1)		o Status (Section 11.1)
	skipping to change at page 23, line 4 ¶		skipping to change at page 23, line 33 ¶
	o Maximum Data Rate (Receive) (Section 11.12)		o Maximum Data Rate (Receive) (Section 11.12)
	o Maximum Data Rate (Transmit) (Section 11.13)		o Maximum Data Rate (Transmit) (Section 11.13)
	o Current Data Rate (Receive) (Section 11.14)		o Current Data Rate (Receive) (Section 11.14)
	o Current Data Rate (Transmit) (Section 11.15)		o Current Data Rate (Transmit) (Section 11.15)
	o Latency (Section 11.16)		o Latency (Section 11.16)
	The Session Initialization Response Message MUST contain one of each		The Session Initialization Response Message MUST contain one of each
	of the following Data Items, if the Data Item will be used during the		of the following Data Items, if the Data Item will be used during the
	lifetime of the session:		lifetime of the session:
	o Resources (Section 11.17)		o Resources (Section 11.17)
	o Relative Link Quality (Receive) (Section 11.18)		o Relative Link Quality (Receive) (Section 11.18)
	o Relative Link Quality (Transmit) (Section 11.19)		o Relative Link Quality (Transmit) (Section 11.19)
	o Maximum Transmission Unit (MTU) (Section 11.20)		o Maximum Transmission Unit (MTU) (Section 11.20)
	The Session Initialization Response Message MAY contain one of each		The Session Initialization Response Message MUST contain an
	of the following Data Items:		Extensions Supported Data Item (Section 11.6), if DLEP extensions are
			supported.
	o Peer Type (Section 11.4)		The Session Initialization Response Message MAY contain a Peer Type
			Data Item (Section 11.4).
	o Extensions Supported (Section 11.6)		The Session Initialization Response Message MAY contain one or more
			of each of the following Data Items, with different values, and the
			data item Add flag set to 1:
			o IPv4 Address (Section 11.8)
			o IPv6 Address (Section 11.9)
			o IPv4 Attached Subnet (Section 11.10)
			o IPv6 Attached Subnet (Section 11.11)
	The Session Initialization Response Message completes the DLEP		The Session Initialization Response Message completes the DLEP
	session establishment; the modem should transition to the In-Session		session establishment; the modem should transition to the In-Session
	state when the Message is sent, and the router should transition to		state when the Message is sent, and the router should transition to
	the In-Session state upon receipt of an acceptable Session		the In-Session state upon receipt of an acceptable Session
	Initialization Response Message.		Initialization Response Message.
	All supported metric Data Items MUST be included in the Session		All supported metric Data Items MUST be included in the Session
	Initialization Response Message, with default values to be used on a		Initialization Response Message, with default values to be used on a
	session-wide basis. This can be viewed as the modem 'declaring' all		session-wide basis. This can be viewed as the modem 'declaring' all
	skipping to change at page 24, line 15 ¶		skipping to change at page 25, line 5 ¶
	10.7. Session Update Message		10.7. Session Update Message
	A Session Update Message MAY be sent by a DLEP participant to		A Session Update Message MAY be sent by a DLEP participant to
	indicate local Layer 3 address changes, or metric changes on a		indicate local Layer 3 address changes, or metric changes on a
	session-wide basis.		session-wide basis.
	To construct a Session Update Message, the Message Type value in the		To construct a Session Update Message, the Message Type value in the
	Message Header is set to 3 (see Message Type Registration		Message Header is set to 3 (see Message Type Registration
	(Section 13.3)).		(Section 13.3)).
	The Session Update Message MAY contain one of each of the following		The Session Update Message MAY contain one or more of each of the
	Data Items:		following Data Items, with different values:
			o IPv4 Address (Section 11.8)
			o IPv6 Address (Section 11.9)
			o IPv4 Attached Subnet (Section 11.10)
			o IPv6 Attached Subnet (Section 11.11)
			When sent by a modem, the Session Update Message MAY contain one of
			each of the following Data Items:
	o Maximum Data Rate (Receive) (Section 11.12)		o Maximum Data Rate (Receive) (Section 11.12)
	o Maximum Data Rate (Transmit) (Section 11.13)		o Maximum Data Rate (Transmit) (Section 11.13)
	o Current Data Rate (Receive) (Section 11.14)		o Current Data Rate (Receive) (Section 11.14)
	o Current Data Rate (Transmit) (Section 11.15)		o Current Data Rate (Transmit) (Section 11.15)
	o Latency (Section 11.16)		o Latency (Section 11.16)
	The Session Update Message MAY contain one of each of the following		When sent by a modem, the Session Update Message MAY contain one of
	Data Items, if the Data Item is in use by the session:		each of the following Data Items, if the Data Item is in use by the
			session:
	o Resources (Section 11.17)		o Resources (Section 11.17)
	o Relative Link Quality (Receive) (Section 11.18)		o Relative Link Quality (Receive) (Section 11.18)
	o Relative Link Quality (Transmit) (Section 11.19)		o Relative Link Quality (Transmit) (Section 11.19)
	o Maximum Transmission Unit (MTU) (Section 11.20)		o Maximum Transmission Unit (MTU) (Section 11.20)
	The Session Update Message MAY contain one or more of each of the
	following Data Items, with different values:
	o IPv4 Address (Section 11.8)
	o IPv6 Address (Section 11.9)
	If metrics are supplied with the Session Update Message (e.g.,		If metrics are supplied with the Session Update Message (e.g.,
	Maximum Data Rate), these metrics are considered to be session-wide,		Maximum Data Rate), these metrics are considered to be session-wide,
	and therefore MUST be applied to all destinations in the information		and therefore MUST be applied to all destinations in the information
	base associated with the DLEP session. This includes destinations		base associated with the DLEP session. This includes destinations
	for which metrics may have been stored based on received Destination		for which metrics may have been stored based on received Destination
	Update messages.		Update messages.
	It should be noted that Session Update Messages can be sent by both		It should be noted that Session Update Messages can be sent by both
	routers and modems. For example, addition of an IPv4 address to the		routers and modems. For example, addition of an IPv4 address on the
	router MAY prompt a Session Update Message to its attached modems.		router MAY prompt a Session Update Message to its attached modems.
	Also, for example, a modem that changes its Maximum Data Rate		Also, for example, a modem that changes its Maximum Data Rate
	(Receive) for all destinations MAY reflect that change via a Session		(Receive) for all destinations MAY reflect that change via a Session
	Update Message to its attached router(s).		Update Message to its attached router(s).
	Concerning Layer 3 addresses: If the modem is capable of		Concerning Layer 3 addresses and subnets: If the modem is capable of
	understanding and forwarding this information (via proprietary		understanding and forwarding this information (via mechanisms not
	mechanisms), the address update would prompt any remote DLEP modems		defined by DLEP), the update would prompt any remote DLEP-enabled
	(DLEP-enabled modems in a remote node) to issue a Destination Update		modems to issue a Destination Update Message (Section 10.17) to their
	Message (Section 10.17) to their local routers with the new (or		local routers with the new (or deleted) addresses and subnets.
	deleted) addresses. Modems that do not track Layer 3 addresses
	SHOULD silently ignore Address Data Items.
	10.8. Session Update Response Message		10.8. Session Update Response Message
	A Session Update Response Message MUST be sent by a DLEP participant		A Session Update Response Message MUST be sent by a DLEP participant
	when a Session Update Message (Section 10.7) is received.		when a Session Update Message (Section 10.7) is received.
	To construct a Session Update Response Message, the Message Type		To construct a Session Update Response Message, the Message Type
	value in the Message Header is set to 4 (see Message Type		value in the Message Header is set to 4 (see Message Type
	Registration (Section 13.3)).		Registration (Section 13.3)).
	skipping to change at page 36, line 19 ¶		skipping to change at page 37, line 19 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Code | Text... :		| Code | Text... :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Data Item Type: 1		Data Item Type: 1
	Length: 1 + Length of text, in octets		Length: 1 + Length of text, in octets
	Status Code: One of the codes defined in Table 2 below.		Status Code: One of the codes defined in Table 2 below.
	Text: UTF-8 encoded string of UNICODE [UNIV8] characters, describing		Text: UTF-8 encoded string of UNICODE [RFC3629] characters,
	the cause, used for implementation defined purposes. Since this		describing the cause, used for implementation defined purposes.
	field is used for description, implementations SHOULD limit		Since this field is used for description, implementations SHOULD
	characters in this field to printable characters. Implementations		limit characters in this field to printable characters.
	receiving this Data Item SHOULD check for printable characters in		Implementations receiving this Data Item SHOULD check for
	the field.		printable characters in the field.
	An implementation MUST NOT assume the Text field is NUL-terminated.		An implementation MUST NOT assume the Text field is NUL-terminated.
	+----------+-------------+------------------+-----------------------+		+----------+-------------+------------------+-----------------------+
	| Status | Failure | Description | Reason |		| Status | Failure | Description | Reason |
	| Code | Mode | | |		| Code | Mode | | |
	+----------+-------------+------------------+-----------------------+		+----------+-------------+------------------+-----------------------+
	| 0 | Continue | Success | The Message was |		| 0 | Continue | Success | The Message was |
	| | | | processed |		| | | | processed |
	| | | | successfully. |		| | | | successfully. |
	skipping to change at page 36, line 47 ¶		skipping to change at page 37, line 47 ¶
	| | | | Message subject, e.g. |		| | | | Message subject, e.g. |
	| | | | in a Destination Up |		| | | | in a Destination Up |
	| | | | Response Message |		| | | | Response Message |
	| | | | (Section 10.12) to |		| | | | (Section 10.12) to |
	| | | | indicate no further |		| | | | indicate no further |
	| | | | Messages about the |		| | | | Messages about the |
	| | | | destination. |		| | | | destination. |
	| 2 | Continue | Request Denied | The receiver refuses |		| 2 | Continue | Request Denied | The receiver refuses |
	| | | | to complete the |		| | | | to complete the |
	| | | | request. |		| | | | request. |
	| 3-111 | Continue | <Reserved> | Reserved for future |		| 3 | Continue | Inconsistent | One or more Data |
			| | | Data | Items in the Message |
			| | | | describe a logically |
			| | | | inconsistent state in |
			| | | | the network. For |
			| | | | example, in the |
			| | | | Destination Up |
			| | | | Message (Section |
			| | | | 10.11) when an |
			| | | | announced subnet |
			| | | | clashes with an |
			| | | | existing destination |
			| | | | subnet. |
			| 4-111 | Continue | <Reserved> | Reserved for future |
	| | | | extensions. |		| | | | extensions. |
	| 112-127 | Continue | <Private Use> | Available for |		| 112-127 | Continue | <Private Use> | Available for |
	| | | | experiments. |		| | | | experiments. |
	| 128 | Terminate | Unknown Message | The Message was not |		| 128 | Terminate | Unknown Message | The Message was not |
	| | | | recognized by the |		| | | | recognized by the |
	| | | | implementation. |		| | | | implementation. |
	| 129 | Terminate | Unexpected | The Message was not |		| 129 | Terminate | Unexpected | The Message was not |
	| | | Message | expected while the |		| | | Message | expected while the |
	| | | | device was in the |		| | | | device was in the |
	| | | | current state, e.g., |		| | | | current state, e.g., |
	skipping to change at page 38, line 28 ¶		skipping to change at page 39, line 38 ¶
	Flags: Flags field, defined below.		Flags: Flags field, defined below.
	IPv4 Address: The IPv4 address listening on the modem.		IPv4 Address: The IPv4 address listening on the modem.
	TCP Port Number: TCP Port number on the modem.		TCP Port Number: TCP Port number on the modem.
	If the Length field is 7, the port number specified MUST be used to		If the Length field is 7, the port number specified MUST be used to
	establish the TCP session. If the TCP Port Number is omitted, i.e.		establish the TCP session. If the TCP Port Number is omitted, i.e.
	the Length field is 5, the router MUST use the DLEP well-known port		the Length field is 5, the router MUST use the DLEP well-known port
	number (Section 13.7) to establish the TCP connection.		number (Section 13.13) to establish the TCP connection.
	The Flags field is defined as:		The Flags field is defined as:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Reserved |		| Reserved |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Reserved: MUST be zero. Reserved for future use.		Reserved: MUST be zero. Reserved for future use.
	skipping to change at page 39, line 34 ¶		skipping to change at page 40, line 43 ¶
	Flags: Flags field, defined below.		Flags: Flags field, defined below.
	IPv6 Address: The IPv6 address listening on the modem.		IPv6 Address: The IPv6 address listening on the modem.
	TCP Port Number: TCP Port number on the modem.		TCP Port Number: TCP Port number on the modem.
	If the Length field is 19, the port number specified MUST be used to		If the Length field is 19, the port number specified MUST be used to
	establish the TCP session. If the TCP Port Number is omitted, i.e.		establish the TCP session. If the TCP Port Number is omitted, i.e.
	the Length field is 17, the router MUST use the DLEP well-known port		the Length field is 17, the router MUST use the DLEP well-known port
	number (Section 13.7) to establish the TCP connection.		number (Section 13.13) to establish the TCP connection.
	The Flags field is defined as:		The Flags field is defined as:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Reserved |		| Reserved |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Reserved: MUST be zero. Reserved for future use.		Reserved: MUST be zero. Reserved for future use.
	skipping to change at page 40, line 19 ¶		skipping to change at page 41, line 26 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Data Item Type | Length |		| Data Item Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer Type... :		| Peer Type... :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Data Item Type: 4		Data Item Type: 4
	Length: Length of Peer Type string, in octets.		Length: Length of Peer Type string, in octets.
	Peer Type: UTF-8 encoded string of UNICODE [UNIV8] characters. For		Peer Type: UTF-8 encoded string of UNICODE [RFC3629] characters.
	example, a satellite modem might set this variable to "Satellite		For example, a satellite modem might set this variable to
	terminal". Since this Data Item is intended to provide additional		"Satellite terminal". Since this Data Item is intended to provide
	information for display commands, sending implementations SHOULD		additional information for display commands, sending
	limit the data to printable characters, and receiving		implementations SHOULD limit the data to printable characters, and
	implementations SHOULD check the data for printable characters.		receiving implementations SHOULD check the data for printable
			characters.
	An implementation MUST NOT assume the Peer Type field is NUL-		An implementation MUST NOT assume the Peer Type field is NUL-
	terminated.		terminated.
	11.5. Heartbeat Interval		11.5. Heartbeat Interval
	The Heartbeat Interval Data Item is used to specify a period in		The Heartbeat Interval Data Item is used to specify a period in
	milliseconds for Heartbeat Messages (Section 10.20).		milliseconds for Heartbeat Messages (Section 10.20).
	The Heartbeat Interval Data Item contains the following fields:		The Heartbeat Interval Data Item contains the following fields:
	skipping to change at page 41, line 21 ¶		skipping to change at page 42, line 26 ¶
	Each Extension Type definition includes which additional Signals and		Each Extension Type definition includes which additional Signals and
	Data Items are supported.		Data Items are supported.
	The Extensions Supported Data Item contains the following fields:		The Extensions Supported Data Item contains the following fields:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Data Item Type | Length |		| Data Item Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Extensions List...		| Extensions List... :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Data Item Type: 6		Data Item Type: 6
	Length: Length of the extensions list in octets. This is twice (2x)		Length: Length of the extensions list in octets. This is twice (2x)
	the number of extensions.		the number of extensions.
	Extension List: A list of extensions supported, identified by their		Extension List: A list of extensions supported, identified by their
	2-octet value as listed in the extensions registry.		2-octet value as listed in the extensions registry.
	skipping to change at page 42, line 25 ¶		skipping to change at page 43, line 25 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Data Item Type: 7		Data Item Type: 7
	Length: 6 for EUI-48 format, or 8 for EUI-64 format		Length: 6 for EUI-48 format, or 8 for EUI-64 format
	MAC Address: MAC Address of the destination.		MAC Address: MAC Address of the destination.
	11.8. IPv4 Address		11.8. IPv4 Address
	When included in Destination Messages, this Data Item contains the		When included in the Session Update Message, this Data Item contains
	IPv4 address of the destination. When included in the Session Update		the IPv4 address of the peer. When included in Destination Messages,
	Message, this Data Item contains the IPv4 address of the peer. In		this Data Item contains the IPv4 address of the destination. In
	either case, the Data Item also contains an indication of whether		either case, the Data Item also contains an indication of whether
	this is a new or existing address, or is a deletion of a previously		this is a new or existing address, or is a deletion of a previously
	known address.		known address.
	The IPv4 Address Data Item contains the following fields:		The IPv4 Address Data Item contains the following fields:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Data Item Type | Length |		| Data Item Type | Length |
	skipping to change at page 43, line 15 ¶		skipping to change at page 44, line 15 ¶
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Reserved |A|		| Reserved |A|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	A: Add/Drop flag, indicating whether this is a new or existing		A: Add/Drop flag, indicating whether this is a new or existing
	address (1), or a withdrawal of an address (0).		address (1), or a withdrawal of an address (0).
	Reserved: MUST be zero. Reserved for future use.		Reserved: MUST be zero. Reserved for future use.
			11.8.1. IPv4 Address Processing
			Processing of the IPv4 Address Data Item MUST be done within the
			context of the DLEP Peer session on which it is presented.
			The handling of erroneous or logically inconsistent conditions
			depends upon the type of the message that contains the data item:
			If the containing message is a Session Message, e.g., Session
			Initialization Message (Section 10.5), or Session Update Message
			(Section 10.7), the receiver of inconsistent information MUST issue a
			Session Termination Message (Section 10.9) containing a Status Data
			Item (Section 11.1) with status code set to 130 'Invalid Data', and
			transition to the Session Termination state. Examples of such
			conditions are:
			o An address Drop operation referencing an address that is not
			associated with the peer in the current session.
			o An address Add operation referencing an address that has already
			been added to the peer in the current session.
			If the containing message is a Destination Message, e.g., Destination
			Up Message (Section 10.11), or Destination Update Message
			(Section 10.17), the receiver of inconsistent information MAY issue
			the appropriate response message containing a Status Data Item, with
			status code set to 3 'Inconsistent Data', but MUST continue with
			session processing. Examples of such conditions are:
			o An address Add operation referencing an address that has already
			been added to the destination in the current session.
			o An address Add operation referencing an address that is associated
			with a different destination or the peer in the current session
			o An address Drop operation referencing an address that is not
			associated with the destination in the current session.
			If no response message is appropriate, for example, the Destination
			Update Message, then the implementation MUST continue with session
			processing.
			Modems that do not track IPv4 addresses MUST silently ignore IPv4
			Address Data Items.
	11.9. IPv6 Address		11.9. IPv6 Address
	When included in Destination Messages, this Data Item contains the		When included in the Session Update Message, this Data Item contains
	IPv6 address of the destination. When included in the Session Update		the IPv6 address of the peer. When included in Destination Messages,
	Message, this Data Item contains the IPv6 address of the peer. In		this Data Item contains the IPv6 address of the destination. In
	either case, the Data Item also contains an indication of whether		either case, the Data Item also contains an indication of whether
	this is a new or existing address, or is a deletion of a previously		this is a new or existing address, or is a deletion of a previously
	known address.		known address.
	The IPv6 Address Data Item contains the following fields:		The IPv6 Address Data Item contains the following fields:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Data Item Type | Length |		| Data Item Type | Length |
	skipping to change at page 44, line 9 ¶		skipping to change at page 46, line 4 ¶
	Flags: Flags field, defined below.		Flags: Flags field, defined below.
	IPv6 Address: IPv6 Address of the destination or peer.		IPv6 Address: IPv6 Address of the destination or peer.
	The Flags field is defined as:		The Flags field is defined as:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Reserved |A|		| Reserved |A|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	A: Add/Drop flag, indicating whether this is a new or existing		A: Add/Drop flag, indicating whether this is a new or existing
	address (1), or a withdrawal of an address (0).		address (1), or a withdrawal of an address (0).
	Reserved: MUST be zero. Reserved for future use.		Reserved: MUST be zero. Reserved for future use.
			11.9.1. IPv6 Address Processing
			Processing of the IPv6 Address Data Item MUST be done within the
			context of the DLEP Peer session on which it is presented.
			The handling of erroneous or logically inconsistent conditions
			depends upon the type of the message that contains the data item:
			If the containing message is a Session Message, e.g., Session
			Initialization Message (Section 10.5), or Session Update Message
			(Section 10.7), the receiver of inconsistent information MUST issue a
			Session Termination Message (Section 10.9) containing a Status Data
			Item (Section 11.1) with status code set to 130 'Invalid Data', and
			transition to the Session Termination state. Examples of such
			conditions are:
			o An address Drop operation referencing an address that is not
			associated with the peer in the current session.
			o An address Add operation referencing an address that has already
			been added to the peer in the current session.
			If the containing message is a Destination Message, e.g., Destination
			Up Message (Section 10.11), or Destination Update Message
			(Section 10.17), the receiver of inconsistent information MAY issue
			the appropriate response message containing a Status Data Item, with
			status code set to 3 'Inconsistent Data', but MUST continue with
			session processing. Examples of such conditions are:
			o An address Add operation referencing an address that has already
			been added to the destination in the current session.
			o An address Add operation referencing an address that is associated
			with a different destination or the peer in the current session
			o An address Drop operation referencing an address that is not
			associated with the destination in the current session.
			If no response message is appropriate, for example, the Destination
			Update Message, then the implementation MUST continue with session
			processing.
			Modems that do not track IPv6 addresses MUST silently ignore IPv6
			Address Data Items.
	11.10. IPv4 Attached Subnet		11.10. IPv4 Attached Subnet
	The DLEP IPv4 Attached Subnet allows a device to declare that it has		The DLEP IPv4 Attached Subnet allows a device to declare that it has
	an IPv4 subnet (e.g., a stub network) attached, that it has become		an IPv4 subnet (e.g., a stub network) attached, that it has become
	aware of an IPv4 subnet being present at a remote destination, or		aware of an IPv4 subnet being present at a remote destination, or
	that it has become aware of the loss of a subnet at the remote		that it has become aware of the loss of a subnet at the remote
	destination.		destination.
	The DLEP IPv4 Attached Subnet Data Item contains the following		The DLEP IPv4 Attached Subnet Data Item contains the following
	fields:		fields:
	skipping to change at page 45, line 15 ¶		skipping to change at page 48, line 5 ¶
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Reserved |A|		| Reserved |A|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	A: Add/Drop flag, indicating whether this is a new or existing subnet		A: Add/Drop flag, indicating whether this is a new or existing subnet
	address (1), or a withdrawal of a subnet address (0).		address (1), or a withdrawal of a subnet address (0).
	Reserved: MUST be zero. Reserved for future use.		Reserved: MUST be zero. Reserved for future use.
			11.10.1. IPv4 Attached Subnet Processing
			Processing of the IPv4 Attached Subnet Data Item MUST be done within
			the context of the DLEP Peer session on which it is presented.
			If the containing message is a Session Message, e.g., Session
			Initialization Message (Section 10.5), or Session Update Message
			(Section 10.7), the receiver of inconsistent information MUST issue a
			Session Termination Message (Section 10.9) containing a Status Data
			Item (Section 11.1) with status code set to 130 'Invalid Data', and
			transition to the Session Termination state. Examples of such
			conditions are:
			o A subnet Drop operation referencing a subnet that is not
			associated with the peer in the current session.
			o A subnet Add operation referencing a subnet that has already been
			added to the peer in the current session.
			If the containing message is a Destination Message, e.g., Destination
			Up Message (Section 10.11), or Destination Update Message
			(Section 10.17), the receiver of inconsistent information MAY issue
			the appropriate response message containing a Status Data Item, with
			status code set to 3 'Inconsistent Data', but MUST continue with
			session processing. Examples of such conditions are:
			o A subnet Add operation referencing a subnet that has already been
			added to the destination in the current session.
			o A subnet Add operation referencing a subnet that is associated
			with a different destination in the current session.
			o A subnet Drop operation referencing a subnet that is not
			associated with the destination in the current session.
			If no response message is appropriate, for example, the Destination
			Update Message, then the implementation MUST continue with session
			processing.
			Modems that do not track IPv4 subnets MUST silently ignore IPv4
			Attached Subnet Data Items.
	11.11. IPv6 Attached Subnet		11.11. IPv6 Attached Subnet
	The DLEP IPv6 Attached Subnet allows a device to declare that it has		The DLEP IPv6 Attached Subnet allows a device to declare that it has
	an IPv6 subnet (e.g., a stub network) attached, that it has become		an IPv6 subnet (e.g., a stub network) attached, that it has become
	aware of an IPv6 subnet being present at a remote destination, or		aware of an IPv6 subnet being present at a remote destination, or
	that it has become aware of the loss of a subnet at the remote		that it has become aware of the loss of a subnet at the remote
	destination.		destination.
	The DLEP IPv6 Attached Subnet Data Item contains the following		The DLEP IPv6 Attached Subnet Data Item contains the following
	fields:		fields:
	skipping to change at page 46, line 17 ¶		skipping to change at page 50, line 5 ¶
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Reserved |A|		| Reserved |A|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	A: Add/Drop flag, indicating whether this is a new or existing subnet		A: Add/Drop flag, indicating whether this is a new or existing subnet
	address (1), or a withdrawal of a subnet address (0).		address (1), or a withdrawal of a subnet address (0).
	Reserved: MUST be zero. Reserved for future use.		Reserved: MUST be zero. Reserved for future use.
			11.11.1. IPv6 Attached Subnet Processing
			Processing of the IPv6 Attached Subnet Data Item MUST be done within
			the context of the DLEP Peer session on which it is presented.
			If the containing message is a Session Message, e.g., Session
			Initialization Message (Section 10.5), or Session Update Message
			(Section 10.7), the receiver of inconsistent information MUST issue a
			Session Termination Message (Section 10.9) containing a Status Data
			Item (Section 11.1) with status code set to 130 'Invalid Data', and
			transition to the Session Termination state. Examples of such
			conditions are:
			o A subnet Drop operation referencing a subnet that is not
			associated with the peer in the current session.
			o A subnet Add operation referencing a subnet that has already been
			added to the peer in the current session.
			If the containing message is a Destination Message, e.g., Destination
			Up Message (Section 10.11), or Destination Update Message
			(Section 10.17), the receiver of inconsistent information MAY issue
			the appropriate response message containing a Status Data Item, with
			status code set to 3 'Inconsistent Data', but MUST continue with
			session processing. Examples of such conditions are:
			o A subnet Add operation referencing a subnet that has already been
			added to the destination in the current session.
			o A subnet Add operation referencing a subnet that is associated
			with a different destination in the current session.
			o A subnet Drop operation referencing a subnet that is not
			associated with the destination in the current session.
			If no response message is appropriate, for example, the Destination
			Update Message, then the implementation MUST continue with session
			processing.
			Modems that do not track IPv6 subnets MUST silently ignore IPv4
			Attached Subnet Data Items.
	11.12. Maximum Data Rate (Receive)		11.12. Maximum Data Rate (Receive)
	The Maximum Data Rate (Receive) (MDRR) Data Item is used to indicate		The Maximum Data Rate (Receive) (MDRR) Data Item is used to indicate
	the maximum theoretical data rate, in bits per second, that can be		the maximum theoretical data rate, in bits per second, that can be
	achieved while receiving data on the link.		achieved while receiving data on the link.
	The Maximum Data Rate (Receive) Data Item contains the following		The Maximum Data Rate (Receive) Data Item contains the following
	fields:		fields:
	0 1 2 3		0 1 2 3
	skipping to change at page 53, line 17 ¶		skipping to change at page 57, line 38 ¶
	information base of hosts that persistently fail Session		information base of hosts that persistently fail Session
	Initialization having provided an acceptable Peer Discovery Signal,		Initialization having provided an acceptable Peer Discovery Signal,
	and ignore subsequent Peer Discovery Signals from such hosts.		and ignore subsequent Peer Discovery Signals from such hosts.
	This specification does not address security of the data plane, as it		This specification does not address security of the data plane, as it
	(the data plane) is not affected, and standard security procedures		(the data plane) is not affected, and standard security procedures
	can be employed.		can be employed.
	13. IANA Considerations		13. IANA Considerations
	This section specifies requests to IANA.
	13.1. Registrations		13.1. Registrations
	Upon approval of this document, IANA is requested to create a new		Upon approval of this document, IANA is requested to create a new
	protocol registry for Dynamic Link Exchange Protocol (DLEP). The		protocol registry for Dynamic Link Exchange Protocol (DLEP). The
	remainder of this section requests the creation of new DLEP specific		remainder of this section requests the creation of new DLEP specific
	registries.		registries.
	13.2. Signal Type Registration		13.2. Signal Type Registration
	Upon approval of this document, IANA is requested to create a new		Upon approval of this document, IANA is requested to create a new
	skipping to change at page 56, line 11 ¶		skipping to change at page 60, line 11 ¶
	The following table provides initial registry values and the		The following table provides initial registry values and the
	[RFC5226] defined policies that should apply to the registry:		[RFC5226] defined policies that should apply to the registry:
	+--------------+---------------+-------------------------+		+--------------+---------------+-------------------------+
	| Status Code | Failure Mode | Description/Policy |		| Status Code | Failure Mode | Description/Policy |
	+--------------+---------------+-------------------------+		+--------------+---------------+-------------------------+
	| 0 | Continue | Success |		| 0 | Continue | Success |
	| 1 | Continue | Not Interested |		| 1 | Continue | Not Interested |
	| 2 | Continue | Request Denied |		| 2 | Continue | Request Denied |
	| 3-111 | Continue | Specification Required |		| 3 | Continue | Inconsistent Data |
			| 4-111 | Continue | Specification Required |
	| 112-127 | Continue | Private Use |		| 112-127 | Continue | Private Use |
	| 128 | Terminate | Unknown Message |		| 128 | Terminate | Unknown Message |
	| 129 | Terminate | Unexpected Message |		| 129 | Terminate | Unexpected Message |
	| 130 | Terminate | Invalid Data |		| 130 | Terminate | Invalid Data |
	| 131 | Terminate | Invalid Destination |		| 131 | Terminate | Invalid Destination |
	| 132 | Terminate | Timed Out |		| 132 | Terminate | Timed Out |
	| 133-239 | Terminate | Specification Required |		| 133-239 | Terminate | Specification Required |
	| 240-254 | Terminate | Private Use |		| 240-254 | Terminate | Private Use |
	| 255 | Terminate | Reserved |		| 255 | Terminate | Reserved |
	+--------------+---------------+-------------------------+		+--------------+---------------+-------------------------+
	skipping to change at page 56, line 43 ¶		skipping to change at page 60, line 44 ¶
	+--------------+----------------------------+		+--------------+----------------------------+
	| 0 | Reserved |		| 0 | Reserved |
	| 1 | Credit Windowing [CREDIT] |		| 1 | Credit Windowing [CREDIT] |
	| 2-65519 | Specification Required |		| 2-65519 | Specification Required |
	| 65520-65534 | Private Use |		| 65520-65534 | Private Use |
	| 65535 | Reserved |		| 65535 | Reserved |
	+--------------+----------------------------+		+--------------+----------------------------+
	Table 3: DLEP Extension types		Table 3: DLEP Extension types
	13.7. DLEP Well-known Port		13.7. DLEP IPv4 Connection Point Flags
			Upon approval of this document, IANA is requested to create a new
			DLEP registry, named "IPv4 Connection Point Flags".
			The following table provides initial registry values and the
			[RFC5226] defined policies that should apply to the registry:
			+------------+----------------------------------+
			| Bit | Description/Policy |
			+------------+----------------------------------+
			| 0-7 | Reserved/Specification Required |
			+------------+----------------------------------+
			13.8. DLEP IPv6 Connection Point Flags
			Upon approval of this document, IANA is requested to create a new
			DLEP registry, named "IPv6 Connection Point Flags".
			The following table provides initial registry values and the
			[RFC5226] defined policies that should apply to the registry:
			+------------+----------------------------------+
			| Bit | Description/Policy |
			+------------+----------------------------------+
			| 0-7 | Reserved/Specification Required |
			+------------+----------------------------------+
			13.9. DLEP IPv4 Address Flag
			Upon approval of this document, IANA is requested to create a new
			DLEP registry, named "IPv4 Address Flags".
			The following table provides initial registry values and the
			[RFC5226] defined policies that should apply to the registry:
			+------------+----------------------------------+
			| Bit | Description/Policy |
			+------------+----------------------------------+
			| 0-6 | Reserved/Specification Required |
			| 7 | Add/Drop indicator |
			+------------+----------------------------------+
			13.10. DLEP IPv6 Address Flag
			Upon approval of this document, IANA is requested to create a new
			DLEP registry, named "IPv6 Address Flags".
			The following table provides initial registry values and the
			[RFC5226] defined policies that should apply to the registry:
			+------------+----------------------------------+
			| Bit | Description/Policy |
			+------------+----------------------------------+
			| 0-6 | Reserved/Specification Required |
			| 7 | Add/Drop indicator |
			+------------+----------------------------------+
			13.11. DLEP IPv4 Attached Subnet Flag
			Upon approval of this document, IANA is requested to create a new
			DLEP registry, named "IPv4 Attached Subnet Flags".
			The following table provides initial registry values and the
			[RFC5226] defined policies that should apply to the registry:
			+------------+----------------------------------+
			| Bit | Description/Policy |
			+------------+----------------------------------+
			| 0-6 | Reserved/Specification Required |
			| 7 | Add/Drop indicator |
			+------------+----------------------------------+
			13.12. DLEP IPv6 Attached Subnet Flag
			Upon approval of this document, IANA is requested to create a new
			DLEP registry, named "IPv6 Attached Subnet Flags".
			The following table provides initial registry values and the
			[RFC5226] defined policies that should apply to the registry:
			+------------+----------------------------------+
			| Bit | Description/Policy |
			+------------+----------------------------------+
			| 0-6 | Reserved/Specification Required |
			| 7 | Add/Drop indicator |
			+------------+----------------------------------+
			13.13. DLEP Well-known Port
	Upon approval of this document, IANA is requested to assign a single		Upon approval of this document, IANA is requested to assign a single
	value in the "Service Name and Transport Protocol Port Number		value in the "Service Name and Transport Protocol Port Number
	Registry" found at https://www.iana.org/assignments/service-names-		Registry" found at https://www.iana.org/assignments/service-names-
	port-numbers/service-names-port-numbers.xhtml for use by "DLEP", as		port-numbers/service-names-port-numbers.xhtml for use by "DLEP", as
	defined in this document. This assignment should be valid for TCP		defined in this document. This assignment should be valid for TCP
	and UDP.		and UDP.
	13.8. DLEP IPv4 Link-local Multicast Address		13.14. DLEP IPv4 Link-local Multicast Address
	Upon approval of this document, IANA is requested to assign an IPv4		Upon approval of this document, IANA is requested to assign an IPv4
	multicast address registry found at http://www.iana.org/assignments/		multicast address registry found at http://www.iana.org/assignments/
	multicast-addresses for use as the "IPv4 DLEP Discovery Address".		multicast-addresses for use as the "IPv4 DLEP Discovery Address".
	13.9. DLEP IPv6 Link-local Multicast Address		13.15. DLEP IPv6 Link-local Multicast Address
	Upon approval of this document, IANA is requested to assign an IPv6		Upon approval of this document, IANA is requested to assign an IPv6
	multicast address registry found at http://www.iana.org/assignments/		multicast address registry found at http://www.iana.org/assignments/
	multicast-addresses for use as the "IPv6 DLEP Discovery Address".		multicast-addresses for use as the "IPv6 DLEP Discovery Address".
	14. Acknowledgements		14. Acknowledgements
	We would like to acknowledge and thank the members of the DLEP design		We would like to acknowledge and thank the members of the DLEP design
	team, who have provided invaluable insight. The members of the		team, who have provided invaluable insight. The members of the
	design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning		design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning
	skipping to change at page 57, line 37 ¶		skipping to change at page 63, line 37 ¶
	15. References		15. References
	15.1. Normative References		15.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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
			[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
			10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
			2003, <http://www.rfc-editor.org/info/rfc3629>.
	[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.		[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
	Pignataro, "The Generalized TTL Security Mechanism		Pignataro, "The Generalized TTL Security Mechanism
	(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,		(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
	<http://www.rfc-editor.org/info/rfc5082>.		<http://www.rfc-editor.org/info/rfc5082>.
	[UNIV8] "The Unicode Consortium. The Unicode Standard, Version
	8.0.0, (Mountain View, CA: The Unicode Consortium, 2015.
	ISBN 978-1-936213-10-8)",
	http://www.unicode.org/versions/Unicode8.0.0/, June 2015.
	15.2. Informative References		15.2. Informative References
	[CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", IETF		[CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", IETF
	draft draft-ietf-manet-credit-window-04, March 2016.		draft draft-ietf-manet-credit-window-04, March 2016.
	[IEEE-802.1AE]		[IEEE-802.1AE]
	"IEEE Standards for Local and Metropolitan Area Networks:		"IEEE Standards for Local and Metropolitan Area Networks:
	Media Access Control (MAC) Security",		Media Access Control (MAC) Security",
	DOI 10.1109/IEEESTD.2006.245590, August 2006.		DOI 10.1109/IEEESTD.2006.245590, August 2006.
End of changes. 50 change blocks.
	144 lines changed or deleted		462 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/