IPv4 - IPv6 Multicast Gateway

Introduction

There exist several transition solutions for unicast IP. For multicast very little exists. We have developed a multicast gateway that can translate between IPv4 and IPv6 multicast, and give an entire IPv6 PIM-SM domain access to IPv4 multicast.

How it works

The gateway can be deployed in a IPv6 PIM-SM domain, and the entire domain will be able to use the gateway without any other modifications. The only requirement is that the gateway is known to be an RP for a /96 multicast prefix. The prefix can be chosen by the administrator deploying the gateway. The RP mapping is configured as usual; static, BSR, embeded-RP or other means throughout the domain. By domain we mean simply a convex part of the internet where every router has this RP mapping.

The IPv4 multicast space is embedded into IPv6 using this /96 prefix. The IPv4 address is simply appended to the /96 to construct the respective IPv6 multicast address. An application on a host in the domain, can send traffic to any IPv4 multicast group (might be limited by scope) a.b.c.d by sending to the respectve IPv6 group PREFIX:a.b.c.d. That is, the /96 prefix with a.b.c.d appended. The application may also join the group PREFIX:a.b.c.d to receive all IPv4 multicast sent to a.b.c.d. Also note that if multiple hosts are sending to or joining PREFIX:a.b.c.d they will be able to send to and receive from eachother as usual.

Since the gateway is the RP for the chosen /96 prefix, it will be able to receive all data sent to PREFIX:a.b.c.d so that it can resend it as IPv4 multicast to a.b.c.d. It will also know whether there are any hosts interested in receiving traffic from PREFIX:a.b.c.d. If that is the case, it will join the IPv4 group a.b.c.d and resend all traffic received from it. Note that IPv6 hosts can send without joining. And also that this allows communications in both directions, and you might have say a video conference with multiple IPv6 participants all using PREFIX:a.b.c.d and multiple IPv4 participants all using a.b.c.d. Everyone should be able to send to and/or receive from all others.

More details

Seen from IPv4, the gateway is just a normal host using IGMP. It might join and send to a large number of IPv4 groups. In IPv6 it acts as a PIM router and is an RP for some /96 prefix.

In this example, an IPv6 host somewhere in the PIM domain wants to receive data from the IPv4 multicast group 224.2.240.176. The gateway is here deployed using the prefix ff3e:30:2001:700:1:ffff::/96, and is an RP for this prefix. This RP must be defined on all the routers on the path from the IPv6 host to the RP. To join the IPv4 group, the IPv6 host joins ff3e:30:2001:700:1:ffff:224.2.240.176, or written the usual way it becomes ff3e:30:2001:700:1:ffff:e002:f0b0. PIM joins are being propagated towards the gateway as usual, building a shared tree or RPT. When the RP (gateway) detects that there are listeners, it will look at the last 32 bits of the address, and see that it's the multicast group 224.2.240.176. It will then join this IPv4 group as a normal IPv4 host. The data received is being resent. In IPv6 the source of the packets will appear to be the gateway.

Here we look at what happens when the IPv6 host sends packets to the group. The first-hop router will as usual encapsulate the packets into PIM register messages, and send them to the RP, which is the gateway. The gateway will then send the data to the respective IPv4 group, using its IPv4 address as source address. As usual the gateway will also forward the data packets towards IPv6 listeners. Also, as usual, the gateway might build shortest path tree (SPT) towards the source, and receive packets natively.

Implementations

A prototype implementation is available. The current implementation is a bit hard to deploy and the performance could be better. It has been deployed in the M6Bone for more than a year, with several people using it regularly. It appears to work well at least under the current load. The implementation as it is, requires a host running BSD with pim6sd to act as the RP. It can run completely standard pim6sd, it just needs to be configured as the RP for the chosen /96 prefix. Then there is a perl script that monitors the pim6sd to detect when an IPv6 host sends to or joins a group inside the /96 prefix. Then there is a separate application that currently needs to run on a Linux machine, that does the actual translation between IPv4 and IPv6. There's a TCP session from this application to the perl script. The perl script tells it which groups to translate. For each of the groups, the application joins both the IPv4 groups and the respective IPv6 groups, and resends all packets received from IPv4 groups to the respective group IPv6 groups, and vice versa.

The current implementation is available here.

Session announcement translation

To make the gateway more userfriendly and more transparent to end-users, one might try to translate session announcements. For an SDP file containing IPv4 multicast addresses, one would like to replace them with the corresponding IPv6 multicast addresses. Which addresses depends on which /96 prefix is picked for the gateway. A tool has been implemented that listens to IPv4 SAP announcements, and resends them to the IPv6 SAP group with translated addresses. Hence a user on an IPv6 host can simply run a tool like sdr, and receive all IPv4 announcements, and join them the usual way. Whether it's IPv4 or IPv6 need not matter to the user.

Let's look at an example.

Here we are using sdr, and we're looking at the announcement for the IPv4 group "Places all over the world".

Here we're still in sdr, at an IPv6 host looking at the translated announcement. Unfortunately the entire group address isn't visible, but it's been rewritten as the corresponding IPv6 address, and we see that the source of the announcement is an IPv6 address. That's the address of the host running the SAP translator.

The source for the SAP translator is available here. Instructions are in the beginning of the file.

M6Bone Deployment

The gateway and the SAP translator is deployed by UNINETT, and is available to everyone in the M6Bone. Currently the /96 prefix ff3e:30:2001:700:1:ffff:/96 is used. Throughout the M6Bone the gateway is announced as an RP for this prefix using BSR. So in the M6Bone if you want to join an IPv4 group like "Places all over the world" with address 224.2.172.238, you need to join ff3e:30:2001:700:1:ffff:224.2.172.238. With e.g. vic, you could in IPv4 do "vic 224.2.172.238/51482". For IPv6 you will need to do "vic ff3e:30:2001:700:1:ffff:224.2.172.238/51482". There might be some systems that can't cope with this address syntax. So alternatively, one can do "vic ff3e:30:2001:700:1:ffff:e002:acee/51482".

Since the SAP translator is also deployed. You can find all the IPv4 announcements by running sdr for IPv6. They will be prefixed by "zmcgw". You should find e.g. "zmcgw: Places all over the world". So simply click on this and you should be able receive as usual.