Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network
Extracted elements (25)
DS-Lite (RFC 6333) covers only unicast services; without multicast extension, AFTR devices become replication points for downstream multicast traffic, sending multicast data over a unicast infrastructure and consuming downstream bandwidth. The solution extends DS-Lite to use IPv6 multicast distribution trees, preserving native multicast efficiency.
It is recommended to configure the mAFTR as the Rendezvous Point (RP) for the IPv4-embedded IPv6 multicast groups it manages, so that no PIM registration procedure is required and multicast distribution tree computation is simplified.
The address mapping is stateless: mPrefix64 (/96) maps IPv4 multicast group addresses to IPv6 multicast addresses by simple concatenation, while uPrefix64 maps IPv4 source addresses to IPv6 unicast addresses per RFC 6052. Stateless translation simplifies the solution and avoids per-flow state at translation points.
The solution supports both SSM and ASM but recommends SSM (per RFC 4607 Section 1) because SSM simplifies operation — RP placement considerations are no longer relevant and the translation mechanism is simpler.
The solution is not limited to DS-Lite and can be applied in other deployment contexts such as Lightweight 4over6 (RFC 7596) and MAP-E (RFC 7597). The same mPrefix64, uPrefix64, and address-building algorithm must be consistently configured on all mAFTR nodes for load balancing scenarios.
Version mismatches between IGMP and MLD may arise at the mB4 (e.g., IGMPv2 with MLDv2, or IGMPv3 with MLDv1). The mB4 should perform the router portion of the matching IGMP version and apply RFC 3376 Section 7 interaction for signaling with IPv4 receivers. IPv4 SSM requires MLDv2 in the IPv6 network.
A host implementing the built-in mB4 function MUST implement the behaviors of Sections 6.1 (IGMP-MLD interworking), 6.2 (multicast data forwarding), and 6.3 (fragmentation).
If SSM is deployed, the mB4 MUST construct the IPv6 source address (or retrieve the IPv4 source address) using uPrefix64.
The IGMP-MLD interworking address translation is stateless and MUST follow the address mapping specified in Section 5. The mB4 performs the host portion of MLD on the upstream interface, and the IPv6 membership composition MUST synchronize with the IGMP membership database.
The IPv4 source address MUST be mapped to an IPv6 source address using uPrefix64, and the uPrefix64 MUST be derived from the IPv6 unicast address space.
The mAFTR MUST fragment oversized IPv6 packets after encapsulation; the mB4 MUST reassemble IPv6 fragments, decapsulate the IPv6 header, and forward the IPv4 packet to subscribing hosts.
The mAFTR MUST interwork PIM Join/Prune messages: (*,G6) and (S6,G6) on the IPv6 side are mapped to corresponding (*,G4) and (S4,G4) on the IPv4 side. The mAFTR MUST process received PIMv6 Join messages by updating both TIB6 and TIB4 accordingly.
The mAFTR MUST use uPrefix64 to build the IPv6 source addresses derived from mPrefix64 and MUST advertise the route towards uPrefix64 with the IPv6 IGP so that IPv6 multicast routers can perform RPF checks.
The mPrefix64 MUST be derived from the corresponding IPv6 multicast address space (e.g., SSM_mPrefix64 must fall within the SSM multicast address range defined in RFC 4607).
The multicast address translation MUST follow the algorithm defined in Section 5.2: concatenate the 96-bit mPrefix64 with the 32-bit IPv4 address to form the IPv4-embedded IPv6 multicast address.
When multiple mPrefix64s are available with distinct scopes, the mB4 MUST select the IPv4-embedded IPv6 multicast prefix whose scope matches the IPv4 multicast address scope and does not exceed it. If no matching prefix is found and scope preservation is required, IPv6 multicast address mapping SHOULD fail.
When the mB4 receives an IPv6 multicast packet, it MUST check the group and source addresses. If the group prefix is mPrefix64 and source prefix is uPrefix64, the mB4 MUST decapsulate the IPv6 header per RFC 2473 and forward the IPv4 packet; otherwise the mB4 MUST silently drop the packet.
mPrefix64 is a /96 IPv6 multicast prefix provisioned to both mAFTR and mB4, used to construct IPv4-embedded IPv6 multicast addresses. It can be of type ASM_mPrefix64 (for ASM mode) or SSM_mPrefix64 (for SSM mode).
Two static and dynamic PIM triggering modes are defined. In Static Mode, the mAFTR is pre-configured with permanent (S6,G6) and (*,G6) TIB6 entries. In Dynamic Mode, (S6,G6) or (*,G6) entries are instantiated or withdrawn upon receipt of PIMv6 messages.
uPrefix64 is a /96 IPv6 unicast prefix provisioned to both mAFTR and mB4, used to construct IPv4-embedded IPv6 unicast source addresses from IPv4 source addresses per RFC 6052. It may be the Well-Known Prefix (64:ff9b::/96) or a Network-Specific Prefix.
An mB4 SHOULD be configured with appropriate information to preserve the scope of multicast messages when mapping IPv4 multicast addresses to IPv4-embedded IPv6 multicast addresses and vice versa, preventing scope escalation.
The CPE embedding the mB4 function SHOULD be configured to accept incoming MLD messages and traffic forwarded to subscribed multicast groups, while implicitly filtering unsubscribed groups.
The solution does not introduce new security concerns beyond those in RFC 6052 (Section 5), RFC 3810 (Section 10), and RFC 7761 (Section 6). Unlike unicast-mapping solutions, it does not exacerbate DoS attacks because multicast distribution is preserved.
The mAFTR maintains two TIBs (TIB4 and TIB6) bridged by an IPv4-in-IPv6 virtual interface. On receipt of PIMv6 Join (*,G6): update TIB6 entry (create if absent), extract G4, update TIB4 entry (create if absent). On receipt of multicast data: look up TIB4, encapsulate and look up TIB6, forward on IPv6 tree.
IPv4-embedded IPv6 multicast addresses are formed by concatenating the 96-bit mPrefix64 with the 32-bit IPv4 multicast address, yielding a 128-bit IPv6 address. Extraction reverses this: strip the known /96 prefix and take the last 32 bits as the IPv4 address.