]> Cisco Systems, Inc.

Tasman Drive San Jose CA 95134 United States of America svenaas@cisco.com

Cisco Systems, Inc.

821 Alder Drive Milpitas CA 95035 United States mankamis@cisco.com

Aramco

salah.buraiky.1@aramco.com

Routing PIM Working Group PIM IPv6 IPv4-over-IPv6 Multicast RPF Vector 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.

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

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 when, and only when, they appear in all capitals, as shown here.

Protocol Operation

PIM Message Encoding 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.

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

PIM Hello Option 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.

Register and Assert 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. 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 .

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.

Security Considerations This document does not change the security properties of . However, it introduces the handling of mixed-address-family control packets which implementations must validate to prevent malformed packet processing.

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

Normative References This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source. This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard. Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. [STANDARDS-TRACK] This document describes a use of the Protocol Independent Multicast (PIM) Join Attribute as defined in RFC 5384, which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.