Unicast-Prefix-based IPv6 Multicast Addresses
RFC 3306

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]