| Internet-Draft | 6man-sub-link-scope-multicast | July 2025 |
| Lamparter | Expires 26 January 2026 | [Page] |
The IPv6 addressing architecture for multicast has the scope of a multicast group embedded in its address, with the smallest non-reserved scopes being interface-local and link-local, numbered 1 and 2. This document suggests the introduction of a scope inbetween these two, for use with lower-layer transport multicast that reaches parts of a link. Since there is no room to insert a scope value for this, a separate address block is used. A mapping for Ethernet as lower-layer transport is provided.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 26 January 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This draft lives at https://github.com/eqvinox/6man-sub-link-scope-multicast ¶
A major application of IPv6 multicast is in discovery protocols to find other systems participating in the same protocol on the same link. These applications commonly use an IPv6 multicast address in the ff02::/16 range, i.e. scoped to the link.¶
In some cases however, it is useful to further limit the scope of discovery for an application. In particular, a device's immediate attachment segment to a layer 2 domain (i.e. switch) is useful for hybrid layer 2/3 setups (e.g. EVPN [EVPN]), as well as for situations where the first layer 2 hop might be trusted but other participants in the broadcast domain are not.¶
Ongoing work in this area has resorted to using LLDP [LLDP] as a transport and encapsulating their data, e.g. [BGP-LLDP] and [HOSTRT-LLDP]. However, LLDP was designed as a layer 2 discovery protocol, and its use in such applications has drawbacks like limiting choice on the actual scope getting used, interacting nontrivially with STP, complicating security considerations, and first and foremost creating dependencies between components that are normally independent of each other.¶
The desirable functionality in these cases is not necessarily LLDP itself, but rather the limited scope of propagation for the discovery protocol. This document exposes these scopes for use in IPv6 multicast.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The representation of addresses in this document introduces two fields, "linktype" and "linkspecific". The former is used to index into new IANA-managed allocations of values identifying lower-layer link technologies. Given that value, the latter is then used to identify a particular lower-link multicast behavior.¶
Packets with a multicast destination address of this structure behave as follows:¶
[MCASTARCH] defines the structure of IPv6 multicast addresses as follows:¶
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | +--------+----+----+----+----+--------+----------------+----------+ |11111111|ff1 |scop|ff2 |rsvd| plen | network prefix | group ID | +--------+----+----+----+----+--------+----------------+----------+¶
With ff1 as follows:¶
+-+-+-+-+ |X|Y|P|T| +-+-+-+-+¶
The combination of P = 1, T = 0 was explicitly forbidden. This document redefines that combination to indicate a sub-link scoped multicast address.¶
For an IPv6 multicast address with this combination of bits, the scope value MUST be set to 2. The following further structure is defined:¶
| 8 | 4 | 4 | 4 | 4 | 72 bits | 32 bits | +--------+----+----+----+----+--------------+----------+ |11111111|XY10|0010|ff2 |type| linkspecific | group ID | +--------+----+----+----+----+--------------+----------+¶
The (non-constant) fields are as follows:¶
No meaning is defined for the X and Y bits, as well as the flags in the ff2 field. They MUST be sent as zero and packets received with nonzero values MUST be discarded until some other document assigns some meaning to them. (The use of an embedded RP address is nonsensical for a multicast group that is never forwarded, as such the interpretation of Y to signal an embedded RP address is not applicable here.)¶
There is no conflict with the "plen"/"network prefix" fields used in other multicast addresses since the scope defined here is less than even a link. Deriving unique addresses on a larger scale is thus unnecessary.¶
The use of P = 1, T = 0 with other scope values other than 2 is not specified by this document, currently reserved, and available for future use elsewhere.¶
to be decided¶
While multicast group addresses as outlined in this document fit the existing multicast socket interface outlined in [BASICSOCKET] and [SSMSOCKET], the following considerations apply:¶
Ethernet is by far the most commonly used lower-layer link technology carrying IPv6 at this point. For Ethernet's less than whole link multicast addresses, [IPV6oETH] is updated for the following more specific address format and mapping:¶
| 8 | 4 | 4 | 4 | 4 | 24 bits | 48 bits | 32 bits | +--------+----+----+----+----+------------+----------+----------+ |11111111|øø10|0010|øøøø|1110| MAC_suffix | reserved | group ID | +--------+----+----+----+----+------------+----------+----------+ maps to: 01-80-C2-MAC_suffix¶
(The "ø" symbol is used to indicate reserved flag fields that are currently required to be zero.)¶
The (non-constant) fields are as follows:¶
While 802.1Q does not currently define any specific behavior outside of the range 01:80:C2:00:00:00 to 01:80:C2:00:00:3F, the entire block is made representable in the interest of future proofing.¶
This section is applicable to all link layers using MAC-48 addresses and the forwarding behavior described in 802.1Q. This notably also includes 802.11, despite the additional multicast considerations for wireless networks.¶
Since the destination address in a received Ethernet frame indicates which multicast scope it was distributed to, it MUST be verified to match the MAC suffix in the IPv6 address as noted in Section 3. [MCinUC] MUST NOT be applied.¶
When joining any of these groups on a layer 2 forwarding device's IPv6 stack, the join MUST NOT affect forwarding behavior for Ethernet frames addressed to these Ethernet multicast addresses, including IPv6 packets. Whether or not these groups are forwarded or not is solely defined by IEEE 802.1Q.¶
Since the 802.1Q definitions have mostly been made with an intent of a specific use case, they do not directly express a forwarding scope, rather a forwarding scope is derived from their use. However, some of the addresses have shifted into functioning as scope indicator. The use of such addresses is RECOMMENDED and at the time of creation of this document they were, in ascending distribution size:¶
The above list is a recommendation only, and ultimately it is up to the architects developing a particular use of sub-link scoped multicast to choose an appropriate group given the constraints and behavior in the IEEE 802 standards.¶
The following groups SHOULD be automatically joined by all IPv6 nodes implementing this specification:¶
Additionally, the following group SHOULD be joined by all IPv6 routers implementing this specification:¶
(A TPMR also being a router is considered self-contradictory, it would no longer fulfill the IEEE 802.1Q criteria for a TPMR. The ff22:e00:e::1 group is therefore omitted.)¶
Group identifiers for multicast addresses in this range function the same way as identifiers for other scopes. In particular:¶
The ::1 and ::2 group identifiers are assigned to the same function they have in the link-local scope. However, since there is a multitude of group addresses with these group identifiers, but different link layer specific values in the upper part of the address, recommendations to automatically join some of these groups are only made in the definitions of link layer specific mappings.¶
Exposing the limited scope multicast functionality from lower layers can be used to improve security properties of discovery protocols since there is then a guarantee that the packet originated from a limited set of devices.¶
However, to achieve this gain in security, it is paramount that operating systems in fact implement the discard requirements described in section Section 3 MUST absolutely be enforced by all implementations.¶
This document requests the update of one IANA registry and creation of two new IANA registries, all in the IPv6 Multicast Address Space Registry group.¶
The description and applicability of the "Variable Scope Multicast Addresses" registry to add to the notes:¶
The addresses assigned here are also applicable to the Sub-Link scope, with the FF0X: prefix being replaced with "FF22:" in that case.¶
New registry:¶
The initial contents of the registry are:¶
| "linktype" (hex) | Lower-Layer protocol | Reference/Procedure |
| 0 … D | reserved | IETF Review |
| E | Ethernet (and compatible) | [this document] |
| F | Experimental | Experimental |
This registry is created as a blank copy of the "Link-Local Scope Multicast Addresses" registry, with the "variable scope allocation" entries also copied, but none of the actual allocations. The second to sixth 16-bit chunk of the IPv6 address are replaced with an asterisk for the copied entries. The following text is added to the "Note":¶
Bits 16 to 95 (0-based counting) of addresses in this scope are populated with a link layer identifier and link layer specific scope information as documented in the reference document.¶
The following entries are added on top of the variable scope allocation entries:¶
| Address(es) | Description | Reference/Procedure |
| FF22:*:*:*:*:*:0:1 | All Nodes in this Scope | [this document] |
| FF22:*:*:*:*:*:0:2 | All Routers in this Scope | [this document] |
The "Change Controller" and "Last Reviewed" fields are left empty, "Date Registered" is filled appropriately for this document.¶
none yet¶
As there will be some delay until operating systems provide this functionality, it is worth pointing out that it can be emulated by using whatever lower-layer socket interface is also used by LLDP. In most cases this is an interface to Ethernet frames. The application needs then handle the extra headers, i.e. adding and removing Ethernet, IPv6, and likely UDP headers. This is likely quite doable since the values in these headers will be almost entirely static.¶
This document updates [IPV6oETH], [MCASTARCH] and [MCinUC].¶