INTERNET-DRAFT
October 15, 2002
Expires in six month
K. Tsuchiya, Hitachi
H. Higuchi, Hitachi
S. Sawada, Hitachi
S. Nozaki, Hitachi
An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)
<draft-ietf-ngtrans-mtp-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other docu-
ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
In the stage of the transition from IPv4 to IPv6 it is necessary
that IPv4 nodes and IPv6 nodes can communicate directly. This memo
proposes a mechanism which enables such direct communication for
multicast, in addition to that for unicast defined in [SIIT] and
[NAT-PT].
Tsuchiya draft-ietf-ngtrans-mtp-03.txt [Page 1]
INTERNET-DRAFT Expires in six month October 2002
1. Introduction
It is expected that lots of IPv4 nodes will remain, for their suc-
cess, for a long time even after the transition to IPv6 starts. On
the other hand IPv6-only nodes will appear, for cost reasons or as
a result of exhaustion of the IPv4 address space, before IPv4 nodes
disappear. Therefore, it is highly desirable to develop a mechanism
which enables direct communication between IPv4 nodes and IPv6
nodes, in order to advance the transition smoothly. [SIIT] and
[NAT-PT] have already proposed such mechanisms, but they are
applied only to unicast communication, not to multicast. So it is
necessary to provide another mechanism for multicast.
This memo describes an entire scheme of multicast communication
between IPv4 nodes and IPv6 nodes. The scheme is composed by a mul-
ticast translator and an address mapper who are located at the site
boundary between IPv4 and IPv6. It is not necessary to modify IPv4
nodes and IPv6 nodes.
This memo uses the words defined in [IPV4], [IPV6], and [TRANS-
MECH].
2. Components
This section describes components needed for the mechanism.
The system consists of a multicast translator, and an address map-
per. In order to allow IPv4 nodes and IPv6 nodes to directly commu-
nicate using multicast, they need to be installed on the site
boundary between IPv4 and IPv6. Figure 1 illustrates the network
system interconnected by them.
Tsuchiya draft-ietf-ngtrans-mtp-03.txt [Page 2]
INTERNET-DRAFT Expires in six month October 2002
+-----------+ +-----------+
| IPv4 | | IPv6 |
| Multicast | | Multicast |
| Sender | | Sender |
| Node | | Node |
+-----+-----+ +-----+-----+
| |
+-----+-----+ +-----+-----+
| | +------------------+ | |
| IPv4 land | | Address Mapper | | IPv6 land |
| | +--------+---------+ | |
| | | | |
| | +------------+------------+ | |
| | | Multicast Translator | | |
| | | +----------+ | | |
| +--+ |Translator| +--+ |
| | | +----------+ | | |
| | | +---------+ +---------+ | | |
| | | |IPv4 | |IPv6 | | | |
| | | |Multicast| |Multicast| | | |
| | | |Proxy | |Proxy | | | |
| | | +---------+ +---------+ | | |
| | +-------------------------+ | |
+-----+-----+ +-----+-----+
| |
+-----+-----+ +-----+-----+
| IPv4 | | IPv6 |
| Multicast | | Multicast |
| Receiver | | Receiver |
| Node | | Node |
+-----------+ +-----------+
Figure. 1 Network system
2.1 Multicast Translator
It locates between an IPv4 land and an IPv6 land, and translates
IPv4 multicast packets into IPv6 multicast packets and vice versa.
It consists of the following three sub-components.
(1) Translator
It is a component which translates IPv4 multicast packets into
IPv6 multicast packets and vice versa. There are several trans-
lation types.
Tsuchiya draft-ietf-ngtrans-mtp-03.txt [Page 3]
INTERNET-DRAFT Expires in six month October 2002
o Gateway
It terminates data bound for an IPv4 multicast group at
application layer, and relays the data to an IPv6 multicast
group and vice versa.
o Header conversion router
When receiving IPv4 multicast packets, it converts the IPv4
headers into IPv6 headers, fragments the IPv6 packets if nec-
essary, and then forwards the packets. Likewise, when receiv-
ing IPv6 multicast packets, it converts the IPv6 headers into
IPv4 headers, and then forwards the IPv4 packets.
(2) IPv4 Multicast Proxy
It joins IPv4 multicast groups as a proxy of IPv6 receiver
nodes. Thereby it receives packets bound for the IPv4 multicast
groups, and then hands the packets to the translator.
(3) IPv6 Multicast Proxy
It joins IPv6 multicast groups as a proxy of IPv4 receiver
nodes. Thereby it receives packets bound for the IPv6 multicast
groups, and then hands the packets to the translator.
2.2 Address mapper
It maintains each unicast address spool for IPv4 and IPv6. The IPv4
spool, for example, consists of private addresses [PRIVATE] bound
for the multicast translator. An example of the IPv6 spool is IPv6
address space assigned to virtual IPv6 organization on the IPv4
land.
NOTE: The IPv4 spool is used for temporary IPv4 addresses of IPv6
sender nodes (or IPv6 receiver nodes) in the IPv4 land. Also the
IPv6 spool is used for temporary IPv6 addresses of IPv4 sender
nodes (or IPv4 receiver nodes) in the IPv6 land. So the mtp should
advertise IPv4/IPv6 unicast routes for them so that packets to them
can be delivered to the mtp and also RPF check (RPF: Reverse Path
Forwarding) can work well.
Tsuchiya draft-ietf-ngtrans-mtp-03.txt [Page 4]
INTERNET-DRAFT Expires in six month October 2002
Also, it maintains a mapping table which consists of pairs of an
IPv4 address and an IPv6 address. When the translator (or the IPv4
Proxy or the IPv6 Proxy) requests it to assign an IPv6 address cor-
responding to an IPv4 address (an IPv4 source address), it selects
a proper IPv6 address out of the table, and returns the address to
the translator. When there is not a proper entry for an IPv4 uni-
cast address, it selects and returns an IPv6 unicast address out of
the spool, and registers a new entry into the table. When there is
not a proper entry for an IPv4 multicast group address (an IPv4
destination address), it registers a new entry, which consists of
the IPv4 multicast group address and that of IPv6 corresponding to
the IPv4 address, into the table. The IPv6 address is a special
type of one proposed in this memo. See section 4.
NOTE: The translator translates packets between IPv4 and IPv6
according to the table. The scheme of the above address mapping is
conformable to NAT-PT; IPv4 addresses are mapped to IPv6 addresses
one to one. In addition, there may be another scheme which follows
NAPT-PT, but in that case there can be a limitation in the system.
For example, if an IPv4 sender node's address is mapped to a single
registered IPv6 address and its TCP/UDP port, then IPv6 receiver
node cannot communicate with the IPv4 sender node in unicast except
via this TCP/UDP port. Because it does not have a mapping table
except for that TCP/UDP port, and the translator would fail in
translating IPv6 into IPv4 in case of the TCP/UDP port.
When the translator (or the IPv4 Proxy or the IPv6 Proxy) requests
it to assign an IPv4 address corresponding to an IPv6 address, it
works like the above.
3. Interaction Examples
This section explains communication from one IPv4 multicast sender
node to one or more IPv6 multicast receiver nodes, and communica-
tion from one IPv6 multicast sender node to one or more IPv4 multi-
cast receiver nodes, respectively.
3.1 Communication from IPv4 to IPv6
The following subsection explains communication from one IPv4 mul-
ticast sender node, called "sender4", to one or more IPv6 multicast
receiver nodes, called "receiver6."
Tsuchiya draft-ietf-ngtrans-mtp-03.txt [Page 5]
INTERNET-DRAFT Expires in six month October 2002
Preceding the communication, the administrator of the multicast
translator carries out the setup to translate IPv4 multicast pack-
ets, which are sent by "sender4", into IPv6. According to the
direction of the administrator, the IPv4 multicast proxy joins the
IPv4 multicast group as a proxy of "receiver6", and then registers
a new entry, which consists of the IPv4 multicast group address and
that of IPv6 corresponding to the IPv4 address, into the mapping
table. The IPv6 address is a special type of one proposed in this
memo, and takes the structure which is identified by a prefix of
ffxy::/96 and holds the IPv4 address in the low-order 32-bits. See
section 4.
NOTE: In order to make MTP applicable to the Source-Specific Multi-
cast(PIM-SSM), MTP needs to show IPv6 addresses corresponding to
IPv4 multicast Senders to an IPv6 Receiver, in addition to IPv6
addresses corresponding to IPv4 multicast addresses available; MTP
can know IPv4 multicast addresses available and their Senders'
addresses as one of IPv4 Receivers. For example, MTP obtains IPv4
multicast addresses available and their Senders' addresses via an
IPv4 SAP(an IPv4 SDR). MTP shows the IPv4 multicast addresses and
the corresponding IPv6 multicast addresses, and the Senders'
addresses and the corresponding IPv6 unicast addresses on its web.
An IPv6 Receiver looks at its web and gets the IPv6 multicast
address and the IPv6 Senders' address.
The communication is triggered by "sender4." "sender4" sends an
IPv4 multicast packet.
When the packet arrives at the multicast translator, the IPv4 mul-
ticast proxy receives it and hands it to the translator. The trans-
lator tries to translate it into an IPv6 packet but does not know
how to translate the IPv4 source address and the IPv4 destination
address. So the translator requests the mapper to tell mapping
entries for them.
The mapper checks its mapping table with each of them and finds
only a mapping entry for the IPv4 destination address.
But there is not a mapping entry for the IPv4 source address, so
the mapper selects an IPv6 address out of the IPv6 spool and regis-
ters a new entry, which consists of the IPv4 address and the IPv6
address, into the mapping table. And then the mapper returns the
IPv6 destination address and the IPv6 source address to the trans-
lator.
Tsuchiya draft-ietf-ngtrans-mtp-03.txt [Page 6]
INTERNET-DRAFT Expires in six month October 2002
After that the translator translates the packet to IPv6, fragments
it if necessary, and forwards it. Note: The translation from the
IPv4 source address to the IPv6 source address is unicast one.
Finally it arrives at "receiver6."
Figure 2 illustrates the interaction communicating from IPv4 to
IPv6.
"sender4" "multicast translator" "address "receiver6"
mapper"
IPv4 translator IPv6
multicast multicast
proxy proxy
| | | | | |
| <------| Sends an "IGMP Membership Report" for joining the
| | IPv4 multicast group. | | |
| | | | | |
| |----------------------------------->| |
| | Registers a entry for the group into the mapping
| | table. | | | |
| | | | | |
| | | | | |
|=========>| Sends an IPv4 multicast packet. | |
| | | | | |
| |===========>| Hands it. | | |
| | | | | |
| | | Request IPv6 addresses corresponding
| | | to the IPv4 addresses.| |
| | |---------------------->| |
| | |<----------------------| |
| | | Reply with the IPv6 addresses. |
| | | | | |
| | | <<Translate IPv4 into IPv6.>> |
| | | | | |
| | | Forwards an IPv6 multicast packet.
| | |=================================>|
| | | | | |
Figure. 2 The interaction communicating from IPv4 to IPv6.
Tsuchiya draft-ietf-ngtrans-mtp-03.txt [Page 7]
INTERNET-DRAFT Expires in six month October 2002
3.2 Communication from IPv6 to IPv4
The following subsection explains communication from one IPv6 mul-
ticast sender node, called "sender6", to one or more IPv4 multicast
receiver nodes, called "receiver4."
Preceding the communication, the administrator of the multicast
translator carries out the setup to translate IPv6 multicast pack-
ets, which are sent by "sender6" to a special type of IPv6 address
proposed in this memo, into IPv4. In the case, the IPv6 multicast
proxy joins the IPv6 multicast group as a proxy of "receiver4", and
then registers a new entry, which consists of the IPv6 multicast
group address and that of IPv4 corresponding to the IPv6 address,
into the mapping table. The IPv4 address is the low-order 32-bits
of the IPv6 address.
Subsequent interaction is symmetric to the case described in Sec-
tion 3.1.
Figure 3 illustrates the interaction communicating from IPv6 to
IPv4.
Tsuchiya draft-ietf-ngtrans-mtp-03.txt [Page 8]
INTERNET-DRAFT Expires in six month October 2002
"receiver4" "multicast translator" "address "sender6"
mapper"
IPv4 translator IPv6
multicast multicast
proxy proxy
| | | | | |
| | | Sends an "MLD Multicast Listener |
| | | Report" for joining the IPv6 multicast
| | | group. | | |
| | | |-----> | |
| | | | | |
| | | |---------->| |
| | | Registers a entry for the group into
| | | the mapping table. | |
| | | | | |
| | | | | |
| | | Sends an IPv6 multicast packet. |
| | | |<=====================|
| | | | | |
| | |<==========| Hands it. | |
| | | | | |
| | | Request IPv4 addresses corresponding
| | | to the IPv6 addresses.| |
| | |---------------------->| |
| | |<----------------------| |
| | | Reply with the IPv4 addresses. |
| | | | | |
| | | <<Translate IPv6 into IPv4.>> |
| | | | | |
|<======================| Forwards an IPv4 multicast packet.
| | | | | |
Figure. 3 The interaction communicating from IPv6 to IPv4.
4. Addressing for IPv4/IPv6 multicast communication
The mechanism uses a special type of an IPv6 address which is
termed an "IPv4-compatible" IPv6 multicast group address. The
address is identified by an prefix for IPv6 multicast (ffxy::/96),
and holds an IPv4 multicast group address in the low-order 32-bits.
Its format is:
Tsuchiya draft-ietf-ngtrans-mtp-03.txt [Page 9]
INTERNET-DRAFT Expires in six month October 2002
| 96-bits | 32-bits |
+--------------------------------------+---------------+
| ffxy:0:0:0:0:0 | IPv4 multicast|
| | group address |
+--------------------------------------+---------------+
The flag (x) is set to 0 when an IPv4 multicast address is a perma-
nently-assigned ("well-known") multicast address by the global-
internet-numbering-authority, otherwise is set to 1. Note: MTP
needs to have a list of "well-known" addresses, and the list must
be configurable by the MTP administrator.
The scope (y) is translated according to the mapping between an
IPv4 multicast prefix and an IPv6 scope value described in RFC2365
[RFC2365].
5. Protocol Translation Details
Protocol Translation Details described in [NAT-PT], including
TCP/UDP/ICMP Checksum Update, are associated to MTP. See [NAT-PT].
Also the influence on RTP/RTCP of a translator investigated in Sec-
tion 7 of RFC1889[RTP] is associated to MTP. See [RTP].
6. Applicability and Limitations
This section considers applicability and limitations.
6.1 Applicability
The multicast translator based on the mechanism locates at the site
boundary between IPv4 and IPv6, and allows them to communicate
directly. Therefore, the mechanism can be useful during a long
term, until IPv4 nodes disappear after IPv6-only nodes appear.
It can be applicable to small-scale network systems, and to the
extent of division networks in intranets where its administrator
can operate the setup easily on demand by receivers.
It cannot be applicable to large-scale network systems like world-
wide Internet as it stands because it needs the setup by its admin-
istrator. In order to apply it to large-scale network systems, it
needs developing a new standard protocol between multicast
Tsuchiya draft-ietf-ngtrans-mtp-03.txt [Page 10]
INTERNET-DRAFT Expires in six month October 2002
translators and receivers for carrying out the setup automatically
on demand by receivers.
In order to apply it to large-scale network systems, it is neces-
sary to automate the setup which the administrator carries out
according to the requests of the receivers. That is, the receivers
directly call on the IPv4 multicast proxy (or the IPv6 multicast
proxy) to join in the group which they want to receive. The inter-
action can be carried out by some protocols. For example, using
http makes it possible to do proper user authentication, and allows
to encrypt the interaction data by security mechanism such as SSL.
But to define a specific protocol for the interaction is out of
scope of this memo.
6.2 Limitations
(1) Applications
In common with [NAT] and [NAT-PT], IP conversion needs to trans-
late IP addresses embedded in application layer protocols. So
MTP needs ALGs for their translation.
(2) Topology
The topology is limited to a tree, and there can be one mtp per
group. If more than one mtps exist per group, receiver nodes may
receive the same packets doubly.
Note that mtp is recognized to be one of IPv4 receiver nodes by
IPv4 sender nodes, and is recognized to be pseudo IPv6 sender
nodes by IPv6 receiver nodes. Also note that mtp is recognized
to be one of IPv6 receiver nodes by IPv6 sender nodes, and is
recognized to be pseudo IPv4 sender nodes by IPv4 receiver
nodes. Since IPv4 multicast domain and IPv6 multicast domain are
completely separated, mtp can be applicable to multicast routing
protocols regardless of Rendezvous Point (RP), i.e. PIM-SM
(using RP) or PIM-DM (not using RP) is applicable.
7. Security considerations
Header conversions of AH [AH] and ESP [ESP] may be cryptographi-
cally impossible in header conversion router approach. It is a big
disadvantage. On the other hand it will be possible to use both AH
and ESP in proxy gateway approach.
Tsuchiya draft-ietf-ngtrans-mtp-03.txt [Page 11]
INTERNET-DRAFT Expires in six month October 2002
8. References
[SIIT] Erik Nordmark, "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[NAT-PT] G. Tsirtsis, P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[IPV4] J. Postel, "Internet Protocol", RFC 791, September 1981.
[NAT] P. Srisuresh and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC3022, January 2001
[IPV6] S. Deering and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[TRANS-MECH] R. Gilligan and E. Nordmark, "Transition Mechanisms
for IPv6 Hosts and Routers", RFC 1933, April 1996.
[PRIVATE] Y. Rekhter, B. Moskowitz, D. Karrenberg,
G. J. de Groot and E. Lear, "Address Allocation for
Private Internets", RFC1918, February 1996.
[RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC1889, January 1996.
[AH] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Protocol (ESP)", RFC 2406, November 1998.
[RFC2365] D. Meyer, "Administratively Scoped IP Multicast",
RFC 2365, July 1998.
9. Acknowledgements
The authors would like to thank the WIDE project and Shinsuke
Suzuki for many helpful suggestions.
Tsuchiya draft-ietf-ngtrans-mtp-03.txt [Page 12]
INTERNET-DRAFT Expires in six month October 2002
10. Authors' Addresses
Kazuaki TSUCHIYA
Enterprise Server Division, Hitachi, Ltd.
1 Horiyamashita, Hatano-shi, Kanagawa-ken, 259-1392 JAPAN
Phone: +81-463-87-6771
Fax: +81-463-87-7341
Email: kazuaki.tsuchiya@itg.hitachi.co.jp
Hidemitsu HIGUCHI
Enterprise Server Division, Hitachi, Ltd.
1 Horiyamashita, Hatano-shi, Kanagawa-ken, 259-1392 JAPAN
Phone: +81-463-87-6771
Fax: +81-463-87-7341
Email: hidemitsu.higuchi@itg.hitachi.co.jp
Sunao SAWADA
System Development Laboratory, Hitachi, Ltd.
1099 Ohzenji, Asao-ku, Kawasaki-shi, Kanagawa-ken, 215-0013 JAPAN
Phone: +81-45-860-3085
Fax: +81-45 860-1674
Email: vsawada@sdl.hitachi.co.jp
Shinji NOZAKI
Enterprise Server Division, Hitachi, Ltd.
1 Horiyamashita, Hatano-shi, Kanagawa-ken, 259-1392 JAPAN
Phone: +81-463-87-6771
Fax: +81-463-87-7341
Email: shinji.nozaki@itg.hitachi.co.jp
11. Changes
This memo has the following changes.
Since draft-ietf-ngtrans-mtp-02.txt:
1) Added a note about application to the Source-Specific Multi-
cast(PIM-SSM) to "3.1 Communication from IPv4 to IPv6."
2) Added the "well-known addresses" list had to be configurable
by the MTP administrator to "4 Addressing for IPv4/IPv6
Tsuchiya draft-ietf-ngtrans-mtp-03.txt [Page 13]
INTERNET-DRAFT Expires in six month October 2002
multicast communication."
3) Added the influence on RTP/RTCP of a translator to "5 Proto-
col Translation Details."
Since draft-ietf-ngtrans-mtp-01.txt:
1) Corrected the flag value, and specified that MTP needs a list
of "well-known" addresses, in "4 Addressing for IPv4/IPv6 multi-
cast communication."
2) Added protocol translation details including TCP/UDP/ICMP
Checksum Update, in "5. Protocol Translation Details."
3) Specified the necessity for ALG in "6.2 (1) Applications."
Since draft-ietf-ngtrans-mtp-00.txt:
1) Added description of temporary address mapping scheme from
the viewpoint of RPF checks and bi-directional communication to
"2.2 Address mapper."
2) Added the correspondence of IPv4 and IPv6 about a scope and a
flag to "4. Addressing for IPv4/IPv6 multicast communication."
3) Added topological issues to "5.2 Limitations."
Since draft-tsuchiya-imp-00.txt:
1) Updated Applicability and Limitations. Extended applicability
to large-scale network systems.
2) Added [AH] and [ESP] to References.
Tsuchiya draft-ietf-ngtrans-mtp-03.txt [Page 14]
