The forthcoming transition period when both IPv4 and IPv6 will have to coexist raises new challenges for service providers. In particular, they need to ensure that their customers will still be able to access the IPv4 Internet from any IPv4-only terminal while they will be provisioned with an IPv6-only prefix. There is widespread need for continuing this so-called IPv4 Internet service.
IPv4 multicast services are part of the IPv4 Internet service that needs to be continued. These services need to be delivered to IPv4-only receivers through various access networking environments, including IPv6 access environments (denoted as the 4-6-4 use case).
The IETF 82 meeting last November in Taipei, Taiwan, provided an opportunity for academics, service providers, and vendors to demonstrate techniques that address the need for IPv4 multicast service continuity. Two demonstrations were arranged for that purpose, thanks to a close collaboration among Beijing University of Posts and Telecommunications (BUPT), China Telecom, Comcast, France Telecom/Orange, Huawei, and ZTE Corporation.
Demo 1: The IETF Softwires working group’s (WG’s) document draft-ietf-softwire-dslite-multicast (http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/)documents multicast extensions to the DS-Lite technique for delivering IPv4 multicast services to IPv4 receivers connected to an IPv6 multicast-enabled network.
The demonstration of draft-ietf-softwire-dslite-multicast (Figure 1) was composed of an IPv4 receiver, a multicast B4 capability embedded in a CPE device, an MLD querier, and a multicast Address Family Transition Router (mAFTR) capability colocated with a DS-Lite CGN device.
France Telecom/Orange has developed the “mB4 function” that conveys the contents of the Internet Group Management Protocol (IGMP) report messages sent by the IPv4 multicast receiver into the equivalent Multicast Listener Discovery (MLD) report messages that are forwarded by the CPE towards the MLD querier located upstream in the IPv6 multicast network for further processing.
The mB4 capability is embedded in an OpenWRT-based CPE (see https://openwrt.org/), while ZTE Corporation has developed the mAFTR function, which is used to extend the Protocol Independent Multicast (PIM) v4-computed multicast distribution tree into an equivalent PIMv6-computed multicast distribution tree that is established and maintained in the IPv6 multicast-enabled access infrastructure.
From the perspective of a control plane, the mB4 is responsible for conveying the contents of the IGMP Report messages into the equivalent MLD Report messages by means of a specific IGMP/MLD interworking function and the use of the IPv6 prefixes that are derived from the IPv4 multicast addressing used by the original IPv4 source, as documented in http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-03.
The mAFTR capability is then used to extend the PIMv4-computed multicast distribution tree with the equivalent PIMv6-computed multicast distribution tree, by means of a PIMv4/PIMv6 interworking function that allows the triggering of PIMv4 Join messages towards the original IPv4 source based upon the processing of PIMv6 Join messages sent by the PIMv6 DR router colocated with the MLD querier.
Once the IPv6 multicast tree has been established to convey the IPv6 multicast packets that embed the original IPv4 multicast content, the latter is delivered thanks to a stateless IPv4-in-IPv6 encapsulation/decapsulation scheme implemented in both the mB4 and the mAFTR.
Figure 1: Demonstrating multicast extensions to DS-Lite based on a stateless encapsulation mode.
Huawei has developed code for multicast IPv4-to-IPv6 translation that runs in the forwarding plane (Figure 2) in Huawei’s router product NE40E with wire-speed forwarding for multicast flows. In order to demonstrate interoperability, the France Telecom/Orange CPE was used to connect to a multicast receiver.
This code demonstrates two of the use cases documented in:
http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-03, https://datatracker.ietf.org/doc/draft-venaas-behave-v4v6mc-framework/, and http://www.ietf.org/internet-drafts/draft-tsou-multrans-use-cases-00.txt
Huawei’s 4-6-4 implementation uses translation capabilities that assume the support of so-called adaptation functions that associate the contents of IGMPv2/v3 Report messages with the triggering of PIMv6 Join messages. The specific devices used for the demo are shown in Figure 2, where translation is activated in edge routers.
Figure 2: Demonstrating multicast extensions to 4-6-4 [DS-Lite] based on translation capabilities in the forwarding plane.
Huawei also addressed the IPv6-IPv6-IPv4 (6-6-4) use case by providing the relevant adaptation functions in the forwarding plane. This allows IPv4 multicast content traffic to be sent via an IPv6 multicast network to an IPv6 receiver (as shown in Figure 3). The multicast distribution tree is set-up by the IPv6 signaling (MLDv2 and PIMv6). The IPv4 multicast distribution tree is set up using IPv4 multicast. The 6-6-4 context allows IPv6-only receivers that are connected to an IPv6 multicast network to access IPv4 multicast content.
Figure 3 – Accessing IPv4 multicast content from an IPv6-only receiver through an IPv6 multicast access infrastructure (6-6-4 Use Case).
Multicast Content for the Demos
The IPv4 multicast content was provided by BUPT and delivered through the China Education and Research Network (CERNET) and the Chunghua Telecom (HiNet) network infrastructure for both demos.
BUPT, serving as an IPTV content provider in CERNET and CERNET2, has acquired significant experience in serving IPv6 multicast content. BUPT started to provide IPTV service in 2006, and supports both IPv4 and IPv6 access. In order to promote IPv6 technology, BUPT delivers IPv6-only IPTV content to receivers connected to the CERNET2 network.
Currently, the average number of unique IP addresses that are used to visit the IPTV portal each day is around 20,000. According to the statistics, around 90 percent of the traffic comes from universities other than BUPT that are connected to the CERNET2 network.
IPTV service has become one of the most popular services of CERNET2. Sometimes, the 10G router port in the BUPT-managed CERNET2 POP is fully occupied by IPTV traffic.
BUPT has already conducted several other IPv4-to-IPv6 transition technology experiments that have been successful.
IETF 82 was another opportunity to demonstrate the progress that is being accomplished to solve some of the issues raised by the forthcoming transition period. From that perspective, we can expect to look forward to more demos at future IETF meetings that further strengthen the key role played by IETF standardization in promoting IPv6 deployment and usage.
Demonstration team personnel include:
- France Telecom Orange: Christian Jacquenet, Xiaohong Deng, Mohamed Boucadair, Gu Daqing, Wang Lan
- Huawei Technologies: Susan Hares, Tina Tsou, Thomas Zhang, Cathy Zhou, Charlie Zha, James Huang, Leaf Yeh
- Beijing University of Posts and Telecommunications: Yan Ma, Xiaohong Huang, Qin Zhao, Zhenhua Wang, Xiaodong Zhang
- ZTE Corporation: Jacni Qin, Fei Zhang, Huaikuo Yang, Jun Wang
- China Telecom: Qian Wang
- Comcast: Yiu Lee
In INTERNET SOCIETY_TAIPEI_132-1 from left to right:
Charlie Zha, Thomas Zhang, Cathy Zhou, Tina Tsou, James Huang, Xiaohong Deng
In INTERNET SOCIETY_TAIPEI_133-2 from left to right:
Bo Wu, Qilei Wang, Tian Tian, Xiaohong Deng, Fei Zhang, Yuan Wei