Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

IPv6 Multicast Group Address Assignments

Jeff Harris (jeff@lightweb.net)

Abstract

This BRC specifies the IPv6 multicast group address scheme for the BSV transaction sharding pipeline. It defines how the 16-bit shard index space is allocated across data-plane shard groups and control-plane service groups, how addresses are derived from the IANA Bitcoin multicast allocation, and the canonical addresses for beacon discovery, subtree announcement, and the block control channel. The scheme defines addressing for both Any-Source Multicast (ASM, the default) and Source-Specific Multicast (SSM) transport modes, selected per deployment without any change to the frame, NACK, or sharding semantics.

Copyright

This BRC is licensed under the Open BSV License.

Motivation

BRC-82 details a design for a scalable IPv6 multicast protocol for BSV transaction distribution. BRC-124 defines a multicast transmission wire frame format. Both reference a set of multicast group addresses without specifying a canonical address scheme. As the multicast infrastructure is deployed across multiple scopes (site-local, organisation-local, and global) and across independent operator networks, a shared addressing convention is needed so that:

  1. Any deployment with shardBits ≤ 12 produces data-plane group indices that are orthogonal to control-plane groups.

  2. Control-plane services — beacon discovery, subtree announcements, and block control — use stable, well-known addresses operators can pre-configure in firewalls and routing policy.

  3. Operators running private or test networks can use an alternative group-id to isolate their multicast address space without modifying any other aspect of the protocol.

  4. Deployments can run the data plane under Source-Specific Multicast for inter-domain scale — RFC 8815 deprecates inter-domain ASM — using the same group-id and shard-index conventions, so addresses differ only in their high-order prefix.

Specification

IANA Allocation

IANA allocates IPv6 multicast group addresses on the 96-bit boundary: the top 96 bits (bytes [0:12]) identify the IANA-assigned group, leaving the bottom 32 bits (bytes [12:16]) for sub-allocation by the assignee.

The IANA Bitcoin multicast allocation is FF0X::B (group-id 0x000B). This BRC splits the bottom 32 bits of that allocation into two 16-bit subfields:

  • Bytes [12:14] — IANA group-id (default 0x000B)

  • Bytes [14:16] — shard index (16-bit, application-assigned)

Conformant deployments MUST use group-id 0x000B. Operators MAY override the group-id (see Group-ID Override) for testing or private deployments. Deployments using different group-ids operate in entirely disjoint multicast address spaces.

This bottom-32-bit split (group-id in bytes [12:14], shard index in bytes [14:16]) is identical under both source modes defined in Source Mode and Address Range; only the high-order prefix bytes [0:2] differ.

Source Mode and Address Range

The fabric runs in one of two source modes. Any-Source Multicast (ASM) is the default; Source-Specific Multicast (SSM) is an opt-in transport mode for deployments that need inter-domain distribution (see Source-Specific Multicast (SSM)). The source mode selects the address range via the multicast prefix byte [1], which encodes flags(4 bits) | scope(4 bits):

  • ASM uses the well-known permanent prefix (flags = 0) → FF0x.

  • SSM uses the RFC 4607 SSM range FF3x::/32 (flags = 3) → FF3x.

The scope nibble (5 site-local, 8 organisation-local, E global) is unchanged between modes. Because RFC 8815 deprecates inter-domain ASM, global scope is SSM-only.

Mode
Site scope (intra-domain)
Global scope (inter-domain)

ASM

FF05::B:idx

not supported (RFC 8815)

SSM

FF35::B:idx

FF3E::B:idx

The group-id (0x000B) and the shard-index field are preserved across modes — only the high 32 bits change. All addresses elsewhere in this BRC are written in their ASM (FF0x) form; under SSM, substitute the corresponding FF3x prefix.

Address Derivation

Every multicast group address in the BSV shard pipeline is derived from three components:

  1. Multicast prefix (MCPrefix, 2 bytes) — the first two bytes of the IPv6 address, encoding flags(4) | scope(4). Under ASM: FF05 (site-local), FF08 (organisation-local), FF0E (global). Under SSM: FF35, FF38, FF3E for the same scopes (see Source Mode and Address Range).

  2. IANA group-id (MCGroupID, 2 bytes) — occupies bytes [12:14]. Default: 0x000B.

  3. Shard group index (IDX, 2 bytes) — occupies bytes [14:16].

The full 128-bit address is assembled as:

For example, with prefix FF05 (ASM site-local), group-id 0x000B, and shard index 0x0003:

Compressed form: FF05::B:3. The same group under SSM site-local is FF35::B:3 and under SSM global is FF3E::B:3 — only the prefix changes.

Data-Plane Shard Groups

Shard group indices MUST occupy the range 0x0000–0x0FFF (4,096 indices). The maximum permitted value is shardBits = 12 (4,096 groups), which keeps all shard indices within this range. Indices at or above 0x1000 MUST NOT be used as shard group indices.

The group index for a transaction is derived deterministically from its TxID:

Implementations MUST use only the low 16 bits of groupIndex when assembling the multicast address.

Free Space and Specialty Transmission Domains

Indices 0x1000–0xF7FF (56,832 indices) are unassigned and reserved for future use. This range accommodates future expansion of the shard group space, as well as specialty transmission domains for purpose-specific multicast services that are not general-purpose transaction sharding. No current protocol assigns addresses in this range. Implementations MUST NOT join or transmit to addresses in this range unless explicitly specified by a future BRC.

Control-Plane Reserved Indices

Network service groups occupy 0xF800–0xFFFF (2,048 indices). Current protocol assignments are allocated from the top of this range; the remainder is reserved for future network services. Implementations MUST NOT use unassigned indices within this range. The defined assignments MUST be supported at the scopes indicated; additional scopes are permitted where operationally necessary.

Index
Purpose
Scope
Full address (default group-id)
Compressed

0xFFFA

Block Header egress (BRC-135)

varies

FF05:0000:0000:0000:0000:0000:<egress-gid>:FFFA

FF05::<egress-gid>:FFFA

0xFFFB

Subtree Announcements (site)

FF05

FF05:0000:0000:0000:0000:0000:000B:FFFB

FF05::B:FFFB

0xFFFB

Subtree Announcements (org)

FF08

FF08:0000:0000:0000:0000:0000:000B:FFFB

FF08::B:FFFB

0xFFFB

Subtree Announcements (global)

FF0E

FF0E:0000:0000:0000:0000:0000:000B:FFFB

FF0E::B:FFFB

0xFFFC

Subtree Group Announcements (site)

FF05

FF05:0000:0000:0000:0000:0000:000B:FFFC

FF05::B:FFFC

0xFFFC

Subtree Group Announcements (org)

FF08

FF08:0000:0000:0000:0000:0000:000B:FFFC

FF08::B:FFFC

0xFFFC

Subtree Group Announcements (global)

FF0E

FF0E:0000:0000:0000:0000:0000:000B:FFFC

FF0E::B:FFFC

0xFFFD

Beacon (site)

FF05

FF05:0000:0000:0000:0000:0000:000B:FFFD

FF05::B:FFFD

0xFFFD

Beacon (org)

FF08

FF08:0000:0000:0000:0000:0000:000B:FFFD

FF08::B:FFFD

0xFFFD

Beacon (global)

FF0E

FF0E:0000:0000:0000:0000:0000:000B:FFFD

FF0E::B:FFFD

0xFFFE

Block Broadcast channel

FF0E

FF0E:0000:0000:0000:0000:0000:000B:FFFE

FF0E::B:FFFE

0xFFFF

(reserved)

—

reserved

do not use

The addresses above are shown in their ASM (FF0x) form. Under SSM, substitute the FF3x prefix for the same scope (FF35 site, FF3E global) — the group-id and index are unchanged. For example, the beacon group becomes FF35::B:FFFD (site) or FF3E::B:FFFD (global). See Source-Specific Multicast (SSM).

Virtual HashKey Ingredient Indices

Several control-plane frame types share GroupBlockBroadcast (0xFFFE) as their egress multicast destination but must form independent per-sender flows so each carries its own monotonic SeqNum counter. The proxy's flow key is (senderIPv6, groupIdx, subtreeID); to keep these flows separate while still emitting to the same multicast group, the proxy substitutes a distinct virtual groupIdx into the HashKey computation defined in BRC-124. These virtual indices are never assembled into an actual IPv6 multicast address and MUST NOT be joined or transmitted to; they exist only as inputs to the XXH64 HashKey derivation.

Virtual index
Constant
Used by
Egress group

0xFFF8

GroupCoinbaseFlow

BRC-133 coinbase tx

0xFFFE

0xFFF9

GroupAnchorFlow

BRC-134 anchor tx

0xFFFE

BRC-131 block announcements continue to use 0xFFFE itself as the HashKey ingredient, so coinbase (BRC-133) and anchor (BRC-134) frames remain distinct flows from block announcements even though all three egress to FF0E::B:FFFE.

Group-ID Override

The 16-bit IANA group-id field (bytes [12:14]) is configurable via the -mc-group-id flag (environment variable MC_GROUP_ID). The default is 0x000B (IANA Bitcoin allocation).

All group addresses — both shard and network-service — inherit the same group-id. Deployments using different group-ids are entirely isolated at the multicast layer with no protocol changes required.

Source-Specific Multicast (SSM)

SSM is a transport mode only: the frame format (BRC-124), the NACK protocol (BRC-126), the HashKey computation, and the shard derivation are all unchanged. SSM affects only the address range (the high 32 bits, per Source Mode and Address Range) and how receivers join a group:

  • Joins. Under ASM, receivers perform an any-source (*,G) join. Under SSM, receivers perform a source-specific (S,G) join per RFC 3678 (MCAST_JOIN_SOURCE_GROUP), one join per (source, group) pair.

  • Distinct source per publisher. Each publisher MUST emit from a distinct, stable unicast source address (bindSource). This is required by PIM-SSM reverse-path forwarding and preserves the per-publisher HashKey flow identity. Anycast or shared-source emission is not supported under SSM; a deployment needing a single stable identity SHOULD use VRRP active-standby (failover, not load distribution).

  • Source discovery. Receivers must learn the set of publisher sources for each group before issuing (S,G) joins:

    • Data-plane sources are distributed via the shard manifest protocol (BRC-139), whose announcements carry the active publisher source set; a receiver unions the sources across currently-valid manifests.

    • Control-plane groups (beacon, manifest, subtree announcement) are joined against per-group bootstrap source lists configured out of band (IPv6 literals or DNS names re-resolved on refresh), since their sources cannot be discovered from within the group itself.

Beacon Groups

Beacon groups (0xFFFD) carry ADVERT messages that enable listeners to discover retry endpoint addresses without manual configuration. Each beacon-enabled service instance advertises to exactly one scope group, selected via -beacon-scope. Deployments requiring coverage across multiple scopes run separate service instances per scope. The beacon protocol is specified in BRC-126.

Subtree Announcements

Subtree Announcement groups (0xFFFB) carry signed announcements of a subtree's transaction IDs and their ordering within the subtree's Merkle structure. The subtree ID is the Merkle root hash of the announced set. Listeners subscribe to this group to discover transaction batches for downstream filtering. The subtree data frame format carried on this group is specified in BRC-132; the SubtreeID-to-group mapping announcements on 0xFFFC are specified in BRC-127.

Subtree Group Announcements

Subtree Group Announcement groups (0xFFFC) carry batched announcements of new subtree inclusions in a logical group of subtrees. This enables listeners to discover related transaction groupings and configure automated filtering for special-interest downstream networks. Like beacon and subtree announcement groups, multiple scopes are supported.

Block Header Egress Channel

FF05::<egress-gid>:FFFA (index 0xFFFA) is used by listener nodes to re-emit standalone BRC-135 block header frames to downstream consumers such as SPV wallets and header-chain validators. The scope and group-id are configured independently of the ingress fabric via the listener's egress flags, allowing isolation of the egress domain. BRC-135 frames MUST NOT be re-injected onto FF0E::B:FFFE to avoid feedback loops. The block header frame format is specified in BRC-135.

Block Broadcast Channel

Index 0xFFFE (global scope) is a mandatory channel distributing block headers, block templates, coinbase transactions, chained-transaction anchors, and other producer data of interest to all network participants. All conformant network participants MUST join this group. The concrete address depends on the source mode: under ASM the channel is FF0E::B:FFFE and is intra-domain only (inter- domain ASM is deprecated by RFC 8815); inter-domain distribution uses the SSM address FF3E::B:FFFE.

References

PreviousMulticast Extended Transaction Frame FormatNextMulticast Transaction Frame Fragmentation

Last updated

Was this helpful?