draft-ietf-ipv6-link-scoped-mcast-08.txt		draft-ietf-ipv6-link-scoped-mcast-09.txt
	IPv6 Working Group J-S. Park		IPv6 Working Group J-S. Park
	INTERNET DRAFT ETRI		INTERNET DRAFT ETRI
	Expires: June 2005 M-K. Shin		Expires: January 18, 2006 M-K. Shin
	ETRI/NIST		Updates: 3306 ETRI
	H-J. Kim		H-J. Kim
	ETRI		ETRI
	December 2004		July 17, 2005
	Link Scoped IPv6 Multicast Addresses		A Method for Generating Link Scoped IPv6 Multicast Addresses
	<draft-ietf-ipv6-link-scoped-mcast-08.txt>		<draft-ietf-ipv6-link-scoped-mcast-09.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been disclosed,		applicable patent or other IPR claims of which he or she is aware
	and any of which I become aware will be disclosed, in accordance		have been or will be disclosed, and any of which he or she becomes
	with RFC 3668.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other docu-		months and may be updated, replaced, or obsoleted by other docu-
	ments at any time. It is inappropriate to use Internet-Drafts as		ments at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in pro-		reference material or to cite them other than as "work in pro-
	gress."		gress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on June 2005.		This Internet-Draft will expire on January 18, 2006.
			Copyright Notice
			Copyright (C) The Internet Society (2005).
	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 for the use
	of Interface Identifiers (IIDs) to allocate multicast addresses.		of Interface Identifiers (IIDs) to allocate multicast addresses.
	When a link-local unicast address is configured at each interface		When a link-local unicast address is configured at each interface
	of a node, an IID is uniquely determined. After that, each node		of a node, an IID is uniquely determined. After that, each node
	can generate their unique multicast addresses automatically without		can generate their unique multicast addresses automatically without
	conflicts. Basically, this document proposes an alternative method		conflicts. Basically, this document proposes an alternative method
	for creating link-local multicast addresses over a known method		for creating link-local multicast addresses over a known method
	like unicast-prefix-based IPv6 multicast addresses. It is preferred		like unicast-prefix-based IPv6 multicast addresses. It is preferred
	to use this method for link-local scope rather than unicast-		to use this method for link-local scope rather than unicast-
	prefix-based IPv6 multicast addresses. This memo update RFC3306.		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 ....................................................3		4. Example ....................................................4
	5. Consideration of Lifetime ..................................3		5. Consideration of Lifetime ..................................4
	6. Security Considerations.....................................4		6. Security Considerations.....................................4
	7. Acknowledgments.............................................4		7. Acknowledgments.............................................4
	8. References..................................................4		8. References..................................................5
	Author's Addresses.............................................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 [RFC 3513]. The current architecture
	does not contain any built-in support for dynamic address		does not contain any built-in support for dynamic address
	allocation. The extension allows for use of IIDs to allocate		allocation. The extension allows for use of IIDs to allocate
	multicast addresses. When a link-local unicast address is		multicast addresses. When a link-local unicast address is
	configured at each interface of a node, an IID is uniquely		configured at each interface of a node, an IID is uniquely
	determined. After that, each node can generate their unique		determined. After that, each node can generate their unique
	multicast addresses automatically without conflicts. That is,		multicast addresses automatically without conflicts. That is,
	these addresses could safely be configured at any time after DAD		these addresses could safely be configured at any time after DAD
	(Duplicate Address Detection) has completed.		(Duplicate Address Detection) has completed.
	Basically, it is preferred to use this method for the link-local		Basically, it is preferred to use this method for the link-local
	scope rather than unicast-prefix-based IPv6 multicast addresses		scope rather than unicast-prefix-based IPv6 multicast addresses
	[RFC 3306]. This document restricts the usage of defined fields		[RFC 3306], since by delegating multicast addresses using the IID,
	such as scop, plen and network prefix fields of [RFC 3306].		each node can generate its multicast addresses automatically
	Therefore, this document specifies encoded information for link-		without allocation servers. This method goes well with
	local scope in multicast addresses.		applications in serverless environment such as ad-hoc and network
			mobility rather thant unicast-prefix-based method. This document
			restricts the usage of defined fields such as scop, plen and
			network prefix fields of [RFC 3306]. Therefore, this document
			specifies encoded information for link-local scope in multicast
			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 document are to be interpreted as described in [RFC 2119].		this document are to be interpreted as described in [RFC 2119].
	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. Especially, this method goes 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 link-local scope are themselves generated by nodes supplying		to link-local scope are themselves generated by nodes supplying
	multicast services without conflicts. Also, hosts which are		multicast services without conflicts. Also, hosts which are
	supplied multicast services from multicast servers then make		supplied multicast services from multicast servers then make
	multicast addresses of multicast servers using ND (address		multicast addresses of multicast servers using ND (address
	resolution) and well-known group IDs.		resolution) and well-known group IDs.
	skipping to change at page 3, line 31		skipping to change at page 3, line 43
	Figure 1: Link scoped multicast IPv6 address format		Figure 1: Link scoped multicast IPv6 address format
	Flgs, scop, and plen fields are used to identify whether an address		Flgs, scop, and plen fields are used to identify whether an address
	is a multicast address as specified in this document as follows:		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).		4. "plen" field is a special value "1111 1111" (decimal 255).
	The IID field (replacing the 64-bit prefix field from [RFC 3306])		The IID field (replacing the 64-bit prefix field from [RFC 3306])
	is used to distinguish each node from others. This value is		is used to distinguish each node from others. Given the use of
	obtained from the IEEE EUI-64 based interface identifier of the		this method for link-local scope, the IID embedded in the multicast
	link-local unicast IPv6 address. Given the use of this method for		address MUST only come from the IID of the link-local unicast
	link-local scope, the IID embedded in the multicast address MUST		address on the interface after DAD has completed. That is, the
	only come from the IID of the link-local unicast address on the		creation of the multicast address MUST only occur after DAD has
	interface after DAD has completed. That is, the creation of the		completed as part of the auto-configuration process.
	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		Group ID is generated to indicate a multicast application and is
	used to guarantee its uniqueness only in the host. It may also be		used to guarantee its uniqueness only in the host. It may also be
	set on the basis of the guidelines outlined in [RFC 3307].		set on the basis of the guidelines outlined in [RFC 3307].
	4. Example		4. Example
	This is an example of link scoped IPv6 multicast addresses. For		This is an example of link scoped IPv6 multicast addresses. For
	example in an ethernet environment, if the link-local unicast		example in an ethernet environment, if the link-local unicast
	address is FE80::A12:34FF:FE56:7890, the link scoped multicast		address is FE80::A12:34FF:FE56:7890, the link scoped multicast
	skipping to change at page 6, line 34		skipping to change at page 7, line 42
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT		EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
	THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR		THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
	ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A		ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
	PARTICULAR PURPOSE.		PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2004). This document is		Copyright (C) The Internet Society (2005). This document is
	subject to the rights, licenses and restrictions contained in BCP		subject to the rights, licenses and restrictions contained in BCP
	78, and except as set forth therein, the authors retain all their		78, and except as set forth therein, the authors retain all their
	rights.		rights.
	Acknowledgment		Acknowledgment
	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.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/