draft-ietf-dhc-dhcpv6-agentopt-delegate-04.txt		draft-ietf-dhc-dhcpv6-agentopt-delegate-05.txt
	dhc Group R. Droms		Network Working Group R. Droms
	Internet-Draft B. Volz		Internet-Draft
	Intended status: Standards Track O. Troan		Intended status: Standards Track B. Volz
	Expires: January 14, 2010 Cisco Systems, Inc.		Expires: October 3, 2017 Cisco Systems
	July 13, 2009		O. Troan
			Cisco Systems, Inc.
			April 1, 2017
	DHCPv6 Relay Agent Assignment Notification (RAAN) Option		DHCPv6 Relay Agent Assignment Notification (RAAN) Option
	draft-ietf-dhc-dhcpv6-agentopt-delegate-04.txt		draft-ietf-dhc-dhcpv6-agentopt-delegate-05.txt
	Status of this Memo		Abstract
	This Internet-Draft is submitted to IETF in full conformance with the		The DHCP Relay Agent Assignment Notification (RAAN) option is sent
	provisions of BCP 78 and BCP 79. This document may contain material		from a DHCP server to a DHCP relay agent to inform the relay agent of
	from IETF Documents or IETF Contributions published or made publicly		IPv6 addresses that have been assigned or IPv6 prefixes that have
	available before November 10, 2008. The person(s) controlling the		been delegated to DHCP clients.
	copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Status of This Memo
	IETF Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this		This Internet-Draft is submitted in full conformance with the
	document may not be modified outside the IETF Standards Process, and		provisions of BCP 78 and BCP 79.
	derivative works of it may not be created outside the IETF Standards
	Process, except to format it for publication as an RFC or to
	translate it into languages other than English.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on October 3, 2017.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 14, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2017 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
			include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
			described in the Simplified BSD License.
	Abstract		Table of Contents
	The DHCP Relay Agent Assignment Notification (RAAN) option is sent		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	from a DHCP server to a DHCP relay agent to inform the relay agent of		2. Requirements Language and Terminology . . . . . . . . . . . . 3
	IPv6 addresses that have been assigned or IPv6 prefixes that have		3. Option Semantics and Usage . . . . . . . . . . . . . . . . . 3
	been delegated to DHCP clients.		4. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 4
			5. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 4
			6. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 4
			7. Encapsulating DHCP Options in the RAAN Option . . . . . . . . 5
			7.1. IA Address Option . . . . . . . . . . . . . . . . . . . . 5
			7.2. IA Prefix Option . . . . . . . . . . . . . . . . . . . . 6
			8. Requesting Assignment Information from the DHCP Server . . . 6
			9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
			10. Security Considerations . . . . . . . . . . . . . . . . . . . 6
			11. Changes Log . . . . . . . . . . . . . . . . . . . . . . . . . 7
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
			12.1. Normative References . . . . . . . . . . . . . . . . . . 8
			12.2. Informative References . . . . . . . . . . . . . . . . . 8
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The DHCP Relay Agent Assignment Notification (RAAN) option		The DHCP Relay Agent Assignment Notification (RAAN) option
	encapsulates address and prefix options to indicate that an address		encapsulates address and prefix options to indicate that an address
	or prefix has been assigned. The option may also carry other		or prefix has been assigned. The option may also carry other
	information required by the network element for configuration related		information required by the network element for configuration related
	to the assigned address or prefix.		to the assigned address or prefix.
	For example, a network administrator uses the RAAN option to inform a		For example, a relay agent uses the RAAN option to learn when a
	relay agent of a prefix that has been delegated through DHCP PD to a		prefix that has been delegated through DHCP prefix delegation (PD) to
	DHCP client. The relay agent notifies the network element on which		a DHCP client. The relay agent notifies the network element on which
	it is implemented of the delegation information so the network		it is implemented of the delegation information so the network
	element can add routing information about the delegated prefix into		element can add routing information about the delegated prefix into
	the routing infrastructure.		the routing infrastructure.
	2. Terminology		While the practice to date for DHCPv6 has been for the relay agents
			to "snoop" the client's message (encapsulated in the received Relay
			Message option, and which is forwarded to the client), this will no
			longer be possible when clients and servers use
			[I-D.ietf-dhc-sedhcpv6] to encrypt their communication.
	The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,		Use of the RAAN option has another benefit in that the Reply to a
	SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be		client's Release message, which does not have any useful information
	interpreted as described in RFC 2119 [RFC2119].		for the relay agent about the addresses or delegated prefixes the
			client released, can now communicate this information in the RAAN
			option to the relay agent.
			2. Requirements Language and Terminology
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119] when they
			appear in ALL CAPS. When these words are not in ALL CAPS (such as
			"should" or "Should"), they have their usual English meanings, and
			are not to be interpreted as [RFC2119] key words.
	The term "DHCP" in this document refers to DHCP for IPv6, as defined		The term "DHCP" in this document refers to DHCP for IPv6, as defined
	in RFC 3315 [RFC3315]. The terms "DHCP prefix delegation" and "DHCP		in [RFC3315]. The terms "DHCP prefix delegation" and "DHCP PD" refer
	PD" refer DHCP for IPv6 prefix delegation, as defined in RFC 3633		DHCP for IPv6 prefix delegation, as defined in [RFC3633].
	[RFC3633]
	Additional terms used in the description of DHCP and DHCP prefix		Additional terms used in the description of DHCP and DHCP prefix
	delegation are defined in RFC 3315 and RFC 3633. In this document		delegation are defined in RFC 3315 and RFC 3633. In this document
	"assigning" an IPv6 prefix is equivalent to "delegating" a prefix.		"assigning" an IPv6 prefix is equivalent to "delegating" a prefix.
	3. Option Semantics and Usage		3. Option Semantics and Usage
	The RAAN option carries information about assigned IPv6 addresses and		The RAAN option carries information about assigned IPv6 addresses and
	prefixes. It encapsulates IA Address options (RFC 3315) and/or IA		prefixes. It encapsulates IA Address options (RFC 3315) and/or IA
	Prefix options (RFC 3633), and possibly other options that carry		Prefix options (RFC 3633), and possibly other options that carry
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 46 ¶
	and a valid lifetime of zero.		and a valid lifetime of zero.
	When a DHCP server sends this option to a relay agent, it MUST		When a DHCP server sends this option to a relay agent, it MUST
	include all addresses and prefixes assigned to the client on the link		include all addresses and prefixes assigned to the client on the link
	to which the option refers at the time the option is sent.		to which the option refers at the time the option is sent.
	Examples of use:		Examples of use:
	o Populate an ACL with an assigned IPv6 address if the network		o Populate an ACL with an assigned IPv6 address if the network
	security policy requires limiting IPv6 forwarding to devices that		security policy requires limiting IPv6 forwarding to devices that
	have obtained an address through DHCP		have obtained an address through DHCP.
	o Inject routing information into a routing infrastructure about a		o Inject routing information into a routing infrastructure about a
	delegated prefix on behalf of a requesting router		delegated prefix on behalf of a requesting router.
	4. Relay Agent Behavior		4. Relay Agent Behavior
	A relay agent that wants information from the server in a RAAN option		A relay agent that wants information from the server in a RAAN option
	includes an ORO requesting the RAAN option in its Relay-Forw message.		includes an ORO requesting the RAAN option in its Relay-Forw message.
	A relay agent may do this for any relayed message, regardless of the		A relay agent may do this for any relayed message, regardless of the
	message type or the message contents.		message type or the message contents.
	When a relay agent receives a Relay-Reply message containing a RAAN		When a relay agent receives a Relay-Reply message containing a RAAN
	option, the relay agent may forward that option data to the node in		option, the relay agent may forward that option data to the node in
	which the relay agent is instantiated. If no RAAN option is included		which the relay agent is instantiated. If no RAAN option is included
	in the Relay-Reply, the relay agent MUST NOT assume anything with		in the Relay-Reply, the relay agent MUST NOT assume anything with
	regard to RAAN data and MUST NOT forward any indication to the node		regard to RAAN data and MUST NOT forward any indication to the node
	in which the relay agent is instantiated.		in which the relay agent is instantiated.
	If a node creates state based on the information included in this		If a node creates state based on the information included in this
	option, it MUST remove that state when the lifetime as specified in		option, it MUST remove that state when the lifetime as specified in
	the option expires.		the option expires.
			One concern with the RAAN option is that messages from the DHCP
			server may be received (or processed) out of order. But this concern
			is no different than that for the "snooping" which has been used by
			relay agents for many years (both in DHCPv4 and DHCPv6).
			Implementers should be aware of this and should consider making use
			of Leasequery ([RFC5007]) to resolve conflicts.
	5. Server Behavior		5. Server Behavior
	When a server is responding to a request and the ORO contains an RAAN		When a server is responding to a request and the ORO contains an RAAN
	option, the server SHOULD include a RAAN option with all of the		option, the server SHOULD include a RAAN option with all of the
	addresses and prefixes that have been (or are being assigned) to the		addresses and prefixes that have been (or are being assigned) to the
	client. If no addresses or prefixes are assigned, the server SHOULD		client. If no addresses or prefixes are assigned, the server SHOULD
	send a RAAN option with no addresses or prefixes.		send a RAAN option with no addresses or prefixes.
	If the DHCP server does include this option in a Relay-Reply message,		If the DHCP server does include this option in a Relay-Reply message,
	it MUST include it in the option area of the Relay-Reply message sent		it MUST include it in the option area of the Relay-Reply message sent
	to the relay agent intended as the recipient of the option.		to the relay agent intended as the recipient of the option.
	If the message received from the client contains no Client Identifier		If the message received from the client contains no Client Identifier
	option or the server is otherwise unable to identify the client or		option or the server is otherwise unable to identify the client or
	the client's link (perhaps because of missing or invalid data in the		the client's link (perhaps because of missing or invalid data in the
	request), the server MUST NOT include a RAAN option in the response.		request), the server MUST NOT include a RAAN option in the response.
	6. Option format		6. Option Format
	The RAAN option has the following format:		The RAAN option has the following format:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| option-code | length |		| option-code | length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| encapsulated-options |		. .
	. .		. encapsulated-options .
	. .		. .
	. .		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	option-code OPTION_AGENT_NOTIFY (TBD)		Figure 1: Relay Agent Assignment Notification Option Format
	length length of encapsulated options, in octets		option-code OPTION_AGENT_NOTIFY (TBD).
			option-len Length of encapsulated options, in octets.
	encapsulated-options DHCP options to be delivered by the relay agent		encapsulated-options DHCP options to be delivered by the relay agent
	Assignment Notification option		Assignment Notification option.
	7. Encapsulating DHCP options in the RAAN Option		7. Encapsulating DHCP Options in the RAAN Option
	The contents of options encapsulated in the RAAN option are		The contents of options encapsulated in the RAAN option are
	interpreted according to the use of those options in the node on		interpreted according to the use of those options in the node on
	which the relay agent is implemented. For the purposes of address		which the relay agent is implemented. For the purposes of address
	and prefix assignment, the uses of the DHCP IA Address and IA Prefix		and prefix assignment, the uses of the DHCP IA Address and IA Prefix
	options are defined in this document.		options are defined in this document.
	Note that the contents of these options are not necessarily the same		Note that the contents of these options are not necessarily the same
	as in the corresponding options sent to the DHCP client.		as in the corresponding options sent to the DHCP client.
	7.1. IA Address option		7.1. IA Address Option
	The fields in an IA Address option (OPTION_IAADDR, option code 5) are		The fields in an IA Address option (OPTION_IAADDR, option code 5) are
	used as follows:		used as follows:
	IPv6 address The IPv6 address assigned in this DHCP message		IPv6 address The IPv6 address assigned in this DHCP message
	preferred-lifetime Not used by the relay agent; the server SHOULD		preferred-lifetime Not used by the relay agent; the server SHOULD
	set this field to the preferred-lifetime of the		set this field to the preferred-lifetime of the
	corresponding IA Address options in the message		corresponding IA Address options in the message
	to be forwarded to the client		to be forwarded to the client
	valid-lifetime The lifetime of the information carried in this		valid-lifetime The lifetime of the information carried in this
	IA Address option, expressed in units of seconds;		IA Address option, expressed in units of
	if the valid-lifetime is 0, the information is no		seconds; if the valid-lifetime is 0, the
	longer valid		information is no longer valid
	IAaddr-options Not used by the relay agent; the server SHOULD		IAaddr-options Not used by the relay agent; the server SHOULD
	set this field to the IAaddr-options of the		set this field to the IAaddr-options of the
	corresponding IA Address option in the message to		corresponding IA Address option in the message
	be forwarded to the client		to be forwarded to the client
	7.2. IA Prefix option		7.2. IA Prefix Option
	The fields in an IA Prefix option (OPTION_IAPREFIX, option code 28)		The fields in an IA Prefix option (OPTION_IAPREFIX, option code 28)
	are used as follows:		are used as follows:
	preferred-lifetime Not used by the relay agent; the server SHOULD		preferred-lifetime Not used by the relay agent; the server SHOULD
	set this field to the preferred-lifetime of the		set this field to the preferred-lifetime of the
	corresponding IA Prefix options in the message to		corresponding IA Prefix options in the message
	be forwarded to the client		to be forwarded to the client
	valid-lifetime The lifetime of the information carried in this		valid-lifetime The lifetime of the information carried in this
	IA Prefix option, expressed in units of seconds;		IA Prefix option, expressed in units of seconds;
	if the valid-lifetime is 0, the information is no		if the valid-lifetime is 0, the information is
	longer valid		no longer valid
	prefix-length length for this prefix in bits		prefix-length Length for this prefix in bits
	IPv6-prefix The IPv6 prefix assigned in this DHCP message		IPv6-prefix The IPv6 prefix assigned in this DHCP message
	IAprefix-options Not used by the relay agent; the server SHOULD
	set this field to the IAprefix-options of the
	corresponding IA Prefix option in the message to
	be forwarded to the client
	8. Requesting assignment information from the DHCP server		IAprefix-options Not used by the relay agent; the server SHOULD
			set this field to the IAprefix-options of the
			corresponding IA Prefix option in the message to
			be forwarded to the client
			8. Requesting Assignment Information from the DHCP Server
	If a relay agent requires the DHCP server to provide information		If a relay agent requires the DHCP server to provide information
	about assigned addresses and prefixes, it MUST include an Option		about assigned addresses and prefixes, it MUST include an Option
	Request option, requesting the Assignment Notification option, as		Request option, requesting the Assignment Notification option, as
	described in section 22.7 of RFC 3315.		described in section 22.7 of RFC 3315.
	9. IANA considerations		9. IANA Considerations
	IANA is requested to assign an option code from the "DHCPv6 and		IANA is requested to assign an option code from the "DHCPv6 and
	DHCPv6 options" registry		DHCPv6 options" registry http://www.iana.org/assignments/
	http://www.iana.org/assignments/dhcpv6-parameters to		dhcpv6-parameters to OPTION_AGENT_NOTIFY.
	OPTION_AGENT_NOTIFY.
	10. Security considerations		10. Security Considerations
	Security issues related to DHCP are described in RFC 3315 and RFC		Security issues related to DHCP are described in RFC 3315 and RFC
	3633.		3633.
	The RAAN option may be used to mount a denial of service attack by		The RAAN option may be used to mount a denial of service attack by
	causing a node to incorrectly populate an ACL or incorrectly		causing a node to incorrectly populate an ACL or incorrectly
	configure routing information for a delegated prefix. This option		configure routing information for a delegated prefix. This option
	may also be used to insert invalid prefixes into the routing		may also be used to insert invalid prefixes into the routing
	infrastructure or add invalid IP addresses to ACLs in nodes.		infrastructure or add invalid IP addresses to ACLs in nodes.
	Communication between a server and a relay agent, and communication		Communication between a server and a relay agent, and communication
	between relay agents, can be secured through the use of IPSec, as		between relay agents, can be secured through the use of IPSec, as
	described in section 21.1 of RFC 3315.		described in [I-D.ietf-dhc-relay-server-security].
	11. Changes log		11. Changes Log
	If this section is included in the document when it is submitted for		If this section is included in the document when it is submitted for
	publication, the RFC Editor is requested to remove it.		publication, the RFC Editor is requested to remove it.
	Changes in rev -01:		Changes in rev -01:
	o Added section describing use of "Server Reply Sequence Number"
	option to allow resequencing of out-of-order messages		o Added section describing use of "Server Reply Sequence Number"
			option to allow resequencing of out-of-order messages.
	Changes in rev -02:		Changes in rev -02:
	o Made editorial change in section 1: s/the appropriate routing		o Made editorial change in section 1: s/the appropriate routing
	protocols/the routing infrastructure/		protocols/the routing infrastructure/
	o Updated first paragraph in Section 3 to allow multiple IA Address
	options and/or IA Prefix options		o Updated first paragraph in Section 3 to allow multiple IA
	o Renamed section 3 to "Options Semantics and Usage"		Address options and/or IA Prefix options
	o Added paragraph to section "Option Semantics and Usage" requiring
	that the DHCP server must include all addresses/prefixes for the		o Renamed section 3 to "Options Semantics and Usage"
	client (on that link) in the RAAN option
	o Added list of use cases to section "Option Semantics and Usage"		o Added paragraph to section "Option Semantics and Usage"
	o Added section "Relay Agent Behavior"		requiring that the DHCP server must include all addresses/
	o Added section "Server Behavior"; moved second paragraph of section		prefixes for the client (on that link) in the RAAN option
	"Option Semantics and Usage" to "Server Behavior"
	o Updated reference to draft-ietf-dhc-dhcpv6-srsn-option-00		o Added list of use cases to section "Option Semantics and Usage"
	o Clarified descriptions of various option fields in section
	"Encapsulating DHCP options in the RAAN Option"		o Added section "Relay Agent Behavior"
			o Added section "Server Behavior"; moved second paragraph of
			section "Option Semantics and Usage" to "Server Behavior"
			o Updated reference to draft-ietf-dhc-dhcpv6-srsn-option-00
			o Clarified descriptions of various option fields in section
			"Encapsulating DHCP options in the RAAN Option"
	Changes in rev -03: refreshed after expiration.		Changes in rev -03: refreshed after expiration.
	Changes in rev -04: all references to the "Server Reply Sequence		Changes in rev -04: all references to the "Server Reply Sequence
	Number" option were removed from the draft.		Number" option were removed from the draft.
	12. Normative References		Changes in rev -05:
			o Converted the -04 text version to xml.
			o Updated introduction to add motivation for option because of
			[I-D.ietf-dhc-sedhcpv6], and also Reply to Release "snooping"
			issues.
			o Updated security considerations to reference IPsec document
			([I-D.ietf-dhc-relay-server-security]).
			12. References
			12.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, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,		[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
	and M. Carney, "Dynamic Host Configuration Protocol for		C., and M. Carney, "Dynamic Host Configuration Protocol
	IPv6 (DHCPv6)", RFC 3315, July 2003.		for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
			2003, <http://www.rfc-editor.org/info/rfc3315>.
	[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic		[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
	Host Configuration Protocol (DHCP) version 6", RFC 3633,		Host Configuration Protocol (DHCP) version 6", RFC 3633,
	December 2003.		DOI 10.17487/RFC3633, December 2003,
			<http://www.rfc-editor.org/info/rfc3633>.
			12.2. Informative References
			[I-D.ietf-dhc-relay-server-security]
			Volz, B. and Y. Pal, "Security of Messages Exchanged
			Between Servers and Relay Agents", draft-ietf-dhc-relay-
			server-security-04 (work in progress), March 2017.
			[I-D.ietf-dhc-sedhcpv6]
			Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D.
			Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work
			in progress), February 2017.
			[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
			"DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007,
			September 2007, <http://www.rfc-editor.org/info/rfc5007>.
	Authors' Addresses		Authors' Addresses
	Ralph Droms		Ralph Droms
	Cisco Systems, Inc.
	1414 Massachusetts Avenue
	Boxborough, MA 01719
	USA
	Phone: +1 978.936.1674		Email: rdroms.ietf@gmail.com
	Email: rdroms@cisco.com
	Bernie Volz		Bernie Volz
	Cisco Systems, Inc.		Cisco Systems, Inc.
	1414 Massachusetts Avenue		1414 Massachusetts Ave
	Boxborough, MA 01719		Boxborough, MA 01719
	USA		USA
	Phone: +1 978.936.0382
	Email: volz@cisco.com		Email: volz@cisco.com
	Ole Troan		Ole Troan
	Cisco Systems, Inc.		Cisco Systems, Inc.
			Oslo
			Norway
	Phone: +47 23 27 3664
	Email: otroan@cisco.com		Email: otroan@cisco.com
End of changes. 51 change blocks.
	135 lines changed or deleted		206 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/