Softwire WG Q. Wang
Internet-Draft China Telecom
Intended status: Standards Track J. Qin
Expires: December 15, 2011 ZTE
M. Boucadair
C. Jacquenet
France Telecom
Y. Lee
Comcast
June 13, 2011
Multicast Extensions to DS-Lite Technique in Broadband Deployments
draft-qin-softwire-dslite-multicast-04
Abstract
This document proposes a solution for the delivery of multicast
service offerings to DS-Lite serviced customers. The proposed
solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme
and does not require performing any NAT operation along the path used
to deliver multicast traffic.
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 December 15, 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
Wang, et al. Expires December 15, 2011 [Page 1]
Internet-Draft DS-Lite Multicast June 2011
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.
Wang, et al. Expires December 15, 2011 [Page 2]
Internet-Draft DS-Lite Multicast June 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Context and Scope . . . . . . . . . . . . . . . . . . . . . . 5
3.1. IPTV-centric View . . . . . . . . . . . . . . . . . . . . 5
3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. IPv4-embedded IPv6 Address Prefixes . . . . . . . . . . . 8
4.3. Multicast Distribution Tree . . . . . . . . . . . . . . . 9
4.4. Multicast Forwarding . . . . . . . . . . . . . . . . . . . 10
4.5. Multicast DS-Lite vs. Unicast DS-Lite . . . . . . . . . . 10
5. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 10
5.2. Text Representation Examples . . . . . . . . . . . . . . . 11
6. Multicast B4 (mB4) . . . . . . . . . . . . . . . . . . . . . . 11
6.1. IGMP-MLD Interworking function . . . . . . . . . . . . . . 11
6.2. De-capsulation and Forwarding . . . . . . . . . . . . . . 12
6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12
6.4. Host with mB4 function embedded . . . . . . . . . . . . . 12
7. Multicast AFTR (mAFTR) . . . . . . . . . . . . . . . . . . . . 13
7.1. Routing Considerations . . . . . . . . . . . . . . . . . . 13
7.2. Processing PIM/MLD Join Messages . . . . . . . . . . . . . 13
7.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 13
7.4. ASM Mode: Building Shared Trees . . . . . . . . . . . . . 14
7.4.1. IPv4 Side . . . . . . . . . . . . . . . . . . . . . . 14
7.4.2. IPv6 Side . . . . . . . . . . . . . . . . . . . . . . 14
7.5. TTL/Scope . . . . . . . . . . . . . . . . . . . . . . . . 15
7.6. Encapsulation and forwarding . . . . . . . . . . . . . . . 16
8. Optimization in L2 Access Networks . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. Firewall Configuration . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Translation vs. Encapsulation . . . . . . . . . . . . 19
A.1. Translation . . . . . . . . . . . . . . . . . . . . . . . 19
A.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Wang, et al. Expires December 15, 2011 [Page 3]
Internet-Draft DS-Lite Multicast June 2011
1. Introduction
DS-Lite [I-D.ietf-softwire-dual-stack-lite] is a technique to
rationalize the use of the remaining IPv4 addresses during the
transition period. The current design of DS-Lite covers unicast
services exclusively.
If customers access IPv4 multicast-based service offerings through a
DS-Lite environment, AFTR (Address Family Transition Router) devices
have to process all the IGMP reports [RFC2236] [RFC3376] received
within IPv4-in-IPv6 tunnels and behave as a replication point for
downstream multicast traffic. That is likely to severely affect the
multicast traffic forwarding efficiency by losing the benefits of
deterministic replication of the data as close to the receivers as
possible. As a consequence, the downstream bandwidth will be vastly
consumed while the AFTR capability may become rapidly overloaded, in
particular if the AFTR capability is deployed in a centralized
manner.
This document discusses an extension to the DS-Lite model to be used
for the delivery of IPv4 multicast-based service offerings.
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. Terminology
This document makes use of the following terms:
o IPv4-embedded IPv6 address: is an IPv6 address which embeds a 32
bit-encoded IPv4 address. An IPv4-embedded IPv6 address can be
unicast or multicast.
o mPrefix64: is a dedicated multicast IPv6 prefix for constructing
IPv4-embedded IPv6 multicast address
[I-D.boucadair-behave-64-multicast-address-format]. mPrefix64 can
be of two types: ASM_mPrefix64 used in ASM mode or SSM_mPrefix64
used in SSM mode [RFC4607].
o uPrefix64: is a dedicated unicast IPv6 prefix for constructing
IPv4-embedded IPv6 unicast address [RFC6052].
o Multicast AFTR (mAFTR for short): is a functional entity which is
part of both the IPv4 and IPv6 multicast distribution trees and
Wang, et al. Expires December 15, 2011 [Page 4]
Internet-Draft DS-Lite Multicast June 2011
which replicates IPv4 multicast streams into IPv4-in-IPv6 streams
in the relevant branches of the IPv6 multicast distribution tree.
o Multicast B4 (mB4 for short): is a functional entity embedded in a
CPE, which is able to enforce an IGMP-MLD interworking function (
refer to Section 6.1) together with a de-capsulation function of
received multicast IPv4-in-IPv6 packets.
3. Context and Scope
3.1. IPTV-centric View
IPTV generally includes two categories of service offerings:
1. VoD (Video on Demand) or Catch-up TV channels streams that are
delivered using unicast mode to receivers.
2. Live TV Broadcast services that are generally multicast to
receivers.
Numerous players intervene in the delivery of this service:
o Content Providers: the content can be provided by the same
provider as the one providing the connectivity service or by
distinct providers;
o Network Provider: the one providing network connectivity service
(e.g., responsible for carrying multicast flows from head-ends to
receivers). Refer to [I-D.ietf-mboned-multiaaa-framework].
Many of the current IPTV contents are likely to remain IPv4-formatted
and out of control of the network providers. Additionally, there are
numerous legacy receivers (e.g., IPv4-only Set Top Boxes (STB)) that
can't be upgraded or be easily replaced. As a consequence, IPv4
service continuity must be guaranteed during the transition period,
including the delivery of multicast-based services such as Live TV
Broadcasting. The dilemma is the same as in the transition of
unicast-based Internet services where the customer premises and
global Internet are out of control of the service providers even if
they would like to promote the use of IPv6. The DS-Lite design tries
to eliminate this issue by decoupling the IPv6 deployments in service
provider networks from that in global Internet and in customer
devices and applications.
DS-Lite can be seen as a catalyst for IPv6 deployment while
preserving customer's Quality of Experience (QoE). This is also the
design goal of the solution proposed in this document for DS-Lite
Wang, et al. Expires December 15, 2011 [Page 5]
Internet-Draft DS-Lite Multicast June 2011
serviced customers who have subscribed to a multicast-based service
offering.
3.2. Scope
This document focuses only on issues raised by a DS-Lite networking
environment: subscription to an IPv4 multicast group and the delivery
of IPv4-formatted content to IPv4 receivers. In particular, only the
following case is covered:
1. An IPv4 receiver accessing IPv4 content (i.e., content formatted
and reachable in IPv4)
A viable scenario for this use case in DS-Lite environment: Customers
with legacy receivers must continue to access the IPv4-enabled
multicast services. This means the traffic should be accessed
through IPv4 and additional functions are needed to traverse
operators' IPv6- enabled network which is the purpose of this
document. While since technically, there is no extra function
required for the scenario of native access (i.e. to access dual-stack
content natively from the IPv6 receiver), this portion is not taken
into account. Refer to [I-D.jaclee-behave-v4v6-mcast-ps] for the
deployment considerations.
This document does not cover the case where an IPv4 host connected to
a CPE served by a DS-Lite AFTR can be the source of multicast
traffic.
Note that some contract agreements prevent a network provider to
alter the content as sent by the content provider, in particular for
copyright, confidentiality and SLA assurance reasons. The streams
should be delivered unaltered to requesting users.
4. Solution Overview
In the original DS-Lite specification
[I-D.ietf-softwire-dual-stack-lite], an IPv4-in-IPv6 tunnel is used
to carry the bidirectional IPv4 unicast traffic between B4 and AFTR.
This document defines an IPv4-in-IPv6 encapsulation scheme to deliver
multicast traffic. Within the context of this document, an IPv4
derived IPv6 multicast address is used as the destination of the
encapsulated unidirectional IPv4-in-IPv6 multicast traffic from the
mAFTR to the mB4. The IPv4 address of the source of the multicast
content is represented in the IPv6 realm with an IPv4-embedded IPv6
address as well.
See following sections for the multicast distribution tree
Wang, et al. Expires December 15, 2011 [Page 6]
Internet-Draft DS-Lite Multicast June 2011
establishment (Section 4.3) and the multicast traffic forwarding
(Section 4.4).
Note that IPv4-in-IPv6 encapsulated multicast flows are treated in an
IPv6 realm like any other IPv6 multicast flow. Upon completion of
the establishment of a multicast distribution tree, no extra function
is required to be defined to forward IPv4-in-IPv6 multicast traffic
in the IPv6 network.
4.1. Rationale
This document introduces two new functional elements (Figure 1):
1. The mAFTR: responsible for replicating IPv4 multicast flows in
the IPv6 domain owing to a stateless IPv4-in-IPv6 encapsulation
function. The mAFTR does not undertake any NAT operation. The
mAFTR is a demarcation point which connects to both the IPv4 and
IPv6 multicast networks.
2. The mB4: is a functional entity embedded in a CPE responsible for
the de-capsulation of the received IPv4-in-IPv6 multicast packets
and forwarding them to the appropriate IPv4 receivers.
Wang, et al. Expires December 15, 2011 [Page 7]
Internet-Draft DS-Lite Multicast June 2011
+-----------+
| IPv4 |
| Source |
+-----------+
|
------------
/ \
| IPv4 network |
\ /
------------
|
+-------------+
| mAFTR |
+-------------+
|
------------
/ \
| IPv6 network |
\ /
------------
|
+-----------+
| mB4 |
+-----------+
|
+-----------+
| IPv4 |
| Receiver |
+-----------+
Figure 1: Functional Architecture
4.2. IPv4-embedded IPv6 Address Prefixes
A dedicated IPv6 multicast prefix (mPrefix64) is needed for forming
IPv6 multicast addresses, with IPv4 multicast address embedded. The
mPrefix64 can be of two types: ASM_mPrefix64 (an mPrefix64 used in
ASM mode) or SSM_mPrefix64 (an mPrefix64 used in SSM mode), and MUST
be derived from the corresponding IPv6 multicast address space
[I-D.boucadair-behave-64-multicast-address-format].
In addition, the address of the IPv4 multicast source should be
mapped to IPv6 addresses in the IPv6 realm: an IPv6 unicast prefix
(uPrefix64) is therefore needed for forming IPv6 unicast addresses
with IPv4 unicast address embedded. The uPrefix64 MUST be derived
from the IPv6 unicast address space [RFC6052].
The mAFTR and mB4 MUST use the same mPrefixe64 and uPrefix64, and the
Wang, et al. Expires December 15, 2011 [Page 8]
Internet-Draft DS-Lite Multicast June 2011
same algorithm for building IPv4-embedded IPv6 addresses. Refer to
Section 5 for more details on the IPv6 address format.
4.3. Multicast Distribution Tree
Assume that an IPv4 receiver sends an IGMP Report towards the mB4 to
join a given multicast group. After receiving the IGMP Report
message, the mB4 converts the IGMP message into a MLD Report
[RFC2710] message which will then be forwarded upstream towards the
MLD Querier. The MLD Querier is likely to coexist with the PIM DR
where the PIMv6 Join message will be triggered and sent up hop by hop
along the PIMv6 routers. Note that the mAFTR is in the path to reach
the IPv4 source; this is typically achieved by the underlying unicast
IPv6 routing protocol that advertises the unicast IPv4-embedded IPv6
addresses: these addresses are used to represent IPv4 sources in the
IPv6 multicast domain.
Both the MLD and the PIMv6 Join messages convey the IPv6 address of
the multicast group to be joined. The corresponding IPv6 multicast
group address is constructed by using the pre-configured mPrefix64
and an algorithm so that the IPv4 multicast group address is embedded
accordingly.
When source-specific multicast is deployed, the IPv6 address of the
multicast source should be constructed in the same way (using
uPrefix64, with IPv4 multicast source embedded). Refer to Section
6.1 for more details of the mB4 function.
o If the mAFTR is embedded in the MLD Querier/PIMv6 DR, it should
process the received MLD Report message for the IPv4-embedded IPv6
group and send the corresponding IPv4 PIM Join message.
o If the mAFTR is embedded in some upstream PIMv6 router more than
one hop away from the mB4, it should process the received PIMv6
Join message for the IPv4-embedded IPv6 group and send the
corresponding IPv4 PIM Join message.
In both cases, an entry for an IPv6 multicast group address is
created by the mAFTR in its multicast Routing Information Base and is
used to forward multicast IPv4-in-IPv6 datagrams. Refer to Section
7.1 for more details about the mAFTR function.
A branch of the multicast distribution tree is then established,
comprising both an IPv4 part (from the mAFTR upstream) and an IPv6
part (between the mB4 and the mAFTR).
Wang, et al. Expires December 15, 2011 [Page 9]
Internet-Draft DS-Lite Multicast June 2011
4.4. Multicast Forwarding
Whenever an IPv4 multicast packet is received on a mAFTR (this
assumes the RPF Check has passed Section 7.1), it will be
encapsulated into an IPv6 packet using the IPv4-embedded IPv6
multicast address as the destination address and an IPv4-embedded
IPv6 unicast address as the source of the IPv4-in-IPv6 packet. The
new IPv6 multicast packet will then be sent through the outgoing
interface of the matching entry in the multicast routing table and
forwarded down the IPv6 multicast distribution tree towards the mB4.
When receiving the packet, the mB4 should de-capsulate it and forward
the original IPv4 multicast packet to the appropriate receiver. If
mB4 does not have any route to forward the packet (e.g., change of
the IPv4 address without cleaning MLD states), the encapsulated IPv4
datagram is silently dropped.
Note that: There is an alternative to the encapsulation based
mechanism (which is detailed in this memo) for Multicast Forwarding:
Translation based approach, which is per
[I-D.boucadair-behave-64-multicast-address-format], [RFC6052] and
[RFC6145]. Refer to Appendix A.
4.5. Multicast DS-Lite vs. Unicast DS-Lite
Unlike a unicast AFTR, a mAFTR does not perform any NAT for
delivering IPv4 multicast traffic.
Unlike unicast DS-Lite, a mB4 does not need to discover a mAFTR.
mAFTR is responsible for encapsulating in a stateless manner the IPv4
multicast traffic into IPv6 datagrams. mB4 is responsible for de-
capsulating in a stateless manner the IPv4-in-IPv6 multicast traffic.
Further elaboration is provided in the following sections about the
behaviour of the mAFTR and the mB4.
The corresponding multicast DS-Lite and the unicast DS-Lite
functional elements can be co-located in the same device or
separated.
5. Address Mapping
5.1. Prefix Assignment
In order to map the addresses of IPv4 multicast traffic with IPv6
multicast addresses, an IPv6 multicast prefix (mPrefix64) and an IPv6
unicast prefix (uPrefix64) are provided to mAFTR and mB4 elements.
Wang, et al. Expires December 15, 2011 [Page 10]
Internet-Draft DS-Lite Multicast June 2011
The address format to be used is being left to the responsibility of
the service provider as indicated in [RFC6052] and
[I-D.boucadair-behave-64-multicast-address-format].
The mPrefix64 and uPrefix64 together with the address format to be
used can be configured in the mB4 through a dedicated provisioning
protocol, such as DHCPv6 or another protocol. Two candidate DHCPv6
options are identified in [I-D.ietf-behave-nat64-learn-analysis].
5.2. Text Representation Examples
Group address mapping example when a /96 is used:
+----------------------+--------------+-----------------------------+
| mPrefix64 | IPv4 address | IPv4-Embedded IPv6 address |
+----------------------+--------------+-----------------------------+
| ffxx:abc::/96 | 230.1.2.3 | ffxx:abc::230.1.2.3 |
+----------------------+--------------+-----------------------------+
Source address mapping example when a /96 is used:
+----------------------+--------------+-----------------------------+
| uPrefix64 | IPv4 address | IPv4-Embedded IPv6 address |
+----------------------+--------------+-----------------------------+
| 2001:db8::/96 | 192.1.2.3 | 2001:db8::192.1.2.3 |
+----------------------+--------------+-----------------------------+
6. Multicast B4 (mB4)
6.1. IGMP-MLD Interworking function
IGMP-MLD Interworking function combines the IGMP/MLD Proxying
function specified in [RFC4605] and the IGMP/MLD adaptation function
which is meant to reflect the contents of IGMP messages into MLD
messages.
Then mB4 performs the router portion of the IGMP protocol on each
downstream interface and performs the host portion of the MLD
protocol on the upstream interface (Figure 2).
The output of the operation is a set of membership information which
is maintained separately on each downstream interface (e.g., Wifi and
Wired Ethernet). In addition, the membership information on each
downstream interface is merged into the membership database on which
the IPv4 multicast packets are forwarded by mB4.
Wang, et al. Expires December 15, 2011 [Page 11]
Internet-Draft DS-Lite Multicast June 2011
+----------+ IGMP +-------+ MLD +---------+
| IPv4 |---------| CPE |---------| MLD |
| Receiver | | mB4 | | Querier |
+----------+ +-------+ +---------+
Figure 2: IGMP-MLD Interworking
When an IGMP Report message is received from a receiver to subscribe
to a given multicast group G (e.g., 230.1.2.3) (and optionally
associated to a source 192.1.2.3 if SSM mode is used), the mB4 MUST
send an MLD Report message to subscribe to the corresponding IPv6
group identified by an IPv4-embedded IPv6 multicast address using a
pre-configured prefix and algorithm (e.g., ffxx:abc::230.1.2.3 (and
optionally source 2001:db8::192.1.2.3 if SSM mode is used)). The MLD
Report message is sent through the upstream interface natively (i.e.,
without any encapsulation).
6.2. De-capsulation and Forwarding
When the mB4 receives an IPv6 multicast packet, it checks whether the
group address is in the range of mPrefix64 and the source address is
in the range of uPrefix64. If it is true, the mB4 MUST de-capsulate
the IPv4-in-IPv6 packets to extract the original IPv4 multicast
packets.
Then the IPv4 multicast packet will be forwarded to downstream
receivers based on information maintained by the mB4 in the
membership database. If no route is found, the packet is silently
dropped.
6.3. Fragmentation
Encapsulating IPv4 over IPv6 from mAFTR to mB4 for data forwarding
reduces the effective MTU size by the size of an IPv6 header
(assuming [RFC2473] encapsulation). To avoid fragmentation, a
service provider may increase the MTU size by 40 bytes on the IPv6
network or mAFTR and mB4 may use IPv6 Path MTU discovery.
6.4. Host with mB4 function embedded
The mB4 function can be embedded in the CE or in a dual-stack host
behind the CP router (e.g., STB). If mB4 is embedded in the STB, the
IGMP-MLD interworking function is not needed. The STB should
formulate the MLD message correspondingly based on given IPv4 group
address to be joint using mPrefix64 (and uPrefix64 for IPv4-embedded
source if SSM is deployed), and de-encapsulate the downstream
multicast traffics received by itself.
Wang, et al. Expires December 15, 2011 [Page 12]
Internet-Draft DS-Lite Multicast June 2011
7. Multicast AFTR (mAFTR)
7.1. Routing Considerations
Except the need for the mAFTR to belong to IPv4 multicast
distribution trees and to be on the reverse path towards the source
when performing RPF checks on PIMv6 routers, no further routing
constraint is to be taken into account.
Having the mAFTR in the reverse path ensures PIM Join sent to the
source (e.g., SSM mode or SPT mode in ASM) will be intercepted by the
mAFTR.
7.2. Processing PIM/MLD Join Messages
Upon receipt of the PIM/MLD Join for an IPv6 group (e.g., ffxx:abc::
230.1.2.3), the mAFTR checks the corresponding entry in the IPv6
multicast routing table and adds the IPv6 interface through which the
Join message has been received into the Out-Interface-List of that
entry. If the entry does not exist, a new one will be created, as
per typical PIM machinery [RFC4601]. The mAFTR should check whether
the IPv6 group address belongs to the mPrefix64 (e.g., ffxx:
abc::/96). If so, the mAFTR will need to extract the IPv4 group
address (e.g., 230.1.2.3) from the IPv4-embedded IPv6 address (e.g.,
according to [I-D.boucadair-behave-64-multicast-address-format]) and
check the corresponding entry in the IPv4 multicast routing table
then add the tunnel interface into the Out-Interface-List of that
entry. If the entry does not exist, a new entry should be created
and a PIM join message for that IPv4 group will be sent towards the
RP or source connected to the IPv4 network.
When SSM is deployed, the mAFTR would in addition check if the source
(e.g., 2001:db8::192.1.2.3) described in the PIMv6 Join message
belongs to uPrefix64 (e.g., 2001:db8::/96). If so, it can then send
a PIM (S, G) Join message directly towards the IPv4 source (e.g.,
192.1.2.3).
The initialization of the tunnel interface (used for encapsulation
purposes) on the mAFTR is out of the scope of this document.
7.3. Reliability
For robustness, reliability and load distribution purposes, several
nodes in the network can embed the mAFTR function. In such case, the
same IPv6 prefixes (i.e., mPrefix64 and uPrefix64) and algorithm to
build IPv4-embedded IPv6 addresses MUST be configured on those nodes.
Wang, et al. Expires December 15, 2011 [Page 13]
Internet-Draft DS-Lite Multicast June 2011
7.4. ASM Mode: Building Shared Trees
7.4.1. IPv4 Side
For a given Rendezvous Point (RP) used in the IPv4 realm, there is no
new requirement. Like any other IPv4 PIM router, the RP of each IPv4
multicast groups is configured to the mAFTR or discovered using some
appropriate means. Moreover, PIM-SM registration procedure [RFC4601]
in the IPv4 realm is not impacted.
Shared IPv4 multicast trees are built using the procedure defined in
[RFC4601] for instance.
7.4.2. IPv6 Side
In the IPv6 side, the RP of IPv4-embedded IPv6 multicast groups is
configured to all IPv6 PIM routers or discovered using appropriate
means. For the sake of simplicity, it is RECOMMENDED to configure an
mAFTR as the RP for IPv4-embedded IPv6 multicast groups.
[Note 1: If some other IPv6 multicast router wants to become the
RP of the IPv4-embedded IPv6 multicast groups, it may require an
mAFTR to emulate the PIM Source Register procedure on behalf of
IPv4-embedded IPv6 sources with the RP. The PIM Source Register
procedure in the IPv4 domain is not altered.]
[Note 2: How the mAFTR is aware about the sources? This can be
considered as deployment-specific:
(i) By configuration: mAFTR can be configured to join a set of
IPv4 multicast groups and to initiate a registration procedure
on behalf of a set of sources to the RP in the v6 domain;
(ii) Dynamic: this assumes that mAFTR is configured to join a
set of IPv4 multicast groups. The source address of received
flows will be used as a trigger to initiate the registration
procedure to the RP in the IPv6 domain. There is a special
case where mAFTR is the RP of the IPv4 group in the IPv4
domain: The registration procedure should then be relayed to
the RP in the IPv6 domain.
]
Shared IPv6 multicast trees are built using the procedure defined in
[RFC4601] for instance. Switching from a shared tree to source-based
tree can be accommodated since the mAFTR is in the path to join the
source.
Wang, et al. Expires December 15, 2011 [Page 14]
Internet-Draft DS-Lite Multicast June 2011
The mAFTR will graft to the IPv4 shared tree either because it has
been configured with the list of IPv4 multicast groups that will be
subscribed by the DS-Lite serviced receivers downstream or upon
receipt of a PIMv6 Join message.
An example of the exchange of PIM messages is illustrated in
Figure 3.
------------
/ \
| IPv4 network |
\ /
------------
: | ^
IPv4 Multicast : | : PIMv4 Join
v | :
+-------------+
| mAFTR |
+-------------+
|:| | ^
IPv6 Multicast |:| | : (PIMv6 Join, PIMv6 Routers in between)
(IPv4 embedded) |.| ... .
------------
/ \
| IPv6 network |
\ /
------------
|:| | : MLD Report
|v| | :
+-----------+
| mB4 |
+-----------+
: | ^
IPv4 Multicast : | : IGMP Report
v | :
+-----------+
| IPv4 |
| Receiver |
+-----------+
Figure 3: Procedure Overview
7.5. TTL/Scope
The Scope field of IPv4-in-IPv6 multicast addresses can be valued to
"E" (Global scope) or to "8" (Organization-local scope). This is
left to service providers taste.
Wang, et al. Expires December 15, 2011 [Page 15]
Internet-Draft DS-Lite Multicast June 2011
7.6. Encapsulation and forwarding
When receiving an IPv4 multicast packet, a lookup of the IPv4
multicast routing table is performed by the PIMv4 router that embeds
the mAFTR capability. If an interface used for IPv4-in-IPv6
encapsulation is found in the Out-Interface-List of the matching
entry, the encapsulation operation is triggered. The mAFTR
encapsulates in a stateless fashion the IPv4 multicast packet into an
IPv6 multicast datagram. It MUST use the pre-provisioned mPrefix64/
uPrefix64 together with an algorithm for building the IPv4-embedded
IPv6 multicast address that identifies the multicast group, as well
as the IPv6 source address that represents the IPv4 source in the
IPv6 network.
As an illustration, if a packet is received from source 192.1.2.3 and
forwarded to group 230.1.2.3, the mAFTR encapsulates it into an IPv6
multicast packet using ffxx:abc::230.1.2.3 as the destination IPv6
address and 2001:db8::192.1.2.3 as the multicast source address.
Then a lookup of the IPv6 multicast routing table is performed by the
PIMv6 router that embeds the mAFTR capability, based on the IPv4-
embedded IPv6 address. If a matching entry is found and there exist
IPv6 interfaces in the Out-Interface-List, the IPv6 multicast packet
will be sent out through these interfaces and forwarded down the
multicast distribution tree towards the mB4 devices.
8. Optimization in L2 Access Networks
The approach specified in this document is compatible with a Layer-2
infrastructure which may be involved for deterministic multicast
replication.
The IPv4-in-IPv6 encapsulated multicast flows destined to IPv4-
embedded IPv6 group addresses are treated as any IPv6 multicast flow,
and can be replicated across Multicast VLANs. Additionally,
mechanisms such as MLD Snooping, MLD Proxying, etc., can be
introduced into the distributed Access Network Nodes (e.g.,
Aggregation Switches, xPON devices) which then could behave as MLD
Querier and replicate multicast flows as appropriate. Thus, the
multicast replication point is moved downward closer to the
receivers, so that bandwidth consumption is optimized.
9. Security Considerations
This document does not introduce any new security concern in addition
to what is discussed in Section 5 of [RFC6052], Section 10 of
Wang, et al. Expires December 15, 2011 [Page 16]
Internet-Draft DS-Lite Multicast June 2011
[RFC3810] and Section 6 of [RFC4601].
9.1. Firewall Configuration
The CPE should be configured to accept incoming MLD messages and
traffic forwarded to multicast groups subscribed by receivers located
in the customer premises.
10. Acknowledgements
The authors would like to thank Dan Wing for his guidance in the
early discussions which initiated this work. We also appreciate Peng
Sun, Jie Hu, Qiong Sun, Lizhong Jin, Alain Durand, Dean Cheng, and
Behcet Sarikaya for their valuable comments.
11. IANA Considerations
This document includes no request to IANA.
12. References
12.1. Normative 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.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work
in progress), May 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
Wang, et al. Expires December 15, 2011 [Page 17]
Internet-Draft DS-Lite Multicast June 2011
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
12.2. Informative References
[I-D.ietf-behave-nat64-learn-analysis]
Korhonen, J. and T. Savolainen, "Analysis of solution
proposals for hosts to learn NAT64 prefix",
draft-ietf-behave-nat64-learn-analysis-00 (work in
progress), May 2011.
[I-D.ietf-mboned-multiaaa-framework]
Satou, H., Ohta, H., Hayashi, T., Jacquenet, C., and H.
He, "AAA and Admission Control Framework for
Multicasting", draft-ietf-mboned-multiaaa-framework-12
(work in progress), August 2010.
[I-D.jaclee-behave-v4v6-mcast-ps]
Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T.
ZOU), "IPv4-IPv6 Multicast: Problem Statement and Use
Cases", draft-jaclee-behave-v4v6-mcast-ps-02 (work in
progress), June 2011.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
Wang, et al. Expires December 15, 2011 [Page 18]
Internet-Draft DS-Lite Multicast June 2011
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006.
[RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific
Protocol Independent Multicast in 232/8", BCP 120,
RFC 4608, August 2006.
Appendix A. Translation vs. Encapsulation
In order to deliver IPv4 multicast flows to DS-Lite serviced
receivers, two options can be considered:(1) Translation;
(2)Encapsulation.
It should be noted that some contract agreement may prevent the
contents from being altered. In this case, the employment of the
translation approach may raise issues e.g., Integrity Check failures.
A.1. Translation
To delivery IPv4 multicasst contents to an IPv4 receiver: Introduce
translation functions at the boundaries of IPv6 network. The IPv4-
translated multicast streams are distributed within the IPv6 network
natively until the customer premises device where the IPv4-translated
IPv6 streams are translated back and passed to IPv4 receivers.
Multicast Distribution Tree is established by normal machinery of
control protocols (e.g. IGMP, MLD, PIMv4/v6) and the Interworking
functions (e.g. IGMP-MLD, PIMv6-PIMv4), refer to Section 6 and
Section 7. The translation function is stateless owing to the use of
IPv4-Embedded IPv6 address
[I-D.boucadair-behave-64-multicast-address-format] and [RFC6052].
A.2. Encapsulation
To deliver IPv4 multicast contents to an IPv4 receiver: Introduce two
elements at the boundaries of IPv6 network, mAFTR and mB4. Multicast
Distribution Tree is established by normal machinery of control
protocols (e.g. IGMP, MLD, PIMv4/v6) and the Interworking functions
(e.g. IGMP-MLD, PIMv6-PIMv4), refer to Section 6 and Section 7.
Multicast streams are forwarded to a receiver by using an IPv4-in-
IPv6 encapsulation scheme. The encapsulation/de-capsulation function
is stateless owing to the use of IPv4-Embedded IPv6 address
[I-D.boucadair-behave-64-multicast-address-format] and [RFC6052].
Wang, et al. Expires December 15, 2011 [Page 19]
Internet-Draft DS-Lite Multicast June 2011
Authors' Addresses
Qian Wang
China Telecom
No.118, Xizhimennei
Beijing, 100035
China
Phone: +86 10 5855 2177
Email: wangqian@ctbri.com.cn
Jacni Qin
ZTE
Shanghai,
China
Phone: +86 1391 8619 913
Email: jacniq@gmail.com
Mohamed Boucadair
France Telecom
Rennes, 35000
France
Phone:
Email: mohamed.boucadair@orange-ftgroup.com
Christian Jacquenet
France Telecom
Rennes, 35000
France
Phone:
Email: christian.jacquenet@orange-ftgroup.com
Yiu L. Lee
Comcast
U.S.A.
Phone:
Email: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Wang, et al. Expires December 15, 2011 [Page 20]