| Internet-Draft | IPv4 in IPv6 Core using PIM | July 2026 |
| Venaas, et al. | Expires 7 January 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 7 January 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.¶
In order for IPv4 PIM to communicate with IPv4 PIM neighbors without requiring IPv4 interface addresses, we define a new ALL-PIM-4OVER6-ROUTERS link-local IPv6 multicast group TBD that is used instead of the regular ALL-PIM-ROUTERS group. This is used for all PIM messages that in PIM Sparse-Mode [RFC7761] are sent to the ALL-PIM-ROUTERS group.¶
Note that on a given interface, IPv4 PIM MUST operate in either the regular mode using ALL-PIM-ROUTERS or in this new 4over6 mode using ALL-PIM-4OVER6-ROUTERS. This determines which address link-local PIM messages are sent to. The IPv4 PIM protocol instance MUST process only one mode on the interface. However, an implementation MAY log or count messages received for the other mode.¶
Processing of link-local messages using the new mode is the same as before with a few exceptions.¶
Each PIM router must determine the RPF neighbor and interface for a given (*,G) or (S,G).¶
If core routers have a RIB with IPv4 prefixes and IPv6 next-hops (e.g., via [RFC8950]), this information is used for the RPF lookup.¶
Alternatively, the RPF Vector [RFC5496] can be used. This allows an egress core router to include RPF vector(s) with the IPv6 address(es) of the ingress core routers in the PIM Join message. By doing so, the core network does not require IPv4 unicast routing information.¶
IPv4 PIM messages sent to an IPv6 address are sent as IPv6 packets and the checksum is calculated using an IPv6 "pseudo-header" as defined for IPv6 in [RFC7761].¶
This document uses IPv6 packets to carry PIMv2 control messages for constructing IPv4 multicast forwarding state across an IPv6-only core. The IPv6 Next Header value for these packets is 103, identifying PIM.¶
For link-local PIM messages sent under this specification, the IPv6 source address MUST be the link-local address of the sending interface. The IPv6 destination address MUST be the link-local multicast address ALL-PIM-4OVER6-ROUTERS. The IPv6 Hop Limit MUST be 1.¶
Hello messages are processed as usual, except that the neighbor state created would be for IPv6 neighbors since the source addresses are IPv6 addresses.¶
A PIM Join/Prune message sent under this specification uses the normal Join/Prune message format defined in [RFC7761], with the following address-family rules:¶
The Upstream Neighbor Address field MUST be an IPv6 Encoded-Unicast Address. It identifies the upstream PIM neighbor on the link over which the Join/Prune is sent.¶
The Multicast Group Address field MUST be an IPv4 Encoded-Group Address.¶
The Joined Source Address and Pruned Source Address fields MUST be IPv4 Encoded-Source Addresses.¶
Thus, the IPv6 packet header and the Join/Prune Upstream Neighbor Address identify the IPv6 PIM adjacency used in the core, while the group and source information carried in the Join/Prune message identifies IPv4 multicast state.¶
Within one Join/Prune message sent under this specification, all Multicast Group Address fields, Joined Source Address fields, and Pruned Source Address fields MUST be of the same address family, and that address family MUST be IPv4. A router MUST NOT mix IPv4 and IPv6 group or source addresses in the same Join/Prune message. If both IPv4-over-IPv6 multicast state and native IPv6 multicast state need to be signaled to the same neighbor, they MUST be sent in separate PIM messages.¶
It is assumed that Rendezvous Points (RPs) are located outside of the core; therefore, no special handling for PIM Register messages is defined in this document.¶
An IPv6 core router must be able to detect native IPv4 packets received on the (S,G) incoming interface (for switching to the Shortest Path Tree) and on Outgoing Interface Lists (OIFs) for Assert handling.¶
This document does not change the security properties of [RFC7761]. IPv4 PIM message are sent with IPv6 headers and if IPsec is used, it would be for IPv6.¶
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.¶