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/