Movatterモバイル変換

Network Working Group                                          J-S. ParkRequest for Comments: 4489                                     M-K. ShinUpdates:3306                                                   H-J. KimCategory: Standards Track                                           ETRI                                                              April 2006A Method for Generating Link-Scoped IPv6 Multicast AddressesStatus of This Memo   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 (C) The Internet Society (2006).Abstract   This document specifies an extension to the multicast addressing   architecture of the IPv6 protocol.  The extension allows the use of   Interface Identifiers (IIDs) to allocate multicast addresses.  When a   link-local unicast address is configured at each interface of a node,   an IID is uniquely determined.  After that, each node can generate   its unique multicast addresses automatically without conflicts.  The   alternative method for creating link-local multicast addresses   proposed in this document is better than known methods like unicast-   prefix-based IPv6 multicast addresses.  This memo updatesRFC 3306.Table of Contents:1. Introduction ....................................................22. Applicability ...................................................23. Link-Scoped Multicast Address Format ............................34. Example .........................................................35. Consideration of Lifetime .......................................46. Security Considerations .........................................47. Acknowledgements ................................................48. References ......................................................5Park, et al.                Standards Track                     [Page 1]

RFC 4489               Link-Scoped IPv6 Multicast             April 20061.  Introduction   This document defines an extension to the multicast portion of the   IPv6 addressing architecture [RFC4291].  The current architecture   does not contain any built-in support for dynamic address allocation.   The extension allows for use of IIDs to allocate multicast addresses.   When a link-local unicast address is configured at each interface of   a node, an IID is uniquely determined.  After that, each node can   generate its unique multicast addresses automatically without   conflicts.  That is, these addresses could safely be configured at   any time after Duplicate Address Detection (DAD) has completed.   This method for the link-local scope is preferred over unicast-   prefix-based IPv6 multicast addresses [RFC3306], since by delegating   multicast addresses using the IID, each node can generate its   multicast addresses automatically without allocation servers.  This   method works better than the unicast-prefix-based method with   applications in serverless environments such as ad-hoc and network   mobility.  This document restricts the usage of defined fields such   as the scop, plen, and network prefix fields of [RFC3306].   Therefore, this document specifies encoded information for link-local   scope in multicast addresses.   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described in [RFC2119].2.  Applicability   The allocation technique in this document is designed to be used in   any environment in which link-local scope IPv6 multicast addresses   are assigned or selected.  This method goes especially well with   nodes supplying multicast services in a zeroconf/serverless   environment.  For example, multicast addresses less than or equal to   link-local scope are themselves generated by nodes supplying   multicast services without conflicts.  Also, hosts that are supplied   multicast services from multicast servers then make multicast   addresses of multicast servers using ND (address resolution) and   well-known group IDs [RFC2461].   Consequently, this technique MUST only be used for link scoped   multicast addresses.  If you want to use multicast addresses greater   than link-local scope, you need to use other methods as described in   [RFC3306].Park, et al.                Standards Track                     [Page 2]

RFC 4489               Link-Scoped IPv6 Multicast             April 20063.  Link-Scoped Multicast Address Format   This document specifies a new format that incorporates IID in the   link-local scope multicast addresses.   Figure 1 illustrates the new format for link-scoped multicast   addresses.      |   8    |  4 |  4 |   8    |    8   |       64       |    32    |      +--------+----+----+--------+--------+----------------+----------+      |11111111|flgs|scop|reserved|  plen  |       IID      | group ID |      +--------+----+----+--------+--------+----------------+----------+           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:    1. flgs MUST be "0011".    2. scop MUST be <= 2.    3. The reserved field MUST be zero.    4. The "plen" field is a special value, "1111 1111" (decimal 255).   The IID field (replacing the 64-bit prefix field from [RFC3306]) 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 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   In an Ethernet environment, if the link-local unicast address is   FE80::A12:34FF:FE56:7890, the link-scoped multicast prefix of the   node is FF32:00FF:A12:34FF:FE56:7890::/96.Park, et al.                Standards Track                     [Page 3]

RFC 4489               Link-Scoped IPv6 Multicast             April 20065.  Consideration of Lifetime   Generally, link-scoped multicast addresses have no lifetime, because   link-local unicast addresses also have no lifetime.  However, this is   not true in the mobile environment.  Even though multicast addresses   are created from the unique IIDs of unicast addresses, their useful   lifetime is linked to the period during which the IID is known to be   unique.  Thus, conflict is possible between IIDs, due to a new node   in merged network that uses the same IID as a powered node.   In this scenario, DAD also fails to guarantee uniqueness of the   unicast address, but this document does not try to address this   issue.6.  Security Considerations   The uniqueness of multicast addresses using this method is guaranteed   by the DAD process.  So, a secure DAD process is needed for stability   of this method.  This document proposes the mechanism in [RFC3041]   for this purpose.   [RFC3041] describes the privacy extension to IPv6 stateless address   autoconfiguration to configure the IID of non-link-local scope   unicast addresses.  [RFC3041] cannot be used for making a link-local   unicast address, and hence it cannot be used to create an IID for   link-scoped multicast address.  However, as [RFC3041] does not   protect the privacy of link-local unicast addresses, it does not seem   to be required to protect the privacy of IID-based link-local   multicast addresses.7.  Acknowledgements   We would like to thank Dave Thaler and Brian Haberman for their   comments related to the consistency between the unicast prefix-based   multicast document and this one.  Special thanks are due to Erik   Nordmark and Pekka Savola for valuable comments.Park, et al.                Standards Track                     [Page 4]

RFC 4489               Link-Scoped IPv6 Multicast             April 20068.  References8.1.  Normative References   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119, March 1997.   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor              Discovery for IP Version 6 (IPv6)",RFC 2461, December              1998..ti  3   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for              Stateless Address Autoconfiguration in IPv6",RFC 3041,              January 2001.   [RFC3306]  Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6              Multicast Addresses",RFC 3306, August 2002.   [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast              Addresses",RFC 3307, August 2002.   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing              Architecture",RFC 4291, February 2006.Authors' Addresses   Jung-Soo Park   ETRI PEC   161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea   Phone: +82 42 860 6514   EMail: pjs@etri.re.kr   Myung-Ki Shin   ETRI PEC   161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea   Phone: +82 42 860 4847   EMail: myungki.shin@gmail.com   Hyoung-Jun Kim   ETRI PEC   161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea   Phone: +82 42 860 6576   EMail: khj@etri.re.krPark, et al.                Standards Track                     [Page 5]

RFC 4489               Link-Scoped IPv6 Multicast             April 2006Full Copyright Statement   Copyright (C) The Internet Society (2006).   This document is subject to the rights, licenses and restrictions   contained inBCP 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   Intellectual Property Rights or other rights that might be claimed to   pertain to the implementation or use of the technology described in   this document or the extent to which any license under such rights   might or might not be available; nor does it represent that it has   made any independent effort to identify any such rights.  Information   on the procedures with respect to rights in RFC documents can be   found inBCP 78 andBCP 79.   Copies of IPR disclosures made to the IETF Secretariat and any   assurances of licenses to be made available, or the result of an   attempt made to obtain a general license or permission for the use of   such proprietary rights by implementers or users of this   specification can be obtained from the IETF on-line IPR repository athttp://www.ietf.org/ipr.   The IETF invites any interested party to bring to its attention any   copyrights, patents or patent applications, or other proprietary   rights that may cover technology that may be required to implement   this standard.  Please address the information to the IETF at ietf-   ipr@ietf.org.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Park, et al.                Standards Track                     [Page 6]