Internet DRAFT - draft-sarikaya-softwire-6rdmulticast
draft-sarikaya-softwire-6rdmulticast
Internet Engineering Task Force B. Sarikaya
Internet-Draft T. Tsou
Intended status: Informational Huawei Technologies (USA)
Expires: March 15, 2014 H. Ji
China Telecom
C. Zhou
Huawei Technologies
September 11, 2013
IPv6 Multicast in a 6rd Deployment
draft-sarikaya-softwire-6rdmulticast-06
Abstract
This memo specifies 6rd's multicast component so that IPv6 hosts can
receive multicast data from IPv6 servers. In the 6rd encapsulation
solution, multicast communication is completely integrated into the
6rd tunnel. In the 6rd translation solution, the protocol is based
on proxying MLD at the 6rd Customer Edge router interworking the MLD
messages to IGMP messages and sending them upstream through a network
which supports IPv4 multicast. The 6rd Border Relay is a multicast
router and interworks the IGMP to MLD for onward propasgation toward
the IPv6 multicast source. IPv6 Multicast data received at 6rd
Border Relay is translated into IPv4 multicast data and and delivered
through the IPv4 multicast tree downstream to the 6rd Customer Edge.
The latter translates it back to IPv6 multicast data then delivers it
to the hosts.
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 March 15, 2014.
Copyright Notice
Sarikaya, et al. Expires March 15, 2014 [Page 1]
Internet-Draft IPv6 Multicast in a 6rd Deployment September 2013
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. 6rd Tunneling Architecture . . . . . . . . . . . . . . . 4
4.2. Translation Architecture . . . . . . . . . . . . . . . . 5
5. 6rd Tunneling Multicast Operation . . . . . . . . . . . . . . 6
5.1. Tunnel Interface Considerations . . . . . . . . . . . . . 7
5.2. Avalanche Problem . . . . . . . . . . . . . . . . . . . . 8
6. 6rd Translation Multicast Operation . . . . . . . . . . . . . 8
6.1. Solution Based on Layer 2 Multicast Support . . . . . . . 10
6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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 an IPv4-only
legacy ISP network. The 6rd Customer Edge (CE) device's LAN side is
dual stack and the WAN side is IPv4 only. The CE tunnels IPv6
packets received from the LAN side to 6rd Border Relays (BR) after
encapsulating them as IPv4 packets. The BRs have anycast IPv4
addresses and receive encapsulated packets from CEs over a virtual
interface. 6rd operation is stateless. Packets are received/ sent
independently of each other and no state needs to be maintained.
Sarikaya, et al. Expires March 15, 2014 [Page 2]
Internet-Draft IPv6 Multicast in a 6rd Deployment September 2013
It should be noted that there is no depletion problem for IPv4
address space allocated for any source multicast and source specific
multicast [RFC3171]. This document is not motivated by the depletion
of IPv4 multicast addresses.
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. This is what is meant
by 6rd multicast protocol.
In the 6rd encapsulation approach, 6rd multicast is integrated into
the 6rd unicast solution. 6rd customer premise equipment (CPE) is
extended to support an MLD proxy [RFC4605]. This proxy receives MLD
Membership Report messages [RFC4601] requesting to join a multicast
group from its subtended hosts. It tunnels aggregated join requests
upstream to the 6rd Border Router (BR) using IPv6 in IPv4
encapsulation. The 6rd Border Router is extended to support an MLD
querier, which sends join requests upstream towards the multicast
source(s, becomes part of the multicast tree, and thus receives IPv6
multicast data. The 6rd Border Router encapsulates the IPv6
multicast data using 6rd's IPv6 in IPv4 encapsulation and sends it to
each member CPE that has joined the stream concerned. The CPE
decapsulates the packet and the MLD proxy sends the IPv6 multicast
data downstream to the member hosts.
In the translation approach, native IPv4 multicast support in the
network between Customer Edge routers and Border Router can be
exploited. The translation approach requires MLD to IGMP
interworking at the Customer Edge and IGMP to MLD interworking at the
border router. The border router needs to translate IPv6 multicast
data into IPv4 multicast data and the Customer Edge router needs to
translate IPv4 multicast data back into IPv6 multicast data.
6rd's CE to CE forwarding feature is not used in either approach.
2. Terminology
This document uses the terminology defined in [RFC5969], [RFC5569],
[RFC3810], [RFC3376], and [I-D.ietf-softwire-dslite-multicast].
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].
3. Requirements
This section states requirements on 6rd multicast support protocol.
Sarikaya, et al. Expires March 15, 2014 [Page 3]
Internet-Draft IPv6 Multicast in a 6rd Deployment September 2013
IPv6 hosts connected to 6rd CE router MUST be able to join multicast
groups in IPv6 and receive multicast data.
Both any source multicast (ASM) and source specific multicast (SSM)
MUST be supported.
6rd multicast MUST NOT introduce the need to use more IPv4 addresses,
thereby contributing to public IPv4 address depletion.
4. Architecture
In 6rd, IPv6 or IPv4/IPv6 dual stack hosts are served by the 6rd
Customer Edge device (CE). The CE is dual stack facing the hosts and
IPv4 only facing the network or WAN side. The CE tunnels IPv6
packets in IPv4 to the 6rd Border Relay (BR). The BR decapsulates
the tunneled packets and forwards them to the IPv6 network. In the
reverse direction, the BR receives IPv6 packets from the IPv6 network
tunnels them in IPv4 to the CE. The CE decapsulates the IPv6 packets
and forwards them to the hosts.
Unicast 6rd is stateless. Each IPv6 packet sent by the CE is treated
separately and different packets from the same CE may go to different
BRs. The CE encapsulates IPv6 packets in IPv4 with the IPv4
destination address set to the BR address (usually an anycast IPv4
address). BRs are placed where IPv6 native connectivity exists to
other networks. A CE is configured with its own IPv4 address (public
or private), with a 6rd IPv6 prefix from which the CE's IPv4 address
can be derived, and with one or more BR IPv4 addresses. When the BR
receives IPv6 packets addressed to the CE, it extracts the CE's IPv4
address from the destination IPv6 address and uses this address as
the destination address for the IPv4 encapsulation of the IPv6
packet. 6rd views the IPv4-only network as an NBMA link from the
IPv6 point of view and all 6rd CEs and BRs are defined as off-link
neighbors from one other.
4.1. 6rd Tunneling Architecture
In order to support multicast, the CE implements an MLD Proxy
function [RFC4605]. IPv6 hosts send their join requests (MLD
Membership Report messages) to CE. The CE as a proxy sends
aggregated Report messages upstream towards BR in unicast using IPv6
in IPv4 encapsulation.
Dual Stack Hosts IPv4
+----+ Network
| H1 | IPv4
+----+ +-----+ only +-------+ +
Sarikaya, et al. Expires March 15, 2014 [Page 4]
Internet-Draft IPv6 Multicast in a 6rd Deployment September 2013
+----+ | CE | network -- | BR |
| H2 | ---| MLD |--- IPv6 | MLD | IPv6
+----+ |Proxy| in |Querier| Network
+----+ +-----+ IPv4 +-------+
| H3 | Encapsulation
+----+
Figure 1: Architecture of 6rd Tunneling Multicast Protocol
The BR is the default multicast querier for the CE. The BR
implements a multicast router function or it could be another MLD
proxy.
All the elements of 6rd multicast support system are shown in Figure
1.
4.2. Translation Architecture
In order to support multicast, CE implements MLD Proxy [RFC4605] and
MLD to IGMP interworking function
[ID.perreault-igmp-mld-translation]. IPv6 hosts send their join
requests (MLD Membership Report messages) to CE. CE as a proxy sends
aggregated IGMP Report messages upstream towards BR.
In order to support SSM, MLDv2 [RFC3810] and IGMPv3 [RFC3376] must be
supported by the CE and BR, and MLDv2 must be supported by the host.
The BR is the default multicast querier for the CE. The BR
implements an IGMP to MLD interworking function and multicast router
function or it could be another MLD proxy.
It is assumed that the IPv4 only network to which the CE and the BR
are connected supports native IPv4 multicast.
All the elements of 6rd translation-based multicast support system
are shown in Figure 2.
Sarikaya, et al. Expires March 15, 2014 [Page 5]
Internet-Draft IPv6 Multicast in a 6rd Deployment September 2013
Dual Stack Hosts IPv4
+----+ Network
| H1 | IPv4
+----+ +----------------+ only +------------------+
+----+ | CE MLD | network |IGMP BR | +
| H2 | ---| MLD IGMP |-----------| MLD MLD |
+----+ |Proxy Translator| |Translator Querier|
+----+ +----------------+ +------------------+
| H3 | IPv6
+----+ Network
Figure 2: Architecture of 6rd Translation-Based Multicast
5. 6rd Tunneling 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 Figure 1.
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.
The Customer Edge device is an MLD Proxy. After receiving the first
MLD Report message requesting subscription to an IPv6 multicast
group, the CE establishes a tunnel interface with a Border Relay.
The tunnel is IPv4 based but it will carry MLD messages back and
forth and IPv6 multicast data messages downstream.
The CE is a regular MLD proxy and it keeps an MLD proxy membership
database. The CE inserts multicast forwarding state on the incoming
interface, and merges state updates into the MLD proxy membership
database. The CE updates or remove elements from the database as
required. The CE will then send an aggregated Report via the
upstream tunnel to the BR when the membership database changes.
The CE answers MLD queries from the BR based on the membership
database. The CE's downstream link follows the traditional
multipoint channel forwarding and does not pose any specific
problems.
The CE receives IPv6 multicast data from the BR tunneled over the
tunnel interface. The CE decapsulates the packet and then forwards
it downstream. Each member host receives the data packet based on
the Layer 2 multicast interface. No packet duplication is necessary.
Sarikaya, et al. Expires March 15, 2014 [Page 6]
Internet-Draft IPv6 Multicast in a 6rd Deployment September 2013
The Border Relay acts 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 subtending CEs, the
BR establishes group/source-specific multicast forwarding states at
its corresponding downstream tunnel interfaces. After that, the BR
maintains or removes the state as required by the aggregated reports
received from CEs.
At the upstream interface, the 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.
When the BR receives MLD join requests from downstream CEs, the BR
sends PIM join messages upstream towards multicast source(s). This
results in a multicast tree formation where the BR is at the leaf of
the multicast tree, enabling the BR to receive IPv6 multicast data
sent by the source.
Multicast traffic arriving at the BR is transparently forwarded
according to its multicast forwarding information base. Multicast
data is first replicated according to MLD multicast group state and
then forwarded in IPv6-in-IPv4 tunnels from the BR to the
corresponding CEs.
5.1. Tunnel Interface Considerations
IPv6 in IPv4 tunneling is performed as specified in [RFC4213].
Considerations specified in [RFC5969] apply. Packets passing
upstream from the CE carry only MLD signaling messages and they are
not expected to be fragmented. However packets downstream, i.e.,
multicast data to the CEs, may be subject to fragmentation.
Source and destination addresses of MLD messages in IPv6-in-IPv4
tunnel from CE are as follows:
o The source address of IPv4 header is the CE WAN interface IPv4
address. The destination address is the BR anycast address when
an invite message is sent to group G. Subsequent messages to group
G contain the BR unicast address as destination address.
Sarikaya, et al. Expires March 15, 2014 [Page 7]
Internet-Draft IPv6 Multicast in a 6rd Deployment September 2013
o The source address of the inner MLD message is the link local
address. The destination address is all MLDv2-capable multicast
routers or FF02::16 for MLD Version 2 Multicast Listener Reports.
The source and destination addresses of MLD messages in the IPv6- in-
IPv4 softwire from BR are as follows:
o The source address of the IPv4 header is the BR IPv4 unicast
address. The destination address is the CE IPv4 address. This
also holds for multicast data.
o The source address of the inner MLD message is the link local
address. The destination address is the link-scope all-nodes
multicast address (FF02::1) for General Queries, or the IPv6
multicast group address for specific queries.
The source address of IPv6 multicast data is the unicast IPv6 address
of the multicast source, e.g., the content provider. The destination
address is the3 IPv6 multicast group address.
5.2. Avalanche Problem
In Section 5.1, multicast data is replicated to all interfaces, i.e.,
to all member CEs at the BR. This replication (often called
avalanche problem) can be very costly if is a very large number of
downstream member CEs such as in the IPTV application. See
Appendix A in [I-D.ietf-softwire-dslite-multicast].
In 6rd tunneling multicast, the avalanche problem can be reduced by
careful network partitioning. More BRs can be deployed in areas
where IPv6 users are increasing in numbers. Deploying BRs by
collocating them with the access network gateway as with the Border
Network Gateway (BNG) is another possibility.
In the 6rd tunneling multicast operation, CEs are enabled to exploit
multiple BRs that can be deployed in the network by using the BR
anycast address any time they send an upstream MLD join request and
then using the same BR that received the join message in subsequent
MLD messages by using the same BR's unicast address.
6. 6rd Translation 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 Figure 2.
The hosts will send their subscription requests for IPv6 multicast
groups upstream to the default router, i.e., the Costumer Edge
Sarikaya, et al. Expires March 15, 2014 [Page 8]
Internet-Draft IPv6 Multicast in a 6rd Deployment September 2013
device. After subscribing the group, the host can receive multicast
data from the CE. The host implements the MLD protocol's host part.
The Customer Edge device is an MLD Proxy. After receiving the first
MLD Report message requesting subscription to an IPv6 multicast
group, the CE interworks the MLD Membership Report message to an IGMP
Membership report message. It sends it upstream only if joining a
new group is needed.
Address translation in generating an IGMP Membership report message
is done as follows: the destination address is copied from the last
32 bits of IPv6 multicast group address. The CE inserts the IPv4
address of its WAN interface into the source address. It is assumed
that the IPv6 multicast group address in MLD Report message conforms
to the addressing scheme described in
[I-D.ietf-mboned-64-multicast-address-format], for any-source and
source-specific multicast address formats.
Source addresses in the MLDv2 payload are translated as follows.
Multicast source addresses in MLD Membership Report message MUST use
uPrefix64, i.e. 64:ff9b::/96 defined in [RFC6052]. uPrefix64
facilitates translation into an IPv4 source address to be used in
IGMPv3 Membership Report messages for source-specific multicast,
i.e., by extracting the last 32 bits of IPv6 source address.
The IGMP Report message is received by the IGMP Querier/Proxy
upstream on the link. (Normally this node is the Broadband Network
Gateway, BNG in broadband networks.) The IGMP Querier/Proxy sends
IGMPv3 Report message to the neighboring routers to join the group.
In networks where PIM is supported, the IGMP Report message may be
received by the PIM Designated Router. The PIM router sends a PIMv4
join message to join an IPv4 group.
The border router that receives the join message translates the
message into MLD. To join an IPv6 group for any-source multicast,
the IPv6 Multicast group address is obtained from the destination
address. For source-specific multicast, the IPv6 source address is
generated after obtaining the IPv4 source address of Membership
Report message's Group Record Source Address field. The BR sends the
PIMv6 join message upstream towards the source.
The BR MUST act as the designated router to which the source of the
source-specific IGMP join message is connected. The BR MUST act as
the rendez-vous point (RP) of the multicast group for the any-source
multicast IGMP join message. Normally there is one such BR in an
operator's network. An IPv4 multicast tree eventually forms in the
network between the CE and BR and an IPv6 multicast tree upstream
from the BR for the same ASM or SSM group.
Sarikaya, et al. Expires March 15, 2014 [Page 9]
Internet-Draft IPv6 Multicast in a 6rd Deployment September 2013
IPv6 multicast data received at the border router from the source is
translated into IPv4. The last 32 bits of the source and destination
address fields determine the source and destination addresses of the
IPv4 multicast data packet. This packet is sent downstream on the
multicast tree already formed for this IPv4 multicast group.
Multicast data packet address translation follows the rules in
[I-D.ietf-mboned-64-multicast-address-format] for the multicast group
address and [RFC6052] for source- specific multicast source address,
i.e. using uPrefix64. For any- source multicast, the Border Router
inserts an IPv4 source address, different for each source.
Packet header translation follows the rules in [RFC6145].
Fragmentation and reassembly are handled as described in [RFC6145].
After the IPv4 multicast data packet is sent downstream from the BR
it may be fragmented by the routers.
The CE receives the IPv4 multicast data packet, possibly in
fragments, and reassembles the fragments. The CE translates the IPv4
multicast data packet back to an IPv6 multicast data packet. Address
translation is done following
[I-D.ietf-mboned-64-multicast-address-format] for multicast group
addresses and [RFC6052] for unicast SSM source addresses. Header
translation is done as in [RFC6145].
IPv6 multicast data is sent on the home link to the host(s). IEEE
802.3 or IEEE 802.11 multicast link support usually handles this
delivery in Layer 2 without any packet duplication if there are more
than one members to the any-source multicast group or SSM source and
multicast group.
6.1. 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 set up which link layer 2 multicast groups to the
egress ports. IGMP snooping switches are commonly used in operators'
networks, most commonly at the access nodes (AN) [RFC6788].
When an IGMP Report message is received, the bridge will set up a
multicast filter entry that allows (in case of a join message) or
prevents (in case of a leave message) packets to flow on the port on
which the IGMP Report message was received. In terms of IPv4
Sarikaya, et al. Expires March 15, 2014 [Page 10]
Internet-Draft IPv6 Multicast in a 6rd Deployment September 2013
multicast addresses, the mapping is not unique as 32 IPv4 multicast
addresses map to a single Ethernet multicast MAC address [RFC4541].
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 IGMP packets sent
upstream by the CE and set the filtering rules accordingly. When
IPv4 data packets are received the IGMP snooping switches forward
these packets towards all CEs that have members, effectively
achieving packet duplication at the access node level.
6.2. Analysis
An analysis of the translation solution reveals the following:\
o The translation solution imposes a requirement on the IPv6 source-
specific multicast sources to use uPrefix64 compatible source
addresses. This requirement cannot be satified with simple
configuration of the CPE router and Border Router.
o In the case of any-source multicast, the border router must use a
public IPv4 address distinctively to represent each IPv6 any-
source multicast source.
o In deployments which use IGMP routers, not PIM routers, source-
specific multicast can be supported only if all routers have been
upgraded to IGMPv3 and no IGMPv1 or IGMPv2 systems are present.
Otherwise the operation reverts to the older version of IGMP to
preserve compatibility and thus SSM can not be supported. With
the use of PIM routers, this is avoided.
o The border router must act as the designated router or the rendez-
vous point for the IPv4/IPv6 multicast group and this may lead to
the use of a single border router in the network instead of load
sharing with various border routers.
7. Security Considerations
6rd Translation Multicast control and data message security are as
described in [RFC5969]. The threats and their mitigation described
in [RFC5969] apply to multicast communication as well.
8. IANA Considerations
TBD.
Sarikaya, et al. Expires March 15, 2014 [Page 11]
Internet-Draft IPv6 Multicast in a 6rd Deployment September 2013
9. Acknowledgements
We would like to specially thank Mark Townsley for his constructive
comments. Steve Wright's online and very many offline comments
helped us improve the document.
10. References
10.1. Normative References
[I-D.ietf-mboned-64-multicast-address-format]
Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work
in progress)", August 2012.
[I-D.ietf-mboned-auto-multicast]
Bumgardner, G., "Automatic Multicast Tunneling (work in
progress)", June 2012.
[I-D.ietf-softwire-dslite-multicast]
Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q.
Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients
over an IPv6 Multicast Network", draft-ietf-softwire-
dslite-multicast-05 (work in progress), April 2013.
[ID.perreault-igmp-mld-translation]
Perrault, S. and T. Tsou, "Internet Group Management
Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based
Multicast Translation ("IGMP/MLD Translation") (Work in
progress)", February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks", RFC
2491, January 1999.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
Sarikaya, et al. Expires March 15, 2014 [Page 12]
Internet-Draft IPv6 Multicast in a 6rd Deployment September 2013
[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.
[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.
[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.
[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.
10.2. Informative References
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments",
RFC 3171, August 2001.
[RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E.
Nordmark, "The Line-Identification Option", RFC 6788,
November 2012.
Authors' Addresses
Sarikaya, et al. Expires March 15, 2014 [Page 13]
Internet-Draft IPv6 Multicast in a 6rd Deployment September 2013
B. Sarikaya
Huawei Technologies (USA)
5340 Legacy Dr. Building 175
Plano, TX 75024
USA
Email: sarikaya@ieee.org
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: Tina.Tsou.Zouting@huawei.com
URI: http://tinatsou.weebly.com/contact.html
Hui Ji
China Telecom
NO19.North Street
Beijing, Chaoyangmen,Dongcheng District
P.R. China
Email: jihui@chinatelecom.com.cn
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: cathy.zhou@huawei.com
Sarikaya, et al. Expires March 15, 2014 [Page 14]
