Network Working Group B. Sarikaya
Internet-Draft Huawei USA
Intended status: Standards Track June 8, 2011
Expires: December 10, 2011
Multicast Support for 6rd
draft-sarikaya-softwire-6rdmulticast-01.txt
Abstract
This memo specifies modifications required to 6rd so that both IPv6
hosts can receive multicast data from IPv6 servers. The 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 December 10, 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
Sarikaya Expires December 10, 2011 [Page 1]
Internet-Draft Multicast Support for 6rd June 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. 6rd Multicast Operation . . . . . . . . . . . . . . . . . . . . 4
5.1. Tunnel Interface Considerations . . . . . . . . . . . . . . 5
5.2. Supporting IPv4 Multicast in 6rd . . . . . . . . . . . . . 6
6. Solution Based on Layer 2 Multicast Support . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
10.2. Informative references . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Sarikaya Expires December 10, 2011 [Page 2]
Internet-Draft Multicast Support for 6rd June 2011
1. Introduction
With IPv4 address depletion on the horizon, many techniques are being
standardized for IPv6 migration including 6rd [RFC5969]. 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.
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 6rd multicast support protocol.
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 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.
Sarikaya Expires December 10, 2011 [Page 3]
Internet-Draft Multicast Support for 6rd June 2011
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 1: 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 1.
5. 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.
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
[RFC6224] 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
Sarikaya Expires December 10, 2011 [Page 4]
Internet-Draft Multicast Support for 6rd June 2011
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
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.
5.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
Sarikaya Expires December 10, 2011 [Page 5]
Internet-Draft Multicast Support for 6rd June 2011
fragmentation. However packets downstream, i.e. multicast data to CE
may be subject to fragmentation.
5.2. Supporting IPv4 Multicast in 6rd
IPv4 multicast can be supported in a way similar to IPv6 as described
in Section 5. 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 of 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.
6. Solution Based on Layer 2 Multicast Support
In this section we assume that Layer 2 multicast is supported in the
network. Layer 2 multicast support is done in order to forward
multicast data downstream to the ports of Layer 2 devices, i.e.
switches that requested a multicast group instead of flooding the
data to all the ports.
In the switches called snooping switches, multicast MAC address based
filters are setup which link Layer 2 multicast groups to the egress
ports. When an MLD Report message is received, the bridge will setup
a multicast filter entry that allows (in case of a join message) or
prevents (in case of a leave message) packets to flow the port on
which the MLD Report message was received. In terms of IP multicast
addresses, the mapping is not unique as 2 ** (112 - 32) IPv6
multicast addresses map to a single Ethernet multicast MAC address.
This would be reduced to 32 if allocation policy of using only the
Sarikaya Expires December 10, 2011 [Page 6]
Internet-Draft Multicast Support for 6rd June 2011
lower 32 bits in 112 bit group ID field of IPv6 multicast address is
followed.
Snooping switches maintain a list of multicast routers and the ports
on which they are attached called router ports. For this purpose
multicast router discovery protocol described in [RFC4286] is used.
The switch sends an ICMPv6 Multicast Router Solicitation message and
the router sends ICMPv6 Multicast Router Advertisement message in
reply.
The main functionality of a snooping switch is to forward multicast
data packets based on the filters that are setup, i.e. to those
egress ports with multicast groups downstream and also to the router
ports.
In a 6rd network the snooping switches MUST detect MLD packets in the
tunnel between CE and BR. This requires IPv6 snooping switches to be
capable of reading IPv4 protocol field values. A value of 58
indicates that an ICMPv6 packet is encapsulated. A value of 41
indicates that an IPv6 data packet is encapsulated. The fact that
MLD packets are ICMPv6 packets complicates the operation snooping
switch. The switch needs to look further into the packet to
correctly identify an MLD packet.
In case multicast is supported in Layer 2, BR after receiving a
multicast data packet does not attempt to replicate the packet. The
packet replication is taken care of by the snooping switches. So
Layer 2 multicast support avoids packet duplication at BR which could
be costly in some cases.
7. Security Considerations
TBD.
8. IANA Considerations
TBD.
9. Acknowledgements
TBD.
10. References
Sarikaya Expires December 10, 2011 [Page 7]
Internet-Draft Multicast Support for 6rd June 2011
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.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, December 2005.
[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.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
10.2. Informative references
Sarikaya Expires December 10, 2011 [Page 8]
Internet-Draft Multicast Support for 6rd June 2011
Author's Address
Behcet Sarikaya
Huawei USA
5340 Legacy Dr. Building 175
Plano, TX 75074
Phone:
Email: sarikaya@ieee.org
Sarikaya Expires December 10, 2011 [Page 9]