draft-ietf-ipv6-link-scoped-mcast-00.txt		draft-ietf-ipv6-link-scoped-mcast-01.txt
	INTERNET DRAFT Jung-Soo Park		INTERNET DRAFT Jung-Soo Park
	Expires: October 2002 Myung-Ki Shin		Expires: October 2002 Myung-Ki Shin
	Yong-Jin Kim		Yong-Jin Kim
	ETRI		ETRI
	April 2002		April 2002
	Link Scoped IPv6 Multicast Addresses		Link Scoped IPv6 Multicast Addresses
	<draft-ietf-ipv6-link-scoped-mcast-00.txt>		<draft-ietf-ipv6-link-scoped-mcast-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and working groups. Note that other		Task Force (IETF), its areas, and working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-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 obsolete by other documents		months and may be updated, replaced, or made obsolete by other documents
	at anytime. It is inappropriate to use Internet Drafts as reference		at anytime. 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 "works in progress."
	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.
	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		architecture of the IPv6 protocol. The extension allows for the
	use of interface-ID to allocate multicast addresses. When the		use of interface-IDs to allocate multicast addresses. When the
	link-local unicast address is configured at each interface of host,		link-local unicast address is configured at each interface of a host,
	interface ID is uniquely determined. By delegating multicast		an interface ID is uniquely determined. By delegating multicast
	addresses at the same time as interface ID, each host can identify		addresses at the same time as the interface ID, each host can identify
	their multicast addresses automatically at Layer 1 without running		their multicast addresses automatically at Layer 1 without running
	an intra- or inter-domain allocation protocol in the serverless		an intra- or inter-domain allocation protocol in serverless
	environments.		environments.
	Table of Contents:		Table of Contents:
	1. Introduction		1. Introduction
	2. Terminology		2. Terminology
	3. Applicability		3. Applicability
	4. Link scoped multicast address format		4. Link scoped multicast address format
	5. Examples		5. Examples
	6. Considerations		6. Considerations
	7. Security considerations		7. Security considerations
	8. References		8. References
	9. Acknowledgements		9. Acknowledgements
	1. Introduction		1. Introduction
	This specification defines an extension to the multicast portion of		This specification defines an extension to the multicast portion of
	the IPv6 addressing architecture [ADDRARCH]. The current		the IPv6 addressing architecture [ADDRARCH]. The current
	architecture does not contain any built-in support for dynamic		architecture does not contain any built-in support for dynamic
	address allocation. The extension allows for using interface-ID to		address allocation. The extension allows for use of interface-IDs to
	allocate multicast addresses. When the link-local unicast address		allocate multicast addresses. When the link-local unicast address
	is configured at each interface of host, interface ID is uniquely		is configured at each interface of a host, an interface ID is uniquely
	determined. By delegating multicast addresses at the same time as		determined. By delegating multicast addresses at the same time as
	interface ID, each host can identify its multicast addresses		the interface ID, each host can identify its multicast addresses
	automatically without running an intra- or inter-domain allocation		automatically without running an intra- or inter-domain allocation
	protocol in the serveless environments.		protocol in serveless environments.
	The current multicast address allocation architecture [RFC 2908] is		The current multicast address allocation architecture [RFC 2908] is
	based on a multi-layered, multi-protocol system. The goal of this		based on a multi-layered, multi-protocol system. The goal of this
	proposal is to reduce the number of protocols and servers to get		proposal is to reduce the number of protocols and servers to get
	dynamic multicast address allocation.		dynamic multicast address allocation.
	The use of interface ID-based multicast address allocation will, at		The use of interface ID-based multicast address allocation will, at
	a minimum, remove the need to run the Multicast Address Allocation		a minimum, remove the need to run the Multicast Address Allocation
	Protocol (AAP) [AAP WORK][RFC 2909] and the Multicast Address		Protocol (AAP) [AAP WORK][RFC 2909] and the Multicast Address
	Allocation servers [RFC 2908].		Allocation servers [RFC 2908].
	skipping to change at page 2, line 48		skipping to change at page 2, line 48
	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].
	3. Applicability		3. 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 environment. For		nodes supplying multicast services in a zeroconf environment. For
	example, multicast addresses less than or equal to link-local scope		example, multicast addresses less than or equal to link-local scope
	are generated itself by nodes supplying multicast services.		are themselves generated by nodes supplying multicast services.
	Consequently, this technique is limited to use by multicast scope.		Consequently, this technique is limited to use by multicast scope.
	If you want to use greater multicast addresses than link-local, you		If you want to use multicast addresses greater than link-local, you
	need to get other methods.		need other methods.
	4. Link scoped multicast address format		4. Link scoped multicast address format
	Section 2.7 of [ADDRARCH] defines the following operational format		Section 2.7 of [ADDRARCH] defines the following operational format
	of IPv6 multicast addresses:		of IPv6 multicast addresses:
	| 8 | 4 | 4 | 112 |		| 8 | 4 | 4 | 112 |
	+--------+----+----+---------------------------------------------+		+--------+----+----+---------------------------------------------+
	|11111111|flgs|scop| group ID |		|11111111|flgs|scop| group ID |
	+--------+----+----+---------------------------------------------+		+--------+----+----+---------------------------------------------+
	Figure 1: Generic IPv6 multicast address format		Figure 1: Generic IPv6 multicast address format
	This document introduces new formats that incorporate interface ID		This document introduces new formats that incorporate interface ID
	information in the multicast address. The idea delegating		information in the multicast address. The idea of delegating
	multicast addresses at the same time as interface ID, can be		multicast addresses at the same time as the interface ID, can be
	applicable to link-local.		applicable to link-local.
	Figure 2 illustrates the new format for link-local multicast		Figure 2 illustrates the new format for link-local multicast
	addresses.		addresses.
	| 8 | 4 | 4 | 16 | 64 | 32 |		| 8 | 4 | 4 | 16 | 64 | 32 |
	+--------+----+----+------------+----------------+---------------+		+--------+----+----+------------+----------------+---------------+
	|11111111|flgs|scop| reserved | Interface ID | group ID |		|11111111|flgs|scop| reserved | Interface ID | group ID |
	+--------+----+----+------------+----------------+---------------+		+--------+----+----+------------+----------------+---------------+
	Figure 2: link scoped multicast address format		Figure 2: link scoped multicast address format
	+-+-+-+-+		+-+-+-+-+
	flgs is a set of 4 flags: |0|0|P|T|		flgs is a set of 4 flags: |0|0|P|T|
	+-+-+-+-+		+-+-+-+-+
	o P = 0 indicates a multicast address that is not assigned		o P = 0 indicates a multicast address that is not assigned
	based on the interface ID.		on the basis of the interface ID.
	o P = 1 indicates a multicast address that is assigned		o P = 1 indicates a multicast address that is assigned
	based on the interface ID.		on the basis of the interface ID.
	o If P = 1, T MUST be set to 1, otherwise the setting of		o If P = 1, T MUST be set to 1, otherwise the setting of
	the T bit is defined in Section 2.7 of RFC 2373.		the T bit is defined in Section 2.7 of RFC 2373.
	flgs should use the same flag defined in section 3 of [UNIMULTI].		flgs should use the same flag defined in section 3 of [UNIMULTI].
	That is, this document proposes the third bit of 'flgs' field to		That is, this document proposes the third bit of 'flgs' field to
	indicates a Interface ID-based multicast addresses. Additionly,		indicates an Interface ID-based multicast addresses. Additionally,
	it is required to distinguish between Inteface ID-based multicast		it is necessary to distinguish between an Inteface ID-based multicast
	address and unicast-prefix-based multicast address.		address and a unicast-prefix-based multicast address.
	scop <= 2. The scope of this multicast address MUST be independent		scop <= 2. The scope of this multicast address MUST be independent
	of the scope of the unicast address, which derives the interface ID		of the scope of the unicast address, which derives the interface ID
	embedded in the multicast address.		embedded in the multicast address.
	The reserved field MUST be zero.		The reserved field MUST be zero.
	interface ID field is used to distinguish each host from others.		interface ID field is used to distinguish each host from others.
	And this value is obtained from IEEE EUI-64 based interface		And this value is obtained from the IEEE EUI-64 based interface
	identifier of the link-local unicast IPv6 address.		identifier of the link-local unicast IPv6 address.
	group ID is generated to indicate multicast application and is used		group ID is generated to indicate multicast application and is used
	to guarantee its uniqueness only in host. Also, it may be set based		to guarantee its uniqueness only in the host. It may also be set on
	on the guidelines outlined in [IPV6 GID].		the basis of the guidelines outlined in [IPV6 GID].
	The lifetime of a Interface ID-based multicast address has no		The lifetime of an Interface ID-based multicast address has no
	dependency to the Valid Lifetime field in the Prefix Information		dependency on the Valid Lifetime field in the Prefix Information
	option, corresponding to the unicast address being used, contained		option, corresponding to the unicast address being used, contained
	in the Router Advertisement message [RFC 2461].		in the Router Advertisement message [RFC 2461].
	5. Examples		5. Examples
	This is an example for interface ID-based multicast address with		This is an example of an interface ID-based multicast address with
	link-local scope. For example in ethernet environment, if the IEEE		link-local scope. For example in an ethernet environment, if the IEEE
	48-bit MAC's address is 12:34:56:78:90:AB, the mutlicast prefix of		48-bit MAC's address is 12:34:56:78:90:AB, the mutlicast prefix of
	a host is FF32:0:1234:56FF:FE78:90AB::/96.		the host is FF32:0:1234:56FF:FE78:90AB::/96.
	6. Considerations		6. Considerations
	This draft considers only the link-local multicast addresses. For		This draft considers only link-local multicast addresses. For
	this purpose, P flag is used in figure 2. [UNIMULTI] draft also use		this purpose, P flag is used in figure 2. The [UNIMULTI] draft also
	the P flag to indicate multicast address that is assigned based on		uses the P flag to indicate a multicast address that is assigned on
	network prefix. For consistency, some modifications in [UNIMULTI]		the basis of the network prefix. For consistency, some modifications
	draft are required. For example, by restrictng the syntax to		in the [UNIMULTI] draft are required. For example, by restrictng the
	scope > 2 in [UNIMULTI].		syntax to scope > 2 in [UNIMULTI].
	7. Security considerations		7. Security considerations
	[RFC3041] describes the privacy extension to IPv6 stateless		[RFC3041] describes the privacy extension to IPv6 stateless
	address autoconfiguration for interface ID. So, [RFC3041]		address autoconfiguration for an interface ID. So, [RFC3041]
	satisfied our requirements.		satisfied our requirements.
	8. References		8. References
	[RFC 2373]		[RFC 2373]
	R. Hinden and S. Deering, "IP Version 6 Addressing Architecture",		R. Hinden and S. Deering, "IP Version 6 Addressing Architecture",
	RFC 2373, July 1998.		RFC 2373, July 1998.
	[RFC 2460]		[RFC 2460]
	S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6)		S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6)
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/