IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages
Extracted elements (15)
GRE/IPv4 encapsulation is reused for Type 4 S-PMSI Joins carrying IPv6 customer flows, consistent with the encapsulation already defined in RFC 6513 Section 12 for Type 1 (IPv4) flows. This avoids defining a new tunnel type and keeps the P-tunnel mechanism uniform regardless of customer address family.
IPv4-mapped IPv6 addresses (per RFC 4291) are used as the IPv6 source address for both S-PMSI Join UDP datagrams and IPv6 PIM control messages. This approach allows IPv6 customer signaling to traverse an IPv4 provider infrastructure without requiring dual-stack P-tunnels, maintaining a single PIM instance for P-tunnel construction.
RFC 6513 defined Type 1 S-PMSI Joins for IPv4 customer flows and did not cover IPv6 customer flows. RFC 6516 extends that specification by adding Type 4 for IPv6 flows; implementations of RFC 6513 alone cannot bind IPv6 (C-S,C-G) flows to PIM/IPv4 P-tunnels.
A single UDP datagram MAY carry multiple S-PMSI Join messages. If multiple S-PMSI Joins are present in one datagram, they MUST all be of the same S-PMSI Join type.
A Type 4 S-PMSI Join MUST be encapsulated in an IPv6 UDP datagram. The IPv6 source address SHOULD be the IPv4-mapped IPv6 address corresponding to the IPv4 address the originating PE uses as its PIM source address for the specified P-tunnel.
The end of the last S-PMSI Join in a UDP datagram (as determined by the S-PMSI Join length field) MUST coincide with the end of the UDP datagram as determined by the UDP length field.
The IPv6 Source Address of PE-originated IPv6 PIM control messages SHOULD be the IPv4-mapped IPv6 address corresponding to the IPv4 address the originating PE uses as its PIM source address for the specified P-tunnel.
The Reserved field in the Type 4 S-PMSI Join SHOULD be set to zero when transmitted and MUST be ignored when received.
When processing a received UDP datagram containing one or more S-PMSI Joins, a router MUST process all S-PMSI Joins that fit into the datagram.
When the IPv6 Destination Address for PE-PE PIM control messages is the ALL-PIM-ROUTERS multicast address, the IPv6 form ff02::d MUST be used rather than an IPv4 or IPv4-mapped form.
PE-PE PIM/IPv6 over an IPv4 P-tunnel: when the VPN customer uses PIM over IPv6 but the SP uses an IPv4 infrastructure, PE routers originate IPv6 PIM control messages that are encapsulated in GRE/IPv4 rather than transmitted natively over the SP network.
Type 4 S-PMSI Join is defined to assign a customer IPv6 (C-S,C-G) flow to a P-tunnel created by PIM/IPv4. Data and control packets on the P-tunnel are sent using GRE/IPv4 encapsulation. This complements the existing Type 1 S-PMSI Join, which handles IPv4 customer flows.
The IANA 'S-PMSI Join Message Type Field' registry (created by RFC 6513) is updated with a new entry: Value 4, Description 'GRE S-PMSI for IPv6 traffic (unaggregated)'.
There are no additional security considerations introduced by this document beyond those already specified in RFC 6513 for the base MVPN specification.
Type 4 S-PMSI Join message: Type (8 bits, value 4), Length (16 bits, value 40 octets), Reserved (8 bits), C-source (128 bits, IPv6 customer source address), C-group (128 bits, IPv6 customer group address), P-group (32 bits, IPv4 group address identifying the GRE P-tunnel).