summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4489.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4489.txt')
-rw-r--r--doc/rfc/rfc4489.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc4489.txt b/doc/rfc/rfc4489.txt
new file mode 100644
index 0000000..70eb824
--- /dev/null
+++ b/doc/rfc/rfc4489.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group J-S. Park
+Request for Comments: 4489 M-K. Shin
+Updates: 3306 H-J. Kim
+Category: Standards Track ETRI
+ April 2006
+
+
+ A Method for Generating Link-Scoped IPv6 Multicast Addresses
+
+Status 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 updates RFC 3306.
+
+Table of Contents:
+
+ 1. Introduction ....................................................2
+ 2. Applicability ...................................................2
+ 3. Link-Scoped Multicast Address Format ............................3
+ 4. Example .........................................................3
+ 5. Consideration of Lifetime .......................................4
+ 6. Security Considerations .........................................4
+ 7. Acknowledgements ................................................4
+ 8. References ......................................................5
+
+
+
+
+
+
+
+
+Park, et al. Standards Track [Page 1]
+
+RFC 4489 Link-Scoped IPv6 Multicast April 2006
+
+
+1. 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 2006
+
+
+3. 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 2006
+
+
+5. 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 2006
+
+
+8. References
+
+8.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.kr
+
+
+
+Park, et al. Standards Track [Page 5]
+
+RFC 4489 Link-Scoped IPv6 Multicast April 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 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 in BCP 78 and BCP 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 at
+ http://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]
+