One document matched: draft-lee-behave-v4v6-mcast-fwk-00.txt
BEHAVE Working Group Y. Lee
Internet-Draft Comcast
Intended status: Informational J. Qin
Expires: August 25, 2011 ZTE
February 21, 2011
IPv4/IPv6 Multicast Translation Framework
draft-lee-behave-v4v6-mcast-fwk-00
Abstract
The note describes a framework for IPv4/IPv6 translation of multicast
traffic. This note discusses various multicast scenarios while
transitioning IPv4 multicast to IPv6 multicast.
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 August 25, 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Lee & Qin Expires August 25, 2011 [Page 1]
Internet-Draft MCast Translation Framework February 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Translation Objectives . . . . . . . . . . . . . . . . . . . . 3
4. Scenarios Overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. From the IPv4 source to the IPv6 receiver . . . . . . . . 4
4.2. From the IPv6 source to the IPv4 receiver . . . . . . . . 4
5. Location of the Multicast Translator . . . . . . . . . . . . . 5
5.1. Scenario 1: mXlate46 is not the DR of the IPv4 source . . 6
5.2. Scenario 2: mXlate is the DR of the IPv4 source . . . . . 7
5.3. Scenario 3: mXlate is the MLD Querier . . . . . . . . . . 8
5.4. Scenario 4: mXlate is not the DR of the IPv6 source . . . 8
5.5. Scenario 5: mXlate is the DR of the IPv6 source . . . . . 9
5.6. Scenario 6: mXlate is the IGMP Querier . . . . . . . . . . 10
6. Translation Components . . . . . . . . . . . . . . . . . . . . 10
6.1. Address Translation . . . . . . . . . . . . . . . . . . . 10
6.2. Multicast Translator (mXlate) . . . . . . . . . . . . . . 11
6.2.1. mXlate in ASM . . . . . . . . . . . . . . . . . . . . 11
6.2.2. mXlate in SSM . . . . . . . . . . . . . . . . . . . . 12
6.2.3. Interchanging ASM and SSM . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Lee & Qin Expires August 25, 2011 [Page 2]
Internet-Draft MCast Translation Framework February 2011
1. Introduction
[I-D.ietf-behave-v6v4-framework] describes the framework for IPv4/
IPv6 translation of unicast. This document is a companion note to
describe the framework for IPv4/IPv6 translation of multicast.
2. Terminology
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 [RFC2119]. In
addition, this note uses the terminology defined in
[I-D.ietf-behave-v6v4-framework].
3. Translation Objectives
Similar to unicast translation, the objective of multicast
translation is enabling the source in one address family to deliver
multicast packets to the receiver in a different address family.
For multicast applications, there is usaully one source with one or
more receivers. In Any-Source Multicast (ASM), the receivers join
the multicast distribution tree only depending on the multicast group
address. The multicast streams delivered by any source to that
multicast group address will be accepted by the receivers. In
Source-Specific Multicast (SSM), the receivers join the multicast
distribution tree depending on the mulitcast group address and source
address pair. Only mulitcast streams delivered by that given source
to that multicast group address will be accepted by the receivers.
Sometimes, multicast is used for local service discovery (e.g., OSPF
Multicast addresses); however, we argue that this type of multicast
should not be translated. Multicast is also used for media delivery
such as broadcast videos and live events. In this memo, these are
the primary services for translation.
To enable multicast translation, both multicast protocols (e.g.,
IGMP, PIM, etc.) and multicast packets are required to be translated.
When designing solutions, the existing multicast protocols should be
utilized as much as possible. In addition, the framework should
ensure the packet replication of multicast packets happens at the
edge of the network close to the multicast receivers.
Lee & Qin Expires August 25, 2011 [Page 3]
Internet-Draft MCast Translation Framework February 2011
4. Scenarios Overview
Since the multicast data stream is unidirectional and is forwarded
from the source to the receivers, there are generally two categories
of IPv4/IPv6 translation scenarios per multicast stream:
1. From the IPv4 source to the IPv6 receivers.
2. From the IPv6 source to the IPv4 receivers.
Note that a receiver of given multicast stream may become the source
of another multicast stream. As such, a multicast receiver may turn
the received stream (i.e. which may pass through the translator too)
and become the source of another receiver. In the context of this
document, they should be treated as two independent multicast
streams.
4.1. From the IPv4 source to the IPv6 receiver
There is a requirement for the legacy IPv4 multicast source to
provide services to the IPv6 receivers.
+-----------+ +------------+ +----------+
| IPv6 | ...... | Multicast | ...... | IPv4 |
| Receivers | | Translator | | Source |
+-----------+ +------------+ +----------+
Figure 1
In this case, the multicast traffic is IPv4 framed. The IPv4-
formatted multicast is translated to IPv6-formatted by a Multicast
Translator (mXlate) and forwarded to the IPv6 receivers. The
procedures of multicast data subscribing and forwarding are different
according to the different locations of the Multicast Translator.
Refer to following sections for details.
4.2. From the IPv6 source to the IPv4 receiver
This scenario applies to the environment where the IPv6 multicast
source may still need to provide services to the IPv4 receivers.
Lee & Qin Expires August 25, 2011 [Page 4]
Internet-Draft MCast Translation Framework February 2011
+-----------+ +------------+ +----------+
| IPv4 | ...... | Multicast | ...... | IPv6 |
| Receivers | | Translator | | Source |
+-----------+ +------------+ +----------+
Figure 2
In this case, the multicast traffic is IPv6 framed. The IPv6-
formatted multicast is translated to IPv4-formatted by a Multicast
Translator (mXlate) and forwarded to the IPv4 receivers. The
procedures of multicast data subscribing and forwarding are different
according to the different locations of the Multicast Translator.
Refer to following sections for details.
5. Location of the Multicast Translator
In general, the scheme provisioning multicast can be represented as
Figure 3
+--------+
| Source |
+--------+
|
+------+
| DR |
+------+
|
------------
/ Multicast \ The tree may consist of both IPv4
| Distribution | segment and IPv6 segment joining at
\ Tree / the point of the "translator".
------------
|
+----------+
| IGMP/MLD |
| Querier |
+----------+
/ \
/ \
+----------+ +----------+
| Receiver | | Receiver |
+----------+ +----------+
Lee & Qin Expires August 25, 2011 [Page 5]
Internet-Draft MCast Translation Framework February 2011
Figure 3
The Multicast Translator (mXlate) places a special rule in the
translation. It joins both the IPv4 multicast distribution tree and
IPv6 multicast distribution tree. The mXlate is responsible for
translating the multicast protocols then utilizing the multicast
distribution tree to distribute the translated packets. In this
memo, we consider both Any-Source Multicast (ASM) and Source-Specific
Multicast (SSM).
Depending on the variable locations of the mXlate, each of the two
translation scenarios (i.e. v4 source to v6 receivers; v6 source to
v4 receivers) can be further divided into three scenarios.
For IPv4->IPv6 (mXlate S4R6)
Scenario 1: mXlate is not the DR of the IPv4 source
Scenario 2: mXlate is the DR of the IPv4 source
Scenario 3: mXlate is the MLD Querier
For IPv6->IPv4 (mXlate S6R4)
Scenario 4: mXlate is not the DR of the IPv6 source
Scenario 5: mXlate is the DR of the IPv6 source
Scenario 6: mXlate is the ICMP Querier
5.1. Scenario 1: mXlate46 is not the DR of the IPv4 source
In this scenario, the access network is an IPv6-only network, the
multicast source is still IPv4 and it is in the IPv4 regime. The
mXlate will be deployed between the IPv4 and IPv6 regimes. The
mXlate is not directly connected to the source as such it is not the
Designated Router of the IPv4 multicast source group.
Lee & Qin Expires August 25, 2011 [Page 6]
Internet-Draft MCast Translation Framework February 2011
-------
// \\ -----------
/ \ // \\
/ +------+ \
R6===MR IPv6 |mXlate| IPv4 (S4/RP)
| Network +------+ Network /
\ / \\ // RP = Rendezvous Point
\\ // ----------- S4 = v4 Multicast Source
-------- MR = Multicast Router
----> ------------> ------------> R6 = v6 Receiver
MLD PIMv6-Join PIMv4-Join
<=========== <===========
IPv6 Mcast IPv4 Mcast
Figure 4
This is typical transition scenario in the early phase. The access
network is IPv6-only, but the multicast source is located in an IPv4
network. The mXlate is centralized in the network which can be used
to serve multiple regions. This scenario is suitable for early
transition where there are not many IPv6 receivers requesting IPv4
multicast sources.
5.2. Scenario 2: mXlate is the DR of the IPv4 source
In this scenario, the access network is an IPv6-only network, the
multicast source is still IPv4. The mXlate and the IPv4 multicast
source is on the same network, and the mXlate is also the Designated
Router.
-------
// \\
/ \ |
/ +------+ | R6 = v6 Receiver
R6===MR IPv6 |mXlate|----| MR = Multicast Router
| Network +------+ |- S4 S4 = v4 Multicast Source
\ / |
\\ //
--------
----> ------------>
MLD PIMv6-Join
<=============
IPv6 Mcast
Lee & Qin Expires August 25, 2011 [Page 7]
Internet-Draft MCast Translation Framework February 2011
Figure 5
This could happen if the network and multicast receivers have
migrated to IPv6; however, the multicast source have yet to migrate
to IPv6. mXlate is directly connected to the multicast source and
responsible for translating the IPv4 multicast packets to IPv6
multicast packets to the IPv6 receivers.
5.3. Scenario 3: mXlate is the MLD Querier
In this scenario, the entire network is stll IPv4; however, the
receiver is IPv6-only. The mXlate is the immediate multicast router
of the IPv6-only receiver.
-------
// \\ -----------
/ \ // \\
+------+ +----+ \
R6==|mXlate|========| MR | IPv4 (S4/RP)
+------+ IPv4 +----+ Network /
\ Network / \\ //
\\ // ----------- RP = Rendezvous Point
-------- S4 = v4 Multicast Source
----> -------------> ------------> MR = Multicast Router
MLD ICMP PIMv4-Join R6 = v6 Receiver
<====== <=============================
IPv6 Mcast IPv4 Mcast
Figure 6
This scenario is a typical setup for ISPs which face a real shortage
of IPv4 addresses for the new devices but not yet finished the entire
network upgrade to IPv6 to support multicast. IPv6 will be deployed
between the edge router (e.g. BNG) and home.
5.4. Scenario 4: mXlate is not the DR of the IPv6 source
In this scenario, an IPv4 multicast network with receivers is
connected through mXlate to an IPv4 multicast network where the
source is located. The mXlate translates the IPv6 formatted
mulitcast source to IPv4 and distributes translated packets through
the multicast distribution tree in the IPv4 network.
Lee & Qin Expires August 25, 2011 [Page 8]
Internet-Draft MCast Translation Framework February 2011
-------
// \\ -----------
/ \ // \\
/ +------+ \
R4===MR IPv4 |mXlate| IPv6 (S6/RP)
| Network +------+ Network /
\ / \\ // RP = Rendezvous Point
\\ // ----------- S6 = v6 Multicast Source
-------- MR = Multicast Router
----> ------------> ------------> R4 = v4 Receiver
ICMP PIMv4-Join PIMv6-Join
<=========== <===========
IPv4 Mcast IPv6 Mcast
Figure 7
This could happen when the multicast source and majority of the
network have been migrated to IPv6. However, there are few IPv4
islands left which still want to receive multicast packets from the
IPv6 source.
5.5. Scenario 5: mXlate is the DR of the IPv6 source
In this scenario, the access network is IPv4-only network, the
multicast source has been migrated to IPv6. The mXlate and the IPv6
source is on the same network, and the mXlate is also the Designated
Router.
-------
// \\
/ \ |
/ +------+ | R4 = v4 Receiver
R4===MR IPv4 |mXlate|----| MR = Multicast Router
| Network +------+ |- S6 S6 = v6 Multicast Source
\ / |
\\ //
--------
----> ------------>
MLD PIMv4-Join
<=============
IPv4 Mcast
Figure 8
Lee & Qin Expires August 25, 2011 [Page 9]
Internet-Draft MCast Translation Framework February 2011
This could happen if there are still IPv4-only networks left after
the source has been migrated to IPv6. The mXlate behaves as DR
connected to the IPv4 source and translate the multicast packets to
IPv4 formatted which are then distributed in the IPv4 multicast
network.
5.6. Scenario 6: mXlate is the IGMP Querier
In this scenario, the entire network is IPv6. The multicast source
is also IPv6-only. However, there are some legacy IPv4 receivers
which want to receive packets from the IPv6-only source.
-------
// \\ -----------
/ \ // \\
+------+ +----+ \
R4==|mXlate|========| MR | IPv6 (S6/RP)
+------+ IPv6 +----+ Network /
\ Network / \\ //
\\ // ----------- RP = Rendezvous Point
-------- S6 = Multicast Source
----> ------------> ------------> MR = Multicast Router
MLD ICMP PIMv4-Join R4 = v4 Receiver
<====== <============================
IPv6 Mcast IPv4 Mcast
Figure 9
This scenario could happen after the operator has completely migrated
to IPv6, but few IPv4-only receivers have yet to retire or to migrate
to IPv6. These IPv4-only receivers can be connected by mXlate which
locates in the IGMP Querier.
6. Translation Components
6.1. Address Translation
It is important for the mXlate to specify how an IPxX address is
translated to an IPvY for the operations of mXlate. Scenario 1, 2,
and 3 require to translate an IPv4 multicast group to an IPv6
multicast group. This can be achieved by following the mechanisms
defined in [I-D.boucadair-behave-64-multicast-address-format]. The
mXlate creates a stateless mapping table of IPv4->IPv6 group
addresses indicated by the IPv4-embedded IPv6 addresses and
Lee & Qin Expires August 25, 2011 [Page 10]
Internet-Draft MCast Translation Framework February 2011
translates the IPv4 multicast packets into multicast packets based on
the mapping table.
Scenario 4, 5, and 6 require to translate an IPv6 multicast group to
an IPv4 multicast group. Since the IPv6 multicast group has much
large address space than IPv4 multicast group, it is impossible to
achieve an one-to-one mapping. In fact, this creates a tough
challenge to define an algorithm to translate an IPv6 multicast group
to an IPv4 multicast group. In practice, the mXlate can create a
stateful mapping table of IPv6->IPv4 group addresses. These entries
are probably defined by the operators and each operator may have
different definitions of the table. As such, inter-domain multicast
translation will require coordination.
6.2. Multicast Translator (mXlate)
mXlate plays two roles in the multicast translation. It is
responsible for translating the multicast control protocol from IPvX
to IPvY (e.g., IGMP<->MLD) and translating the actual multicast data
packets from IPvX to IPvY. Depending on the deployment models (ASM
vs. SSM), there are different considerations.
6.2.1. mXlate in ASM
6.2.1.1. mXlate Location
In ASM deployment model, mXlate must be the "root" of the multicast
distribution tree of the translated multicast group. This is
important because the mXlate maintains the mapping information to
translate the IPvX to IPvY.
6.2.1.2. Source Registration
Source Registration happens when the source starts sourcing multicast
packets. The DR will send the Source Registration to the RP. In the
shared tree model, the RP will start replicate the packets to the
interfaces where received the PIM-Join of the multicast group.
Consider Scenario 1 and 4 where mXlate is not the DR of the multicast
source. If a receiver sends a PIMvX-Join of the translated multicast
group to the RPvX, the RPvX will not know where the source is, so it
will wait until it receives the Source Registration coming from
mXlate. Unfortunately the mXlate will never send the Source
Registration because it is not the "DR" and the DRvY never knows that
there is a RP of another address family waiting for the Source
Registration. In order to solve this problem, there are two ways:
Lee & Qin Expires August 25, 2011 [Page 11]
Internet-Draft MCast Translation Framework February 2011
1. Configure the mXlate to become the RP of all the translated
multicast addresses.
2. Configure the mXlate to join all the known IPvY-translated IPvY
multicast groups to the RPvY and IPvY Sources send Source
Registration to the RPvX regardless whether any receiver has
asked to join the groups.
This problem is unique to Scenario 1 and 4. The reminding scenarios
will not suffer from the same problem because the mXlate is the DR of
the source in Scenario 2 and 5, and the mXlate is a simple MLD<->ICMP
translator in Scenario 3 and 6.
6.2.2. mXlate in SSM
6.2.2.1. mXlate Location
In SSM deployment model, mXlate must be the source of the SSM group
of the translated multicast address group. When the mXlate receives
the PIMvX-Join, it would translate this to a PIMvY-Join to upstream
multicast router. The IPvX Source to IPvY Source mapping information
is stateful and stored in the mXlate.
6.2.3. Interchanging ASM and SSM
mXlate is the bridging point of two multicast trees. It is possible
that the mXlate runs SSM in the IPvX domain and ASM in the IPvY
domain or vice versa. For example: In Scenario 1, if the IPv6
network runs SSM and the IPv4 runs ASM, this could potentially solve
the problem of Source Registration described in Section 6.2.1.2.
7. IANA Considerations
This document has no requirement to IANA.
8. Security Considerations
TBD
9. Acknowledgements
TBD
10. References
Lee & Qin Expires August 25, 2011 [Page 12]
Internet-Draft MCast Translation Framework February 2011
10.1. Normative References
[I-D.ietf-behave-v6v4-framework]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation",
draft-ietf-behave-v6v4-framework-10 (work in progress),
August 2010.
10.2. Informative References
[I-D.boucadair-behave-64-multicast-address-format]
Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
M. Xu, "IPv4-Embedded IPv6 Multicast Address Format",
draft-boucadair-behave-64-multicast-address-format-01
(work in progress), February 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Yiu L. Lee
Comcast
Email: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Jacni Qin
ZTE
Email: jacniq@gmail.com
URI: http://www.zte.com.cn
Lee & Qin Expires August 25, 2011 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 02:17:53 |