Native IPv4 multicast in IPv6 Core using PIM

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, (formerly ), 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 . Furthermore, it defines a well-known link-local IPv6 multicast group address that is used for sending IPv4 PIM messages over IPv6.

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 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.

RPF Handling 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 ), this information is used for the RPF lookup.
Alternatively, the RPF Vector 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.

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 .

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.

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.

PIM Join/Prune Messages A PIM Join/Prune message sent under this specification uses the normal Join/Prune message format defined in , 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.

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.

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.