Network Working Group B. Sarikaya
Internet-Draft Huawei USA
Intended status: Standards Track March 7, 2011
Expires: September 8, 2011
Multicast Support for Dual Stack Lite and 6RD
draft-sarikaya-softwire-dslite6rdmulticast-00.txt
Abstract
This memo specifies modifications required to DS-Lite and 6RD so that
both IPv4/ IPv6 hosts can receive multicast data from IPv4/ IPv6
servers.
The DS-Lite solution is based on DS-Lite Basic Bridging BroadBand
element (B4) proxying IGMP and then tunneling IGMP messages to DS-
Lite Address Family Transition Router element (AFTR). IPv4 multicast
data received at AFTR is tunneled to B$ and then delivered to the
hosts. IPv6 multicast and MLD can be supported in a similar way.
The 6RD protocol is based on proxying MLD at the 6RD Customer Edge
and then tunneling MLD messages to 6RD Border Relays where IPv6
multicast routing is supported. Multicast data received at 6RD
Border Relay is tunneled to 6RD Customer Edge node and then delivered
to the hosts. We show that IPv4 multicast and IGMP can be supported
in a similar way.
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 September 8, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Sarikaya Expires September 8, 2011 [Page 1]
Internet-Draft Multicast Support for DS-Lite - 6RD March 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. DS-Lite Multicast Operation . . . . . . . . . . . . . . . . . 5
5.1. Tunnel Interface Considerations . . . . . . . . . . . . . 7
5.2. Supporting IPv6 Multicast in DS-Lite . . . . . . . . . . . 7
6. 6RD Multicast Operation . . . . . . . . . . . . . . . . . . . 7
6.1. Tunnel Interface Considerations . . . . . . . . . . . . . 9
6.2. Supporting IPv4 Multicast in 6RD . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative references . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Sarikaya Expires September 8, 2011 [Page 2]
Internet-Draft Multicast Support for DS-Lite - 6RD March 2011
1. Introduction
With IPv4 address depletion on the horizon, many techniques are being
standardized for IPv6 migration including DS-Lite
[I-D.ietf-softwire-dual-stack-lite] and 6RD [RFC5969]. DS-Lite
enables IPv4 hosts to communicate with external hosts using IPv6 only
network and moves the traditional NAT to the network. B4 element's
LAN side is dual stack and WAN side is IPv6 only. B4 tunnels IPv4
packets received from the LAN side to AFTR element after
encapsulating IPv4 packet in an IPv6 packet. AFTR decapsulates the
packet, does a NAT operation and then sends the packet out to IPv4
public internet.
6RD enables IPv6 hosts to communicate with external hosts using IPv4
only legacy ISP network. 6RD Customer Edge (CE) device's LAN side is
dual stack and WAN side is IPv4 only. CE tunnels IPv6 packets
received from the LAN side to 6RD Border Relays (BR) after
encapsulating IPv6 packet in an IPv4 packet. BRs have anycast IPv4
addresses and receive encapsulated packets from CEs over a virtual
interface. 6RD operation is stateless. Packets are received/ sent
independent of each other and no state needs to be maintained.
DS-Lite as defined in [I-D.ietf-softwire-dual-stack-lite] is unicast
only, it does not support multicast. In this document we specify how
multicast from home IPv4 users can be supported in DS-Lite. We also
show how IPv6 multicast can be supported for home IPv6 users in DS-
Lite.
6RD as defined in [RFC5969] and [RFC5569] is unicast only. It does
not support multicast. In this document we specify how multicast
from home IPv6 users can be supported in 6RD. We also show how IPv4
multicast can be supported for home IPv4 users. Both solutions use
IPv6 and IPv4 multicast addressing and do not require any new
multicast address prefixes such as IPv4-embedded IPv6 multicast
addresses to be allocated.
2. Terminology
This document uses the terminology defined in [RFC5969], [RFC5569],
[RFC3810] and [RFC3376].
3. Requirements
This section states requirements on DS-Lite and 6RD multicast support
protocol.
Sarikaya Expires September 8, 2011 [Page 3]
Internet-Draft Multicast Support for DS-Lite - 6RD March 2011
DS-Lite B4 MUST support IGMP Proxy as defined in [RFC4605]. DS-Lite
B4 MAY support MLD Proxy.
DS-Lite AFTR MUST support IGMP Querrier. DS-Lite AFTR MAY support
MLD Querrier.
6RD CE MUST support MLD Proxy as defined in [RFC4605]. 6RD CE MAY
support IGMP Proxy.
6RD BR MUST support MLD Querrier. 6RD CE MAY support IGMP Querrier.
Both any source multicast (ASM) and source specific multicast (SSM)
MUST be supported.
4. Architecture
In DS-Lite, there are hosts (possibly IPv4/ IPv6 dual stack) served
by B4 element. B4 is dual stack facing the hosts and IPv6 only
facing the network or WAN side. At the boundary of the network there
is AFTR. AFTR receives IPv4 packets tunneled in IPv6 from B4 and
decapsulates them and sends them out to IPv4 network.
In order to support multicast B4 implements IGMP Proxy function
[RFC4605]. IPv4 hosts send their join requests (IGMP Membership
Report messages) to B4. B4 as a proxy sends aggregated Report
messages upstream towards AFTR.
AFTR is the default multicast querier for B4. AFTR implements
multicast router function or it could be another IGMP proxy.
All the elements of DS-Lite multicast support system are shown in
Figure 1.
Dual Stack Hosts IPv4
+----+ Network
| H1 | IPv6
+----+ +-----+ only +-------+ +
+----+ | B4 | network -- | AFTR |
| H2 | ---| IGMP|--- | IGMP | IPv6
+----+ |Proxy| |Querier| Network
+----+ +-----+ +-------+
| H3 |
+----+
Sarikaya Expires September 8, 2011 [Page 4]
Internet-Draft Multicast Support for DS-Lite - 6RD March 2011
Figure 1: Architecture of DS-Lite Multicast Protocol
In 6RD, there are hosts (possibly IPv4/ IPv6 dual stack) served by
6RD Customer Edge device. CE is dual stack facing the hosts and IPv4
only facing the network or WAN side. At the boundary of the network
there is 6RD Border Relay. BR receives IPv6 packets tunneled in IPv4
from CE and decapsulates them and sends them out to IPv6 network.
In order to support multicast CE implements MLD Proxy function
[RFC4605]. IPv6 hosts send their join requests (MLD Membership
Report messages) to CE. CE as a proxy sends aggregated Report
messages upstream towards BR.
Dual Stack Hosts IPv4
+----+ Network
| H1 | IPv4
+----+ +-----+ only +-------+ +
+----+ | CE | network -- | BR |
| H2 | ---| MLD |--- | MLD | IPv6
+----+ |Proxy| |Querier| Network
+----+ +-----+ +-------+
| H3 |
+----+
Figure 2: Architecture of 6RD Multicast Protocol
BR is the default multicast querier for CE. BR implements multicast
router function or it could be another MLD proxy.
All the elements of 6RD multicast support system are shown in
Figure 2.
5. DS-Lite Multicast Operation
In this section we specify how the host can subscribe and receive
IPv4 multicast data from IPv4 content providers based on the
architecture defined in Section 4.
The hosts will send their subscription requests for IPv4 multicast
groups upstream to the default router, i.e. B4 Element. After
subscribing to the group, the host can receive multicast data from
the B4. The host implements IGMP protocol's host part.
Sarikaya Expires September 8, 2011 [Page 5]
Internet-Draft Multicast Support for DS-Lite - 6RD March 2011
B4 Element is IGMP Proxy. After receiving the first IGMP Report
message requesting subscription to an IPv4 multicast group, B4
establishes a tunnel interface with a AFTR. The tunnel is IPv6 based
but it will carry IP traffic, IGMP messages back and forth and IPv4
multicast data messages downstream. This is similar to
[I-D.ietf-multimob-pmipv6-base-solution] but the operation is much
simpler. In DS-Lite environment there is no requirement to handle
host mobility. B4 does not have to keep more than one tunnel
interfaces, a single interface is sufficient. IGMP Proxy at the B4
does not have to have more than one proxy instances, a single
instance is sufficient.
B4 is regular IGMP proxy and it keeps IGMP proxy membership database.
B4 inserts multicast forwarding state on the incoming interface, and
merges state updates into the IGMP proxy membership database. B4
updates or removes elements from the database as required. B4 will
then send an aggregated Report via the upstream tunnel to the AFTR
when the membership database changes.
B4 answers IGMP queries from AFTR based on the membership database.
B4's downstream link follows the traditional multipoint channel
forwarding and does not pose any specific problems.
B4 receives IPv4 multicast data from the AFTR tunneled over the
tunnel interface. B4 decapsulates the packet and then forwards it
downstream. Each member host receives the data packet based on Layer
2 multicast interface. No packet duplication is necessary.
AFTR acts as the as the default multicast querier for all B4s that
have established an IPv6 tunnel with it. In order to keep a
consistent multicast state between a B4 and AFTR, once a B4 is
connected it will stay connected until the state becomes empty.
After that point, the B4 may continue to use the tunnel for IPv4
unicast traffic.
According to aggregated IGMP reports received from a B4, AFTR
establishes group/source-specific multicast forwarding states at its
corresponding downstream tunnel interfaces. After that, AFTR
maintains or removes the state as required by the aggregated reports
received from B4.
At the upstream interface, AFTR procures for aggregated multicast
membership maintenance. Based on the multicast-transparent
operations of the B4s, the AFTR treats its tunnel interfaces as
multicast enabled downstream links, serving zero to many listening
nodes.
Multicast traffic arriving at the AFTR is transparently forwarded
Sarikaya Expires September 8, 2011 [Page 6]
Internet-Draft Multicast Support for DS-Lite - 6RD March 2011
according to its multicast forwarding information base. Multicast
data is first replicated and then forwarded in IPv4-in-IPv6 tunnel
from AFTR to the corresponding B4.
5.1. Tunnel Interface Considerations
Legacy IPv4 in IPv6 tunneling is performed as in [RFC2473].
Considerations specified in [I-D.ietf-softwire-dual-stack-lite]
apply. Packets upstream from B4 carry only IGMP signaling messages
and they are not expected to fragmentation. However packets
downstream, i.e. multicast data to B4 may be subject to
fragmentation.
5.2. Supporting IPv6 Multicast in DS-Lite
IPv6 multicast can be supported in a way similar to IPv4 as described
in Section 5. B4 Element has MLD Proxy function. Proxy operation
for MLD [RFC3810] is described in [RFC4605].
B4 receives MLD join requests from the hosts and then sends
aggregated MLD Report messages upstream in an IPv6 in IPv6 tunnel.
Tunnel addressing is in IPv6 and is as described in
[I-D.ietf-softwire-dual-stack-lite]. Multicast membership database
is maintained for all active IPv6 multicast groups the hosts
subscribe.
AFTR is MLD querier or another MLD Proxy. It serves all B4s
downstream and treats its tunnel interfaces as multicast enabled
downstream links, serving zero to many listening nodes. Multicast
membership database is maintained based on the aggregated Reports
received from downstream tunnel interfaces.
IPv6 multicast data received from the multicast Single Source
Multicast or Any Source Multicast sources are replicated according to
the multicast membership database and the data packets are tunneled
to the B4s that have one or more members of this multicast group.
B4s receive multicast data upstream in the B4-AFTR tunnel and
decapsulate it and then forward the packet downstream. Each member
host receive IPv6 multicast data packet from its Layer 2 interface.
6. 6RD Multicast Operation
In this section we specify how the host can subscribe and receive
IPv6 multicast data from IPv6 content providers based on the
architecture defined in Section 4.
Sarikaya Expires September 8, 2011 [Page 7]
Internet-Draft Multicast Support for DS-Lite - 6RD March 2011
The hosts will send their subscription requests for IPv6 multicast
groups upstream to the default router, i.e. Costumer Edge device.
After subscribing the group, the host can receive multicast data from
the CE. The host implements MLD protocol's host part.
Customer Edge device is MLD Proxy. After receiving the first MLD
Report message requesting subscription to an IPv6 multicast group, CE
establishes a tunnel interface with a Border Relay. The tunnel is
IPv4 based but it will carry IP traffic, MLD messages back and forth
and IPv6 multicast data messages downstream. This is similar to
[I-D.ietf-multimob-pmipv6-base-solution] but the operation is much
simpler. In 6RD environment there is no requirement to handle host
mobility. CE does not have to keep more than one tunnel interfaces,
a single interface is sufficient. MLD Proxy at the CE does not have
to have more than one proxy instances, a single instance is
sufficient.
CE is regular MLD proxy and it keeps MLD proxy membership database.
CE inserts multicast forwarding state on the incoming interface, and
merges state updates into the MLD proxy membership database. CE
updates or remove elements from the database as required. CE will
then send an aggregated Report via the upstream tunnel to the BR when
the membership database changes.
CE answers MLD queries from BR based on the membership database.
CE's downstream link follows the traditional multipoint channel
forwarding and does not pose any specific problems.
CE receives IPv6 multicast data from the BR tunneled over the tunnel
interface. CE decapsulates the packet and then forwards it
downstream. Each member host receives the data packet based on Layer
2 multicast interface. No packet duplication is necessary.
Border Relay acts as the as the default multicast querier for all CEs
that have established an IPv4 tunnel with it. In order to keep a
consistent multicast state between a CE and BR, once a CE is
connected it will stay connected until the state becomes empty.
After that point, the CE may establish another tunnel to a different
BR.
According to aggregated MLD reports received from a CE, BR
establishes group/source-specific multicast forwarding states at its
corresponding downstream tunnel interfaces. After that, BR maintains
or removes the state as required by the aggregated reports received
from CE.
At the upstream interface, BR procures for aggregated multicast
membership maintenance. Based on the multicast-transparent
Sarikaya Expires September 8, 2011 [Page 8]
Internet-Draft Multicast Support for DS-Lite - 6RD March 2011
operations of the CEs, the BR treats its tunnel interfaces as
multicast enabled downstream links, serving zero to many listening
nodes.
Multicast traffic arriving at the BR is transparently forwarded
according to its multicast forwarding information base. Multicast
data is first replicated and then forwarded in IPv6-in-IPv4 tunnel
from BR to the corresponding CE.
6.1. Tunnel Interface Considerations
IPv6 in IPv4 tunneling is performed as specified in [RFC4213].
Considerations specified in [RFC5969] apply. Packets upstream from
CE carry only MLD signaling messages and they are not expected to
fragmentation. However packets downstream, i.e. multicast data to CE
may be subject to fragmentation.
6.2. Supporting IPv4 Multicast in 6RD
IPv4 multicast can be supported in a way similar to IPv6 as described
in Section 6. 6RD Customer Edge device has IGMP Proxy function.
Proxy operation for IGMP [RFC3376] is described in [RFC4605].
CE receives IGMP join requests from the hosts and then sends
aggregated IGMP Report messages upstream in an IPv4 in IPv4 tunnel.
Tunnel addressing is in IPv4 and is as described in [RFC5969].
Multicast membership database is maintained for all active IPv4
multicast groups the hosts subscribe.
6RD Border Relay is IGMP querier or another IGMP Proxy. It serves
all CEs downstream and treats its tunnel interfaces as multicast
enabled downstream links, serving zero to many listening nodes.
Multicast membership database is maintained based on the aggregated
Reports received from downstream tunnel interfaces.
IPv4 multicast data received from the multicast Single Source
Multicast or Any Source Multicast sources are replicated according to
the multicast membership database and the data packets are tunneled
to the CEs that have one or more members of this multicast group.
CEs receive multicast data upstream in the CE-BR tunnel and
decapsulate it and then forward the packet downstream. Each member
host receive IPv4 multicast data packet from its Layer 2 interface.
7. Security Considerations
TBD.
Sarikaya Expires September 8, 2011 [Page 9]
Internet-Draft Multicast Support for DS-Lite - 6RD March 2011
8. IANA Considerations
TBD.
9. Acknowledgements
TBD.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[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.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Sarikaya Expires September 8, 2011 [Page 10]
Internet-Draft Multicast Support for DS-Lite - 6RD March 2011
Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work
in progress), March 2011.
[I-D.ietf-multimob-pmipv6-base-solution]
Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in PMIPv6
Domains", draft-ietf-multimob-pmipv6-base-solution-07
(work in progress), December 2010.
10.2. Informative references
Sarikaya Expires September 8, 2011 [Page 11]
Internet-Draft Multicast Support for DS-Lite - 6RD March 2011
Author's Address
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Sarikaya Expires September 8, 2011 [Page 12]