One document matched: draft-tsou-softwire-6rd-multicast-00.txt
Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies (USA)
Intended status: Standards Track T. Taylor
Expires: July 9, 2011 C. Zhou
Huawei Technologies
H. Ji
China Telecom
January 5, 2011
IPv6 Multicast Using Native IPv4 Capabilities in a 6rd Deployment
draft-tsou-softwire-6rd-multicast-00
Abstract
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.
Status of this Memo
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 Notice
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
Tsou, et al. Expires July 9, 2011 [Page 1]
Internet-Draft IPv6 Multicast With 6rd January 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Description of the Solution . . . . . . . . . . . . . . . . . . 3
2.1. Assumed Architecture . . . . . . . . . . . . . . . . . . . 3
2.2. Steps In the Proposed Solution . . . . . . . . . . . . . . 5
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Tsou, et al. Expires July 9, 2011 [Page 2]
Internet-Draft IPv6 Multicast With 6rd January 2011
1. Introduction
6rd ([RFC5569], [RFC5969]) 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).
1.1. Requirements Language
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].
2. Description of the Solution
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.
2.1. Assumed Architecture
This document assumes an architecture similar to that of 6rd
[RFC5569], [RFC5969], 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.
Tsou, et al. Expires July 9, 2011 [Page 3]
Internet-Draft IPv6 Multicast With 6rd January 2011
+------------+
| 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:
o requesting a mapping between IPv6 <Source, Group> pairs presented
by the IPv6 Host and IPv4 <Source, Group> pairs valid for the
provider's IPv4 network;
o interworking between MLD [RFC3810] presented by the IPv6 Host and
IGMP [RFC3376] forwarded toward the provider's IPv4 network;
o translating incoming IPv4 multicast streams to IPv6 before
forwarding them to the IPv6 Host.
The Provider IP Edge has the normal function of interworking between
IGMP [RFC3376] and PIM [RFC4601] multicast signalling.
The Border Relay has the usual 6rd responsibilities. In addition, it
is responsible for:
o requesting a mapping between IPv4 <Source, Group> pairs received
in PIM messages from the IPv4 network and IPv6 <Source, Group>
pairs valid for the neighbouring IPv6 network;
o translating PIM messaging between the IPv4 and IPv6 networks;
o using the reverse mapping from IPv6 to IPv4 <Source, Group> pairs
to translate and forward multicast media streams coming from the
IPv6 network.
The Translator function has the following responsibilities:
o creating a mapping between IPv6 and IPv4 <Source, Group> address
pairs for multicast streams, beginning with IPv6 address pairs
provided in requests from the 6rd CE and assigning the
corresponding IPv4 unicast and multicast addresses from pool of
Tsou, et al. Expires July 9, 2011 [Page 4]
Internet-Draft IPv6 Multicast With 6rd January 2011
addresses with which it is configured.
o responding to requests for mappings in either direction.
2.2. Steps In the Proposed Solution
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] 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
Tsou, et al. Expires July 9, 2011 [Page 5]
Internet-Draft IPv6 Multicast With 6rd January 2011
IGMPv3 [RFC3376] 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] or [RFC4601] 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.]
Tsou, et al. Expires July 9, 2011 [Page 6]
Internet-Draft IPv6 Multicast With 6rd January 2011
+------+
|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.
Tsou, et al. Expires July 9, 2011 [Page 7]
Internet-Draft IPv6 Multicast With 6rd January 2011
+------+
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] 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.
3. Acknowledgements
Awaiting comments.
4. IANA Considerations
This memo currently includes no request to IANA.
5. Security Considerations
To come.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Tsou, et al. Expires July 9, 2011 [Page 8]
Internet-Draft IPv6 Multicast With 6rd January 2011
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
6.2. Informative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, January 2010.
Authors' Addresses
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
Tsou, et al. Expires July 9, 2011 [Page 9]
Internet-Draft IPv6 Multicast With 6rd January 2011
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
Tsou, et al. Expires July 9, 2011 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 02:48:10 |