| Internet-Draft | IPv4 in IPv6 Core using PIM | February 2026 |
| Venaas, et al. | Expires 29 August 2026 | [Page] |
This document describes how PIM Sparse-Mode can be used to construct IPv4 multicast trees across an IPv6-only network core. It specifies the use of IPv6 PIM messages to carry IPv4 group and source addresses, the use of RPF vectors for reachability, and a new Hello Option to signal support for this capability.¶
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 29 August 2026.¶
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, [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].¶
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.¶
[RFC7761] uses an encoding for all IP addresses that specifies the address family. This allows a PIM message with an IPv6 header to contain IPv4 addresses. This document proposes exchanging PIM Join/Prune messages with IPv6 headers and IPv6 target addresses, where the Source or Group addresses within the message may be IPv4.¶
It is assumed that all sources in a group record are of the same address family as the group itself.¶
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 [RFC5549]), 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.¶
To ensure interoperability, a new PIM Hello Option is probably needed. A router would include this option to indicate that it accepts PIM messages with IPv6 headers containing IPv4 source and group addresses.¶
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.¶
PIM Assert messages MUST use an IPv6 header and contain IPv4 source and group information. If an RPF vector is used, it MUST be used for the metric calculation as specified in Section 3.3.3 of [RFC5496].¶
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]. However, it introduces the handling of mixed-address-family control packets which implementations must validate to prevent malformed packet processing.¶
If we decide to use a hello option, IANA will be requested to assign a new PIM Hello Option type from the "PIM Hello Options" registry for the option described in this document.¶