Native IPv4 multicast in IPv6 Core using PIM
draft-venaas-pim-ipv4-in-ipv6-core-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Stig Venaas , Mankamana Prasad Mishra , Salah M. Buraiky | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-venaas-pim-ipv4-in-ipv6-core-01
PIM Working Group S. Venaas
Internet-Draft M. Mishra
Intended status: Standards Track Cisco Systems, Inc.
Expires: 7 January 2027 S. Buraiky
Aramco
6 July 2026
Native IPv4 multicast in IPv6 Core using PIM
draft-venaas-pim-ipv4-in-ipv6-core-01
Abstract
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.
Status of This Memo
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 Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Venaas, et al. Expires 7 January 2027 [Page 1]
Internet-Draft IPv4 in IPv6 Core using PIM July 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 3
3.1. RPF Handling . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Checksum . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. PIM Message Encoding . . . . . . . . . . . . . . . . . . 4
3.4. PIM Hello Messages . . . . . . . . . . . . . . . . . . . 4
3.5. PIM Join/Prune Messages . . . . . . . . . . . . . . . . . 4
3.6. Register Messages . . . . . . . . . . . . . . . . . . . . 5
3.7. Data Plane Requirements . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
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.
Venaas, et al. Expires 7 January 2027 [Page 2]
Internet-Draft IPv4 in IPv6 Core using PIM July 2026
2. Terminology
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.
3. Protocol Operation
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.
3.1. RPF Handling
Each PIM router must determine the RPF neighbor and interface for a
given (*,G) or (S,G).
1. 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.
2. 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.
3.2. Checksum
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].
Venaas, et al. Expires 7 January 2027 [Page 3]
Internet-Draft IPv4 in IPv6 Core using PIM July 2026
3.3. PIM Message Encoding
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.
3.4. PIM Hello Messages
Hello messages are processed as usual, except that the neighbor state
created would be for IPv6 neighbors since the source addresses are
IPv6 addresses.
3.5. PIM Join/Prune Messages
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.
Venaas, et al. Expires 7 January 2027 [Page 4]
Internet-Draft IPv4 in IPv6 Core using PIM July 2026
3.6. Register 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.
3.7. Data Plane Requirements
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.
4. Security Considerations
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.
5. IANA Considerations
IANA is requested to assign an IPv6 link-local multicast address for
ALL-PIM-4OVER6-ROUTERS TBD.
6. Acknowledgements
Thanks to David 'equinox' Lamparter for valuable input.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496,
DOI 10.17487/RFC5496, March 2009,
<https://www.rfc-editor.org/rfc/rfc5496>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/rfc/rfc7761>.
Venaas, et al. Expires 7 January 2027 [Page 5]
Internet-Draft IPv4 in IPv6 Core using PIM July 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K.
Patel, "Advertising IPv4 Network Layer Reachability
Information (NLRI) with an IPv6 Next Hop", RFC 8950,
DOI 10.17487/RFC8950, November 2020,
<https://www.rfc-editor.org/rfc/rfc8950>.
7.2. Informative References
[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
Layer Reachability Information with an IPv6 Next Hop",
RFC 5549, DOI 10.17487/RFC5549, May 2009,
<https://www.rfc-editor.org/rfc/rfc5549>.
Authors' Addresses
Stig Venaas
Cisco Systems, Inc.
Tasman Drive
San Jose, CA 95134
United States of America
Email: svenaas@cisco.com
Mankamana Mishra
Cisco Systems, Inc.
821 Alder Drive
Milpitas, CA 95035
United States
Email: mankamis@cisco.com
Salah M. Buraiky
Aramco
Email: salah.buraiky.1@aramco.com
Venaas, et al. Expires 7 January 2027 [Page 6]