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/rfc3306.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc3306.txt (limited to 'doc/rfc/rfc3306.txt') diff --git a/doc/rfc/rfc3306.txt b/doc/rfc/rfc3306.txt new file mode 100644 index 0000000..363af6b --- /dev/null +++ b/doc/rfc/rfc3306.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group B. Haberman +Request for Comments: 3306 Consultant +Category: Standards Track D. Thaler + Microsoft + August 2002 + + + Unicast-Prefix-based 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 (2002). All Rights Reserved. + +Abstract + + This specification defines an extension to the multicast addressing + architecture of the IP Version 6 protocol. The extension presented + in this document allows for unicast-prefix-based allocation of + multicast addresses. By delegating multicast addresses at the same + time as unicast prefixes, network operators will be able to identify + their multicast addresses without needing to run an inter-domain + allocation protocol. + +Table of Contents + + 1. Introduction....................................................2 + 2. Motivation......................................................2 + 3. Terminology.....................................................2 + 4. Multicast Address Format........................................2 + 5. Address Lifetime................................................4 + 6. Source-Specific Multicast Addresses.............................4 + 7. Examples........................................................4 + 8. Security Considerations.........................................5 + 9. References......................................................5 + Author's Address...................................................6 + Full Copyright Statement...........................................7 + + + + + + + +Haberman & Thaler Standards Track [Page 1] + +RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002 + + +1. Introduction + + This document specifies an extension to the multicast portion of the + IPv6 addressing architecture [ADDRARCH]. The current architecture + does not contain any built-in support for dynamic address allocation. + This proposal introduces encoded information in the multicast address + to allow for dynamic allocation of IPv6 multicast addresses and IPv6 + source-specific multicast addresses. + +2. Motivation + + The current IPv4 multicast address allocation architecture [RFC 2908] + is based on a multi-layered, multi-protocol system. The goal of this + proposal is to reduce the number of protocols that need to be + deployed in order to get dynamic multicast address allocation. + + The use of unicast prefix-based multicast address allocation will, at + a minimum, remove the need to run the Multicast Address Allocation + Protocol (AAP) [AAP WORK] and the Multicast Address-Set Claim (MASC) + Protocol [RFC 2909]. + +3. Terminology + + 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 [RFC 2119]. + +4. Multicast Address Format + + Section 2.7 of [ADDRARCH] defines the following operational format of + IPv6 multicast addresses: + + | 8 | 4 | 4 | 112 | + +--------+----+----+---------------------------------------------+ + |11111111|flgs|scop| group ID | + +--------+----+----+---------------------------------------------+ + + + + + + + + + + + + + + + +Haberman & Thaler Standards Track [Page 2] + +RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002 + + + This document introduces a new format that incorporates unicast + prefix information in the multicast address. The following + illustrates the new format: + + | 8 | 4 | 4 | 8 | 8 | 64 | 32 | + +--------+----+----+--------+--------+----------------+----------+ + |11111111|flgs|scop|reserved| plen | network prefix | group ID | + +--------+----+----+--------+--------+----------------+----------+ + + +-+-+-+-+ + flgs is a set of 4 flags: |0|0|P|T| + +-+-+-+-+ + + o P = 0 indicates a multicast address that is not assigned + based on the network prefix. This indicates a multicast + address as defined in [ADDRARCH]. + + o P = 1 indicates a multicast address that is assigned based + on the network prefix. + + o If P = 1, T MUST be set to 1, otherwise the setting of the T + bit is defined in Section 2.7 of [ADDRARCH]. + + The reserved field MUST be zero. + + plen indicates the actual number of bits in the network prefix field + that identify the subnet when P = 1. + + network prefix identifies the network prefix of the unicast subnet + owning the multicast address. If P = 1, this field contains the + unicast network prefix assigned to the domain owning, or allocating, + the multicast address. All non-significant bits of the network + prefix field SHOULD be zero. + + It should be noted that the Interface Identifier requirements in + Section 2.5.1 of [ADDRARCH] effectively restrict the length of the + unicast prefix to 64 bits, hence the network prefix portion of the + multicast address will be at most 64 bits. + + Group ID is set based on the guidelines outlined in [IPV6 GID]. + + The scope of the unicast-prefix based multicast address MUST NOT + exceed the scope of the unicast prefix embedded in the multicast + address. + + + + + + + +Haberman & Thaler Standards Track [Page 3] + +RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002 + + +5. Address Lifetime + + The lifetime of a unicast prefix-based multicast address SHOULD NOT + exceed the Valid Lifetime field in the Prefix Information option, + corresponding to the unicast prefix being used, contained in the + Neighbor Discovery Router Advertisement message [RFC 2461]. The + lifetime of the multicast address is needed to support the Abstract + API for Multicast Address Allocation [RFC 2771]. + + It should be noted that the unicast prefix's Valid Lifetime in the + Router Advertisement message does not indicate that the prefix will + become invalid at the end of the lifetime. Rather, that value is + typically a constant until a renumbering event is scheduled after + which, the prefix does become invalid. + + The use of unicast prefix-based multicast addresses after the unicast + prefix has become invalid may lead to operational problems. For + example, routers that perform policy checks comparing the multicast + prefix against the unicast prefix assigned to an AS may discard the + packet. + +6. Source-Specific Multicast Addresses + + The unicast prefix-based IPv6 multicast address format supports + Source-specific multicast addresses, as defined by [SSM ARCH]. To + accomplish this, a node MUST: + + o Set P = 1. + o Set plen = 0. + o Set network prefix = 0. + + These settings create an SSM range of FF3x::/32 (where 'x' is any + valid scope value). The source address field in the IPv6 header + identifies the owner of the multicast address. + +7. Examples + + The following are a few examples of the structure of unicast prefix- + based multicast addresses. + + - Global prefixes - A network with a unicast prefix of + 3FFE:FFFF:1::/48 would also have a unicast prefix-based + multicast prefix of FF3x:0030:3FFE:FFFF:0001::/96 (where 'x' + is any valid scope). + + - SSM - All IPv6 SSM multicast addresses will have the format + FF3x::/96. + + + + +Haberman & Thaler Standards Track [Page 4] + +RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002 + + +8. Security Considerations + + It is possible that the embedded unicast prefix can aid in + identifying the allocation domain of a given multicast address, + though an allocation domain choosing to avoid being traced has no + obstacles currently to creating addresses using a prefix not assigned + to it, or using a smaller scope embedded prefix. + + Using source-specific multicast addresses can sometimes aid in the + prevention of denial-of-service attacks by arbitrary sources, + although no guarantee is provided. A more in-depth discussion of the + security considerations for SSM can be found in [SSM ARCH]. + +9. References + + [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [RFC 2908] Thaler, D., Handley, M. and D. Estrin, "The Internet + Multicast Address Allocation Architecture", RFC 2908, + September 2000. + + [AAP WORK] Handley, M. and S. Hanna, "Multicast Address Allocation + Protocol (AAP)", Work In Progress. + + [RFC 2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., + Kumar, S. and D. Thaler, "The Multicast Address-Set Claim + (MASC) Protocol", RFC 2909, September 2000. + + [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1999. + + [IPV6 GID] Haberman, B., "Dynamic Allocation Guidelines for IPv6 + Multicast Addresses", RFC 3307, June 2002. + + [RFC 2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + + [RFC 2771] Finlayson, R., "An Abstract API for Multicast Address + Allocation", RFC 2771, February 2000. + + + + +Haberman & Thaler Standards Track [Page 5] + +RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002 + + + [SSM ARCH] Holbrook, H. and B. Cain, "Source-Specific Multicast for + IP", Work In Progress. + +Author's Address + + Brian Haberman + Consultant + Phone: 1-919-949-4828 + EMail: bkhabs@nc.rr.com + + Dave Thaler + Microsoft Corporation + One Microsoft Way + Redmond, WA 48105-6399 + Phone: 1-425-703-8835 + EMail: dthaler@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Haberman & Thaler Standards Track [Page 6] + +RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Haberman & Thaler Standards Track [Page 7] + -- cgit v1.2.3