Internet DRAFT - draft-sarikaya-softwire-map-multicast
draft-sarikaya-softwire-map-multicast
Network Working Group B. Sarikaya
Internet-Draft Huawei USA
Intended status: Standards Track H. Ji
Expires: December 10, 2015 China Telecom
June 8, 2015
Multicast Support for Mapping of Address and Port Protocol and Light
Weight 4over6
draft-sarikaya-softwire-map-multicast-04
Abstract
This memo specifies multicast component for MAP and Light Weight
4over6 so that IPv4 hosts can receive multicast data from IPv4
servers over an IPv6 network. The solution developed is based on
translation. In the Translation Multicast solution for MAP (MAP-E
and MAP-T) and lw4o6, IGMP messages are translated into MLD messages
and sent to the network in IPv6. MAP Border Relay/lwAFTR does the
reverse translation and joins IPv4 multicast group for the hosts.
Border Relay/lwAFTR as multicast router receives IPv4 multicast data
and translates the packet into IPv6 multicast data and sends
downstream on the multicast tree. Member CEs/lwB4s receive multicast
data, translate it back to IPv4 and transmit 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 December 10, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sarikaya & Ji Expires December 10, 2015 [Page 1]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
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. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. MAP-T and 4rd Translation Architecture . . . . . . . . . 4
4. MAP-T and 4rd Translation Multicast Operation . . . . . . . . 7
4.1. Address Translation . . . . . . . . . . . . . . . . . . . 7
4.2. Protocol Translation . . . . . . . . . . . . . . . . . . 9
4.3. Learning Multicast Prefixes for IPv4-embedded IPv6
Multicast Addresses . . . . . . . . . . . . . . . . . . . 10
4.4. Supporting IPv4 Multicast at CE Router and lwB4 . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative references . . . . . . . . . . . . . . . . . 14
Appendix A. Group Membership Message Translation Details . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
With IPv4 address depletion on the horizon, many techniques are being
standardized for IPv6 migration including Mapping of Address and Port
(MAP) - Encapsulation, - Translation and 4rd [I-D.ietf-softwire-map],
[I-D.ietf-softwire-map-t], [I-D.ietf-softwire-4rd]. MAP/4rd enables
IPv4 hosts to communicate with external hosts using IPv6 only ISP
network. MAP/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. MAP/4rd operation is stateless.
Packets are received/ sent independent of each other and no state
needs to be maintained except for NAT44 operation on IPv4 packets
received from the user.
Sarikaya & Ji Expires December 10, 2015 [Page 2]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
Light Weight 4 Over 6 (lw4o6) is a variant of Dual Stack Lite where
carrier grade NAT is moved from AFTR to B4 element, i.e. NAPT is done
locally at each B4 called light weight B4 or lwB4. Unicast lw4o6
takes user IPv4 packets from the local LAN and lwB4 does a NAPT and
then tunnels the packets in an IPv4-in-IPv6 tunnel to lwAFTR which
decapsulates the packet and then sends it to IPv4 network. Incoming
packets follow reverse route and are encapsulated at lwAFTR and sent
to lwB4 which decapsulates and after NAPT operation transmits to the
destination.
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.
MAP-E, MAP-T, 4rd and lw4o6 are unicast only. They do not support
multicast. In this document we specify how multicast from home IPv4
users can be supported in MAP-E (as well as MAP-T and 4rd) and lw4o6.
In case IPv6 network is multicast enabled, MAP-T/4rd can provide
multicast service to the hosts using MAP-T/4rd Multicast Translation
based solution. A Multicast Translator can be used that receives
IPv4 multicast group management messages in IGMP and generates
corresponding IPv6 group management messages in MLD and sends them to
IPv6 network towards MAP-T/4rd Border Relay. We use
[I-D.ietf-softwire-map-t] or [I-D.ietf-softwire-4rd] for sending IPv4
multicast data in IPv6 to the CE routers. At MAP-T/4rd CE router
another translator is needed to translate IPv6 multicast data into
IPv4 multicast data.
It should be noted that if IPv6 network is multicast enabled the
translation multicast solution presented in Section 4 can also be
used for MAP-E.
In this document we address MAP-E (and MAP-T/4rd) and lw4o6 multicast
problem and propose the architecture of Multicast Translation based
solution. Section 2 is on terminology, Section 3 is on architecture,
Section 4 is on multicast translation protocol, and Section 5 states
security considerations.
2. Terminology
This document uses the terminology defined in
[I-D.ietf-softwire-map], [I-D.ietf-softwire-lw4over6],
[I-D.ietf-softwire-map-t], [I-D.ietf-softwire-4rd], [RFC3810] and
[RFC3376].
Sarikaya & Ji Expires December 10, 2015 [Page 3]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
3. Architecture
In MAP-E, MAP-T and 4rd, there are hosts (possibly IPv4/ IPv6 dual
stack) served by MAP-E, MAP-T and 4rd Customer Edge device. CE is
dual stack facing the hosts and IPv6 only facing the network or WAN
side. MAP-E, MAP-T and 4rd CE may be local IPv4 Network Address and
Port Translation (NAPT) box [RFC3022] by assigning private IPv4
addresses to the hosts. MAP-E, MAP-T and 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 MAP-E, MAP-T and
4rd Border Relay. BR receives IPv4 packets tunneled in IPv6 from CE
and decapsulates them and sends them out to IPv4 network.
Unicast MAP-E, MAP-T and 4rd are 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 Rule IPv4 Prefixes, Rule 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.
Unicast Lightweight 4over6 (lw4o6) is a variation of Dual-Stack Lite
(DS-Lite) [RFC6333] which moves carrier-grade IPv4-IPv4 NAT from the
Address Family Transition Router (AFTR) element to the Basic Bridging
BroadBand (B4) element [I-D.ietf-softwire-lw4over6]. The resulting
elements are called lwAFTR and lwB4 with NAPT, respectively. Lw4o6
also adopts some features from MAP-E. A+P scheme of public IPv4
address sharing is used by lwB4's in assigning WAN side IPv4 public
addresses with a distinct port set. As in MAP-E, encapsulation of
IPv4 packets in IPv6 and decapsulation is according to [RFC2473].
3.1. MAP-T and 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.
Sarikaya & Ji Expires December 10, 2015 [Page 4]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
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 the BR as a leaf node in IPv4
multicast distribution tree is translated into IPv6 multicast data by
the translator using [I-D.ietf-softwire-map-t],
[I-D.ietf-softwire-4rd] and then sent downstream to the IPv6 part of
the multicast tree to all downstream routers that are members. IPv6
data packet eventually gets to the CE. At the CE, a reverse
[I-D.ietf-softwire-map-t], [I-D.ietf-softwire-4rd] operation takes
place by the translator and then IPv4 multicast data packet is sent
to the member hosts on the LAN interface. [I-D.ietf-softwire-map-t],
[I-D.ietf-softwire-4rd] are 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).
MAP-T and 4rd Translation Multicast solution uses the multicast 46
translator 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 [I-D.ietf-softwire-4rd] header-mapping into IPv6
multicast data at the BR and another [I-D.ietf-softwire-4rd] header-
mapping back to IPv4 multicast data at the CE router. Encapsulation
variant of [I-D.ietf-softwire-4rd] is not used. In case of MAP-T,
IPv4 data packet is translated using v4 to v6 header translation
using multicast addresses instead of the mapping algorithm used in
[I-D.ietf-softwire-map-t].
All the elements of MAP-T and 4rd translation-based multicast support
system are shown in Figure 1.
Sarikaya & Ji Expires December 10, 2015 [Page 5]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
Dual Stack Hosts IPv4
+----+ Network
| H1 | +----------+ IPv6 +-------------+
| | | CE | | BR |
+----+ |Translator| only | Translator |
|MAP-T/4rd | | MAP-T/4rd |
+----+ | | network | |IGMP| +
| H2 | ---|IGMP-MLD |--------- -- |MLD | or | IPv6
+----+ | Proxy | |Querier |PIM | Network
+----+ +----------+ +-------------+
| H3 |
+----+
Figure 1: Architecture of MAP-T and 4rd Translation Multicast
In case IPv6 only network is multicast enabled, translation multicast
architecture can also be used for lw4o6 multicast. lwB4 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 lwB4. lwB4 as a MLD proxy sends
aggregated MLD Report messages upstream towards lwAFTR. lwB4 replies
MLD membership query messages with MLD membership report messages
based on IGMP membership state in the IGMP/MLD proxy.
lwAFTR is MLD querier on its WAN side. On its interface to IPv4
network lwAFTR may either have IGMP client or PIM. PIM being able to
support both IPv4 and IPv6 multicast should be preferred. lwAFTR
receives MLD join requests, extracts IPv4 multicast group address and
then joins the group upstream, possibly by issuing a PIM join
message.
For multicast data, [I-D.ietf-softwire-dslite-multicast] uses
encapsulation of IPv4 multicast data in IPv6 multicast data packet
but in this document we use translation. IPv4 multicast data
received by the lwAFTR as a leaf node in IPv4 multicast distribution
tree is translated into IPv6 multicast data by the translator and
then sent downstream to the IPv6 part of the multicast tree to all
downstream routers that are members. IPv6 data packet eventually
gets to the lwB4. At the lwB4, a reverse translation operation takes
place by the translator and then IPv4 multicast data packet is sent
to the member hosts on the LAN interface. The translation algorithm
in [I-D.ietf-softwire-map-t], [I-D.ietf-softwire-4rd] are modified to
handle multicast addresses.
In order to support SSM, IGMPv3 MUST be supported by the host, lwB4
and lwAFTR. For ASM, lwAFTR MUST be the Rendezvous Point (RP).
Sarikaya & Ji Expires December 10, 2015 [Page 6]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
MAP-T and 4rd Translation Multicast solution uses the multicast 46
translator in not one but two places in the architecture: at the lwB4
router and at the lwAFTR. IPv4 data packet is translated using v4 to
v6 header translation using multicast addresses instead of the
mapping algorithm used in [I-D.ietf-softwire-map-t].
All the elements of lw4o6 translation-based multicast support system
are shown in Figure 2.
IPv4
+-------+ IPv4 Network
| |Multicast
| | +--------------+ +--------------+ +
| | | lwB4 NAPT |IPv6 | lwAFTR |
| IPv4 |----->| IGMP MLD |----->|IGMP | IGMP | IPv6
| LAN |<-----| Proxy Proxy |------|Router| PIM | Network
| | +--------------+ +--------------+
| |
+-------+
Figure 2: Architecture of lw4o6 Multicast Translation
4. MAP-T and 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. Translation details are given in
Appendix A.
4.1. Address Translation
IPv4-only host, 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
multicast groups are used. Both are /96 prefixes.
SSM_MPREFIX64 is set to ff3x:0:8000::/96, with 'x' set to any valid
scope. ASM_MPREFIX64 values are formed as shown in Figure 3. Flag
field 1 (ff1) field is defined in [RFC7371] bits M bit MUST BE set to
1. "scop" field is defined in [RFC3956]. Flag field 2 (ff2) is a set
of 4 flags rrrM where r bits MUST be set to zero. M bit is set to 1
to indicate that a multicast IPv4 address is embedded in the low-
Sarikaya & Ji Expires December 10, 2015 [Page 7]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
order 32 bits of the multicast IPv6 address. "sub-group-id" field
MUST follow the recommendations specified in [RFC3306] if unicast-
based prefix is used or the recommendations specified in [RFC3956] if
embedded-RP is used. The default value is all zeros.
| 8 | 4 | 4 | 4 | 76 | 32 |
+--------+----+----+----+------------------------------+----------+
|11111111|ff1 |scop|ff2 | 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 is
set to FF3x:0:8000::/96 where 'x' is any valid scope.
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.
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.
Address translation described above for MAP-T applies to lw4over6
multicast translation where the entities involved are lwB4 replaces
Customer Edge device and lwAFTR replaces BR Figure 2.
Sarikaya & Ji Expires December 10, 2015 [Page 8]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
4.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 MAP-T or 4rd BR receives IPv4 multicast data for an IPv4 group
a.b.c.d it [I-D.ietf-softwire-4rd] 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.ietf-softwire-4rd] 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 4.1 and
propose it as a complementary enhancement to the translation
algorithm in [I-D.ietf-softwire-4rd].
The IP/ICMP translation translates IPv4 packets into IPv6 using
minimum MTU size of 1280 bytes (Section 4.3 in
[I-D.ietf-softwire-4rd]) 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, [I-D.ietf-softwire-4rd] 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.3 of [I-D.ietf-softwire-4rd]). 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.
Sarikaya & Ji Expires December 10, 2015 [Page 9]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
In case an IPv4 multicast source sends multicast data with the don't
fragment (DF) flag set to 1, [I-D.ietf-softwire-4rd] header mapping
sets the D bit in IPv6 fragment header before sending the packet
downstream as in Fig. 3 in Section 4.3 of [I-D.ietf-softwire-4rd].
This feature of [I-D.ietf-softwire-4rd] preserves the semantics of DF
flag at the BR and CE.
Because MAP-T/4rd is stateless, Multicast MAP-T/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 may obtain different values for these prefixes,
effectively changing to a different 4rd BR.
Protocol translation described above for MAP-T applies to lw4over6
multicast translation where the entities involved are lwB4 replaces
Customer Edge device and lwAFTR replaces BR Figure 2.
4.3. 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.
A new router advertisement option, a Multicast ASM Translation Prefix
option, can be defined for this purpose. The option contains IPv6
ASM multicast translation prefix, ASM_MPREFIX64. A new router
advertisement option, a Multicast SSM Translation Prefix option, can
be defined for this purpose. The option contains IPv6 SSM multicast
prefix translation prefix SSM_MPREFIX64.
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.
Source-specific multicast (SSM) group membership message payloads in
IGMPv3 and MLDv2 contain address literals and their translation
requires another multicast translation prefix option. IPv4 source
addresses in IGMPv3 Membership Report message are unicast addresses
of IPv4 sources and they have to be translated into unicast IPv6
source addresses in MLDv2 Membership Report message. A new router
advertisement option, a Multicast Translation Unicast Prefix option
can be defined for this purpose. The option contains IPv6 unicast
Network-Specific Prefix U_PREFIX64. The host can be configured by
Sarikaya & Ji Expires December 10, 2015 [Page 10]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
its default router using router advertisements containing the
prefixes [I-D.sarikaya-softwire-6man-raoptions]. 64:ff9b::/96 is the
global value called well-known prefix that is assigned to U_PREFIX64
[RFC6052]. Organization specific values called Network-Specific
Prefixes can also be used. Since multicast is potentially inter-
domain, the use of well-known prefix for U_PREFIX64 is recommended.
DHCP servers can also configure hosts with ASM_MPREFIX64,
SSM_MPREFIX64 and U_PREFIX64 as in
[I-D.ietf-softwire-multicast-prefix-option].
Note that U_PREFIX64 is also used in multicast data packet address
translation. Source-specific multicast source address in multicast
data packets coming from SSM sources MUST be translated using
U_PREFIX64.
4.4. Supporting IPv4 Multicast at CE Router and lwB4
When MAP-E CE router 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. The same applies to lwB4s in lw4over6.
On receiving multicast data packets, lwB4 or CE router MUST NOT
modify destination IP address or destination port of the packets.
Multicast UDP datagrams MUST be forwarded to the local LAN towards
the host that is a member of this group.
IGMP membership reports received at lwB4 or CE router may be sent
upstream individually for any source multicast but for source
specific multicast, e.g. IGMPv3, membership reports MUST be sent
after IGMP aggregation.
5. Security Considerations
Multicast control and data message security can be provided by the
security architecture, mechanisms, and services described in
[RFC4301], [RFC4302] and [RFC4303]. and in [RFC4607] for source
specific multicast.
6. IANA Considerations
TBD.
Sarikaya & Ji Expires December 10, 2015 [Page 11]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
7. Acknowledgements
TBD.
8. References
8.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.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
1997.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments",
RFC 3171, August 2001.
[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", RFC
2491, January 1999.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
Sarikaya & Ji Expires December 10, 2015 [Page 12]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
[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.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[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.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6
Multicast Addressing Architecture", RFC 7371, September
2014.
Sarikaya & Ji Expires December 10, 2015 [Page 13]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
[I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", draft-ietf-softwire-map-13
(work in progress), March 2015.
[I-D.ietf-softwire-lw4over6]
Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
I. Farrer, "Lightweight 4over6: An Extension to the DS-
Lite Architecture", draft-ietf-softwire-lw4over6-13 (work
in progress), November 2014.
[I-D.ietf-softwire-map-t]
Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", draft-ietf-softwire-map-t-08 (work
in progress), December 2014.
[I-D.ietf-softwire-4rd]
Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
Solution (4rd)", draft-ietf-softwire-4rd-10 (work in
progress), December 2014.
[I-D.ietf-mboned-64-multicast-address-format]
Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
M. Xu, "IPv6 Multicast Address With Embedded IPv4
Multicast Address", draft-ietf-mboned-64-multicast-
address-format-06 (work in progress), September 2014.
[I-D.ietf-softwire-multicast-prefix-option]
Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6
Option for IPv4-Embedded Multicast and Unicast IPv6
Prefixes", draft-ietf-softwire-multicast-prefix-option-08
(work in progress), March 2015.
8.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.
Sarikaya & Ji Expires December 10, 2015 [Page 14]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
[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-09 (work in progress), March 2015.
[I-D.sarikaya-softwire-6man-raoptions]
Sarikaya, B., "IPv6 RA Options for Translation Multicast
Prefixes", draft-sarikaya-softwire-6man-raoptions-01 (work
in progress), February 2013.
[I-D.perreault-mboned-igmp-mld-translation]
Perreault, S. and T. Tsou, "Internet Group Management
Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based
Multicast Translation ("IGMP/MLD Translation")", draft-
perreault-mboned-igmp-mld-translation-01 (work in
progress), April 2012.
Appendix A. Group Membership Message Translation Details
IGMP Report messages (IGMP type number 0x12 and 0x16, in IGMPv1 and
IGMPv2 and 0x22 in IGMPv3) are translated into MLD Report messages
(MLDv1 ICMPv6 type number 0x83 and MLDv2 type number 0x8f). IGMP
Query message (IGMP type number 0x11) is translated into MLD Query
message (ICMPv6 type number 0x82)
[I-D.perreault-mboned-igmp-mld-translation].
Destination address in ASM, i.e. IGMPv1, IGMPv2 and MLDv1, is the
multicast group address so the destination address in IGMP message is
translated into the destination address in MLD message using
[I-D.ietf-mboned-64-multicast-address-format].
Destination address in SSM, i.e. IGMPv3 and MLDv2 is translated as
follows: it could be all nodes on link, which has the value of
224.0.0.1 (IGMPv3) and ff02::1 (MLDv2), all routers on link, which
has the value of 224.0.0.2 (IGMPv3) and ff02::2 (MLDv2), all IGMP/
MLD-capable routers on link, which has the value of 224.0.0.22
(IGMPv3) and ff02::16 (MLDv2).
Source address of MLD message that CE sends is set to link-local IPv6
address of CE's WAN side interface. Source address of MLD message
that BR sends is set to link-local IPv6 address of BR's downstream
interface.
Multicast Address or Group Address field in IGMP message payloads is
translated using [I-D.ietf-mboned-64-multicast-address-format] as
described above into the corresponding field in MLD message.
Sarikaya & Ji Expires December 10, 2015 [Page 15]
Internet-Draft Multicast Support for MAP-E and Lw4over6 June 2015
Source Address in IGMPv3 message payloads is translated using
U_PREFIX64, the IPv6 unicast prefix to be used by SSM source.
[RFC6052] defines in Section 2.3 the address translation algorithm of
embedding an IPv4 source address and obtaining an IPv6 source address
using a network specific prefix like U_PREFIX64. At the BR on its
upstream interface or at the CE on its LAN interface, IPv4 addresses
are extracted from the IPv4-embedded IPv6 addresses.
Maximum Response Time (MRT) field in IGMPv2 and IGMPv3 queries are
translated into Maximum Response Delay (MRD) in MLDv1 and MLDv2
queries, respectively. In the corresponding MLD message, MRD is set
to 100 times the value of MRT. At the BR on its upstream interface
or at the CE on its LAN interface, MRT value is obtained by dividing
MRD into 100 and rounding it to the nearest integer.
IGMP messages are sent with a Router Alert IPv4 option [RFC2113].
The translated MLD message are sent with a Router Alert option in a
Hop-By-Hop IPv6 extension header [RFC2711]. In both cases, 2-octet
value is set to 0.
Authors' Addresses
Behcet Sarikaya
Huawei USA
5340 Legacy Dr. Building 175
Plano, TX 75024
Email: sarikaya@ieee.org
Hui Ji
China Telecom
NO19.North Street
Beijing, Chaoyangmen,Dongcheng District
P.R. China
Email: jihui@chinatelecom.com.cn
Sarikaya & Ji Expires December 10, 2015 [Page 16]
