> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/brc/transactions/0129.md). # IPv6 Multicast Group Address Assignments Jeff Harris () ## 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](/brc/peer-to-peer/0082.md) details a design for a scalable IPv6 multicast protocol for BSV transaction distribution. [BRC-124](/brc/transactions/0124.md) 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](https://www.rfc-editor.org/rfc/rfc8815) 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) ``` Byte: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [scope] [-------- IANA boundary zero -------] [GID] [IDX] FF 05 00 00 00 00 00 00 00 00 00 00 00 0B XX XX ``` Conformant deployments MUST use group-id `0x000B`. Operators MAY override the group-id (see [Group-ID Override](#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](#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)](#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](https://www.rfc-editor.org/rfc/rfc8815) 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](#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: ``` [MCPrefix][0x00 × 10][MCGroupID][IDX] ``` For example, with prefix `FF05` (ASM site-local), group-id `0x000B`, and shard index `0x0003`: ``` FF05:0000:0000:0000:0000:0000:000B:0003 ``` 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: ``` groupIndex = binary.BigEndian.Uint32(txid[0:4]) >> (32 - shardBits) ``` 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::FFFA` | `FF05:::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)](#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](/brc/transactions/0124.md). 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](/brc/transactions/0133.md)) and anchor ([BRC-134](/brc/transactions/0134.md)) 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). ``` -mc-group-id 0x000B # default (IANA Bitcoin) -mc-group-id 0xCAFE # private deployment / lab ``` 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](/brc/transactions/0124.md)), the NACK protocol ([BRC-126](/brc/transactions/0126.md)), 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](#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](https://www.rfc-editor.org/rfc/rfc3678) (`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](/brc/transactions/0126.md). ### 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](/brc/transactions/0132.md); the SubtreeID-to-group mapping announcements on `0xFFFC` are specified in [BRC-127](/brc/transactions/0127.md). ### 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:::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](/brc/transactions/0135.md). ### 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](https://www.rfc-editor.org/rfc/rfc8815)); inter-domain distribution uses the SSM address `FF3E::B:FFFE`. ## References * [BRC-82: Defining a Scalable IPv6 Multicast Protocol for Blockchain Transaction Broadcast and Update Delivery](/brc/peer-to-peer/0082.md) — Overall multicast protocol architecture * [BRC-124: Multicast Transaction Frame Format](/brc/transactions/0124.md) — Wire format for data-plane frames * [BRC-119: SubTree Unified Merkle Path (STUMP) Format](/brc/transactions/0119.md) — Subtree ID concept referenced by the subtree announcement groups * [BRC-126: NACK Retransmission Protocol](/brc/transactions/0126.md) — ADVERT beacon wire format and endpoint discovery * [BRC-127: Subtree Group Announcement Frame Format](/brc/transactions/0127.md) — SubtreeID-to-group mapping announcements on `0xFFFC` * [BRC-132: Multicast Subtree Data Frame Format](/brc/transactions/0132.md) — subtree data frames carried on the `0xFFFB` GroupSubtreeDataAnnounce group * BRC-139: Multicast Shard Manifest Announcement Protocol — distributes the active publisher source set used for SSM data-plane source discovery * [RFC 4607: Source-Specific Multicast for IP](https://www.rfc-editor.org/rfc/rfc4607) — defines the `FF3x::/32` SSM address range * [RFC 3678: Socket Interface Extensions for Multicast Source Filters](https://www.rfc-editor.org/rfc/rfc3678) — `MCAST_JOIN_SOURCE_GROUP` `(S,G)` join API * [RFC 8815: Deprecating Any-Source Multicast (ASM) for Interdomain Multicast](https://www.rfc-editor.org/rfc/rfc8815) — rationale for SSM-only global scope --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://hub.bsvblockchain.org/brc/transactions/0129.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.