| Internet-Draft | IPv4 in IPv6 Core using PIM | November 2026 |
| Venaas, et al. | Expires 6 May 2027 | [Page] |
This document describes how PIM Sparse-Mode can be used to construct IPv4 multicast trees across an IPv6-only network core. This allows forwarding of native IPv4 multicast data packets. The document specifies how to send and receive IPv4 PIM messages with IPv6 headers, using a new well-known link-local IPv6 multicast address, and the use of RPF vectors for reachability.¶
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 6 May 2027.¶
Copyright (c) 2026 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.¶
In typical network deployments, it is preferred that the network core remains simple, pushing complexity to the edge. One such case involves providing a mix of IPv4 and IPv6 unicast and multicast at the edge while deploying only one address family (IPv6) in the core.¶
For unicast, [RFC8950] (formerly [RFC5549]) allows building a RIB with IPv4 prefixes that have IPv6 next-hops, removing the requirement for IPv4 addresses on core routers. This allows native IPv4 unicast packets to be forwarded through a network without IPv4 addresses.¶
This document describes how to build IPv4 multicast trees and construct IPv4 multicast forwarding tables to allow native IPv4 multicast through a network without IPv4 addresses, using PIM Sparse-Mode [RFC7761]. Furthermore, it defines a well-known link-local IPv6 multicast group address that is used for sending IPv4 PIM messages over IPv6.¶
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.¶
This document updates [RFC7761] to support IPv4 PIM using IPv6 headers for IPv4 PIM link-local messages. This includes establishing PIM neighborships over IPv6. Except where modified below, the procedures and state machines of [RFC7761] apply.¶
For each interface, a router either uses IPv4 headers for all PIM link-local messages, operating according to [RFC7761], or it uses IPv6 headers for all PIM link-local messages and follows the modified procedures in this document. An interface using IPv6 headers is referred to as a 4over6 interface. All IPv4 PIM routers on the same link MUST be configured to operate in the same mode. This ensures that all routers on the link can receive one another's messages as needed.¶
On a 4over6 interface, IPv4 multicast sources, groups, and Rendezvous Points are identified by IPv4 addresses, while adjacent PIM routers are identified by IPv6 addresses. The use of IPv6 for PIM control messages does not change the address family of the multicast forwarding state or multicast data packets. A router MAY use ordinary IPv4 PIM on some interfaces and 4over6 operation on others. Both types of interface participate in the construction of IPv4 multicast trees.¶
On each interface, IPv4 PIM MUST operate either using ordinary IPv4 PIM transport or using the IPv6 transport specified in this document. It MUST NOT operate in both modes simultaneously on the same interface.¶
Hello, Join/Prune, and Assert messages sent on a 4over6 interface MUST use:¶
The sending interface's IPv6 link-local address as the IPv6 source address.¶
ALL-PIM-4OVER6-ROUTERS as the IPv6 destination address.¶
An IPv6 Hop Limit of 1.¶
An IPv6 Next Header value of 103.¶
The PIM checksum MUST be calculated and verified using the IPv6 pseudo-header procedure specified in Section 4.9 of [RFC7761]. The address family of the multicast state carried in the message does not determine the checksum procedure.¶
A router MUST associate messages received for ALL-PIM-4OVER6-ROUTERS with IPv4 PIM operation on the receiving interface. Messages received for ordinary IPv4 PIM or native IPv6 PIM MUST NOT establish or refresh a 4over6 adjacency.¶
Just as regular IPv4 PIM and native IPv6 PIM may operate concurrently on the same interface, one MAY operate IPv4 PIM with 4over6 and native IPv6 PIM concurrently on the same interface. They are distinguished by using ALL-PIM-4OVER6-ROUTERS and ALL-PIM-ROUTERS destination addresses respectively.¶
For IPv4 multicast state, the source address S, group address G, and RP address RP(G) used in [RFC7761] remain IPv4 addresses.¶
On a 4over6 interface, references in link-local PIM procedures to a router's primary interface address refer to its IPv6 link-local address. This interpretation applies to neighbor identification, DR election, Join/Prune targeting, and Assert processing.¶
References identifying a multicast source or RP retain their IPv4 interpretation. In particular, the use of an IPv6 primary interface address for PIM adjacency procedures does not replace an IPv4 RP address or change whether the local router is the RP for a group.¶
A neighbor identity MUST distinguish the interface on which the neighbor is reachable and the PIM operation to which the adjacency belongs. Identical IPv6 link-local addresses on different interfaces, or in native IPv6 PIM and 4over6 operation, MUST NOT cause the corresponding neighbors to be treated as one adjacency.¶
The procedures in Section 4.3 of [RFC7761] apply to 4over6 operation, with the address interpretation specified above.¶
A neighbor's primary address is the IPv6 link-local source address of its Hello messages. Neighbor liveness, Generation ID processing, Hello option processing, and the requirement to send a Hello before sending Join/Prune or Assert messages apply within the 4over6 adjacency context.¶
An implementation MUST support the Address List Hello option for IPv6 addresses. When present in a 4over6 Hello, this option MUST contain only IPv6 addresses. Its processing follows Section 4.3.4 of [RFC7761] and provides the mapping from an IPv6 next-hop address to the neighbor’s primary IPv6 link-local address.¶
DR election MUST consider the neighbors participating in 4over6 operation on the interface. Where the election requires an address comparison, the primary IPv6 link-local addresses MUST be compared numerically as 128-bit unsigned values.¶
Hello messages received for native IPv6 PIM MUST NOT affect 4over6 neighbor liveness, DR election, or Hello option negotiation.¶
Changing an interface between ordinary IPv4 PIM and 4over6 operation MUST cause the old adjacencies to be removed and new adjacencies to be established using the selected mode. The resulting neighbor changes are processed by the IPv4 PIM state machines.¶
The RPF procedures MUST distinguish the address identifying the root of an IPv4 multicast tree from the address identifying an adjacent upstream router.¶
When IPv4 routing information with IPv6 next hops is available, the RPF lookup is performed for the IPv4 source S or IPv4 RP address RP(G), as appropriate. The selected route is resolved to an outgoing interface and an adjacent next hop. On a 4over6 interface, that next hop is identified by an IPv6 address.¶
Alternatively, an egress core router MAY include an IPv6 RPF Vector identifying the ingress core router toward the IPv4 source or RP. The Join Attribute procedures of [RFC5384] and the RPF Vector procedures of [RFC5496] apply. Where a vector applies, the RPF interface and next hop for the corresponding IPv4 multicast tree are determined toward the IPv6 vector address. The IPv4 source and RP addresses identifying the tree are unchanged.¶
For the functions defined in Section 4.1.5 of [RFC7761]:¶
MRIB.next_hop(S) and MRIB.next_hop(RP(G)) can return IPv6 next-hop addresses when the selected interface uses 4over6 operation.¶
NBR(I,A) MUST map the resolved IPv6 next-hop address A to the primary IPv6 link-local address of the corresponding 4over6 neighbor on interface I.¶
RPF'(*,G), RPF'(S,G), and RPF'(S,G,rpt) can identify IPv6-addressed neighbors, including neighbors selected through Assert processing.¶
On a 4over6 interface, next-hop-to-neighbor mapping MUST use the primary and secondary IPv6 address information associated with the appropriate adjacency. A native IPv6 PIM adjacency MUST NOT be used to identify a usable upstream neighbor for IPv4 multicast.¶
On a 4over6 interface, if the resolved next hop cannot be associated with a 4over6 neighbor on the selected interface, no usable RPF neighbor is available through that next hop.¶
Comparisons between RPF neighbors MUST compare their scoped neighbor identities. An implementation MUST NOT assume that the address family of an RPF neighbor is the same as that of S, G, or RP(G).¶
The [RFC7761] handling of directly connected sources and locally rooted trees continues to apply.¶
A Join/Prune message sent on a 4over6 interface MUST use:¶
An IPv6 Encoded-Unicast Address for the Upstream Neighbor Address.¶
IPv4 Encoded-Group Addresses for multicast groups.¶
IPv4 Encoded-Source Addresses for joined and pruned sources, including entries identifying an IPv4 RP.¶
The Upstream Neighbor Address MUST identify the upstream neighbor by its primary IPv6 link-local address on the transmitting interface.¶
For these messages, this specification overrides the address-family matching guidance in Section 4.9.5 of [RFC7761]. A receiver MUST accept the combination of an IPv6 upstream-neighbor address and IPv4 group and source addresses. It MUST NOT discard otherwise valid IPv4 entries because their address family differs from that of the upstream-neighbor address or outer IP header.¶
IPv4 and IPv6 multicast group or source entries MUST NOT be combined in one Join/Prune message.¶
In the downstream state machines of Section 4.5 of [RFC7761], a Join/Prune addresses the local router when its Upstream Neighbor Address matches the local IPv6 link-local address on the receiving interface.¶
In upstream processing, including Join suppression and prune override, the Upstream Neighbor Address identifies a 4over6 neighbor on that interface. The corresponding events and actions operate on IPv4 multicast state.¶
When constructing and dividing Join/Prune messages to fit the IPv6 interface MTU, implementations MUST account for the IPv6 header and IPv6 Upstream Neighbor Address.¶
Assert and AssertCancel messages on a 4over6 interface MUST use IPv4 Encoded-Group and Encoded-Unicast Source Addresses. Where a zero source address is used for a wildcard Assert, it is encoded as the IPv4 address 0.0.0.0.¶
The Assert sender and Assert winner are identified by their IPv6 neighbor identities. An implementation MUST be able to store an IPv6-addressed Assert winner for IPv4 multicast state.¶
For the metric calculations in Section 4.6.3 of [RFC7761], my_ip_address(I) is the local IPv6 link-local address on interface I. Address tie-breaking MUST compare the primary IPv6 link-local addresses numerically as 128-bit unsigned values.¶
Routing preference and metric are obtained from the routing information used for the applicable tree’s RPF selection, including the vector-related metric procedures of [RFC5496] where applicable.¶
An IPv6-addressed Assert winner MUST be usable as the replacement RPF neighbor in the [RFC7761] state summarization functions and upstream state machines.¶
The IPv4 PIM state machines MUST process changes to IPv6-addressed upstream neighbors, including changes resulting from routing updates, neighbor loss, Generation ID changes, and Assert processing.¶
The procedures for joining a new upstream neighbor, pruning an old upstream neighbor, and refreshing state following an upstream restart apply to these neighbors.¶
The forwarding and SPT-switching procedures in Section 4.2 of [RFC7761] operate on native IPv4 multicast packets. Comparisons involving RPF'(S,G) and RPF'(*,G), including those used to set the SPTbit, MUST use the neighbor identities specified in this document.¶
A router MUST support the reception indications needed to process native IPv4 multicast traffic on 4over6 interfaces, including traffic received on an incoming interface for SPT switching and traffic received on an outgoing interface for Assert processing.¶
Local receiver membership for IPv4 multicast remains IPv4 membership information, such as that obtained through IGMP. The IPv6 transport used for PIM messages does not change the membership protocol.¶
This specification assumes that RPs are outside the IPv6 core. It does not define IPv6 transport for IPv4 PIM Register or Register-Stop messages.¶
ASM deployments MUST provide IPv4 unicast connectivity between source DRs and RPs sufficient to carry these messages. This connectivity can use IPv4 unicast forwarding through the core or a separately provided transport. RPF Vectors do not themselves provide this connectivity.¶
This specification does not define transport of IPv4 Bootstrap messages across 4over6 interfaces. Deployments requiring ASM MUST provide the necessary IPv4 group-to-RP mappings through configuration or another mechanism whose operation across the deployment is independently supported.¶
The security considerations of [RFC7761] apply. In particular, forged Hello, Join/Prune, and Assert messages can disrupt multicast forwarding or consume router and network resources. This specification changes the transport and neighbor addressing used for these messages; it does not introduce a new authentication mechanism.¶
An attacker with access to a link on which 4over6 operation is enabled can attempt to influence IPv4 multicast forwarding by sending IPv6 PIM messages, without having an IPv4 address on that link. The use of IPv6 link-local addresses, a link-local multicast destination, and a Hop Limit of 1 limits the intended scope of communication but does not authenticate the sender. Receipt of a Hello message alone is not proof that a neighbor is authorized.¶
Access controls and control-plane protection used for IPv4 PIM need to account for IPv6 packets addressed to ALL-PIM-4OVER6-ROUTERS. Policies that permit or deny native IPv6 PIM do not necessarily express the intended policy for 4over6 operation. Where neighbor restrictions are configured, they need to identify the permitted IPv6 neighbors on the appropriate interfaces.¶
IPv4 multicast RPF selection can depend on IPv6 routing information. Consequently, unauthorized changes to the IPv6 routes used to resolve upstream neighbors or RPF Vectors can disrupt IPv4 multicast forwarding. The routing information on which this resolution depends requires protection consistent with its role in IPv4 multicast operation.¶
When RPF Vectors are used, the security considerations of [RFC5496] also apply. Forged vectors can influence upstream selection and cause incorrect tree construction. Deployments may restrict accepted vectors to addresses identifying permitted ingress core routers.¶
If IPsec is used to protect link-local PIM messages, as described in [RFC5796], its policies and security associations need to cover the IPv6 transport and ALL-PIM-4OVER6-ROUTERS destination used by this specification. Protection configured for ordinary IPv4 PIM or native IPv6 PIM does not automatically cover these messages.¶
Multicast data packets remain native IPv4 packets. IPv4 data-plane access controls and multicast boundary policies therefore remain applicable independently of the protections used for IPv6 PIM control messages.¶
IANA is requested to assign an IPv6 link-local multicast address for ALL-PIM-4OVER6-ROUTERS TBD.¶
Thanks to David 'equinox' Lamparter for valuable input.¶