IPv4-IPv6 Multicast Transition Technologies

     The need for IPv6 support for multicast has been established for the next generation Internet and large multicast address space is planned for this purpose. Though, the number of IPv6 nodes increasing after its implementation, lots of IPv4 nodes will still remain for their success. Therefore, IPv6 won磘 replace IPv4 in a short time, they will co-exist for years. During that time an IPv6-only network will appear on a regional-basis according to IPv6 deployment strategy. In this case, pure IPv4 and pure IPv6 networks will co-exist and interleave.

      It is therefore highly desirable to develop a mechanism that enables direct communications between IPv4 nodes and IPv6 nodes in order to advance the transition smoothly. So far, a number of such mechanisms have been proposed but they are applied only to unicast communication instead of multicast. However, now the mechanism is not emphasized in the study as an important direction in deployment, it is drawing increasing attention of regulators and standard bodies[1-4].

1 Multicast Transition Technologies

1.1 Dual Stack Technology
The solution for the transition with dual stack multicast is in fact the mixed addition of an IPv4-only multicast network and an IPv6-only multicast network. For unicast we can try to make servers dual stack and IPv4-only and IPv6-only hosts can easily access them. Similarly, a multicast source can be made dual stack and it can stream to both IPv4 and IPv6 groups to allow all hosts that run different protocol stacks to reach the multicast packets.

      We can deploy the IPv4 and IPv6 multicast in a dual stack network. The routers and hosts can simultaneously do IPv4 and IPv6 multicast and both can be done over the same network links. A router could also be a Rendezvous Point (RP) for the IPv4 and IPv6 groups.

      The easiest and commonest scenario is that of a single source sending data to a number of clients. If the streaming data is within a closed environment where all potential receivers support the same IP protocol, the source will just use this IP protocol. In a more open environment where the potential receivers and which IP protocols they support are unknown, to ensure that all of them will be able to receive, one source for IPv4 and one for IPv6 are needed. In this case, both sources use the same source data.

      When there are a few sources only, all sources can be configured as dual stack and send messages to IPv4 and IPv6 groups at the same time. However, in a videoconference where almost everyone receives and sends data, some participants have IPv4-only hosts and some others have IPv6-only hosts,  the dual stack solution would fail. In addition, the dual stack approach will double the bandwidth consumption.

      The dual stack solution is the easiest to be implemented as it needs no additional device or additional translation of multicast data. It applies when an IPv4 host doesn磘 have to communicate with an IPv6 host, for example, in the case of content distribution.

1.2 Protocol Translation Technology
Without the modification of infrastructure, protocol translation technology enables an IPv6 host to communicate with any IPv4 multicast group via common IPv6 multicast protocol, just as it does with an IPv6 multicast group. The idea is to have one or more translation devices on the path(s) between sources that use one IP protocol and receivers that use another IP protocol. In some rare cases, translation might also be carried out within the sending or receiving host. This can be useful on a dual stack host where the application used only supports one IP protocol. Translation can be done in several ways:

      (1) Reflector

      For IPv4, the reflector is usually adopted when global multicast fails. The Virtual Rooms Videoconferencing System (VRVS) is a typical example of reflector applications. The VRVS uses pure multicast on the core network and sets up a reflector, as multicast agent for regions not allowed direct multicast. The core network connects to a reflector in unicast mode while the reflector connects to terminal systems in pure multicast or unicast mode.
Rather than reflecting between unicast and multicast,

      IPv4-IPv6 multicast reflector reflects between IPv4 and IPv6 multicast. For a given IPv4 group address, port, and a given IPv6 group address and port, the reflector will join both groups and monitor the corresponding ports. All data received from one group will be resent to the other.

      The reflector can be deployed in two ways in the IPv6 evolution process. One is, when the content provider uses a protocol not widely supported, and the host and application don磘 support both IP protocols and it puts the reflector near the source. The other is, when the receiver uses a protocol different from that of the source and it puts the reflector near the receiver.

      The disadvantage of the reflector solution lies in its low performance (not able to support large-scale multicast applications). In addition, the reflector needs to run one instance for each session and it will receive and resend data even if there are no receivers.

      Because of the above limitations, the reflector can be used for resending multicast for many groups, but the number of sessions will be limited. If it were used in the network, the users would have to contact an administrator and ask specific sessions to be allocated for a limited time. Alternatively, as with Tunnel Broker, a web authentication or other means may possibly be taken for automating the session allocation process.

      (2) Gateway
      The multicast transition technologies have been developed later than the unicast. Therefore, it partly made use of the earlier-developed unicast transition technologies. For example, they both adopt the dual stack approach, which is the same in both technologies. The reflector technology works at the transport layer, thus obviating header conversion, which reminds us of the similar TCP/UDP relay technology for unicast transition. The IPv4-IPv6 multicast gateway scheme is similar to the Network Address Translation-Protocol Translation (NAT-PT) solution.

      NAT-PT[5] has been originally proposed for unicast purposes and thus not quite applicable for multicast. Based on the NAT-PT principle and with the multicast features considered, the IPv4-IPv6 multicast gateway technology has been optimized and improved.

      The idea of gateway is to embed IPv4 multicast addresses into IPv6 by putting a specific "/96" IPv6 prefix to the addresses, such that for each IPv4 multicast address there is a respective IPv6 multicast address. Likewise, each IPv6 address corresponds to an IPv4 address. In the multicast transition, IPv4 addresses are mapped to IPv6 addresses one to one, which is a very important feature for the IPv4-IPv6 multicast gateway. This feature helps with smooth protocol translation.

      This gateway could be placed on the border between an IPv4 and an IPv6 network or inside a dual stack network. It could be used within a single site or organization, or offered as a service in a large network. If necessary, several gateways may be deployed in the same network.

      The gateway has two main limitations. One is that it is insensitive to the validity limit of the IPv4 multicast group member and source. The other is that IPv4 users can only access IPv6 multicast sessions with a given prefix.
The advantage of using a gateway is that it provides a multicast interoperability between IPv4 and IPv6. A videoconference with multiple participants of IPv4 and IPv6 groups and full bidirectional connection can be estimated. As the NAT-PT is gradually becoming the mainstream unicast transition, the similar gateway multicast transition is undoubtedly one of the most widely applicable solutions.

      (3) Other Transition Technologies
      The 6over4-transition technology uses the IPv4 network as a link equipped with the multicast functions. It implements the neighbor discovery for IPv6 via mapping multicast addresses between IPv6 and IPv4, thus interconnecting stand-alone IPv6 hosts via IPv6 protocol. This unicast transition mechanism uses IPv4 multicast as its bottom layer carrier and only maps its destination address to the special/private multicast address domain?239.0.0.0/8, for the purpose of IPv6 multicast. The 6over4-transition technology is not employed widely and very few contributions are devoted to its multicast technology.

      The Application Layer Multicast (ALM) implements multicast functions at the application layer instead of the network layer. In fact, It磗 a logic network superimposed over a unicast network. Therefore, the application layer should guarantee the ALM transition, that is, unicast IPv6 transition.

      The NAT-PT+ALG technology adds a multicast Application Layer Gateway (ALG) to current NAT-PT to deliver multicast functions. This scheme once appeared in the ETRI program of Korea and GTPv6 program of Europe.

      Tunnel technology encapsulates multicast packets that support one protocol into packets that support another protocol to implement inter-network transmission of multicast. Presently, not all tunnel transition techniques support multicast, but many do with additional functional code. All tunnel techniques are based on dual stack technologies and therefore are not able to support communications between IPv6-only hosts and IPv4-only hosts.

2 Multicast Translation Gateway (MTG) Model
The MTG model is a prototype of gateway protocol transformation based on the Linux 2.4 kernel.

      Figure 1 shows the MTG model deployment in a network?on the boundary between IPv4 and IPv6 networks. The MTG model put IPv4 and IPv6 networks as two heterogeneous peers:

      IPv4-only network on one side and IPv6-only network on the other. The MTG works for IPv4 and IPv6 equally. The IPv6 host can join the multicast group with the multicast source located in the IPv4 network while the IPv4 host can join the multicast group with the multicast source located in the IPv6 network.

      In the IPv4 network, MTG works as the IPv6 proxy and participates in the IPv4 multicast. Likewise, MTG works as the IPv4 proxy in the IPv6 network. The MTG in Figure 1 represents a single dual stack device or a dual stack network. Two proxies perform protocol translation inside the MTG system.

2.1 Model Structure
Figure 2 shows the MTG model structure inside dotted lines. The MTG model is composed of the IPv4 multicast proxy, the IPv6 multicast proxy, the multicast protocol translator, the address mapper, the Simple Network Management Protocol (SNMP) interface, and the Management Information Base (MIB).

      (1) IPv4 Multicast Proxy
      The IPv4 multicast proxy joins IPv4 multicast groups as an agent of IPv6 receiver nodes. It receives packets bound for IPv4 multicast groups, and then forwards the packets to the multicast protocol translator. Specifically, it sends Internet Group Management Protocol (IGMP) messages to the IPv4 network, sends multicast data to the IPv4 network and receives multicast packets from IPv4. (The messages including responding to IGMP query, proactively sending unapproved membership reports to the router and proactively sending leaving group messages). The proxy must perform validity checks to receive multicast packets. If all hosts of IPv6 have left this multicast group, then the proxy won磘 hand the packets to the translator but send a leaving group message to the IPv4 network immediately.

      (2) IPv6 Multicast Proxy
      The IPv6 multicast proxy joins IPv6 multicast groups as a proxy of IPv4 receiver nodes. It receives packets bound for IPv6 multicast groups, and then forwards packets to the multicast protocol translator. Due to the MTG deployment difference between IPv4 and IPv6, the IPv6 multicast proxy has a different work scope from that for IPv4. Specifically, it receives the Multicast Listener Discovery (MLD) membership report from IPv6 host (when working as a specified router for multicast), receives the Protocol Independent Multicast (PIM) join message, sends multicast data to the IPv6 network, and receives multicast packets from the IPv6 network. The MTG no longer works as a common host in IPv6 but the multicast router and the RP of IPv6 to perform router functionalities. If there is no IPv4 multicast receiver in IPv6, the MTG will know about this and leave IPv4 group as a response, which is unavailable for IPv4. In short, IPv6 multicast data can in any case be handed to the translator and sent to IPv4 network.

      (3) Multicast Protocol Translator
      A multicast protocol translator does translation between IPv4 multicast packets and IPv6 multicast packets. It works at the network layer to convert headers between IPv4 and IPv6 and forwards the packet fragments when necessary.

      As shown in Figure 2, the core module of the model is the multicast protocol translator that converts IPv4 headers into IPv6 headers and vice versa. Table 1 lists the IPv4 and IPv6 header field conversions.

      The 8-bit "Traffic Class" field for IPv6 is not yet regulated in any standard draft. However, it has similar functions (providing some differentiated services) to the 8-bit "Type of Service (ToS)" field for IPv4. Presently, the MTG does the equivalent conversion for them so the ToS-based QoS work in IPv4 will continue in IPv6. In addition, the MTG provides extended interfaces for this purpose and can adjust the conversion policy when needed.

      The field "Hop Limit" in IPv6 functions similarly to the "Time To Live" (TTL) in IPv4 to limit the packets？ delivery range. Equivalent conversions and extended interfaces also should be used here as for conversions between the traffic class and the ToS.

      For a non-Source Specific Multicast (SSM), the source address translation is done with the fixed IPv4 unicast address or fixed IPv6 unicast address of MTG. From the perspective of an IPv6 receiver, the gateway is the source that resends all IPv4 data; while from the perspective of IPv4, the gateway is also the source that resends all IPv6 data. For SSM the same group simultaneously may be used for multiple frequencies, hence multiple sources exist. This makes it impossible to use a fixed multicast source address and then a new address must be assigned for it in the address mapper.

      The destination address is also the multicast group address. For IPv4 to IPv6 translation, the address is identified by a prefix"FFxy::/96" for IPv6 multicast[6], and an IPv4 multicast group address is held in low-order 32 bits. If the IPv4 multicast address is permanently assigned by global Internet numbering authority, "x " in the prefix is set to "0", otherwise to "1". To use SSM, "x "in the multicast prefix identifier is set to "3". "y " in the multicast prefix identifier is subject to translation according to the mapping relation between IPv4 multicast prefix and the IPv6 field value as defined in Draft Standard RFC2365. For IPv6 to IPv4 translation, the address type has to be determined based on both "x " and "y ", then an the IPv4 multicast group address can be allocated from the address mapper. Note that the Session Announcement Protocol (SAP) address of IPv6 has to be translated to "FF0y::2:7FFE" mode. When the IPv4 multicast session address falls within the scope of 224.2.128.0?224.2.255.255, SAP address is usually 224.2.127.254. Other cases refer to Draft Standard RFC2974.

      The multicast protocol translator provides a callback interface link for the application layer to implement the protocol translation needed by the application layer. The default application layer callback is used for the protocol translation of SAP packets.

      (4) Address Mapper 
      The address mapper maintains each unicast address pool for IPv4 and IPv6, as well as a mapping table that consists of pairs of IPv4 and IPv6 addresses. The IPv4 pool is used for temporary IPv4 addresses of IPv6 nodes in the IPv4 land, while the IPv6 pool is used for temporary IPv6 addresses of IPv4 nodes in the IPv6 land. With the addresses known by IPv4/IPv6 unicast routes, packets sent can be delivered to the gateway and checked by a Reverse Path Forwarding (RPF).

      The address mapper concerns allocation of 3 categories of addresses: the IPv4 multicast group address, the IPv4 SSM source address and the IPv6 SSM source address.

      When the request comes to assign an IPv6 address that corresponding to an IPv4 address (an IPv4 source address), the mapper selects a proper IPv6 address out of the address-mapping table and returns the address to the translator. When there is no proper entry for an IPv4 unicast address, it selects and returns an IPv6 unicast address out of the IPv6 address pool and registers a new entry into the table. When there is no proper entry for an IPv4 multicast group address, it registers a new entry into the table, which consists of the IPv4 multicast group address and the corresponding IPv6 address. IPv4 address assignment works similarly.

      (5) SNMP Interface
      SNMP interfaces have internal interfaces and external interfaces. The internal interface provides methods for interaction between internal modules and MIB while external interface provides users with methods of managing MTG.  Users may use standard SNMP commands to learn about the current MTG running state or adjustable parameters that are dynamically modified.

      (6) MIB of MTG
      The MIB of MTG provides the environment configuration needed for MTG operation and it records the current MTG state.

2.2 Workflow of MTG
Let磗 take a videoconference as an example to demonstrate the workflow of MTG.

      There are two participants, F1 and F2, in IPv4 and two participants, S1 and S2, in IPv6. F1 is the organizer of the conference. All participants run the Session Description Protocol (SDP) or a monitor similar to SAP to obtain the session information.

      The IPv4 and IPv6 addresses of MTG are 202.112.25.214 and 3FFE:3206:1000::19D6 respectively. The MTG is configured as the specified router for IPv6 multicast.

      First, F1 announces the conference information to 224.2.127.254:9875, notifies other participants to use 224.5.5.5 as the session address and meanwhile sends video/audio streaming to IPv4.

      F2 receives this SAP announcement via SDR and initiates the multicast conference tool. Now F1 and F2 may start a session.

      When the SAP announcement reaches the MTG, the IPv4 multicast proxy hands it to the multicast protocol translator, which then performs a header translation. The source address is converted to the fixed IPv6 address 3FFE:3206:1000::19D6 of the MTG and the destination address is FF0E:0::2:7FFE. The callback function at the application layer is now called to resolve out the multicast session address 224.5.5.5. The IPv6 address FF1E::224.5.5.5 is then obtained from the address mapper and the information carried is modified at the application layer. Multicast protocol translator then hands the translated SAP packets to the IPv6 multicast proxy and sends it to the IPv6 network. When the SAP arrives for the first time, the address mapper will update the mapping table.
S1 and S2 initiate the MLD membership report after they receive a SAP announcement. The IPv6 multicast proxy receives the MLD report and then hands it to multicast protocol translator. Then the translator changes the MLD report to the IGMP membership report, sends it to IPv4 via the IPv4 multicast proxy and joins the 224.5.5.5 group. So far, 4 participants have joined the multicast session.

      The IPv4 multicast protocol receives IPv4 multicast packets sent by F1 and hands it to the multicast protocol translator, which performs the header translation. The source address is converted to the fixed IPv6 address, 3FFE:3206:1000::19D6 of the MTG and the destination address, 224.5.5.5 to a corresponding IPv6 address, FF1E::224.5.5.5. Packets are then sent to S1 and S2 via the IPv6 multicast proxy. The IPv6 multicast proxy receives IPv6 multicast packets sent by S1 and S2, and hands it to the multicast protocol translator, which performs the header translation. The source address is converted to the fixed IPv4 address, 202.112.25.214 of the MTG and the destination address, FF1E::224.5.5.5 to a corresponding IPv4 address 224.5.5.5. Packets are then sent to F1 and F2 via the IPv4 multicast proxy. Once both S1 and S2 leave, the IPv4 multicast proxy will no longer hand multicast packets of this group to the multicast protocol translator.

      When no SAP is being used, the conference address 202.5.5.5 has to be notified to all conference participants manually or by a way of web announcement. The administrator or an authorized terminal user uses the SNMP external interface to register the 202.5.5.5 multicast group and obtain the IPv6 mapping address, FF1E::224.5.5.5. The IPv6 user uses FF1E::224.5.5.5 address to join a multicast session.

3 Conclusions
To enable multicast communication between an IPv4 and IPv6 host, protocol translation must be done, such as, a reflector at the transport layer or a gateway at the network layer. In addition to basic functions of a gateway, the MTG has made other improvements as compared to gateways. The insensibility problem of a gateway to the validity period of an IPv4 multicast group member and source, can be solved by MTG serving also as the IPv4 multicast router. Therefore, MTG can learn about the group member status. The problem that IPv4 can only access IPv6 groups with a given prefix is solved through manageable static address mapping based on the added prefix, as the MTG model structure implies.

      The MTG also discusses issues not specified in the gateway scheme. For example, according to Draft Standard RFC2365, it includes mapping of multicast management domains in different protocols and gateway management standardization via a SNMP interface and extended MIB. Moreover, at the bottom layer, MTG uses a level-by-level detail-oriented processing flow, to which configurable gateway congestion control strategy and packet scheduling strategy have been added. With these strategies, packets in cache can be scheduled based on QoS and flow control requirements in a controllable way.

      With the MTG, IPv4-IPv6 multicast communication can be implemented in an effective way.

References
[1] Venaas S. An IPv4 - IPv6 Multicast Gateway[EB/OL].[2003-02-28]. http://www.6net.org/publications/standards/draft-venaas-mboned-v4v6mcastgw-00.txt.
[2] IPv4/IPv6 Multicast Interoperability[EB/OL].[2003-07-15]. http://www.6net.org/publications/deliverables/D3.4.4.pdf.
[3] Tsuchiya K, Higuchi H, Sawada S, Nozaki S. An IPv6/IPv4 Multicast Translator Based on IGMP/MLD Proxying (mtp) [EB/OL]. [2002-10-15]. http://www.watersprings.org/pub/id/draft-ietf-ngtrans-mtp-03.txt.
[4] Meyer D. Administratively Scoped IP Multicast[S]. RFC2365, 1998.
[5] Tsirtsis G, Srisuresh P. Network Address Translation - Protocol Translation (NAT-PT)[S]. RFC2766, 2000.
[6] Haberman B. Allocation Guidelines for IPv6 Multicast Addresses[S]. RFC3307, 2002.

Manuscript received: 2005-11-28

Author Introduce:

  Yang Xianfeng received his Master磗 degree from Department of Computer Science and Engineering, Southeast University. His main research interests are IPv6 and multicast technology.

Cao Zheng  is an Associate Professor of Department of Computer Science and Engineering, Southeast University, Deputy Head of Jiangsu Education and Research Network Center. He has years of experience in the research and education on computer networks. He has undertaken or participated in 6 national key R&D programs, national "863" project, and national defense research projects of China. He has won one national science and technology progress award and 6 provincial/ministry-level science and technology progress awards.