Transition Technology of IPv4-IPv6 Multicast

In the next generation Internet, it has been determined that IPv6 must support multicast and a large number of multicast address spaces are arranged. Although more and more pure IPv6 nodes will exist after IPv6 is applied, many IPv4 nodes will continue to exist due to their successful operation. Therefore, IPv6 cannot replace all IPv4 addresses in a short period of time. The two will coexist for a long time. During this long period of coexistence, according to the IPv6 deployment policy, the pure IPv6 Network will continue to appear in a regional manner. At this time, the network will present a situation where the pure IPv4 network and the pure IPv6 network coexist and are intertwined.

Therefore, there must be a mechanism to ensure that IPv4 and IPv6 nodes can communicate directly to achieve smooth transition. Currently, many transition technologies have been proposed, but they are only applicable to unicast communication and not multicast communication. Although the transition technology of multicast communication has not yet become the focus of people's research work, as a very practical research direction, more and more organizations and groups are focusing on [1-4].

1. multicast Transition Technology

1.1 double stack Technology

The dual-stack multicast transition solution is actually a combination of pure IPv4 multicast networks and pure IPv6 multicast networks. In unicast, the server can be configured as a dual-stack, so that only IPv4 and pure IPv6 hosts can easily access it. Similarly, the multicast source can be configured as a dual-stack, and data streams can be sent to IPv4 and IPv6 groups, so that all hosts running different protocol stacks can receive multicast packets.

Both IPv4 and IPv6 Multicast can be deployed on a dual-stack network. IPv4 and IPv6 Multicast can run on both the router and the host, and can exist on the same network link at the same time. The router can also become the convergence point (RP) of IPv4 and IPv6 groups at the same time ).

For simple single-source scenarios, if a data stream only exists in a closed environment and all potential receivers support the same IP protocol, the source only needs to use this IP protocol. In more open environments, potential receivers and Their supported IP protocols are unknown. To ensure that all receivers can receive them, an IPv4 source and an IPv6 source are required, make sure that both sources use the same source data.

When there are only a few sources, you can use the dual-stack technology to configure all sources into a dual-stack, and send packets to IPv4 and IPv6 groups at the same time. However, in a video conference, almost everyone needs to receive and send data at the same time, and some participants use pure IPv4, while others use pure IPv6. In this case, the dual-stack technology will be powerless. In addition, when using the double stack technology, the bandwidth consumption will be twice the original.

The dual-stack technology does not require additional devices or additional conversions to multicast data. Therefore, it is the easiest solution to implement. It is applicable to scenarios where communications between IPv4 and IPv6 hosts are not required in the application environment, such as content delivery.

1.2 protocol conversion technology

Protocol conversion technology allows IPv6 hosts to communicate with IPv6 multicast groups without changing the infrastructure, use the common IPv6 multicast protocol to communicate with any IPv4 multicast group. The core idea is to place one or more conversion devices on the path between the IP protocol and the IP protocol. In rare cases, the conversion is also completed on the sending or receiving host, which is mainly for applications that run on a dual-stack host but only support one IP protocol. There are several common conversion methods:

(1) Forwarder

In IPv4, Reflector is often used when global multicast fails. The Virtual Room Video Conferencing System (VRVS) is a typical example. It uses pure Multicast on the core network, you cannot directly set the forwarder as the multicast proxy in this region through the multicast region. The core network and the forwarder are connected by means of single play, and the forwarder and the terminal system can adopt pure multicast or unicast.

The IPv4-IPv6 multicast forwarder converts between IPv4 and IPv6 multicast instead of between unicast and multicast. Given the IPv4 group address and port, as well as the IPv6 group address and port, the forwarder adds the IPv4 group address and port to the two groups at the same time, listens to the corresponding port, and resends all the data received from the group (Resend) to another group.

According to the IPv6 transition process, the forwarder can have two deployment schemes: when the protocol used by the content provider is not widely supported and the host or application does not support the dual protocol, the forwarder is located near the source. When the receiver uses another protocol different from the source protocol, it is very effective to place the forwarder near the receiver.

The main defect of the repeater solution is its low performance, and it cannot support large-scale multicast applications. In addition, it must enable an instance for each session, even if there is no receiver, it still executes the process of receiving and resending.

Due to the limitations above, the forwarder can be used to work for Multiple Multicast Groups, but the number of sessions that work simultaneously is limited. If a forwarder is used to provide services on the network, the user must contact the Administrator to apply for a session to be allocated within a limited period of time; or, like TunnelBroker, use Web Authentication and other auxiliary measures to automate the session allocation process.

(2) Gateway

The development of multicast transition technology is later than that of unicast transition technology. Therefore, most multicast transition technologies use the idea of unicast transition technology to varying degrees. The dual-stack technology naturally does not have to be repeated because it is completely consistent with the unicast transition technology. The forwarder technology works on the transport layer, thus avoiding header conversion, which is consistent with the thought of unicast transition TCP-UDP relay technology. IPv4-IPv6 multicast gateway is a kind of Network Address Translation/protocol conversion (NAT-PT) solution.

NAT-PT [5] is mainly proposed for unicast, and cannot be fully applied to multicast. According to the idea of NAT-PT and the characteristics of multicast, the gateway optimizes and improves the performance, so as to form the IPv4-IPv6 transition technology suitable for multicast.

The idea of the gateway is to embed an IPv4 multicast address into an IPv6 address by adding the specified "/96" prefix, so that each IPv4 multicast address has a corresponding IPv6 multicast address; similarly, each IPv6 address corresponds to an IPv4 address. The relationship between IPv4 and IPv6 addresses involved in the multicast transition is one-to-one ing, which is a crucial feature of the IPv4-IPv6 multicast gateway. It is precisely because of this feature that protocol conversion can proceed smoothly.

The gateway can be deployed on the border between IPv4 and IPv6 networks, or in a dual-stack network. It can be used for a single site or organization or as a service on a large network. If necessary, you can even deploy multiple gateways for the same network.

The Gateway has two main limitations: it is not sensitive to the group members and source validity periods of IPv4 multicast, and IPv4 can only access IPv6 groups with a given prefix.

The biggest advantage of the gateway is that it provides communication between IPv4 and IPv6 multicast. Using the gateway, you can establish multi-party video conferences with both IPv4 and IPv6, and perform full bidirectional connections. The NAT-PT has gradually become the main unicast transition scheme, and the similar gateway multicast transition scheme is undoubtedly one of the most widely applied transition schemes.

(3) other transitional Technologies

The 6over4 transition technology regards an IPv4 network as a link with the multicast function. Through the ing between the IPv6 multicast address and the IPv4 multicast address, the Neighbor Discovery Function of the IPv6 protocol is realized, enables IPv6 interconnection between isolated IPv6 hosts. This unicast transition mechanism uses IPv4 multicast as its underlying carrier. When it is used for IPv6 multicast, it only maps its destination address to the private multicast address domain ?? 239.0.0.0/8. Because 6over4 transition technology is not widely used, its Multicast technology is rarely mentioned.

The Application Layer Multicast (ALM) implements the multicast function at the application layer, rather than the multicast function at the network layer. It is actually a logical network that overlays on unicast networks. Therefore, the transition of ALM is ensured by the application layer. Its transition problem is ultimately caused by unicast IPv6 transition. NAT-PT + ALG is added to the Multicast Application Layer Gateway (ALG) on the basis of the existing NAT-PT to meet the requirement of multicast. ETRI project in South Korea and GTPv6 project in Europe once proposed this scheme.

Tunnel Technology encapsulates multicast packets in another protocol, so that Multicast can be transmitted across the network. Although not all tunnel transition technologies currently support multicast, many of them can be supported after additional functional code is added. All tunneling technologies are based on dual-stack. Therefore, communication between pure IPv6 hosts and pure IPv4 hosts cannot be achieved.

2 multicast translation gateway Model

The multicast translation gateway (MTG) model is a prototype of the gateway protocol conversion solution based on the Linux2.4 kernel.

As shown in deployment 1 of the MTG model in the network, the MTG is deployed on the boundaries of IPv4 and IPv6 networks. The MTG model regards the IPv4 network and IPv6 network as two heterogeneous networks with equal status. From the perspective of the gateway, one side is a pure IPv4 network and the other side is a pure IPv6 network. The work of the gateway is also equivalent to IPv4 and IPv6: an IPv6 host can be added to a multicast group where the multicast source is located in an IPv4 network, an IPv4 host can also be added to a multicast group where the multicast source is located in an IPv6 network.

In IPv4, MTG acts as the IPv6 proxy and participates in IPv4 multicast. Similarly, MTG acts as the IPv4 proxy in IPv6. In the figure, MTG can be understood as either a single dual-stack device or a dual-stack network. In the MTG system, two proxies perform protocol conversion.

2.1 Model Structure

Figure 2 The dotted box section shows the MTG model structure. It mainly consists of IPv4 multicast proxy (MP4), IPv6 multicast proxy (MP6), multicast protocol converter (MT), address Er (AM), and Simple Network Management Protocol (SNMP) interface and MTG Management Information Library (MIB.

(1) IPv4 multicast proxy

The IPv4 multicast proxy acts as the proxy of the IPv6 receiving node to join the IPv4 multicast group. It receives multicast packets from IPv4 and forwards the packets to the multicast protocol converter. The IPv4 multicast proxy mainly includes sending Internet Group Management Protocol (IGMP) messages to IPv4 networks, sending multicast data to IPv4 networks, and receiving multicast packets from IPv4 networks. IGMP messages sent to IPv4 networks include response to IGMP queries, proactive transmission of unapproved membership reports to routers, and proactive initiation and departure of group information. When receiving multicast packets, you must check the validity. If all hosts in IPv6 have left the multicast group, the packets are no longer transferred to the multicast protocol converter, and immediately sends an Exit message to IPv4.

(2) IPv6 multicast proxy

The IPv6 multicast proxy acts as the proxy of the IPv6 receiving node to join the IPv4 multicast group. It receives multicast packets from IPv6 and forwards the packets to the multicast protocol converter. Because MTG is deployed differently in IPv4 and IPv6, the work of the IPv6 multicast proxy is different from that of IPv4. The IPv6 multicast proxy mainly includes: receiving the multicast listening discovery (MLD) member Report of an IPv6 host (when it is used as the vro for multicast), and receiving protocol-Independent Multicast (PIM) add messages, send multicast data to IPv6 networks, and receive multicast packets from IPv6 networks. In IPv6, MTG is no longer a common host, but a multicast router and RP of IPv6. Therefore, MTG is more likely to act as a router. When there is no IPv4 multicast receiver in IPv6, MTG can know and respond to it and leave the IPv4 group. This is what an IPv4 multicast proxy cannot do. Therefore, IPv6 multicast data is always unconditionally transferred to the multicast protocol converter and sent to an IPv4 network.

(3) multicast protocol Converter

The multicast protocol converter converts IPv4 multicast packets and IPv6 multicast packets. It mainly works at the network layer, implements header conversion between IPv4 and IPv6, and forwards packets in parts if necessary.

As shown in figure 2, the core module of the entire model is the multicast protocol converter, which is mainly responsible for conversion between IPv4 and IPv6 headers. Table 1 converts IPv4 and IPv6 header fields.

The eight-bit business type (TrafficClass) Field in IPv6 does not have a standard draft, but it is similar to the eight-bit service type (ToS) Field in IPv4, it is mainly used to provide Differentiated Services. At present, MTG performs Equivalent Conversion to facilitate IPv4 service quality (QoS) based on service types to continue in IPv6. In addition, MTG provides an extended interface to adjust the conversion policy as needed.

The HopLimit field in IPv6 is consistent with the TTL field in IPv4, and is used to limit the transmission range of packets. Its processing is the same as the conversion of business and service types. It also uses Equivalent Conversion and provides an extended interface. For non-specified source multicast (SSM), the conversion of source addresses uses a fixed IPv4 unicast address or a fixed IPv6 unicast address of MTG. From the perspective of IPv6 receiver, the gateway is the source of all IPv4 data resends. From the perspective of IPv4, the gateway is also the source of all IPv6 data resends. For SSM, the same group may be used for multiple channels at the same time, so there are multiple sources. Therefore, a fixed Multicast Source Address cannot be used, and it must be assigned a new address in the address er.

The host address is the multicast group address. When an IPv4 address is converted to an IPv6 address, the IPv6 multicast prefix ID is used ?? FFxy:/96 [6], and the IPv4 multicast group address is placed at a low 32-bit. When an IPv4 multicast address is a multicast address that is permanently assigned by the global Internet addressing Center (GINA), the x mark in the multicast prefix is set to "0 ", otherwise, the value is "1". When SSM is used, the variable x mark in the multicast prefix is set to "3 ". In the multicast prefix identification, y is converted based on the ing between the IPv4 multicast prefix and the IPv6 Domain value defined in RFC2365 of the standard draft. When converting IPv6 to IPv4, you must determine the address type based on x and y, and then assign an IPv4 multicast group address from the address er. Note that the IPv6 Session announcement protocol (SAP) address must be converted to FF0y: 2: 7FFE format. When the IPv4 multicast session address is 224.2.128.0? Generally, the SAP address is 224.2.127.254 within 224.2.18.255. For other information, see the specific definition in RFC2974 of the draft standard.

In addition, the multicast protocol converter also provides the callback interface chain to the application layer to meet the protocol conversion requirements at the application layer. The default application-layer callback is used for protocol conversion of SAP packets.

(4) Address er

The address er maintains a unicast address pool and an address ing table consisting of IPv4 and IPv6 address pairs for IPv4 and IPv6 addresses. The IPv4 address pool is used for temporary IPv4 addresses of IPv6 nodes in the IPv4 domain, and the IPv6 address pool is used for temporary IPv6 addresses of IPv4 nodes in the IPv6 domain. They are advertised to IPv4/IPv6 unicast routers so that the packets sent to them can be forwarded to the gateway and checked through reverse path Forwarding (RPF.

The address CER involves three types of Address Allocation: IPv4 multicast group address, IPv4SSM source address, and IPv6SSM source address. When you need to assign an IPv6 address to correspond to an IPv4 address (IPv4 source address), the address er selects an appropriate IPv6 address from the address ing table to return; when there is no suitable entry that corresponds to an IPv4 unicast address, the address er selects an IPv6 unicast address from the IPv6 address pool and registers a new entry in the address ing table; when there is no suitable entry that corresponds to an IPv4 multicast address (IPv4 destination address), the address er registers a new entry in the table that contains an IPv4 multicast address and an IPv6 address. The allocation of IPv4 addresses is similar to that of IPv4 addresses.

(5) SNMP interface

SNMP interfaces are divided into internal interfaces and external interfaces. The internal interface provides a complete set of methods for the interaction between the internal module and the MIB. The external interface provides you with MTG management methods. You can use the standard SNMP command to learn the current running status of the MTG and the adjustable parameters of the Dynamic Modification part.

(6) MTG Management Information Library

The MTG Management Information Library provides environment configurations required for MTG operation and records the current running status of MTG.

2.2MTG Workflow

The following uses a video conference as an example to describe the MTG workflow.

In IPv4, there are two participants F1 and F2, and IPv6 also have two participants S1 and S2. F1 is the organizer of the meeting. All participants run Session Description Protocol (SDR) or SAP-like listeners to obtain session information. The IPv4 and IPv6 addresses of MTG are 202.112.25.214 and 3FFE: 3206: 1000: 19D6, respectively. At the same time, configure the MTG as the IPv6 multicast router.

Participant F1 first announces the meeting Information to 224.2.127.254: 9875, notifies other participants to use 224.5.5.5 as the session address, and simultaneously sends a video/audio stream to IPv4.

Participant F2 directly receives the SAP announcement through SDR and starts the multicast meeting tool. In this case, F1 and F2 can be used for sessions. When SAP announcement arrives at MTG, MP4 transfers it to MT, MT converts its header, and the source address is converted to the fixed IPv6 address 3FFE: 3206: 1000: 19D6 of MTG, the destination address is FF0E: 0: 2: 7FFE. Call the application-layer callback function to parse the multicast session address 224.5.5.5, and then obtain the corresponding IPv6 address from AM.

FF1E: 224.5.5.5. Modify the information carried in the application layer. MT then transfers the converted SAP packets to MP6 and sends them to the IPv6 network. When SAP arrives for the first time, AM updates the ing table.

After receiving the SAP announcement, participants S1 and S2 initiate the MLD member report. After receiving the MLD report, MP6 transfers it to MT. MT converts the MLD report to an IGMP member report, sends the report to IPv4 through MP4, and adds the report to 224.5.5.5. So far, all four participants have joined the multicast session.

MP4 receives the IPv4 multicast packets sent by the participant F1 and forwards them to MT. MT converts the header and the source address to the fixed IPv6 address 3FFE: 3206: 1000: 19D6 of the mtg, the destination address 224.5.5.5 is converted to the corresponding IPv6 address FF1E: 224.5.5.5, and then played to S1 and S2 of the Participant through MP6. MP6 receives IPv6 multicast packets from S1 and S2 and forwards them to MT. MT converts the source address to the fixed IPv4 address 202.112.25.214 of MTG. the destination address is FF1E:: 224.5.5.5 is converted to the corresponding IPv4 address 224.5.5.5, and then played to the F1 and F2 participants through MP4 multicast. When both S1 and S2 are withdrawn, MP4 no longer forwards the multicast packets to MT.

When SAP is not used, the session address 202.5.5.5 must be reported to all conference participants through manual communication or Web Publishing. The Administrator or authorized end users register the 202.5.5.5 multicast group through the SNMP external interface and obtain the IPv6 ing address FF1E: 224.5.5.5. IPv6 users use the FF1E: 224.5.5.5 address to join a multicast session.

3 conclusion

To enable multicast communication between an IPv4 host and an IPv6 host, you must perform protocol conversion such as a forwarder (at the transport layer) or a gateway (at the network layer.

Based on the implementation of the basic functions of the gateway, MTG makes some improvements to the gateway. The gateway is not sensitive to the group members and source validity periods of IPv4 multicast. By making MTG an IPv4 multicast router at the same time, the MTG can be able to know the status of the group members; IPv4 in the gateway can only access IPv6 groups with a given prefix. The MTG model structure shows that, based on the additional prefix, the static address ing can be managed, removes IPv4 access restrictions on IPv6.

MTG also discussed the issues not specific to the gateway solution. According to the draft standard RFC2365, The ing of multicast management domains between different protocols is added. The management of gateways is standardized through the SNMP interface and the extended MIB. In addition, at the underlying implementation level, MTG adopts a refined process step by step, and adds configurable gateway congestion control policies and packet scheduling policies, supports controllable scheduling of cached packets based on QoS and traffic control requirements.

MTG can effectively achieve intercommunication between IPv4-IPv6 multicast.

Related Articles]

• IPv4 to Ipv6: Internet Development Trend
  

• Comparison between IPv4 and IPv6 protocols
  

• SOCKS-based IPv4 to IPv6 transition technology