Internet Engineering Task Force S. Venaas
Internet Draft UNINETT
Expiration Date: August 2003
February 2003
An IPv4 - IPv6 multicast gateway
draft-venaas-mboned-v4v6mcastgw-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to 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 documents 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.
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document describes an IPv4 - IPv6 gateway solution that embeds
all IPv4 multicast group addresses into IPv6, and allows IPv6 hosts
to receive from and send to IPv4 multicast groups.
Venaas [Expires August 2003] [Page 1]
Internet Draft draft-venaas-mboned-v4v6mcastgw-00.txt February 2003
Table of Contents
1. Introduction ............................................... 2
2. Embedding IPv4 multicast group addresses into IPv6 ......... 3
3. Architecture ............................................... 3
4. Address rewriting .......................................... 4
5. Examples ................................................... 4
5.1. IPv6 host joining a group inside the /96 prefix ........ 4
5.2. IPv6 host sending to group inside the /96 prefix ....... 5
6. Issues ..................................................... 5
7. Acknowledgments ............................................ 5
8. Security Considerations .................................... 5
9. References ................................................. 6
9.1. Normative References ................................... 6
9.2. Informative References ................................. 6
Author's Address ............................................... 6
Appendix A: Source addressing issues ........................... 6
Appendix B: Possible enhancements .............................. 7
Appendix C: Comparison with MTP ................................ 7
1. Introduction
IPv4 and IPv6 will co-exist for many years, possibly decades. There
are several solutions for how IPv4 and IPv6 hosts and networks can
inter-operate. This is usually easy if a host is dual stack. If
however an IPv6-only host needs to communicate with an IPv4-only
host, then somewhere along the data path there must be some form of
translation. There are several ways of doing this for unicast, while
for multicast the only mechanism known to the author is [MTP].
Here we describe a possible multicast gateway solution. This gateway
could be placed at the border between IPv6-only and IPv4-only
networks to allow multicast access between them. The goal is to give
an IPv6 host full access to send to and receive from any IPv4
multicast group by using the usual IPv6 multicast protocols and
applications which will then operate on the respective IPv6 groups.
The gateway solution can be used with no changes to other
infrastructure.
We will define a one-to-one mapping of IPv4 addresses onto a subset
of the IPv6 multicast addresses. An IPv6 host will then be able to
receive data from any IPv4 multicast group by joining the
corresponding IPv6 group. An IPv6 host can also send, without
necessarily joining, to any IPv4 multicast group by sending to the
corresponding IPv6 group.
Venaas [Expires August 2003] [Page 2]
Internet Draft draft-venaas-mboned-v4v6mcastgw-00.txt February 2003
2. Embedding IPv4 multicast group addresses into IPv6
We need a way of referring to an IPv4 multicast group using an IPv6
address. We do this by embedding IPv4 multicast addresses into IPv6
by prepending them with a specific /96 IPv6 prefix such that for each
IPv4 multicast address we have a respective IPv6 multicast address.
Depending on the prefix they might be of any scope desired.
An administrator deploying a gateway needs to choose a /96 prefix in
accordance with the IPv6 multicast address format defined in section
2.7 of [ADDRARCH].
The addresses used will then be of the form FFxx:<blah>:<IPv4> where
flags, scope and the value of "blah" are chosen by the administrator.
"IPv4" is the last 32 bits specifying the IPv4 address of the IPv4
multicast group. The administrator may choose to use Unicast-Prefix-
based multicast addresses as defined in [UNIPRFXM].
3. Architecture
The gateway makes use of PIM Sparse Mode [PIM-SM]. It is a complete
IPv6 PIM-SM router that also is the RP for the /96 IPv6 prefix. With
respect to the IPv4 network, it behaves as an IPv4 multicast host.
When it receives a PIM join message for a new IPv6 group inside the
/96 prefix, it will join the IPv4 multicast group specified by the
last 32 bits in the address. It should also do this if it gets MLD
listener reports for such groups on links where it is the DR.
When an IPv6 source starts sending, the data will reach the gateway.
If the gateway is the DR for the source, it will receive the packets
natively and resend them as IPv4 multicast provided that the
multicast address is within the /96 prefix, and the last 32 bits form
a valid IPv4 multicast address. If the gateway is not the DR, then it
will receive PIM register messages. Again if the multicast address
fulfills the requirements above, the multicast packets are resent as
IPv4 multicast. When receiving register messages, it may, according
to normal PIM behaviour, join the IPv6 group to receive packets
natively instead. These packets are also resent.
Note that by being the Rendezvous Point, it can keep track of all
IPv6 sources and receive all their data. And it will also know which
groups there are listeners for. It does not however, have knowledge
of IPv4 sources and listeners. A drawback with this, is that it will
resend IPv6 data even if there are no IPv4 listeners, and it will
also join and wait for IPv4 data even if there are no sources.
Venaas [Expires August 2003] [Page 3]
Internet Draft draft-venaas-mboned-v4v6mcastgw-00.txt February 2003
4. Address rewriting
When IPv4 packets are resent as IPv6 we will need to replace the
source and destination addresses with suitable IPv6 addresses. And
similar replacement going from IPv6 to IPv4.
The destination address is easy. That is the multicast address. As
described above, we map IPv4 multicast addresses into IPv6 by
prepending them with a /96-prefix. And going the other direction, we
simply extract the last 32 bits.
For the source address we propose using one fixed IPv4 unicast
address, and one fixed IPv6 unicast address. There are no special
requirements, they might be any unicast addresses assigned to the
router. From the perspective of an IPv6 receiver, the gateway will
look like the source of all data resent from IPv4. Similarly in the
other direction.
5. Examples
To illustrate how the gateway works, we will look at two examples. In
both examples we assume that there are no previous state in the
gateway.
5.1. IPv6 host joining a group inside the /96 prefix
An IPv6 host joins the group FFxx:<blah>:a.b.c.d. If the gateway is
the DR for the host, it will receive an MLD membership report. If
not, it will receive a PIM join since it is the RP for the group. The
gateway will then get (*, G) state for the group. So far this is
normal PIM behaviour. The gateway checks whether the address is
inside the /96 prefix, and whether the last 32 bits (a.b.c.d) is an
IPv4 multicast address. If it is, it joins a.b.c.d using IGMP, and
stays joined as long as it has state for the group.
When the gateway receives a multicast packet for a.b.c.d it prepends
the /96 prefix to form the IPv6 address FFxx:<blah>:a.b.c.d. If the
gateway has outgoing interfaces for this group, it will send an IPv6
packet to the same interfaces to which it would have forwarded an
IPv6 packet for the group. The destination address will be
FFxx:<blah>:a.b.c.d, and the source address will be the fixed IPv6
unicast address used for all resent packets.
Venaas [Expires August 2003] [Page 4]
Internet Draft draft-venaas-mboned-v4v6mcastgw-00.txt February 2003
5.2. IPv6 host sending to group inside the /96 prefix
An IPv6 host sends to the group FFxx:<blah>:a.b.c.d. If the gateway
is the DR for the host, it will receive the data natively. If not, it
will receive PIM register messages containing the data since it's the
RP. For each packet received, either natively or inside register
messages, it will first check that the destination address is inside
the /96 prefix and that the last 32 bits (a.b.c.d) is an IPv4
multicast address. If this is okay, it will resend the packet to the
IPv4 address a.b.c.d. The source address is the fixed IPv4 unicast
address used for all resent packets.
6. Issues
The gateway should work well for most multicast protocols and
applications. Since addresses are rewritten, there might, as with
[NAT-PT], be problems with application protocols carrying IP
addresses though. There might also be issues with using the same IP
source address when resending packets from different sources, see
appendix A.
7. Acknowledgments
The author wishes to thank Michal Przybylski and Pekka Savola for
valuable comments, and also people from the M6Bone community for
testing a prototype implementation.
8. Security Considerations
The gateway as specified in this document does not take scoping into
account. Hence there is a danger that multicast content that is
supposed to be available only in a small scope on one side of the
gateway, becomes available in a larger scope on the other side. The
gateway could possibly try to translate IPv6 scopes into IPv4 ttl
values and vice versa. In order to support multiple scopes one would
then use multiple /96 multicast prefixes.
One may wish to limit who can access the gateway. If for instance one
wishes to restrict it to a site, one can use a /96 prefix of site-
local scope, and then filter at the site border, just like one would
for multicast in general. A gateway implementation could also offer a
way of restricting which groups and sources should be accepted.
Venaas [Expires August 2003] [Page 5]
Internet Draft draft-venaas-mboned-v4v6mcastgw-00.txt February 2003
9. References
9.1. Normative References
[ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[UNIPRFXM] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[PIM-SM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D.,
Deering, S., Handley, M., Jacobson, V., Liu, C.,
Sharma, P. and L. Wei, "Protocol Independent
Multicast-Sparse Mode (PIM-SM): Protocol Specification",
RFC 2362, June 1998.
9.2. Informative References
[MTP] Tsuchiya, K., Higuchi, H., Sawada, S., Nozaki, S.,
"An IPv6/IPv4 Multicast Translator based on IGMP/MLD
Proxying (mtp)", work-in-progress,
draft-ietf-ngtrans-mtp-03.txt, October 2002.
[NAT-PT] Tsirtsis, G., Srisuresh, P., "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
Author's Address
Stig Venaas
UNINETT
Trondheim, Norway
Email: venaas@uninett.no
Appendix A: Source addressing issues
As specified above, we use one fixed IPv4 unicast address and one
fixed IPv6 unicast address for all multicast packets resent by the
gateway. This works fine for common mbone tools like vic and rat. It
may cause problems for some applications though. If there are
multiple sources sending to the same group on one side of the
gateway, an application running on a host on the other side may be
unable to know which packets come from which source.
The idea is that for packets with different source addresses on one
side of the gateway, there should also be different source addresses
on the other side. This can be done by rewriting these unicast
address like one would do for [NAT-PT]. Rewriting IPv4 into IPv6 is
Venaas [Expires August 2003] [Page 6]
Internet Draft draft-venaas-mboned-v4v6mcastgw-00.txt February 2003
simple, we can use the same trick as for multicast and use a /96
prefix. Note that this must be different from the prefix used for
multicast since the first bits are different in unicast and multicast
addresses. Going from IPv6 to IPv4 we have a much bigger problem. We
suggest using a pool of IPv4 addresses being dynamically allocated to
the different IPv6 sources. If the total amount of IPv6 sources is
larger than the number of addresses in the pool, one might reuse
addresses between groups, so that the size of the pool would only
need to be as large as the largest number of sources in each group.
Note that these unicast addresses are only used by the gateway as
source addresses, but they must still have valid routes for PIM with
its RPF checks to work.
Appendix B: Possible enhancements
The main draft documents what we see as a complete working gateway
solution. There are however several enhancements possible.
As specified, the gateway operates as an IPv4 host using IGMP. One
could possibly let the gateway be an IPv4 PIM router. It could then
stop sending IPv4 packets if it receives register stop messages from
the RP. When it receives register stop messages, it could itself
send register stop messages for IPv6 sources.
One could possibly add SSM support. One might consider using SSM to
reach the gateway, and not necessarily let it be an RP. One could
also allow IPv6 hosts to join specific IPv4 sources, by using some
/96 IPv6 unicast prefix to embed IPv4 addresses into IPv6. In the
first case we go from IPv6 SSM to IPv4 ASM. In the second we go from
IPv6 SSM to IPv4 SSM.
Appendix C: Comparison with MTP
The gateway solution described in this draft has some resemblance to
[MTP]. They both try to offer multicast connectivity between
IPv4-only and IPv6-only hosts with some sort of translation device
placed at the border between the IPv4 and IPv6 domains.
The main difference between the two is perhaps that MTP only operates
at the IGMP and MLD level. This solution uses standard PIM and MLD
mechanisms to know which groups to resend, while MTP as specified,
requires an administrator to configure which groups to resend. This
might limit the number of groups that can be resent, and there is a
risk that one keeps resending data when there are no receivers
present. MTP might be used together with some out-of-band mechanism
for the user or application to signal interest, this will however
make the solution less transparent to the users, or require software
modifications.
Venaas [Expires August 2003] [Page 7]