RFC 3306

Unicast-Prefix-based IPv6 Multicast Addresses

📅 published September 2002, from ietf

RFC 3306: Unicast-Prefix-based IPv6 Multicast Addresses 💖

okay bestie, RFC 3306 is a total multicast glow-up 🦋 It was written by Brian Haberman (Consultant) and Dave Thaler (Microsoft). It's a Standards Track document dated August 2002, and its title block doesn't list anything it obsoletes or updates.

  • Network Working Group
  • Request for Comments: 3306
  • Category: Standards Track
  • Authors: B. Haberman (Consultant), D. Thaler (Microsoft)
  • Date: August 2002

Status of This Memo ✨

this is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🎀

this spec adds an extension to the multicast addressing architecture of IP Version 6 (IPv6). The extension lets you allocate multicast addresses based on unicast prefixes. Because multicast addresses get delegated right alongside unicast prefixes, network operators can recognize their own multicast addresses without running 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

1. Introduction 🧚

this doc extends the multicast part of the IPv6 addressing architecture [ADDRARCH]. The current architecture has no built-in support for dynamic address allocation, so this proposal encodes extra info into the multicast address. That makes dynamic allocation possible for IPv6 multicast addresses and for IPv6 source-specific multicast addresses 👑

2. Motivation 💜

the current IPv4 multicast address allocation architecture [RFC 2908] is a multi-layered, multi-protocol system, and that's a lot. The goal here is to cut down on how many protocols you need to deploy in order to get dynamic multicast address allocation 😭

Using unicast prefix-based multicast address allocation will, at a minimum, get rid of 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 read as described in [RFC 2119] ✨

4. Multicast Address Format 🦋

Section 2.7 of [ADDRARCH] defines the standard operational format of IPv6 multicast addresses. Here's how it looks:

   |    8   |  4 |  4 |                     112                     |
   +--------+----+----+---------------------------------------------+
   |11111111|flgs|scop|                  group ID                   |
   +--------+----+----+---------------------------------------------+

This document introduces a new format that bakes unicast prefix info right into the multicast address. The layout is:

   |   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|
                               +-+-+-+-+
  • P = 0 means the multicast address is not assigned based on the network prefix. It's a multicast address as defined in [ADDRARCH].
  • P = 1 means the multicast address is assigned based on the network prefix.
  • 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 is the actual number of bits in the network prefix field that identify the subnet when P = 1.

The network prefix field identifies the network prefix of the unicast subnet that owns the multicast address. When P = 1, this field holds the unicast network prefix assigned to the domain that owns, or allocates, the multicast address. All non-significant bits of the network prefix field SHOULD be zero.

Worth noting: the Interface Identifier requirements in Section 2.5.1 of [ADDRARCH] effectively cap the unicast prefix at 64 bits. So the network prefix portion of the multicast address is at most 64 bits, no more 🙈

Group ID is set using the guidelines in [IPV6 GID].

The scope of a unicast-prefix based multicast address MUST NOT exceed the scope of the unicast prefix embedded in it 💅

5. Address Lifetime ⭐

The lifetime of a unicast prefix-based multicast address SHOULD NOT exceed the Valid Lifetime field in the Prefix Information option for the unicast prefix being used. That option lives in the Neighbor Discovery Router Advertisement message [RFC 2461]. The multicast address lifetime is needed to support the Abstract API for Multicast Address Allocation [RFC 2771] 🎀

Heads up: the unicast prefix's Valid Lifetime in the Router Advertisement does not mean the prefix becomes invalid when that lifetime ends. The value is usually a constant until a renumbering event is scheduled, and only then does the prefix actually become invalid.

using unicast prefix-based multicast addresses after the unicast prefix has become invalid may lead to operational problems 💀

For example, routers that run 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 do that, a node MUST:

  • Set P = 1.
  • Set plen = 0.
  • 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 🌈

Here are a few examples of what unicast prefix-based multicast addresses look like 👑

  • Global prefixes: a network with the unicast prefix 3FFE:FFFF:1::/48 would also have the unicast prefix-based multicast prefix FF3x:0030:3FFE:FFFF:0001::/96 (where 'x' is any valid scope).
  • SSM: every IPv6 SSM multicast address will have the format FF3x::/96.

8. Security Considerations 🔥

this part is serious, so please read it carefully 🙈

The embedded unicast prefix can help someone identify the allocation domain of a given multicast address. An allocation domain that wants to avoid being traced still has no obstacles to creating addresses with a prefix that isn't assigned to it, or with a smaller-scope embedded prefix.

Source-specific multicast addresses can sometimes help prevent denial-of-service attacks from arbitrary sources. However, no guarantee is provided. For a more in-depth look at SSM security considerations, see [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.

[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

Copyright (C) The Internet Society (2002). All Rights Reserved.

Legal bits, kept word for word:

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 ✨

📦 where this page comes from