| Internet Engineering Task Force | B. Sarikaya |
| Internet-Draft | T. Tsou |
| Intended status: Informational | Huawei Technologies (USA) |
| Expires: December 26, 2014 | H. Ji |
| China Telecom | |
| C. Zhou | |
| Huawei Technologies | |
| Q. Sun | |
| China Telecom | |
| June 24, 2014 |
IPv6 Multicast in a 6rd Deployment
draft-zhou-softwire-6rdmulticast-00
This memo specifies 6rd's multicast component so that IPv6 hosts can receive multicast data from IPv6 servers. In the 6rd encapsulation solution, multicast communication is completely integrated into the 6rd tunnel. In the 6rd translation solution, the protocol is based on proxying MLD at the 6rd Customer Edge router interworking the MLD messages to IGMP messages and sending them upstream through a network which supports IPv4 multicast. The 6rd Border Relay is a multicast router and interworks the IGMP to MLD for onward propasgation toward the IPv6 multicast source. IPv6 Multicast data received at 6rd Border Relay is translated into IPv4 multicast data and and delivered through the IPv4 multicast tree downstream to the 6rd Customer Edge. The latter translates it back to IPv6 multicast data then delivers it to the hosts.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 26, 2014.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
With IPv4 address depletion on the horizon, many techniques are being standardized for IPv6 migration including 6rd [RFC5969]. 6rd enables IPv6 hosts to communicate with external hosts using an IPv4-only legacy ISP network. The 6rd Customer Edge (CE) device's LAN side is dual stack and the WAN side is IPv4 only. The CE tunnels IPv6 packets received from the LAN side to 6rd Border Relays (BR) after encapsulating them as IPv4 packets. The BRs have anycast IPv4 addresses and receive encapsulated packets from CEs over a virtual interface. 6rd operation is stateless. Packets are received/ sent independently of each other and no state needs to be maintained.
It should be noted that there is no depletion problem for IPv4 address space allocated for any source multicast and source specific multicast [RFC3171]. This document is not motivated by the depletion of IPv4 multicast addresses.
6rd as defined in [RFC5969] and [RFC5569] is unicast only. It does not support multicast. In this document we specify how multicast from home IPv6 users can be supported in 6rd. This is what is meant by 6rd multicast protocol.
In the 6rd encapsulation approach, 6rd multicast is integrated into the 6rd unicast solution. 6rd customer premise equipment (CPE) is extended to support an MLD proxy [RFC4605]. This proxy receives MLD Membership Report messages [RFC4601] requesting to join a multicast group from its subtended hosts. It tunnels aggregated join requests upstream to the 6rd Border Router (BR) using IPv6 in IPv4 encapsulation. The 6rd Border Router is extended to support an MLD querier, which sends join requests upstream towards the multicast source(s, becomes part of the multicast tree, and thus receives IPv6 multicast data. The 6rd Border Router encapsulates the IPv6 multicast data using 6rd's IPv6 in IPv4 encapsulation and sends it to each member CPE that has joined the stream concerned. The CPE decapsulates the packet and the MLD proxy sends the IPv6 multicast data downstream to the member hosts.
In the translation approach, native IPv4 multicast support in the network between Customer Edge routers and Border Router can be exploited. The translation approach requires MLD to IGMP interworking at the Customer Edge and IGMP to MLD interworking at the border router. The border router needs to translate IPv6 multicast data into IPv4 multicast data and the Customer Edge router needs to translate IPv4 multicast data back into IPv6 multicast data.
6rd's CE to CE forwarding feature is not used in either approach.
This document uses the terminology defined in [RFC5969], [RFC5569], [RFC3810], [RFC3376], and [I-D.ietf-softwire-dslite-multicast].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This section states requirements on 6rd multicast support protocol.
IPv6 hosts connected to 6rd CE router MUST be able to join multicast groups in IPv6 and receive multicast data.
Both any source multicast (ASM) and source specific multicast (SSM) MUST be supported.
6rd multicast MUST NOT introduce the need to use more IPv4 addresses, thereby contributing to public IPv4 address depletion.
In 6rd, IPv6 or IPv4/IPv6 dual stack hosts are served by the 6rd Customer Edge device (CE). The CE is dual stack facing the hosts and IPv4 only facing the network or WAN side. The CE tunnels IPv6 packets in IPv4 to the 6rd Border Relay (BR). The BR decapsulates the tunneled packets and forwards them to the IPv6 network. In the reverse direction, the BR receives IPv6 packets from the IPv6 network tunnels them in IPv4 to the CE. The CE decapsulates the IPv6 packets and forwards them to the hosts.
Unicast 6rd is stateless. Each IPv6 packet sent by the CE is treated separately and different packets from the same CE may go to different BRs. The CE encapsulates IPv6 packets in IPv4 with the IPv4 destination address set to the BR address (usually an anycast IPv4 address). BRs are placed where IPv6 native connectivity exists to other networks. A CE is configured with its own IPv4 address (public or private), with a 6rd IPv6 prefix from which the CE's IPv4 address can be derived, and with one or more BR IPv4 addresses. When the BR receives IPv6 packets addressed to the CE, it extracts the CE's IPv4 address from the destination IPv6 address and uses this address as the destination address for the IPv4 encapsulation of the IPv6 packet. 6rd views the IPv4-only network as an NBMA link from the IPv6 point of view and all 6rd CEs and BRs are defined as off-link neighbors from one other.
In order to support multicast, the CE implements an MLD Proxy function [RFC4605]. IPv6 hosts send their join requests (MLD Membership Report messages) to CE. The CE as a proxy sends aggregated Report messages upstream towards BR in unicast using IPv6 in IPv4 encapsulation.
Dual Stack Hosts IPv4 +----+ Network | H1 | IPv4 +----+ +-----+ only +-------+ + +----+ | CE | network -- | BR | | H2 | ---| MLD |--- IPv6 | MLD | IPv6 +----+ |Proxy| in |Querier| Network +----+ +-----+ IPv4 +-------+ | H3 | Encapsulation +----+
Figure 1: Architecture of 6rd Tunneling Multicast Protocol
The BR is the default multicast querier for the CE. The BR implements a multicast router function or it could be another MLD proxy.
All the elements of 6rd multicast support system are shown in Figure 1.
In order to support multicast, CE implements MLD Proxy [RFC4605] and MLD to IGMP interworking function [ID.perreault-igmp-mld-translation]. IPv6 hosts send their join requests (MLD Membership Report messages) to CE. CE as a proxy sends aggregated IGMP Report messages upstream towards BR.
In order to support SSM, MLDv2 [RFC3810] and IGMPv3 [RFC3376] must be supported by the CE and BR, and MLDv2 must be supported by the host.
The BR is the default multicast querier for the CE. The BR implements an IGMP to MLD interworking function and multicast router function or it could be another MLD proxy.
It is assumed that the IPv4 only network to which the CE and the BR are connected supports native IPv4 multicast.
All the elements of 6rd translation-based multicast support system are shown in Figure 2.
Dual Stack Hosts IPv4
+----+ Network
| H1 | IPv4
+----+ +----------------+ only +------------------+
+----+ | CE MLD | network |IGMP BR | +
| H2 | ---| MLD IGMP |-----------| MLD MLD |
+----+ |Proxy Translator| |Translator Querier|
+----+ +----------------+ +------------------+
| H3 | IPv6
+----+ Network
Figure 2: Architecture of 6rd Translation-Based Multicast
In this section we specify how the host can subscribe and receive IPv6 multicast data from IPv6 content providers based on the architecture defined in Figure 1.
The hosts will send their subscription requests for IPv6 multicast groups upstream to the default router, i.e., Costumer Edge device. After subscribing the group, the host can receive multicast data from the CE. The host implements MLD protocol's host part.
The Customer Edge device is an MLD Proxy. After receiving the first MLD Report message requesting subscription to an IPv6 multicast group, the CE establishes a tunnel interface with a Border Relay. The tunnel is IPv4 based but it will carry MLD messages back and forth and IPv6 multicast data messages downstream.
The CE is a regular MLD proxy and it keeps an MLD proxy membership database. The CE inserts multicast forwarding state on the incoming interface, and merges state updates into the MLD proxy membership database. The CE updates or remove elements from the database as required. The CE will then send an aggregated Report via the upstream tunnel to the BR when the membership database changes.
The CE answers MLD queries from the BR based on the membership database. The CE's downstream link follows the traditional multipoint channel forwarding and does not pose any specific problems.
The CE receives IPv6 multicast data from the BR tunneled over the tunnel interface. The CE decapsulates the packet and then forwards it downstream. Each member host receives the data packet based on the Layer 2 multicast interface. No packet duplication is necessary.
The Border Relay acts as the default multicast querier for all CEs that have established an IPv4 tunnel with it. In order to keep a consistent multicast state between a CE and BR, once a CE is connected it will stay connected until the state becomes empty. After that point, the CE may establish another tunnel to a different BR.
According to aggregated MLD reports received from subtending CEs, the BR establishes group/source-specific multicast forwarding states at its corresponding downstream tunnel interfaces. After that, the BR maintains or removes the state as required by the aggregated reports received from CEs.
At the upstream interface, the BR procures for aggregated multicast membership maintenance. Based on the multicast-transparent operations of the CEs, the BR treats its tunnel interfaces as multicast enabled downstream links, serving zero to many listening nodes.
When the BR receives MLD join requests from downstream CEs, the BR sends PIM join messages upstream towards multicast source(s). This results in a multicast tree formation where the BR is at the leaf of the multicast tree, enabling the BR to receive IPv6 multicast data sent by the source.
Multicast traffic arriving at the BR is transparently forwarded according to its multicast forwarding information base. Multicast data is first replicated according to MLD multicast group state and then forwarded in IPv6-in-IPv4 tunnels from the BR to the corresponding CEs.
IPv6 in IPv4 tunneling is performed as specified in [RFC4213]. Considerations specified in [RFC5969] apply. Packets passing upstream from the CE carry only MLD signaling messages and they are not expected to be fragmented. However packets downstream, i.e., multicast data to the CEs, may be subject to fragmentation.
Source and destination addresses of MLD messages in IPv6-in-IPv4 tunnel from CE are as follows:
The source and destination addresses of MLD messages in the IPv6- in-IPv4 softwire from BR are as follows:
The source address of IPv6 multicast data is the unicast IPv6 address of the multicast source, e.g., the content provider. The destination address is the3 IPv6 multicast group address.
In Section 5.1, multicast data is replicated to all interfaces, i.e., to all member CEs at the BR. This replication (often called avalanche problem) can be very costly if is a very large number of downstream member CEs such as in the IPTV application. See Appendix A in [I-D.ietf-softwire-dslite-multicast].
In 6rd tunneling multicast, the avalanche problem can be reduced by careful network partitioning. More BRs can be deployed in areas where IPv6 users are increasing in numbers. Deploying BRs by collocating them with the access network gateway as with the Border Network Gateway (BNG) is another possibility.
In the 6rd tunneling multicast operation, CEs are enabled to exploit multiple BRs that can be deployed in the network by using the BR anycast address any time they send an upstream MLD join request and then using the same BR that received the join message in subsequent MLD messages by using the same BR's unicast address.
In this section we specify how the host can subscribe and receive IPv6 multicast data from IPv6 content providers based on the architecture defined in Figure 2.
The hosts will send their subscription requests for IPv6 multicast groups upstream to the default router, i.e., the Costumer Edge device. After subscribing the group, the host can receive multicast data from the CE. The host implements the MLD protocol's host part.
The Customer Edge device is an MLD Proxy. After receiving the first MLD Report message requesting subscription to an IPv6 multicast group, the CE interworks the MLD Membership Report message to an IGMP Membership report message. It sends it upstream only if joining a new group is needed.
Address translation in generating an IGMP Membership report message is done as follows: the destination address is copied from the last 32 bits of IPv6 multicast group address. The CE inserts the IPv4 address of its WAN interface into the source address. It is assumed that the IPv6 multicast group address in MLD Report message conforms to the addressing scheme described in [I-D.ietf-mboned-64-multicast-address-format], for any-source and source-specific multicast address formats.
Source addresses in the MLDv2 payload are translated as follows. Multicast source addresses in MLD Membership Report message MUST use uPrefix64, i.e. 64:ff9b::/96 defined in [RFC6052]. uPrefix64 facilitates translation into an IPv4 source address to be used in IGMPv3 Membership Report messages for source-specific multicast, i.e., by extracting the last 32 bits of IPv6 source address.
The IGMP Report message is received by the IGMP Querier/Proxy upstream on the link. (Normally this node is the Broadband Network Gateway, BNG in broadband networks.) The IGMP Querier/Proxy sends IGMPv3 Report message to the neighboring routers to join the group. In networks where PIM is supported, the IGMP Report message may be received by the PIM Designated Router. The PIM router sends a PIMv4 join message to join an IPv4 group.
The border router that receives the join message translates the message into MLD. To join an IPv6 group for any-source multicast, the IPv6 Multicast group address is obtained from the destination address. For source-specific multicast, the IPv6 source address is generated after obtaining the IPv4 source address of Membership Report message's Group Record Source Address field. The BR sends the PIMv6 join message upstream towards the source.
The BR MUST act as the designated router to which the source of the source-specific IGMP join message is connected. The BR MUST act as the rendez-vous point (RP) of the multicast group for the any-source multicast IGMP join message. Normally there is one such BR in an operator's network. An IPv4 multicast tree eventually forms in the network between the CE and BR and an IPv6 multicast tree upstream from the BR for the same ASM or SSM group.
IPv6 multicast data received at the border router from the source is translated into IPv4. The last 32 bits of the source and destination address fields determine the source and destination addresses of the IPv4 multicast data packet. This packet is sent downstream on the multicast tree already formed for this IPv4 multicast group.
Multicast data packet address translation follows the rules in [I-D.ietf-mboned-64-multicast-address-format] for the multicast group address and [RFC6052] for source- specific multicast source address, i.e. using uPrefix64. For any- source multicast, the Border Router inserts an IPv4 source address, different for each source.
Packet header translation follows the rules in [RFC6145]. Fragmentation and reassembly are handled as described in [RFC6145]. After the IPv4 multicast data packet is sent downstream from the BR it may be fragmented by the routers.
The CE receives the IPv4 multicast data packet, possibly in fragments, and reassembles the fragments. The CE translates the IPv4 multicast data packet back to an IPv6 multicast data packet. Address translation is done following [I-D.ietf-mboned-64-multicast-address-format] for multicast group addresses and [RFC6052] for unicast SSM source addresses. Header translation is done as in [RFC6145].
IPv6 multicast data is sent on the home link to the host(s). IEEE 802.3 or IEEE 802.11 multicast link support usually handles this delivery in Layer 2 without any packet duplication if there are more than one members to the any-source multicast group or SSM source and multicast group.
In this section we assume that Layer 2 multicast is supported in the network. Layer 2 multicast support is done in order to forward multicast data downstream to the ports of Layer 2 devices, i.e. switches that requested a multicast group instead of flooding the data to all the ports.
In the switches, called snooping switches, multicast MAC address based filters are set up which link layer 2 multicast groups to the egress ports. IGMP snooping switches are commonly used in operators' networks, most commonly at the access nodes (AN) [RFC6788].
When an IGMP Report message is received, the bridge will set up a multicast filter entry that allows (in case of a join message) or prevents (in case of a leave message) packets to flow on the port on which the IGMP Report message was received. In terms of IPv4 multicast addresses, the mapping is not unique as 32 IPv4 multicast addresses map to a single Ethernet multicast MAC address [RFC4541].
The main functionality of a snooping switch is to forward multicast data packets based on the filters that are setup, i.e. to those egress ports with multicast groups downstream and also to the router ports.
In a 6rd network the snooping switches must detect IGMP packets sent upstream by the CE and set the filtering rules accordingly. When IPv4 data packets are received the IGMP snooping switches forward these packets towards all CEs that have members, effectively achieving packet duplication at the access node level.
An analysis of the translation solution reveals the following:\
6rd Translation Multicast control and data message security are as described in [RFC5969]. The threats and their mitigation described in [RFC5969] apply to multicast communication as well.
TBD.
We would like to specially thank Mark Townsley for his constructive comments. Steve Wright's online and very many offline comments helped us improve the document.
| [RFC3171] | Albanna, Z., Almeroth, K., Meyer, D. and M. Schipper, "IANA Guidelines for IPv4 Multicast Address Assignments", RFC 3171, August 2001. |
| [RFC6788] | Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S. and E. Nordmark, "The Line-Identification Option", RFC 6788, November 2012. |