TOC |
|
This document describes how IPv6 multicast can be extended across an IPv4 network to an IPv6 host, using the native multicast capabilities of the IPv4 network.
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 July 9, 2011.
Copyright (c) 2011 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.
1.
Introduction
1.1.
Requirements Language
2.
Description of the Solution
2.1.
Assumed Architecture
2.2.
Steps In the Proposed Solution
3.
Acknowledgements
4.
IANA Considerations
5.
Security Considerations
6.
References
6.1.
Normative References
6.2.
Informative References
§
Authors' Addresses
TOC |
6rd ([RFC5569] (Despres, R., “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd),” January 2010.), [RFC5969] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.)) provides a means to connect IPv6 hosts to the IPv6 Internet across an IPv4 provider network. Unicast traffic is carried through IPv6-in-IPv4 tunnels. It is possible to carry multicast traffic from the IPv6 network through the IPv4 network in the same way, but if multiple customers wish access to the same multicast channels, the failure to use the native multicast capabilities of the IPv4 network wastes resources in that network.
This document describes a solution use the native multicast capabilities of the IPv4 network to acquire and forward multicast traffic from IPv6 Internet to an IPv6 host attached to the IPv4 network. Typically this solution will operate in combination with 6rd for unicast traffic. However, no IPv6-in-IPv4 tunneling is required for signalling, only the ability to interwork between IPv4 and IPv6 at the 6rd Customer Equipment (6rd CE) and the 6rd Border Relay (BR).
TOC |
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
TOC |
A number of problems have to be solved to allow an IPv6 host attached to an IPv4 network to request and receive a multicast stream originating in a neighbouring IPv6 network and passing through the IPv4 network using the native multicast facilities of that network. These problems are described in detail in the course of presenting proposed solutions to them.
TOC |
This document assumes an architecture similar to that of 6rd [RFC5569] (Despres, R., “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd),” January 2010.), [RFC5969] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.), with additional capabilities for the 6rd CE and the 6rd Border Relay. In addition, it postulates a multicast source discovery and translation function, which MAY be collocated with the BR. See Figure 1 (IPv6 Multicast Across an IPv4 Domain Using a Translator Function).
+------------+ | Translator | -| function |- / +------------+ \ +----+ +----+ Access +--------+ / \ |IPv6| LAN | 6rd| Link |Provider| IPv4 +------+ IPv6 |Host|--------| CE |--------|IP Edge |- network ---|Border|--- network +----+ +----+ +--------+ |Relay | +------+
Figure 1: IPv6 Multicast Across an IPv4 Domain Using a Translator Function |
In addition to its 6rd responsibilities, the 6rd CE is responsible for:
The Provider IP Edge has the normal function of interworking between IGMP [RFC3376] (Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” October 2002.) and PIM [RFC4601] (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.) multicast signalling.
The Border Relay has the usual 6rd responsibilities. In addition, it is responsible for:
The Translator function has the following responsibilities:
TOC |
1. Initial discovery and Join request
The IPv6 Host discovers the <Source, Group> address pair of a multicast stream the user wants to receive. The discovery is by means outside the scope of this specification (e.g., via the web). The IPv6 Host sends an MLDv2 [RFC3810] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.) request to the 6rd CE to acquire the stream.
+----+ +----+ |IPv6| LAN | 6rd| |Host|--------| CE | +----+ +----+ -------> MLD/IPv6
Figure 2 |
2. <Source, Group> Address Mapping At 6rd CE
The 6rd CE checks its cache of mappings to see if it already has a mapping between the IPv6 <Source, Group> address pair received in the MLD request and a corresponding pair of IPv4 addresses. Failing to find a mapping, it sends a request for the required mapping to the Translator. The Translator in turn checks whether it has already created the mapping. If not, it assigns unicast and multicast IPv4 addresses from its pool and records the mapping for further use. In either case it returns the requested mapping to the 6rd CE, which caches it. [Editor's Note: The transaction is carried out over a protocol to be specified in a later version of this document.]
+----+ Access +--------+ +------------+ | 6rd| Link |Provider| IPv4 | Translator | | CE |--------|IP Edge |- network -| function | +----+ +--------+ +------------+ -----------------------------> TBD protocol / IPv4
Figure 3 |
3. Propagation Of the Join Request Into the IPv4 Network
The 6rd CE interworks between the MLDv2 request it received and an IGMPv3 [RFC3376] (Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” October 2002.) request which it forwards to the Provider IP Edge. It uses the address pair mapping it received from the Translator as part of this interworking.
The Provider IP Edge acts on the IGMP request by forwarding a PIM [RFC3973] (Adams, A., Nicholas, J., and W. Siadak, “Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised),” January 2005.) or [RFC4601] (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.) request into the IPv4 network, indicating the IPv4 <Source, Group> address pair it was given and ensuring that it is on the multicast tree for the stream concerned. [Editor's note: details later.]
Eventually the PIM request finds its way to the 6rd Border Relay. [Editor's note: details needed here to make sure this happens. Alternatively, we could recast this as using any Border Router and not a 6rd Relay in particular, but we would end up with possibly different paths for the multicast packets and the returning unicast RTCP feedback. Maybe that doesn't matter.]
+----+ Access +--------+ +------+ | 6rd| Link |Provider| IPv4 |Border| IPv6 | CE |--------|IP Edge |- network -|Relay |- network +----+ +--------+ +------+ --------> ------------> IGMP/IPv4 PIM/IPv4
Figure 4 |
4. Remapping the <Source, Group> Address Pair At the 6rd BR
The 6rd BR needs to map from the IPv4 <Source, Group> address pair it received back to the corresponding IPv6 address pair before propagating the PIM request into the IPv6 network. It sends a request to the Translator to provide that mapping. The Translator already has this mapping, as a result of the original 6rd CE request, and returns it to the 6rd BR. [Editor's note: protocol again to be specified later. It can probably be the same as the one used by the 6rd CE, since both nodes are operator-managed even if the 6rd CE is more likely to have been hacked. Have to work out the security considerations.]
+------+ |Border| |Relay | +------+ | TBD protocol | /IPv4 +----V-------+ | Translator | | function | +------------+
Figure 5 |
5. Propagation Of the PIM Request Into the IPv6 Network
The 6rd BR propagates translates the PIM request from IPv4 to IPv6 using the mapping it received. It propagates the request into the IPv6 network to complete the construction of the path for the requested multicast stream. [Editor's note: probably don't have to go this far if there are already other listeners attached to the IPv4 network. Have to insert corresponding text in previous steps. Also, if PIM can return errors, the 6rd BR should notify the Translator so it can mark the IPv6 address pair as bad (so it doesn't get remapped) while releasing the assigned IPv4 addresses.]
+------+ |Border| IPv6 |Relay |- network +------+ -----------> PIM/IPv6
Figure 6 |
6. Transport of Multicast Media and Unicast RTCP Feedback
If the 6rd BR receives a multicast packet from the IPv6 network, it translates the source and group addresses to IPv4 using the mapping it has retained from Step 4. It then forwards it to the next hop in the multicast tree for that stream.
+------+ IPv4 |Border| IPv6 network -|Relay |- network +------+ <---------- <---------- Media packet Media packet <S',G'>/IPv4 <S,G>/IPv6
Figure 7 |
When the 6rd CE receives a multicast packet from the IPv4 network, it translates the packet to IPv4 using the mapping which it has retained from Step 2.
When the IPv6 Host sends unicast RTCP [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) feedback toward the source, the packets are treated by the 6rd CE and 6rd BR like any other unicast packets. That is, they are encapsulated at the 6rd CE, transported across the IPv4 network as IPv6-in-IPv4, and decapsulated at the 6rd BR before forwarding into the IPv6 network.
Finally, if the IPv6 Host emits multicast packets destined for an any-source multicast group, the 6rd CE and 6rd BR translate the packets from IPv6 to IPv4 and back again using the mappings they have retained.
TOC |
Awaiting comments.
TOC |
This memo currently includes no request to IANA.
TOC |
To come.
TOC |
TOC |
[RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
[RFC3376] | Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” RFC 3376, October 2002 (TXT). |
[RFC3810] | Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” RFC 3810, June 2004 (TXT). |
[RFC3973] | Adams, A., Nicholas, J., and W. Siadak, “Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised),” RFC 3973, January 2005 (TXT). |
[RFC4601] | Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” RFC 4601, August 2006 (TXT, PDF). |
[RFC5969] | Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” RFC 5969, August 2010 (TXT). |
TOC |
[RFC3550] | Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” STD 64, RFC 3550, July 2003 (TXT, PS, PDF). |
[RFC5569] | Despres, R., “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd),” RFC 5569, January 2010 (TXT). |
TOC |
Tina Tsou | |
Huawei Technologies (USA) | |
2330 Central Expressway | |
Santa Clara, CA 95050 | |
USA | |
Phone: | +1 408 330 4424 |
Email: | tena@huawei.com |
URI: | http://tinatsou.weebly.com/contact.html |
Tom Taylor | |
Huawei Technologies | |
1852 Lorraine Ave | |
Ottawa, Ontario K1H 6Z8 | |
Canada | |
Phone: | +1 613 680 2675 |
Email: | tom111.taylor@bell.net |
Cathy Zhou | |
Huawei Technologies | |
Bantian, Longgang District | |
Shenzhen 518129 | |
P.R. China | |
Phone: | |
Email: | cathyzhou@huawei.com |
Hui Ji | |
China Telecom | |
NO19.North Street | |
Beijing, Chaoyangmen,Dongcheng District | |
P.R. China | |
Phone: | |
Email: | jihui@chinatelecom.com.cn |