draft-ietf-ipv6-link-scoped-mcast-09.txt		rfc4489.txt
	IPv6 Working Group J-S. Park		Network Working Group J-S. Park
	INTERNET DRAFT ETRI		Request for Comments: 4489 M-K. Shin
	Expires: January 18, 2006 M-K. Shin		Updates: 3306 H-J. Kim
	Updates: 3306 ETRI		Category: Standards Track ETRI
	H-J. Kim		April 2006
	ETRI
	July 17, 2005
	A Method for Generating Link Scoped IPv6 Multicast Addresses
	<draft-ietf-ipv6-link-scoped-mcast-09.txt>
	Status of this Memo
	By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other docu-
	ments at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in pro-
	gress."
	The list of current Internet-Drafts can be accessed at		A Method for Generating Link-Scoped IPv6 Multicast Addresses
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		Status of This Memo
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 18, 2006.		This document specifies an Internet standards track protocol for the
			Internet community, and requests discussion and suggestions for
			improvements. Please refer to the current edition of the "Internet
			Official Protocol Standards" (STD 1) for the standardization state
			and status of this protocol. Distribution of this memo is unlimited.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document specifies an extension to the multicast addressing		This document specifies an extension to the multicast addressing
	architecture of the IPv6 protocol. The extension allows for the use		architecture of the IPv6 protocol. The extension allows the use of
	of Interface Identifiers (IIDs) to allocate multicast addresses.		Interface Identifiers (IIDs) to allocate multicast addresses. When a
	When a link-local unicast address is configured at each interface		link-local unicast address is configured at each interface of a node,
	of a node, an IID is uniquely determined. After that, each node		an IID is uniquely determined. After that, each node can generate
	can generate their unique multicast addresses automatically without		its unique multicast addresses automatically without conflicts. The
	conflicts. Basically, this document proposes an alternative method		alternative method for creating link-local multicast addresses
	for creating link-local multicast addresses over a known method		proposed in this document is better than known methods like unicast-
	like unicast-prefix-based IPv6 multicast addresses. It is preferred		prefix-based IPv6 multicast addresses. This memo updates RFC 3306.
	to use this method for link-local scope rather than unicast-
	prefix-based IPv6 multicast addresses. This memo update RFC3306.
	Table of Contents:		Table of Contents:
	1. Introduction................................................2		1. Introduction ....................................................2
	2. Applicability...............................................2		2. Applicability ...................................................2
	3. Link Scoped Multicast Address Format........................3		3. Link-Scoped Multicast Address Format ............................3
	4. Example ....................................................4		4. Example .........................................................3
	5. Consideration of Lifetime ..................................4		5. Consideration of Lifetime .......................................4
	6. Security Considerations.....................................4		6. Security Considerations .........................................4
	7. Acknowledgments.............................................4		7. Acknowledgements ................................................4
	8. References..................................................5		8. References ......................................................5
	Author's Addresses.............................................5
	1. Introduction		1. Introduction
	This document defines an extension to the multicast portion of the		This document defines an extension to the multicast portion of the
	IPv6 addressing architecture [RFC 3513]. The current architecture		IPv6 addressing architecture [RFC4291]. The current architecture
	does not contain any built-in support for dynamic address		does not contain any built-in support for dynamic address allocation.
	allocation. The extension allows for use of IIDs to allocate		The extension allows for use of IIDs to allocate multicast addresses.
	multicast addresses. When a link-local unicast address is		When a link-local unicast address is configured at each interface of
	configured at each interface of a node, an IID is uniquely		a node, an IID is uniquely determined. After that, each node can
	determined. After that, each node can generate their unique		generate its unique multicast addresses automatically without
	multicast addresses automatically without conflicts. That is,		conflicts. That is, these addresses could safely be configured at
	these addresses could safely be configured at any time after DAD		any time after Duplicate Address Detection (DAD) has completed.
	(Duplicate Address Detection) has completed.
	Basically, it is preferred to use this method for the link-local		This method for the link-local scope is preferred over unicast-
	scope rather than unicast-prefix-based IPv6 multicast addresses		prefix-based IPv6 multicast addresses [RFC3306], since by delegating
	[RFC 3306], since by delegating multicast addresses using the IID,		multicast addresses using the IID, each node can generate its
	each node can generate its multicast addresses automatically		multicast addresses automatically without allocation servers. This
	without allocation servers. This method goes well with		method works better than the unicast-prefix-based method with
	applications in serverless environment such as ad-hoc and network		applications in serverless environments such as ad-hoc and network
	mobility rather thant unicast-prefix-based method. This document		mobility. This document restricts the usage of defined fields such
	restricts the usage of defined fields such as scop, plen and		as the scop, plen, and network prefix fields of [RFC3306].
	network prefix fields of [RFC 3306]. Therefore, this document		Therefore, this document specifies encoded information for link-local
	specifies encoded information for link-local scope in multicast		scope in multicast addresses.
	addresses.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	this document are to be interpreted as described in [RFC 2119].		document are to be interpreted as described in [RFC2119].
	2. Applicability		2. Applicability
	The allocation technique in this document is designed to be used in		The allocation technique in this document is designed to be used in
	any environment in which link-local scope IPv6 multicast addresses		any environment in which link-local scope IPv6 multicast addresses
	are assigned or selected. Especially, this method goes well with		are assigned or selected. This method goes especially well with
	nodes supplying multicast services in a zeroconf/serverless		nodes supplying multicast services in a zeroconf/serverless
	environment. For example, multicast addresses less than or equal		environment. For example, multicast addresses less than or equal to
	to link-local scope are themselves generated by nodes supplying		link-local scope are themselves generated by nodes supplying
	multicast services without conflicts. Also, hosts which are		multicast services without conflicts. Also, hosts that are supplied
	supplied multicast services from multicast servers then make		multicast services from multicast servers then make multicast
	multicast addresses of multicast servers using ND (address		addresses of multicast servers using ND (address resolution) and
	resolution) and well-known group IDs.		well-known group IDs [RFC2461].
	Consequently, this technique MUST only be used for link scoped		Consequently, this technique MUST only be used for link scoped
	multicast addresses. If you want to use multicast addresses		multicast addresses. If you want to use multicast addresses greater
	greater than link-local scope, you need to use other methods as		than link-local scope, you need to use other methods as described in
	described in [RFC 3306].		[RFC3306].
	3. Link Scoped Multicast Address Format		3. Link-Scoped Multicast Address Format
	This document specifies a new format that incorporates IID in the		This document specifies a new format that incorporates IID in the
	link-local scope multicast addresses.		link-local scope multicast addresses.
	Figure 1 illustrates the new format for link scoped multicast		Figure 1 illustrates the new format for link-scoped multicast
	addresses.		addresses.
	| 8 | 4 | 4 | 8 | 8 | 64 | 32 |		| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
	+--------+----+----+--------+--------+----------------+----------+		+--------+----+----+--------+--------+----------------+----------+
	|11111111|flgs|scop|reserved| plen | IID | group ID |		|11111111|flgs|scop|reserved| plen | IID | group ID |
	+--------+----+----+--------+--------+----------------+----------+		+--------+----+----+--------+--------+----------------+----------+
	Figure 1: Link scoped multicast IPv6 address format		Figure 1. Link-Scoped Multicast IPv6 Address Format
			The flgs, scop, and plen fields are used to identify whether an
			address is a multicast address, as follows:
	Flgs, scop, and plen fields are used to identify whether an address
	is a multicast address as specified in this document as follows:
	1. flgs MUST be "0011".		1. flgs MUST be "0011".
	2. scop MUST be <= 2.		2. scop MUST be <= 2.
	3. The reserved field MUST be zero.		3. The reserved field MUST be zero.
	4. "plen" field is a special value "1111 1111" (decimal 255).
	The IID field (replacing the 64-bit prefix field from [RFC 3306])		4. The "plen" field is a special value, "1111 1111" (decimal 255).
	is used to distinguish each node from others. Given the use of
	this method for link-local scope, the IID embedded in the multicast
	address MUST only come from the IID of the link-local unicast
	address on the interface after DAD has completed. That is, the
	creation of the multicast address MUST only occur after DAD has
	completed as part of the auto-configuration process.
	Group ID is generated to indicate a multicast application and is		The IID field (replacing the 64-bit prefix field from [RFC3306]) is
	used to guarantee its uniqueness only in the host. It may also be		used to distinguish each node from others. Given the use of this
	set on the basis of the guidelines outlined in [RFC 3307].		method for link-local scope, the IID embedded in the multicast
			address MUST only come from the IID of the link-local unicast address
			on the interface after DAD has completed. That is, the creation of
			the multicast address MUST only occur after DAD has completed as part
			of the auto-configuration process.
			Group ID is generated to indicate a multicast application and is used
			to guarantee its uniqueness only in the host. It may also be set on
			the basis of the guidelines outlined in [RFC3307].
	4. Example		4. Example
	This is an example of link scoped IPv6 multicast addresses. For		In an Ethernet environment, if the link-local unicast address is
	example in an ethernet environment, if the link-local unicast		FE80::A12:34FF:FE56:7890, the link-scoped multicast prefix of the
	address is FE80::A12:34FF:FE56:7890, the link scoped multicast		node is FF32:00FF:A12:34FF:FE56:7890::/96.
	prefix of the node is FF32:00FF:A12:34FF:FE56:7890::/96.
	5. Consideration of Lifetime		5. Consideration of Lifetime
	Generally, Link scoped multicast addresses have no lifetime because		Generally, link-scoped multicast addresses have no lifetime, because
	link-local unicast addresses also have no lifetime. But, it is not		link-local unicast addresses also have no lifetime. However, this is
	true in environment of mobile. Even though multicast addresses are		not true in the mobile environment. Even though multicast addresses
	created from the unique IID of unicast address, their useful		are created from the unique IIDs of unicast addresses, their useful
	lifetime is linked to the period during which the IID is known to		lifetime is linked to the period during which the IID is known to be
	be unique. Thus, it is possible to conflict between IIDs, due to a		unique. Thus, conflict is possible between IIDs, due to a new node
	new node in merged network that uses the same IID as a powered		in merged network that uses the same IID as a powered node.
	node.
	This is a scenario where DAD also fails to guarantee the uniqueness		In this scenario, DAD also fails to guarantee uniqueness of the
	of the unicast address, so this document does not try to address		unicast address, but this document does not try to address this
	this issue.		issue.
	6. Security Considerations		6. Security Considerations
	The uniqueness of multicast addresses using this method is		The uniqueness of multicast addresses using this method is guaranteed
	guaranteed by the DAD process. So, it is needed to get a secure		by the DAD process. So, a secure DAD process is needed for stability
	DAD process for stability of this method. This document proposes		of this method. This document proposes the mechanism in [RFC3041]
	the mechanism in [RFC 3041] for this purpose.		for this purpose.
	[RFC 3041] describes the privacy extension to IPv6 stateless		[RFC3041] describes the privacy extension to IPv6 stateless address
	address autoconfiguration to how to configure the IID of non-link-		autoconfiguration to configure the IID of non-link-local scope
	local scope unicast addresses. [RFC 3041] can not be used for		unicast addresses. [RFC3041] cannot be used for making a link-local
	making a link-local unicast address, and hence it cannot be used to		unicast address, and hence it cannot be used to create an IID for
	create an IID for link-scoped multicast address. However, as [RFC		link-scoped multicast address. However, as [RFC3041] does not
	3041] does not protect the privacy of link-local unicast addresses,		protect the privacy of link-local unicast addresses, it does not seem
	it does not protect the privacy of link-local unicast addresses, it		to be required to protect the privacy of IID-based link-local
	does not seem to be required to protect the privacy of IID-based		multicast addresses.
	link-local multicast addresses.
	7. Acknowledgements		7. Acknowledgements
	We would like to thank Dave Thaler and Brian Haberman for his		We would like to thank Dave Thaler and Brian Haberman for their
	comments related to the consistency between the unicast prefix-		comments related to the consistency between the unicast prefix-based
	based multicast draft and this one. Special thanks are due to Erik		multicast document and this one. Special thanks are due to Erik
	Nordmark and Pekka Savola for valuable comments.		Nordmark and Pekka Savola for valuable comments.
	8. References		8. References
	Normative		8.1. Normative References
	[RFC 2119] S. Bradner, "Key words for use in RFCs to indicate
	Requirement Levels", RFC 2119, March 1997.
	[RFC 2461] T. Narten, E. Nordmark and W. Simpson, "Neighbor
	Discovery for IP Version 6 (IPv6)", RFC 2461,
	December 1998.
	[RFC 3041] T. Narten and R. Draves, "Privacy Extensions for
	Stateless Address Autoconfiguration in IPv6,"
	RFC 3041, April 2001.
	[RFC 3306] B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Multicast Addresses," RFC 3306, August 2002.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC 3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast		[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
	Addresses," RFC 3307, August 2002.		Discovery for IP Version 6 (IPv6)", RFC 2461, December
			1998..ti 3
	[RFC 3513] R. Hinden and S. Deering, "IP Version 6 Addressing		[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
	Architecture", RFC 3513, April 2003.		Stateless Address Autoconfiguration in IPv6", RFC 3041,
			January 2001.
	Informative		[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
			Multicast Addresses", RFC 3306, August 2002.
	[RFC 3956] P. Savola and B. Haberman, "Embedding the Rendezvous		[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
	Point (RP) Address in an IPv6 Multicast Address		Addresses", RFC 3307, August 2002.
	[SSM ARCH] H. Holbrook and B. Cain, "Source-Specific Multicast		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	for IP", Work In Progress, September 2004.		Architecture", RFC 4291, February 2006.
	Authors' Addresses		Authors' Addresses
	Jung-Soo Park		Jung-Soo Park
	ETRI PEC		ETRI PEC
	161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea		161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
	Phone: +82 42 860 6514		Phone: +82 42 860 6514
	Email: jspark@pec.etri.re.kr		EMail: pjs@etri.re.kr
	Myung-Ki Shin		Myung-Ki Shin
	ETRI/NIST		ETRI PEC
	820 West Diamond Avenue		161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
	Gaithersburg, MD 20899, USA
	Tel : +1 301 975-3613		Phone: +82 42 860 4847
	Fax : +1 301 590-0932		EMail: myungki.shin@gmail.com
	E-mail : mshin@nist.gov
	Hyoung-Jun Kim		Hyoung-Jun Kim
	ETRI PEC		ETRI PEC
	161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea		161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
	Phone: +82 42 860 6576		Phone: +82 42 860 6576
	Email: khj@etri.re.kr		EMail: khj@etri.re.kr
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The Internet Society (2006).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed		Intellectual Property Rights or other rights that might be claimed to
	to pertain to the implementation or use of the technology described		pertain to the implementation or use of the technology described in
	in this document or the extent to which any license under such		this document or the extent to which any license under such rights
	rights might or might not be available; nor does it represent that		might or might not be available; nor does it represent that it has
	it has made any independent effort to identify any such rights.		made any independent effort to identify any such rights. Information
	Information on the procedures with respect to rights in RFC		on the procedures with respect to rights in RFC documents can be
	documents can be found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use		attempt made to obtain a general license or permission for the use of
	of such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository		specification can be obtained from the IETF on-line IPR repository at
	at http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at ietf-
	ietf-ipr@ietf.org.		ipr@ietf.org.
	Disclaimer of Validity
	This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
	THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
	ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
	PARTICULAR PURPOSE.
	Copyright Statement
	Copyright (C) The Internet Society (2005). This document is
	subject to the rights, licenses and restrictions contained in BCP
	78, and except as set forth therein, the authors retain all their
	rights.
	Acknowledgment		Acknowledgement
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 46 change blocks.
	196 lines changed or deleted		163 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/