Multicast Support for 4rd
draft-sarikaya-softwire-4rdmulticast-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Behcet Sarikaya | ||
| Last updated | 2012-03-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sarikaya-softwire-4rdmulticast-02
Network Working Group B. Sarikaya
Internet-Draft Huawei USA
Intended status: Standards Track March 9, 2012
Expires: September 10, 2012
Multicast Support for 4rd
draft-sarikaya-softwire-4rdmulticast-02.txt
Abstract
This memo specifies 4rd technology's multicast component so that IPv4
hosts can receive multicast data from IPv4 servers over an IPv6
network. In 4rd Translation Multicast solution, IGMP messages are
translated into MLD messages at the CE router which is IGMP/MLD Proxy
and sent to the network in IPv6. 4rd Border Relay does the reverse
translation and joins IPv4 multicast group for 4rd hosts. Border
Relay as multicast router receives IPv4 multicast data and translates
the packet into IPv6 multicast data using 4rd-U and sends downstream
on the multicast tree. Member CEs receive multicast data, translate
it back to IPv4 and transmit to the hosts. In AMT based
encapsulation solution, AMT Gateway at the 4rd Customer Edge router
uses AMT protocol to establish a tunnel interface with AMT Relay at
the 4rd Border Relay and this tunnel is used to exchange IGMP
messages to establish multicast state at AMT Relay so that AMT Relay
can tunnel IPv4 multicast data to IPv4 hosts connected to AMT
Gateway.
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 10, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Sarikaya Expires September 10, 2012 [Page 1]
Internet-Draft Multicast Support for 4rd March 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. 4rd Translation Architecture . . . . . . . . . . . . . . . 5
4.2. AMT Architecture . . . . . . . . . . . . . . . . . . . . . 6
5. 4rd Translation Multicast Operation . . . . . . . . . . . . . 7
5.1. Address Translation . . . . . . . . . . . . . . . . . . . 7
5.1.1. Learning Multicast Prefixes for IPv4-embedded
IPv6 Multicast Addresses . . . . . . . . . . . . . . . 9
5.2. Protocol Translation . . . . . . . . . . . . . . . . . . . 9
5.3. Supporting IPv6 Multicast in 4rd Translation Multicast . . 11
6. 4rd AMT Encapsulation Multicast Operation . . . . . . . . . . 11
6.1. Modifications to AMT Messages . . . . . . . . . . . . . . 13
6.2. Supporting IPv6 Multicast in 4rd AMT Multicast . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative references . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Sarikaya Expires September 10, 2012 [Page 2]
Internet-Draft Multicast Support for 4rd March 2012
1. Introduction
With IPv4 address depletion on the horizon, many techniques are being
standardized for IPv6 migration including 4rd
[I-D.mdt-softwire-mapping-address-and-port],
[I-D.mdt-softwire-map-translation], [I-D.xli-behave-divi],
[I-D.despres-softwire-4rd-u]. 4rd enables IPv4 hosts to communicate
with external hosts using IPv6 only ISP network. 4rd Customer Edge
(CE) device's LAN side is dual stack and WAN side is IPv6 only. CE
tunnels/translates IPv4 packets received from the LAN side to 4rd
Border Relays (BR). BRs have anycast IPv6 addresses and receive
encapsulated/translated packets from CEs over a virtual interface.
4rd operation is stateless. Packets are received/ sent independent
of each other and no state needs to be maintained.
4rd as defined in [I-D.mdt-softwire-mapping-address-and-port],
[I-D.mdt-softwire-map-translation], [I-D.xli-behave-divi],
[I-D.despres-softwire-4rd-u] is unicast only. It does not support
multicast. In this document we specify how multicast from home IPv4
users can be supported in 4rd.
In case IPv6 network is multicast enabled, 4rd can provide multicast
service to the hosts using 4rd Multicast Translation based solution.
A Multicast Translator can be used that receives IPv6 multicast group
management messages in MLD and generates corresponding IPv4 group
management messages in IGMP and sends them to IPv4 network in 4rd
Border Relay [I-D.venaas-behave-mcast46]. We use 4rd-U for sending
IPv6 multicast data in IPv4 to the CE routers. At 4rd CE router
another translator is needed to translate IPv6 multicast data into
IPv4 multicast data.
In case 4rd IPv6 network is not multicast enabled, Automatic
Multicast Tunneling (AMT) enables the host(s) in an AMT site to
connect to an AMT Relay which is a multicast router in the multicast
infrastructure [I-D.ietf-mboned-auto-multicast]. The network between
an AMT site and Relay is not multicast enabled and is seen as non-
broadcast multi-access (NBMA) link layer [RFC2491].
When an AMT gateway receives an IGMP join message to an Any-Source
Multicast (ASM) [RFC1112] or Source-Specific Multicast (SSM) group
[RFC4607], it first discovers an AMT Relay using Anycast Relay IP
address. Using a three way handshake the gateway sends IGMP
membership report message in a UDP tunnel to the relay. Relay joins
the source in the multicast infrastructure and sends multicast data
downstream to all member gateways in a UDP tunnel. When a gateway
has no membership state, i.e. after all member hosts leave the
group(s), its state with the relay expires and the gateway can start
relay discovery all over again. Periodically the relay and gateway
Sarikaya Expires September 10, 2012 [Page 3]
Internet-Draft Multicast Support for 4rd March 2012
exchange AMT Query and AMT Membership Update messages. All AMT
control messages are secured using message authentication codes
(MAC).
AMT works for both IPv4 using IGMP and IPv6 using IGMP. IGMP
messages are encapsulated in IPv4 using UDP encapsulation and MLD
messages are encapsulated in IPv6 using UDP encapsulation.
In this document we address 4rd multicast problem and propose two
architectures: Automatic Multicast tunneling (AMT) and Multicast
Translation based solutions. Section 2 is on terminology, Section 3
is on requirements, Section 4 is on architecture, Section 5 is on
multicast translation protocol, Section 6 is on AMT protocol and
Section 7 states security considerations.
2. Terminology
This document uses the terminology defined in
[I-D.mdt-softwire-mapping-address-and-port], [I-D.xli-behave-divi],
[I-D.despres-softwire-4rd-u], [RFC3810] and [RFC3376].
3. Requirements
This section states requirements on 4rd multicast support protocol.
IPv4 hosts connected to 4rd CE router MUST be able to join multicast
groups in IPv4 and receive multicast data.
Any source multicast (ASM) SHOULD be supported and source specific
multicast (SSM) MUST be supported.
In case of translation solution, 4rd CE MUST support IGMP to MLD
translator. 4rd CE MUST be MLD Proxy as defined in [RFC4605].
In case of translation solution, 4rd BR MUST support MLD Querier. 4rd
BR MUST support MLD to IGMP translator upstream.
4rd CE MAY support AMT gateway as defined in
[I-D.ietf-mboned-auto-multicast]. Modifications to AMT protocol
defined in this document applies.
4rd BR MAY support AMT relay as defined in
[I-D.ietf-mboned-auto-multicast]. Modifications to AMT protocol
defined in this document applies.
Sarikaya Expires September 10, 2012 [Page 4]
Internet-Draft Multicast Support for 4rd March 2012
4. Architecture
In 4rd, there are hosts (possibly IPv4/ IPv6 dual stack) served by
4rd Customer Edge device. CE is dual stack facing the hosts and IPv6
only facing the network or WAN side. 4rd CE may be local IPv4 Network
Address and Port Translation (NAPT) box [RFC3022] by assigning
private IPv4 addresses to the hosts. 4rd CEs in the same domain may
use shared public IPv4 addresses on their WAN side and if they do
they should avoid ports outside of the allocated port set for NAPT
operation. At the boundary of the network there is 4rd Border Relay.
BR receives IPv4 packets tunneled in IPv6 from CE and decapsulates
them and sends them out to IPv4 network.
Unicast 4rd is stateless except for the local NAPT at the CE. Each
IPv4 packet sent by CE treated separately and different packets from
the same CE may go to different BRs or CEs. CE encapsulates IPv4
packet in IPv6 with destination address set to BR address (usually
anycast IPv6 address). BR receives the encapsulated packet and
decapsulates and send it to IPv4 network. CEs are configured with
domain 4rd Prefixes, IPv6 Prefixes and with an BR IPv6 anycast
address. BR receives IPv4 packets addressed to this ISP and from the
destination address it extracts the destination host's IPv4 address
and uses this address as destination address and encapsulates the
IPv4 packet in IPv6 and sends it to IPv6-only network.
4.1. 4rd Translation Architecture
In case IPv6 only network is multicast enabled, translation multicast
architecture can be used. CE implements IGMP Proxy function
[RFC4605] towards the LAN side and MLD Proxy on its WAN interface.
IPv4 hosts send their join requests (IGMP Membership Report messages)
to CE. CE as a MLD proxy sends aggregated MLD Report messages
upstream towards BR. CE replies MLD membership query messages with
MLD membership report messages based on IGMP membership state in the
IGMP/MLD proxy.
BR is MLD querier on its WAN side. On its interface to IPv4 network
BR may either have IGMP client or PIM. PIM being able to support
both IPv4 and IPv6 multicast should be preferred. BR receives MLD
join requests, extracts IPv4 multicast group address and then joins
the group upstream, possibly by issuing a PIM join message.
IPv4 multicast data received by BR is translated into IPv6 multicast
data by the translator using 4rd-U and then sent downstream to the
multicast tree to all downstream routers that are members. IPv6 data
packet eventually gets to the CE. At the CE, a reverse 4rd-U
operation takes place by the translator and then IPv4 multicast data
packet is sent to the member hosts on the LAN interface. 4rd-U is
Sarikaya Expires September 10, 2012 [Page 5]
Internet-Draft Multicast Support for 4rd March 2012
modified to handle multicast addresses.
In order to support SSM, IGMPv3 MUST be supported by the host, CE and
BR. For ASM, BR MUST be the Rendezvous Point (RP).
4rd Translation Multicast solution uses the multicast 46 translator
[I-D.venaas-behave-mcast46] in not one but two places in the
architecture: at the CE router and at the Border Relay. IPv4
multicast data received at 4rd BR goes through a 4rd-U header-mapping
into IPv6 multicast data at the BR and another 4rd-U header-mapping
back to IPv4 multicast data at the CE router
[I-D.despres-softwire-4rd-u]. Encapsulation variant of
[I-D.despres-softwire-4rd-u] is not used.
All the elements of 4rd translation-based multicast support system
are shown in Figure 1.
Dual Stack Hosts IPv4
+----+ Network
| H1 | +----------+ IPv6 +-------------+
| | | CE | | BR |
+----+ |Translator| only | Translator |
| 4rd-U | | 4rd-U |
+----+ | | network | |IGMP| +
| H2 | ---|IGMP-MLD |--------- -- |MLD | or | IPv6
+----+ | Proxy | |Querier |PIM | Network
+----+ +----------+ +-------------+
| H3 |
+----+
Figure 1: Architecture of 4rd Translation Multicast
4.2. AMT Architecture
4rd network lends itself easily to the Automatic Multicast Tunneling
architecture. Dual stack hosts connected to the Customer Edge router
constitute an AMT site and it is multicast enabled. IPv6 only
network is the unicast only network. At the boundary of the network
4rd Border Relay is connected to the native multicast backbone
infrastructure.
We place AMT Gateway at the CE router instead of at the hosts. CE
router serves all the connected hosts. For multicast traffic, CE
Router has an AMT pseudo-interface that serves as a default multicast
route. It is a tunneling interface.
AMT Relay is placed at 4rd BR. AMT Relay also has a pseudo-
Sarikaya Expires September 10, 2012 [Page 6]
Internet-Draft Multicast Support for 4rd March 2012
interface. A given relay and all CEs (AMT Gateways) connected to it
can be considered to be on a separate logical NBMA link. On this
link, gateways and relay communicate using AMT protocol to transmit
and receive multicast control messages for membership management and
multicast data from the relay to the gateways.
All the elements of 4rd multicast support system with AMT are shown
in Figure 2.
AMT protocol is designed to provide IPv6 multicast to the hosts in
AMT site using AMT messages in IPv6. AMT protocol is designed to
provide IPv4 multicast to the hosts in AMT site using AMT messages in
IPv4. However, in 4rd the network is IPv6 only. We need to modify
AMT to use IPv6 AMT protocol to transmit IPv4 multicast messages such
as IGMP messages and IPv4 multicast data.
Dual Stack Hosts IPv4
+----+ Network
| H1 | IPv6
+----+ +-------+ only +-----+ +
+----+ | CE | network | BR |
| H2 | ---| AMT |--- -- | AMT | IPv6
+----+ |Gateway| |Relay| Network
+----+ +-------+ +-----+
| H3 |
+----+
Figure 2: Architecture of 4rd AMT Multicast
5. 4rd Translation 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 Figure 1 in two parts: address translation
and protocol translation.
5.1. Address Translation
IPv4-only H1 will join IPv4 multicast group by sending IGMP
Membership Report message upstream towards the IGMP Proxy in
Figure 1. MLD Proxy first creates a synthesized IPv6 address of IPv4
multicast group address using IPv4-embedded IPv6 multicast address
format [I-D.ietf-mboned-64-multicast-address-format]. ASM_MPREFIX64
for any source multicast groups and SSM_MPREFIX64 for source specific
Sarikaya Expires September 10, 2012 [Page 7]
Internet-Draft Multicast Support for 4rd March 2012
multicast groups are used. Both are /96 prefixes.
In both ASM_MPREFIX64 and SSM_MPREFIX64, M bit MUST be set to 1 to
indicate that an IPv4 address is embedded in the last 32 bits of the
multicast IPv6 address. ASM_MPREFIX64 values are formed by setting
flgs bits to make it an embedded RP prefix by setting R bit to 1 and
P and T bits to 1 as shown in Figure 3 [RFC4291], [RFC3306],
[RFC3956].
| 8 | 4 | 4 | 4 | 76 | 32 |
+--------+----+----+----+------------------------------+----------+
|11111111|0111|scop|1000| sub-group-id |v4 address|
+--------+----+----+----+-----------------------------------------+
Figure 3: ASM_MPREFIX64 Formation
Each translator in the upstream BR is assigned a unique ASM_MPREFIX64
prefix. CE (MLD Proxy in CE) can learn this value by means out of
scope with this document. With this, CE can easily create an IPv6
multicast address from the IPv4 group address a.b.c.d that the host
wants to join.
Source-Specific Multicast (SSM) can also be supported similar to the
Any Source Multicast (ASM) described above. In case of SSM, IPv4
multicast addresses use 232.0.0.0/8 prefix. IPv6 SSM_MPREFIX64
values are formed by setting R bit to zero, P and T bits to 1. This
gives FF3x00008x::/96 as the SSM prefix. This prefix is referred to
as SSM_PREFIX64 Figure 4.
| 8 | 4 | 4 | 16 | 4 | 60 | 32 |
+--------+----+----+-----------+----+------------------+----------+
|11111111|0011|scop|00.......00|1000| sub-group-id |v4 address|
+--------+----+----+-----------+----+------------------+----------+
Figure 4: SSM_MPREFIX64 Formation
Since SSM translation requires a unique address for each IPv4
multicast source, an IPv6 unicast prefix must be configured to the
translator in the upstream BR to represent IPv4 sources. This prefix
is prepended to IPv4 source addresses in translated packets.
The join message from the host for the group ASM_MPREFIX64:a.b.c.d or
SSM_MPREFIX64:a.b.c.d or an aggregate join message will be received
by MLD querier at the BR. BR as multicast anchor checks the group
address and recognizes ASM_MPREFIX64 or SSM_MPREFIX64 prefix. It
next checks the last 32 bits is an IPv4 multicast address in range
224/8 - 239/8. If all checks succeed, IGMPv4 Client joins a.b.c.d
using IGMP on its IPv4 interface.
Sarikaya Expires September 10, 2012 [Page 8]
Internet-Draft Multicast Support for 4rd March 2012
Joining IPv4 groups can also be done using PIM since PIM supports
both IPv4 and IPv6. The advantage of using PIM is that there is no
need to enable IGMP support in neighboring IPv4 routers. The
advantage of using IGMP is that IGMP is a simpler protocol and it is
supported by a wider range of routers. The use of PIM or IGMP is
left as an implementation choice.
5.1.1. Learning Multicast Prefixes for IPv4-embedded IPv6 Multicast
Addresses
CE can be pre-configured with Multicast Prefix64 of ASM_MPREFIX64 and
SSM_MPREFIX64 that are supported in their network. However
automating this process is also desired.
[I-D.wing-behave-learn-prefix] suggests several methods including
DHCPv6.
A new DHCPv6 option, OPTION_AFT_PREFIX_DHCP, can be defined for this
purpose. The option contains IPv6 ASM and SSM prefixes. The host
can request these prefixes by sending this option in its request to
the DHCP server and the server replies with the option containing the
prefixes.
After the host gets the multicast prefixes, when an application in
the host wishes to join an IPv4 multicast group the host MUST use
ASM_MPREFIX64 or SSM_MPREFIX64 and then obtain the synthesized IPv6
group address before sending MLD join message.
5.2. Protocol Translation
The hosts will send their subscription requests for IPv4 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 IGMP protocol's host part.
Customer Edge device is IGMP Proxy facing the LAN interface. After
receiving the first IGMP Report message requesting subscription to an
IPv4 multicast group, a.b.c.d, MLD Proxy in the CE's WAN interface
synthesizes an IPv6 multicast group address corresponding to a.b.c.d
and sends an MLD Report message upstream to join the group.
When CE is a NAT or NAPT box assigning private IPv4 addresses to the
hosts, IP Multicast requirements for a Network Address Translator
(NAT) and a Network Address Port Translator (NAPT) stated in
[RFC5135] apply to IGMP messages and IPv4 multicast data packets.
4rd BR as MLD router receives/sends MLD messages on its WAN
interface. 4rd BR does all corresponding actions on its upstream
interface connected to IPv4 network in IGMP/PIM in IPv4. The two
Sarikaya Expires September 10, 2012 [Page 9]
Internet-Draft Multicast Support for 4rd March 2012
sides on the BR share MLD membership state.
When 4rd BR receives IPv4 multicast data for an IPv4 group a.b.c.d it
4rd-U translates/encapsulates IPv4 packet into IPv6 multicast packet
and sends it to IPv6 synthesized address corresponding to a.b.c.d
using ASM_MPREFIX64 or SSM_MPREFIX64. The header mapping described
in [I-D.despres-softwire-4rd-u] Section 4.2 (using Table 1) is used
except for mapping the source and destination addresses. In this
document we use the multicast address translation described in
Section 5.1 and propose it as a complementary enhancement to the
translation algorithm in [I-D.despres-softwire-4rd-u].
The IP/ICMP translation translates IPv4 packets into IPv6 using
minimum MTU size of 1280 bytes (Section 4.1 in
[I-D.despres-softwire-4rd-u]) but this can be changed for multicast.
Path MTU discovery for multicast is possible in IPv6 so 4rd BR can
perform path MTU discovery for each ASM group and use these values
instead of 1280. For SSM, a different MTU value MUST be kept for
each SSM channel. Because of this 8 bytes added by IPv6 fragment
header in each data packet can be tolerated.
Since multicast address translation does not preserve checksum
neutrality, 4rd-U translator/encapsulator at 4rd BR must however
modify the UDP checksum to replace the IPv4 addresses with the IPv6
source and destination addresses in the pseudo-header which consists
of source address, destination address, protocol and UDP length
fields before calculating the new checksum.
IPv6 multicast data must be translated back to IPv4 at the 4rd CE
(e.g. using Table 2 in Section 4.2 of [I-D.despres-softwire-4rd-u]).
Such a task is much simpler than the translation at 4rd BR because
IPv6 header is much simpler than IPv4 header and IPv4 link on the LAN
side of 4rd CE is a local link. The packet is sent on the local link
to IPv4 group address a.b.c.d for IPv6 group address of
ASM_MPREFIX64:a.b.c.d or SSM_MPREFIX64:a.b.c.d.
In case an IPv4 multicast source sends multicast data with the don't
fragment (DF) flag set to 1, 4rd-U header mapping sets the D bit in
IPv6 fragment header before sending the packet downstream as in Fig.
3 in Section 4.2 of [I-D.despres-softwire-4rd-u]. This feature of
4rd-U preserves the semantics of DF flag at the BR and CE.
Because 4rd is stateless, Multicast 4rd should stay faithful to this
as much as possible. Border Relay acts as the default multicast
querier for all CEs that have established multicast communication
with it. In order to keep a consistent multicast state between a CE
and BR, CE MUST use the same IPv6 multicast prefixes (ASM_MPREFIX64/
SSM_REFIX64) until the state becomes empty. After that point, the CE
Sarikaya Expires September 10, 2012 [Page 10]
Internet-Draft Multicast Support for 4rd March 2012
may obtain different values for these prefixes, effectively changing
to a different 4rd BR.
5.3. Supporting IPv6 Multicast in 4rd Translation Multicast
IPv6 multicast can be supported natively in 4rd in case IPv6-only
network is multicast enabled. 4rd Customer Edge device has MLD Proxy
function. Proxy operation for MLD [RFC3810] is described in
[RFC4605].
CE receives MLD join requests from the hosts and then sends
aggregated MLD Report messages upstream towards BR. No address or
protocol translation is needed at the CE or at the BR. IPv6 Hosts in
4rd domain use any source multicast block FF0X [RFC4291] or source
specific multicast block FF3X::8000:0-FF3X::FFFF:FFFF for dynamic
allocation by a host [RFC4607], [RFC3307].
4rd Border Relay is MLD querier. It serves all CEs downstream.
After receiving an MLD join message, BR sends PIM join message
upstream to join IPv6 multicast group. Multicast membership database
is maintained based on the aggregated Reports received from
downstream interfaces in the multicast tree.
4rd Border Relay is a Rendezvous Point (RP) for ASM groups. For SSM,
BR MUST support MLDv2.
IPv6 multicast data received from the Single Source Multicast or Any
Source Multicast sources are replicated according to the multicast
membership database and the data packets are sent downstream on the
multicast tree and eventually received by the CEs that have one of
more members of this multicast group.
MLD Proxy in the CE receives multicast data then forwards the packet
downstream. Each member host receives IPv6 multicast data packet
from its Layer 2 interface.
6. 4rd AMT Encapsulation Multicast Operation
When a host (H1, H2 or H3 in Figure 2) wants to join an IPv4
multicast group, it sends an IGMP report (IGMPv3 report for a source-
specific group) to CE router. CE router uses BR's anycast address
this CE router is configured with.
CE sends AMT Relay Discovery IPv6 message which is a UDP message sent
to a IANA reserved AMT port, e.g. 2268. AMT port MUST be in the port
range of CE. In the payload of this message CE MUST set the I bit to
indicate that CE will encapsulate IGMP messages in IPv6. Note that
Sarikaya Expires September 10, 2012 [Page 11]
Internet-Draft Multicast Support for 4rd March 2012
all UMT messages are UDP messages.
BR (topologically closest to this CE router) receives the message and
replies with AMT Relay Advertisement UDP message in IPv6. BR checks
to see if it can provide IPv6 multicast service and if yes it replies
with AMT Relay Advertisement message. BR MUST set the I bit to
indicate that it can provide IPv4 multicast service.
CE receives AMT Relay Advertisement message. CE now has BR's unicast
address which it uses to send all multicast packets for this session.
CE sends AMT Request message to BR's unicast address to begin the
process of joining IPv4 multicast group. CE initializes a timer used
to send periodic requests.
BR sends AMT Query message. In this message an IGMP Listener Query
message is encapsulated [I-D.ietf-mboned-auto-multicast] with an IP
header.
CE receives AMT Query message and responds by sending AMT Membership
Update message. This message encapsulates IGMP Membership Report
message with an IP header to request BR to join IPv4 multicast group
the host wants to join.
BR receives AMT Membership Update message and it adds the tunnel to
the CE in its outgoing interface list for the group that the host
wants to join. BR will send a join message towards the source of the
multicast group to build a multicast tree in the native multicast
infrastructure.
After the initial three way handshake, periodically AMT Membership
Query and AMT Membership Update messages are exchanged between BR and
CE. As for multicast data, the data packets from the source received
at BR will be replicated to all interfaces in it's outgoing interface
list as well as the tunnel outgoing interface for all member CEs. BR
sends multicast data in AMT Multicast Data messages to CE with the
data packet encapsulated in UDP packet with IP header.
CE receives AMT Multicast Data message over the pseudo interface
associated with the tunnel to BR. CE forwards the packet to the
outgoing interfaces joined by the hosts.
Another host wants to join another IPv4 multicast group, three-way
handshake involving AMT Request/ AMT Membership Query and AMT
Membership Update is needed but AMT Relay Discovery/ AMT Relay
Advertisement messages are not needed.
Sarikaya Expires September 10, 2012 [Page 12]
Internet-Draft Multicast Support for 4rd March 2012
6.1. Modifications to AMT Messages
This specification uses AMT messages as defined in
[I-D.ietf-mboned-auto-multicast] except the changes stated in this
section.
AMT Relay Discovery message changes include the addition of two
flags, M and I flags. AMT gateway uses I flag to negotiate IGMP
message transmission in IPv6.
A summary of the AMT Relay Discovery message format is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=1 |M|I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
The protocol version number
Type
The type of the message
M Flag
Not used in this specification
I Flag
Set to 1 if AMT Gateway wants to send IGMP messages encapsulated
in IPv6
Reserved
A 22-bit reserved field. Sent as 0, ignored on receipt.
Discovery Nonce
A 32-bit random value generated by the gateway and replayed by the
relay.
AMT Relay Advertisement message changes include the addition of two
flags, M and I flags. AMT relay uses I flag to let AMT Gateway know
if AMT Relay is capable of IGMP message transmission in IPv6.
A summary of the AMT Relay Advertisement message format is shown
below.
Sarikaya Expires September 10, 2012 [Page 13]
Internet-Draft Multicast Support for 4rd March 2012
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 | Type=2|M|I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
The protocol version number
Type
The type of the message
M Flag
Not used in this specification
I Flag
Set to 1 if AMT Gateway wants to send IGMP messages encapsulated
in IPv6
Reserved
A 22-bit reserved field. Sent as 0, ignored on receipt.
Discovery Nonce
A 32-bit random value generated by the gateway and replayed by the
relay.
Relay Address
The unicast IPv4 address of the AMT relay.
6.2. Supporting IPv6 Multicast in 4rd AMT Multicast
IPv6 multicast can be supported in a way similar to IPv4 using AMT
architecture as described in Section 6. 4rd Customer Edge device has
AMT Gateway function as described in [I-D.ietf-mboned-auto-multicast]
with no extensions. IPv6 hosts connected to AMT Gateway send and
receive MLD messages [RFC3810] to AMT Gateway which uses AMT protocol
to subscribe the multicast groups with AMT Relay at 4rd Border Relay.
AMT Relay sends IPv6 multicast data in UDP encapsulated IPv6 messages
to AMT Gateway.
Sarikaya Expires September 10, 2012 [Page 14]
Internet-Draft Multicast Support for 4rd March 2012
7. Security Considerations
All AMT control messages are secured using Message Authentication
Code (MAC) that is a cryptographic hash of a private secret, the
originators address, and the request nonce. AMT data messages are
not secured. 4rd Translation Multicast control and data message
security are as described in [RFC4607] for source specific multicast.
8. IANA Considerations
AMT Relay Discovery and AMT Relay Advertisement messages are modified
as in Section 6.1.
9. Acknowledgements
We are grateful to Remi Despres for his contributions to this
document. Mohamed Boucadair provided many comments offline that
helps us improve the document.
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.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks",
Sarikaya Expires September 10, 2012 [Page 15]
Internet-Draft Multicast Support for 4rd March 2012
RFC 2491, January 1999.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[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.
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a
Network Address Translator (NAT) and a Network Address
Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[I-D.mdt-softwire-map-translation]
Bao, C., Li, X., Zhai, Y., Murakami, T., and W. Dec, "MAP
Translation (MAP-T) - specification",
draft-mdt-softwire-map-translation-01 (work in progress),
March 2012.
[I-D.mdt-softwire-mapping-address-and-port]
Bao, C., Troan, O., Matsushima, S., Murakami, T., and X.
Li, "Mapping of Address and Port (MAP)",
draft-mdt-softwire-mapping-address-and-port-03 (work in
progress), January 2012.
[I-D.despres-softwire-4rd-u]
Despres, R., Penno, R., Qin, J., and Y. Lee, "IPv4
Residual Deployment via IPv6 - Unified Solution (4rd)",
draft-despres-softwire-4rd-u-04 (work in progress),
March 2012.
[I-D.xli-behave-divi]
Shang, W., Li, X., Zhai, Y., and C. Bao, "dIVI: Dual-
Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-04
Sarikaya Expires September 10, 2012 [Page 16]
Internet-Draft Multicast Support for 4rd March 2012
(work in progress), October 2011.
[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",
draft-ietf-mboned-64-multicast-address-format-01 (work in
progress), February 2012.
[I-D.ietf-mboned-auto-multicast]
Bumgardner, G. and T. Morin, "Automatic Multicast
Tunneling", draft-ietf-mboned-auto-multicast-12 (work in
progress), February 2012.
10.2. Informative references
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[I-D.wing-behave-learn-prefix]
Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/
IPv4 Translator", draft-wing-behave-learn-prefix-04 (work
in progress), October 2009.
[I-D.venaas-behave-mcast46]
Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
IPv4 - IPv6 multicast translator",
draft-venaas-behave-mcast46-02 (work in progress),
December 2010.
Sarikaya Expires September 10, 2012 [Page 17]
Internet-Draft Multicast Support for 4rd March 2012
Author's Address
Behcet Sarikaya
Huawei USA
5340 Legacy Dr. Building 175
Plano, TX 75074
Phone:
Email: sarikaya@ieee.org
Sarikaya Expires September 10, 2012 [Page 18]