draft-ietf-dhc-host-gen-id-01.txt		draft-ietf-dhc-host-gen-id-02.txt
	Network Working Group S. Jiang		Network Working Group S. Jiang
	Internet-Draft F. Xia		Internet-Draft F. Xia
	Intended status: Standards Track B. Sarikaya		Intended status: Standards Track B. Sarikaya
	Expires: May 24, 2012 Huawei Technologies		Expires: November 24, 2012 Huawei Technologies
	November 21, 2011		May 23, 2012
	Prefix Assignment in DHCPv6		Prefix Assignment in DHCPv6
	draft-ietf-dhc-host-gen-id-01.txt		draft-ietf-dhc-host-gen-id-02
	Abstract		Abstract
	This document describes a procedure for configuring hosts' IPv6		This document introduce a procedure for configuring hosts' IPv6
	address which the prefix is assigned from a DHCPv6 server through		address which the prefix is assigned from a DHCPv6 server through
	DHCPv6 protocol while the interface identifiers are independently		DHCPv6 protocol while the interface identifiers are independently
	generated by the hosts. The method is applicable to		generated by the hosts. The method is applicable to
	Cryptographically Generated Addresses (CGA), and other IPv6 addresses		Cryptographically Generated Addresses (CGA), and other IPv6 addresses
	with host-generated interface identifiers.		with host-generated interface identifiers.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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 May 24, 2012.		This Internet-Draft will expire on November 24, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 7		skipping to change at page 3, line 7
	7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8		7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 8		8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	10.2. Informative references . . . . . . . . . . . . . . . . . . 9		10.2. Informative references . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	[RFC3315] describes the operation of address assignment by a DHCPv6		A host IPv6 address is combined by a prefix and an interface
	server. A client uses a Solicit message to discover DHCPv6 servers		identifier. Currently, there are two mechanisms to configure a host
	configured to assign addresses. A server sends an Advertise message		IPv6 address. [RFC3315] describes the operation of address
	in response to announce the availability of the server to the client.		assignment by a DHCPv6 server. The operation assumes that the server
	The client then uses a Request message to request addresses. The		is responsible for the assignment of an integral address which
	server then returns addresses in a Reply message. The operation		includes prefix and interface identifier parts as described in
	assumes that the server is responsible for the assignment of an		[RFC4291]. In the Stateless Address Autoconfiguration (SLACC,
	integral address which includes prefix and interface identifier parts		[RFC4862]) model, the interface Identifier is generated by the host
	as described in [RFC4291].		itself while the prefix is configured through Router Advertisement
			message defined in [RFC4861].
	This document introduces a new DHCPv6 procedure to configure hosts'		Up to now, there is no mechanism that allows host self-generated
	IPv6 addresses. In this new procedure, the prefix is advertised from		addresses to be used in the DHCPv6-managed network.
	a DHCPv6 server through DHCPv6 protocol while the interface
	identifiers are independently generated by the hosts.
	[RFC3633] defines Prefix Delegation options providing a mechanism for		[RFC3633] defines Prefix Delegation options providing a mechanism for
	automated delegation of IPv6 prefixes using the DHCPv6. This		automated delegation of IPv6 prefixes using the DHCPv6. This
	mechanism is intended for delegating a long-lived prefix from a		mechanism is intended for delegating a long-lived prefix from a
	delegating router to a requesting router. This mechanism "is not		delegating router to a requesting router. This mechanism "is not
	bound to the assignment of IP addresses or other configuration		bound to the assignment of IP addresses or other configuration
	information to hosts" [RFC3633]. It delegates prefixes to a routable		information to hosts" [RFC3633]. It delegates prefixes to a routable
	device for itself use only. It does not support the host-genarated		device for itself use only. It does not support the host-genarated
	interface identifiers model, in which prefix(es) need to be		interface identifiers model, in which prefix(es) need to be
	advertised or assigned to hosts.		advertised or assigned to hosts.
			This document introduces a new DHCPv6 procedure to configure hosts'
			IPv6 addresses. In this new procedure, the prefix is advertised from
			a DHCPv6 server through DHCPv6 protocol while the interface
			identifiers are independently generated by the hosts. The usage of
			DHCPv6 for assigning prefixes separats prefix assignment and
			interface identifier generation.
	[RFC3972] describes a method for binding a public signature key to an		[RFC3972] describes a method for binding a public signature key to an
	IPv6 address in the Secure Neighbor Discovery (SEND) protocol		IPv6 address. The basic idea is to generate the interface identifier
	[RFC3971]. The basic idea is to generate the interface identifier
	(i.e., the rightmost 64 bits) of the IPv6 address by computing a		(i.e., the rightmost 64 bits) of the IPv6 address by computing a
	cryptographic hash of the public key. That is, the host decides its		cryptographic hash of the public key. That is, the host decides its
	interface identifier. As for the prefix part of the CGA, it is		interface identifier. As for the prefix part of the CGA, it is
	probably got through Router Advertisement message defined in		probably got through Router Advertisement message defined in
	[RFC4861], or through DHCPv6 operations defined in this document.		[RFC4861], or through DHCPv6 operations defined in this document.
	[I-D.ietf-csi-dhcpv6-cga-ps] describes potential issues in the
	interaction between DHCPv6 and CGA. In that document , the usage of
	DHCPv6 for assigning prefixes is proposed to facilitate separation of
	prefix assignment and interface identifier generation.
	There are also other host-generated IPv6 addresses, which are		There are also other host-generated IPv6 addresses, which are
	combined by prefixes obtained from network configuration and		combined by prefixes obtained from network configuration and
	ingerface identifiers generated by hosts, such as modified EUI-64		ingerface identifiers generated by hosts, such as modified EUI-64
	interface identifier [EUI-64], temporary addresses for privacy		interface identifier [EUI-64], temporary addresses for privacy
	[RFC4941],etc. The DHCPv6 operations defined in this document also		[RFC4941],etc. The DHCPv6 operations defined in this document also
	supports such address methods.		supports such address methods.
	The DHCPv6 operations defined in this document also supports the		The DHCPv6 operations defined in this document also supports the
	assigned prefix to be shared across multiple hosts.		assigned prefix to be shared across multiple hosts.
	skipping to change at page 9, line 17		skipping to change at page 9, line 17
	The authors would like to thanks Suresh Krishnan, Ted Lemon and other		The authors would like to thanks Suresh Krishnan, Ted Lemon and other
	members of DHC WG for their valuable comments.		members of DHC WG for their valuable comments.
	10. References		10. References
	10.1. Normative References		10.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, March 1997.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.
	[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
	Neighbor Discovery (SEND)", RFC 3971, March 2005.
	[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, March 2005.
	[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,		[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
	and M. Carney, "Dynamic Host Configuration Protocol for		and M. Carney, "Dynamic Host Configuration Protocol for
	IPv6 (DHCPv6)", RFC 3315, July 2003.		IPv6 (DHCPv6)", RFC 3315, July 2003.
	[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.		December 2003.
			[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
			Neighbor Discovery (SEND)", RFC 3971, March 2005.
			[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
			RFC 3972, March 2005.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, February 2006.		Architecture", RFC 4291, February 2006.
			[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
			"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
			September 2007.
			[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
			Address Autoconfiguration", RFC 4862, September 2007.
	[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy		[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
	Extensions for Stateless Address Autoconfiguration in		Extensions for Stateless Address Autoconfiguration in
	IPv6", RFC 4941, September 2007.		IPv6", RFC 4941, September 2007.
	10.2. Informative references		10.2. Informative references
	[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
	Based Networks", RFC 4968, August 2007.
	[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third		[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
	Generation Partnership Project (3GPP) Standards",		Generation Partnership Project (3GPP) Standards",
	RFC 3314, September 2002.		RFC 3314, September 2002.
	[I-D.ietf-csi-dhcpv6-cga-ps]		[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
	Jiang, S., Shen, S., and T. Chown, "DHCPv6 and CGA		Based Networks", RFC 4968, August 2007.
	Interaction: Problem Statement",
	draft-ietf-csi-dhcpv6-cga-ps-07 (work in progress),
	May 2011.
	[I-D.ietf-dhc-secure-dhcpv6]		[I-D.ietf-dhc-secure-dhcpv6]
	Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs",		Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs",
	draft-ietf-dhc-secure-dhcpv6-03 (work in progress),		draft-ietf-dhc-secure-dhcpv6-06 (work in progress),
	June 2011.		March 2012.
	[EUI-64] "Guidelines for 64-bit Global Identifier (EUI-64)		[EUI-64] "Guidelines for 64-bit Global Identifier (EUI-64)
	Registration Authority", http://standards.ieee.org/		Registration Authority", http://standards.ieee.org/
	regauth/oui/tutorials/EUI64.html", March 1997.		regauth/oui/tutorials/EUI64.html", March 1997.
	Authors' Addresses		Authors' Addresses
	Sheng Jiang		Sheng Jiang
	Huawei Technologies		Huawei Technologies
	Q14, Huawei Campus, No.156, BeiQing Road		Q14, Huawei Campus, No.156, BeiQing Road
End of changes. 16 change blocks.
	45 lines changed or deleted		43 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/