< 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 5, line 16 skipping to change at page 5, line 29
[RFC 3306] B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6 [RFC 3306] B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses," RFC 3306, August 2002. Multicast Addresses," RFC 3306, August 2002.
[RFC 3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast [RFC 3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast
Addresses," RFC 3307, August 2002. Addresses," RFC 3307, August 2002.
[RFC 3513] R. Hinden and S. Deering, "IP Version 6 Addressing [RFC 3513] R. Hinden and S. Deering, "IP Version 6 Addressing
Architecture", RFC 3513, April 2003. Architecture", RFC 3513, April 2003.
Informative Informative
[RFC 3956] P. Savola and B. Haberman, "Embedding the Rendezvous [RFC 3956] P. Savola and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address Point (RP) Address in an IPv6 Multicast Address
[SSM ARCH] H. Holbrook and B. Cain, "Source-Specific Multicast [SSM ARCH] H. Holbrook and B. Cain, "Source-Specific Multicast
for IP", Work In Progress, September 2004. for IP", Work In Progress, September 2004.
Authors' Addresses Authors' Addresses
Jung-Soo Park Jung-Soo Park
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. 12 change blocks. 
28 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/