From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4489.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc4489.txt (limited to 'doc/rfc/rfc4489.txt') 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] + -- cgit v1.2.3