More and more operational networks are migrating to support IPv6 transfer capabilities.
Because IPv6 is not backwards compatible with IPv4, a traditional approach that used to be promoted to network operators was to deploy dual stack architectures. Such architectures assume the allocation of an IPv6 prefix in addition to a global IPv4 address to endpoints, whereas IPv4 and IPv6 stacks embedded in network components can be solicited indifferently.
Dual stack architectures are expensive by design, and network operators are tempted to implement more optimal approaches with fewer transition steps — for example, IPv6-only networks.
IPv6-only deployments assume that IPv6-only transfer capabilities are enabled within a network, and in particular, only IPv6 prefixes are assigned to endpoints. Yet, network operators and service providers need to make sure that any Internet content (including IPv4-only content) can be accessed by end-users — this issue is often denoted as the IPv4 service continuity problem.
Several techniques have been standardized to address such issues — for example, DS-Lite, NAT64, MAP-E and Lightweight 4over6. Unfortunately, these mechanisms are designed to cover unicast delivery services.
Extending these mechanisms to process multicast traffic is not an option, since the benefits of IP multicast (resource optimization in the core networks) will be lost. Means to access multicast content from an IPv4 source over an IPv6-only network need to be supported while preserving the benefits of IP multicast (Figure 1).
Figure 1: Accessing IPv4 multicast contents over an IPv6 network where Protocol Independent Multicast (PIM) is activated.
RFC8114 to deliver IPv4 multicast services to IPv4 clients over an IPv6 multicast network
The IETF recently specified a new solution (RFC8114) to deliver IPv4 multicast services to IPv4 clients over an IPv6 multicast network. This solution relies on a stateless translation algorithm applicable to both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM) operations. This algorithm is enabled by the following functional elements:
- mB4: a functional entity that supports an IGMP-MLD Interworking function that translates the IGMP messages into the corresponding Multicast Listener Discovery (MLD) messages, and sends the MLD messages over the IPv6 network towards a MLD Querier. In addition, the mB4 decapsulates incoming IPv4-in-IPv6 multicast packets.
- mAFTR: a functional entity that receives and encapsulates the IPv4 multicast packets into IPv4-in-IPv6 packets. Also, it behaves as the corresponding IPv6 multicast source for the encapsulated IPv4-in-IPv6 packets.
In order to map the addresses of IPv4 multicast traffic with IPv6 multicast addresses, an IPv6 multicast prefix (mPrefix64) and an IPv6 unicast prefix (uPrefix64) are provided to the mAFTR and the mB4 elements (RFC8115). The mAFTR and the mB4 use mPrefix64 to convert an IPv4 multicast address (G4) into an IPv4-embedded IPv6 multicast address (G6). The mAFTR and the mB4 use uPrefix64 to convert an IPv4 source address (S4) into an IPv4-embedded IPv6 address (S6) as per RFC6052.
No coordination is required between the mB4 and the mAFTR because of the same mPrefix64 and uPrefix64.
When an IPv4 receiver connected to the device (typically a CPE) that embeds the mB4 capability wants to subscribe to an IPv4 multicast group, it sends an IGMP Report message towards the mB4. The mB4 creates the IPv6 multicast group (G6) address using mPrefix64 and the original IPv4 multicast group address. The mB4 uses G6 to create the corresponding MLD Report message. The mB4 sends the Report message towards the MLD Querier, which usually coexists with the PIM Designated Router (DR). The PIMv6 DR then sends the corresponding PIMv6 Join message to the mAFTR graft to the IPv6 multicast distribution tree. It can send either a PIMv6 Join (*,G6) in ASM contexts, or a PIMv6 Join (S6,G6) in SSM contexts.
Once the PIMv6 Join is received by the mAFTR, it will extract the IPv4 multicast group address (G4) and then process that message in the IPv4 leg of the multicast distribution tree. A branch of the multicast distribution tree is thus constructed, comprising both an IPv4 part (from the mAFTR upstream) and an IPv6 part (from mAFTR downstream towards the mB4).
Figure 2 summarizes the main technical characteristics of the solution.
Figure 2: Design principles for delivering IPv4 multicast services over an IPv6 multicast network.
What’s Next?
IPv4 multicast service continuity features are now being included as part of the Basic Requirements for IPv6 Customer Edge Routers effort currently conducted by the IPv6 Operations (v6ops) IETF Working Group.
Mohamed Boucadair is a senior architect with Orange.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.