Internet Engineering Task Force Q. Wang
Internet-Draft China Telecom
Intended status: Standards Track J. Qin
Expires: April 28, 2011 P. Sun
ZTE
M. Boucadair
C. Jacquenet
France Telecom
October 25, 2010
Multicast Extensions to DS-Lite in Broadband Deployments
draft-qin-softwire-dslite-multicast-01
Abstract
The DS-Lite technique enables service providers to deliver IPv4
unicast services following IPv4 address exhaustion by combining two
mechanisms: NAT and IPv4-in-IPv6 encapsulation. This document
describes extensions to DS-Lite to support IPv4 multicast delivery.
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 April 28, 2011.
Copyright Notice
Copyright (c) 2010 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
Wang, et al. Expires April 28, 2011 [Page 1]
Internet-Draft DS-Lite Multicast October 2010
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Wang, et al. Expires April 28, 2011 [Page 2]
Internet-Draft DS-Lite Multicast October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Context and Overview . . . . . . . . . . . . . . . . . . . . . 5
3.1. Overview: IPTV-centric View . . . . . . . . . . . . . . . 5
3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Mitigation Alternatives . . . . . . . . . . . . . . . . . 7
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Location of the Multicast AFTR . . . . . . . . . . . . . . 8
4.3. Multicast AFTR vs. Unicast AFTR . . . . . . . . . . . . . 10
4.4. IPv4-Embedded IPv6 Address Prefixes . . . . . . . . . . . 10
4.5. Multicast Distribution Tree . . . . . . . . . . . . . . . 11
4.6. Multicast Forwarding . . . . . . . . . . . . . . . . . . . 11
5. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 12
5.2. Text Representation . . . . . . . . . . . . . . . . . . . 12
6. Multicast B4 . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. IGMP-MLD Interworking . . . . . . . . . . . . . . . . . . 13
6.2. Firewalling . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Address Mapping . . . . . . . . . . . . . . . . . . . . . 13
6.4. De-capsulation and Forwarding . . . . . . . . . . . . . . 13
6.5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 14
7. Multicast AFTR . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Processing PIM/MLD Join Messages . . . . . . . . . . . . . 14
7.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 14
7.3. Routing Considerations . . . . . . . . . . . . . . . . . . 14
7.4. TTL/Scope . . . . . . . . . . . . . . . . . . . . . . . . 15
7.5. Encapsulation and forwarding . . . . . . . . . . . . . . . 15
7.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 15
8. Multicast Traffic Optimization . . . . . . . . . . . . . . . . 15
8.1. Co-existence with native IPv6 multicast . . . . . . . . . 15
8.2. Optimization . . . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Translation vs. Encapsulation . . . . . . . . . . . . 18
A.1. Translation . . . . . . . . . . . . . . . . . . . . . . . 18
A.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Wang, et al. Expires April 28, 2011 [Page 3]
Internet-Draft DS-Lite Multicast October 2010
1. Introduction
DS-Lite [I-D.ietf-softiwre-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 DS-Lite is used for IPv4 multicast, AFTR
devices must work as the multicast replication point where all the
IGMP reports are processed. In particular, DS-Lite designs where the
AFTR capability is centralized is likely to 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.
In practice, a similar issue exists in native IPv4 networks for
multicast. To deal with it, mechanisms like IGMP snooping, IGMP
proxying, multicast VLAN etc., are introduced into distributed Access
Network Nodes (e.g., Aggregation Switches, xPON devices) which then
behave as IGMP Querier devices and replicate multicast traffic. In
this way, the multicast replication point can be moved downward
closer to the subscribers, so the bandwidth consumption and the great
pressure of the layer 3 gateway is reduced substantially.
While in DS-Lite, these mechanisms for multicast traffic optimization
do not work on Access Network Nodes due to the current tunnel
encapsulation.
In this document, we discuss the extension of the DS-Lite model to
adapt it to the delivery of IPv4 multicast-based service offerings.
The key characteristic of this proposal is exactly the same as DS-
Lite: communications stay within their address family and no
translation is enforced in the delivery path. Moreover, unlike
unicast DS-Lite, the Multicast AFTR is stateless.
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. Refer to [I-D.ietf-behave-address-
format] for more details.
Wang, et al. Expires April 28, 2011 [Page 4]
Internet-Draft DS-Lite Multicast October 2010
o Multicast AFTR: is a functional entity which is part of both the
IPv4 and IPv6 multicast distribution trees and which replicates
IPv4 multicast streams into IPv4-in-IPv6 streams in the relevant
branches of the IPv6 multicast distribution tree.
o Multicast B4: is a functional entity embedded in a CPE or a host,
which is able to enforce an IGMP-MLD interworking function
together with a de-capsulation function of received multicast
IPv4-in-IPv6 packets.
3. Context and Overview
3.1. Overview: IPTV-centric View
The current design of DS-Lite covers unicast services exclusively, so
for advanced services (e.g., IPTV), service providers may have to
adopt various strategies for their delivery.
o VoD (Video on Demand) or catch-up TV channels streams can be
delivered via a DS-Lite AFTR since it is based on unicast.
Enhancements to applications is encouraged to promote the usage of
IPv6 whenever possible and therefore avoid the crossing of AFTR
devices (e.g., propose an alternate IPv6 address in SDP
[I-D.boucadair-mmusic-altc]).
o Live TV broadcasting, In current operational deployments, is
delivered through the IP multicast forwarding scheme by many
service. Numerous players intervene in the delivery of this
service: (1) Content providers: the content can be provided by the
same provider as the one providing the connectivity service or by
distinct providers (e.g., external paid channels); (2) Network
provider: is responsible for carrying multicast flows from head-
ends to receivers [I-D.ietf-mboned-multiaaa-framework].
For the sake of network simplification, the recommended solution for
a service provider deploying DS-Lite technique is to upgrade its
multicast-based services to be IPv6-enabled. In particular, the
multicast content should be formatted and accessed in IPv6. Still,
part of the IPTV contents that are currently available are likely to
remain IPv4-formatted. And customers with legacy receivers (e.g.,
IPv4-only Set Top Boxes (STB)) MUST continue to access the service.
his means that the traffic should be accessed over native IPv4.
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. The solution
Wang, et al. Expires April 28, 2011 [Page 5]
Internet-Draft DS-Lite Multicast October 2010
proposed in this document only applies for contents that are allowed
to be encapsulated by a network provider for transport purposes.
The following cases should be covered to the forwarding of IPv4
multicast traffic in DS-Lite environments:
(1) IPv4-only multicast receiver; (2) Dual-Stack multicast
receiver.
As for the content, two scenarios are considered as valid ones:
(1) IPv4-only content; (2) Dual-Stack content (i.e., content
formatted and reachable in both IPv4 and IPv6) (of course,
incentives to inject the same content in both IPv4 and IPv6 may be
questionable).
The following cases are out of scope of this document:
(1) IPv6-only receiver; (2) IPv6-only content.
Figure 1 provides an overview of the main elements to be considered
for the delivery of multicast content in a DS-Lite context.
In reference to Figure 1:
1. The legacy IPv4 receiver can access content reachable over IPv4.
No issue is raised by this scenario. Multicast flows will be
delivered using native IPv4 transfer mode. No AFTR is involved
in the path;
2. An IPv4-only receiver behind a DS-Lite CGN: Additional functions
are required to deliver the content to the receiver;
3. A Dual-Stack receiver should access a IPv6-reachable content
using IPv6. No extra function is required to implement this
scenario;
4. A Dual-Stack receiver accessing IPv4-only content: This scenario
is similar to the IPv4-only receiver accessing the IPv4-only
content (2nd bullet). Additional functions are required.
Wang, et al. Expires April 28, 2011 [Page 6]
Internet-Draft DS-Lite Multicast October 2010
^ +----------+ +----------+
Content | |Dual Stack| | IPv4 |
Provider | | Content | | Content |
| +----------+ +----------+
v
=================
^
Network | +----------+ +----------+
Provider | | Unicast | | Multicast|
| | AFTR | | AFTR |
| +----------+ +----------+
v
=================
^
| +----------+ +----------+
Customer | |Dual Stack| |Dual Stack|
| | CPE | | CPE |
| +----------+ +----------+
|
| +----------+ +----------+
| |Dual Stack| | IPv4-only|
| | Receiver | | Receiver |
v +----------+ +----------+
Figure 1: Reference Environment
3.2. Scope
This document focuses only on issues raised by a DS-Lite networking
environment; in particular: subscription to a multicast group and the
delivery of content to receivers.
Pure IPv6-only devices, receivers or senders (i.e., devices that do
not include an IPv4 stack) are out of the scope of this document.
This document does not cover the case where an IPv4 host behind a DS-
Lite AFTR can be the source of multicast traffic.
3.3. Mitigation Alternatives
In order to prevent complications raised when multicast flows are to
cross a unicast DS-Lite AFTR, Service Providers may opt for a
separated addressing scheme for the delivery of multicast-based
service offerings. Service-specific IPv4 addresses are assigned to
STBs to access a multicast-based service offering. In such case, no
extra standardisation effort is required. The use of a private IPv4
addressing scheme to deliver multicast traffic is likely to yield
additional management complexity (e.g., because of potentially
Wang, et al. Expires April 28, 2011 [Page 7]
Internet-Draft DS-Lite Multicast October 2010
overlapping addressing schemes), which is out of the scope of this
document.
For Service Providers who use a service-agnostic IP addressing
scheme, dedicated solutions are to be specified to be able to deliver
multicast content to DS-Lite serviced customers. This is the purpose
of this document.
4. Solution Overview
In the original DS-Lite specification, IPv4-in-IPv6 tunnel is used to
carry the bidirectional IPv4 unicast traffic between B4 and AFTR.
Within the context of this document, an IPv4-converted IPv6 multicast
address is used as the destination of the encapsulated unidirectional
IPv4-in-IPv6 multicast traffic from the Multicast AFTR to the
subscribed Multicast B4. The IPv4 address of the multicast source
will also be mapped into an IPv6 address by the Multicast AFTR when
forwarding the encapsulated IPv4-in-IPv6 multicast flows in the IPv6
realm.
4.1. Rationale
The solution proposed in this document defines two functional
elements:
o Multicast AFTR: responsible for replicating IPv4 multicast flows
in IPv6 owing to a stateless IPv4-in-IPv6 encapsulation. The
multicast AFTR does not undertake any NAT operation. Unlike
unicast DS-Lite, a B4 does not need to discover a Multicast AFTR.
o Multicast B4: is a functional entity embedded in a CPE responsible
for the de-capsulation of the received IPv4-in-IPv6 packets and
forwarding them to the appropriate IPv4 receivers.
In order for this solution to work, B4 MUST be provisioned with an
IPv6 prefix and an algorithm for building IPv4-Embedded IPv6
addresses [I-D.ietf-behave-address-format].
Multicast AFTR and B4 MUST use the same IPv6 prefix and algorithm for
building IPv4-Embedded IPv6 addresses (for both source address and
group address).
4.2. Location of the Multicast AFTR
The Multicast AFTR can be located in various places in the network.
If the Multicast AFTR is embedded in the first IP router reachable
Wang, et al. Expires April 28, 2011 [Page 8]
Internet-Draft DS-Lite Multicast October 2010
from a B4, the MLD Report message is processed by the AFTR where the
IPv4-embedded (encapsulated) IPv6 multicast is forwarded based on the
MLD membership information database. Please see Figure 2 belowGBPo
+------------+ +-----------+
-------| v4 Router | | v6 Router |-------
+------------+ +-----------+
\ / |
\ / |
\ / |
+---------------+ |
| First-Hop | |
| Router with | |
| AFTR | |
+---------------+ |
| | | Native
| | | IPv6 Multicast
IPv4-embedded | | |
IPv6 Multicast | +----------+ |
| | B4 | |
| +----------+ |
| / \ |
V / \ V
+------+ +------+
| v4 | | v6 |
| Host | | Host |
+------+ +------+
Figure 2: Multicast AFTR embedded in the first IP router
If the Multicast AFTR is not embedded in the router which receives
MLD Report message from a multicast B4, multicast routing mechanisms
are enabled to build the IPv6 multicast distribution tree for
delivering the subscribed traffic to a receiver. We assume that the
PIM-SM is used in this case. Please see Figure 3 belowGBPo
Wang, et al. Expires April 28, 2011 [Page 9]
Internet-Draft DS-Lite Multicast October 2010
+----------+ +-----------+
-------|Multciast | | v6 Router |-------
| AFTR | | |
+----------+ +-----------+
| \ / |
| \ / |
| \ / |
| +-----------+ |
| | First-Hop | |
| |IPv6 Router| |
| +-----------+ |
IPv4-embedded | | | Native
IPv6 Multicast | | | IPv6 Multicast
| | |
| +----------+ |
| | B4 | |
| +----------+ |
| / \ |
V / \ V
+------+ +------+
| v4 | | v6 |
| Host | | Host |
+------+ +------+
Figure 3: Multicast AFTR far from the multicast B4
4.3. Multicast AFTR vs. Unicast AFTR
Unlike an unicast AFTR, the Multicast AFTR does not perform any NAT
when delivering multicast traffic.
A Multicast AFTR is responsible for encapsulating in a stateless
manner the IPv4 multicast content into IPv6 identified by a specific
group address. Further elaboration is provided in the following sub-
sections about the behaviour of the Multicast AFTR and Multicast B4.
Unicast AFTR and Multicast AFTR are two functional elements that can
be co-located in the same device or be separated.
4.4. IPv4-Embedded IPv6 Address Prefixes
One special IPv6 multicast prefix (called mPrefix64) is needed for
constructing IPv6 multicast addresses, with IPv4 multicast address
embedded. Meanwhile, the address of the IPv4 multicast source (or
the RP address in a shared tree environment) should be mapped to IPv6
addresses, so an IPv6 unicast prefix (called uPrefix64) is needed for
constructing IPv6 unicast addresses with IPv4 unicast address
embedded (the multicast source address or an RP's address).
Wang, et al. Expires April 28, 2011 [Page 10]
Internet-Draft DS-Lite Multicast October 2010
The same multicast prefix must be used by B4 and Multicast AFTR.
4.5. Multicast Distribution Tree
Suppose that an IPv4 receiver has acquired the address of IPv4
multicast group which it is interested in, then the receiver will
send an IGMP Report to the Multicast B4 joining that group. After
receiving the IGMP Report message, the B4 performs the IGMP-MLD
Interworking function in addition to a proxy function as described in
[RFC4605]. B4 converts the IGMP message into a MLD Report message
which will then be forwarded to the MLD Querier located upstream in
the network. In the MLD message, the IPv6 address of the multicast
group to be joined is constructed using the preconfigured mPrefix64
and an algorithm, with IPv4 multicast address embedded.
If source-specific multicast is deployed, the IPv6 address of the
multicast source can be constructed in the same way (using uPrefix64,
with IPv4 multicast source embedded).
Receiving this MLD membership report on the first IP router will
trigger the PIM Join message up to the RP or the multicast source.
Make sure the calculated RPF interface for sending PIM Join be on the
path up to a Multicast AFTR. Please refer to the Figure 3 above. Or
the Multicast AFTR may be embedded in the first IP router where the
MLD membership report is processed. Please refer to the Figure 2
above.
When the AFTR receives a PIM or MLD Join for an IPv6 group in the
range of mPrefix64 from the IPv6 network, it will need to join the
corresponding IPv4 multicast group in the IPv4 network. It MUST
behave as an IPv4 PIM router and send an IPv4 PIM join. The IPv4
group address can be obtained from the IPv4-Embedded IPv6 address
according to a preconfigured algorithm (e.g., the last 32 bits of the
IPv4-embedded IPv6 group address).
For Source-Specific Multicast the AFTR would in addition check if the
source in the Join message belongs to uPrefix64. If so, it can then
send a PIM (S, G) Join message directly towards the IPv4 source using
the last 32 bits as the IPv4 source.
Till now, the multicast distribution tree is established.
4.6. Multicast Forwarding
Whenever an IPv4 multicast packet is received on a Multicast AFTR, 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
Wang, et al. Expires April 28, 2011 [Page 11]
Internet-Draft DS-Lite Multicast October 2010
new IPv6 multicast packet will then be sent through the out interface
of the matching entry in the multicast routing table and forwarded
down the IPv6 multicast distribution tree towards the B4.
When receiving the IPv6 multicast packet sent to this multicast group
, B4 should de-capsulate the IPv4-in-IPv6 packet and forward the
original IPv4 multicast packet to the IPv4 receiver.
5. Address Mapping
5.1. Prefix Assignment
In order to map the addresses of IPv4 multicast traffic to IPv6
multicast addresses, an IPv6 multicast prefix (mPrefix64) and an IPv6
unicast prefix (uPrefix64) are provided to Multicast AFTR and B4
elements.
To simplify the implementation, it is recommended to assign prefixes
with the length of 96 (could be prefix + suffix set to 0), the
address format being left to the responsibility of the service
provider [I-D.ietf-behave-address-format].
These two prefixes can be configured onto B4 through some control
protocol, such as DHCPv6 or some out-of-band mechanism. Two
candidates DHCPv6 options are identified in [I-D.korhonen-behave-
nat64-learn-analysis].
5.2. Text Representation
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 |
+----------------------+--------------+-----------------------------+
Wang, et al. Expires April 28, 2011 [Page 12]
Internet-Draft DS-Lite Multicast October 2010
6. Multicast B4
6.1. IGMP-MLD Interworking
We combine the IGMP/MLD proxying function specified in [RFC4605] and
the IGMP-MLD Interworking function. This interworking function is
not complex since MLD is a translation of IGMP for IPv6 semantics.
Then B4 will perform the router portion of the IGMP protocol on each
downstream interface and perform the host portion of the MLD protocol
on the upstream interface. Meanwhile, the IGMP-MLD Interworking is
performed in between by the B4.
The output of the operation is a set of membership information which
is maintained separately on each downstream interface. In addition,
the membership information on each downstream interface is merged
into the membership database on which the IPv4 multicast packets are
forwarded by B4.
+------+ IGMP +-------+ MLD +--------+
| IPv4 |--------| CPE |---------| Access |
| Host | | B4 | | Router |
+------+ +-------+ +--------+
Figure 4: IGMP-MPD Interworking
Outbound multicast control messages are sent in native IPv6 without
any encapsulation.
6.2. Firewalling
This document assumes that the CPE is configured to accept incoming
MLD messages and traffic forwarded to multicast groups subscribed by
receivers located in the customer premises. Considerations on
security policy configuration will be elaborated in the next version.
6.3. Address Mapping
When an IGMP Report message is received from a receivers to subscribe
to multicast group G (e.g., 230.1.2.3) (and optionally a source
192.1.2.3 if SSM mode is used), B4 MUST send an MLD message to
subscribe to ffxx:abc::230.1.2.3 (and optionally source 2001:db8::
192.1.2.3 if SSM mode is used.).
6.4. De-capsulation and Forwarding
When B4 receives an IPv6 multicast packet, it checks whether the
group address is in the range of mPrefix64. If so, B4 should de-
Wang, et al. Expires April 28, 2011 [Page 13]
Internet-Draft DS-Lite Multicast October 2010
capsulate the IPv4-in-IPv6 packets to extract the original IPv4
multicast packet. To simplify the implementation, the B4 may join
the corresponding IPv6 multicast group to trigger the de-capsulation.
Then the IPv4 multicast packet will be forwarded to downstream
receivers based on information maintained by the B4 in the membership
database.
6.5. Fragmentation
Tunnelling IPv4 over IPv6 between Multicast AFTR and Multicast B4
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 multicast AFTR and B4 may use IPv6 Path MTU discovery.
7. Multicast AFTR
7.1. Processing PIM/MLD Join Messages
After receiving the PIM Join for an IPv6 group, a Multicast AFTR
should get the (*, G) entry in the IPv6 multicast routing table and
add the IPv6 interface receiving the Join message into the Out-
Interface-List of that entry. If the entry does not exist, a new one
should be created, as per typical PIM machinery [RFC4601]. The AFTR
should check whether the IPv6 group address is inside the mPrefix64,
if so, the AFTR will need to extract the IPv4 group address from
IPv4-Embedded IPv6 address and get the corresponding (*, G) 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 one should be created and PIM join for the IPv4 group will be
sent towards the source connected to the IPv4 network.
The initialization of the Tunnel interface on the Multicast AFTR is
out of the scope of this document.
7.2. Reliability
For robustness, reliability and load distribution purposes, several
nodes in the network can embed a Multicast AFTR function. In such
case, the same IPv6 prefix and algorithm to build IPv4-Embedded IPv6
addresses MUST be configured on those nodes.
7.3. Routing Considerations
Except the need for the multicast AFTR to belong to IPv4 multicast
distribution trees and to be on the reverse path towards the source
Wang, et al. Expires April 28, 2011 [Page 14]
Internet-Draft DS-Lite Multicast October 2010
when performing RPF checks, no further routing constraint is to be
taken into account.
7.4. TTL/Scope
When Multicast AFTR is deployed for the delivery of multicast-based
services to residential customers for instance, the tweaking of the
Scope field in the corresponding replicated IPv4-in-IPv6 address
SHOULD be global.
7.5. Encapsulation and forwarding
When receiving an IPv4 multicast packet, a lookup of IPv4 multicast
routing table is performed. If the Tunnel interface is found in the
Out-Interface-List of the matching entry, the encapsulation operation
is triggered. The multicast AFTR encapsulates in a stateless fashion
the IPv4 multicast packet into IPv6. It should use the pre-
provisioned mPrefix64 together with an algorithm for building IPv4-
Embedded IPv6 address.
As an illustration, if a packet is received from 192.1.2.3 and
destined to 230.1.2.3, the Multicast AFTR will encapsulate it in an
IPv6 packets using ffxx:abc::230.1.2.3 as a destination IPv6 address
and 2001:db8::192.1.2.3 as the multicast source address.
Then a lookup of IPv6 multicast routing table is performed 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
packet will be sent out through these interfaces and forwarded down
the multicast distribution tree towards the Multicast B4s.
7.6. Fragmentation
Tunnelling IPv4 over IPv6 between Multicast AFTR and Multicast B4
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 multicast AFTR and B4 may use IPv6 Path MTU discovery.
8. Multicast Traffic Optimization
8.1. Co-existence with native IPv6 multicast
To be added ...
Wang, et al. Expires April 28, 2011 [Page 15]
Internet-Draft DS-Lite Multicast October 2010
8.2. Optimization
To be added ...
9. Acknowledgements
The authors would like to thank Dan Wing for his guidance in the
early discussions which initiated this work. We also appreciate Jie
Hu, Qiong Sun, Lizhong Jin for their valuable input.
10. IANA Considerations
This document includes no request to IANA.
11. Security Considerations
To be added ...
12. References
12.1. Normative References
[I-D.ietf-behave-address-format]
Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-10 (work in progress),
August 2010.
[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.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-06 (work
in progress), August 2010.
[I-D.korhonen-behave-nat64-learn-analysis]
Korhonen, J. and T. Savolainen, "Analysis of solution
proposals for hosts to learn NAT64 prefix",
draft-korhonen-behave-nat64-learn-analysis-00 (work in
Wang, et al. Expires April 28, 2011 [Page 16]
Internet-Draft DS-Lite Multicast October 2010
progress), October 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[TR-101] Broadband Forum, "TR-101: Migration to Ethernet-Based DSL
Aggregation", 2006.
12.2. Informative References
[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.
[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.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
Wang, et al. Expires April 28, 2011 [Page 17]
Internet-Draft DS-Lite Multicast October 2010
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[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.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, 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:
A.1. Translation
For IPv4 content, introduce IPv4-IPv6 translation capabilities in the
network. Multicast streams will then be delivered to the receivers
using IPv6 until the CPE. A second level of NAT can then be enforced
if the receiver is IPv4-only.
o Analysis: This solution may require two translation levels, can
impact the overall performance of the CPE, may alter the perceived
quality of experience, etc. This solution may be the source of
service disruption (especially for live TV broadcasting). This is
not desirable.
For IPv6 content, all streams are delivered to the DS-Lite CPE using
IPv6; an IPv4-IPv6 translator can be enabled in the CPE to forward
the streams to an IPv4-only receiver.
o Analysis: The IPv4-IPv6 translation function may impact the
performance of the CPE.
A.2. Encapsulation
To access IPv4 content from an IPv4-only or dual-stack receiver:
introduce a new function called Multicast DS-Lite AFTR in the
network. Multicast streams are forwarded to a receiver by using an
IPv4-in-IPv6 encapsulation scheme. The encapsulation/de- capsulation
Wang, et al. Expires April 28, 2011 [Page 18]
Internet-Draft DS-Lite Multicast October 2010
function is stateless owing to the use of IPv4-Embedded IPv6 address
[I-D.ietf-behave-address-format]. MTU and fragmentation should be
carefully taken care of to avoid service degradation.
To access IPv6 content from a dual-stack receiver: no new function is
required. Multicast IPv6 can be used.
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
Peng Sun
ZTE
Shanghai,
China
Phone: +86 21 6889 7101
Email: sun.peng@zte.com.cn
Mohamed Boucadair
France Telecom
Rennes, 35000
France
Phone:
Email: mohamed.boucadair@orange-ftgroup.com
Wang, et al. Expires April 28, 2011 [Page 19]
Internet-Draft DS-Lite Multicast October 2010
Christian Jacquenet
France Telecom
Rennes, 35000
France
Phone:
Email: christian.jacquenet@orange-ftgroup.com
Wang, et al. Expires April 28, 2011 [Page 20]