Network Working Group S. Venaas
Internet-Draft UNINETT
Intended status: Informational December 12, 2008
Expires: June 15, 2009
An IPv4 - IPv6 multicast translator
draft-venaas-behave-mcast46-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 15, 2009.
Abstract
This document describes an IPv4 - IPv6 translator device that embeds
all IPv4 multicast group addresses into IPv6, and allows IPv6 hosts
to receive from and send to IPv4 multicast groups.
Venaas Expires June 15, 2009 [Page 1]
Internet-Draft An IPv4 - IPv6 multicast translator December 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Embedding IPv4 multicast group addresses into IPv6 . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Address rewriting . . . . . . . . . . . . . . . . . . . . . . . 5
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. IPv6 host joining a group inside the /96 prefix . . . . . . 5
5.2. IPv6 host sending to group inside the /96 prefix . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Venaas Expires June 15, 2009 [Page 2]
Internet-Draft An IPv4 - IPv6 multicast translator December 2008
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, but
not much work has been done on multicast.
Here we describe a multicast translator solution. This translator
could be placed at the border between IPv6-only and IPv4-only
networks to allow multicast access between them, or it may also be
placed in a dual-stack network, where it can support hosts or other
networks that are IPv6-only or IPv4-only. 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. It should
also allow this for multiple hosts. Multiple IPv4 hosts should be
able to use a single IPv4 group, multiple IPv6 hosts a corresponding
IPv6 group, and all hosts should be able to send to and receive from
all the others. Similar to hosts using the same group from the same
address family. The translator solution should work with no changes
to other infrastructure.
We will define a one-to-one mapping of multicast 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. Some way of translating unicast addresses
is also needed to translate addresses of multicast sources.
2. Embedding IPv4 multicast group addresses into IPv6
We need a way of referring to an IPv4 multicast group using an IPv6
address. One could embed IPv4 multicast addresses into IPv6 by
simply prepending them with a specific /96 IPv6 prefix such that for
each IPv4 multicast address we have a respective IPv6 multicast
address. However, both IPv4 and IPv6 have special ranges for SSM
usage, and one might want to take scoping into account. We suggest
using one specific /96 IPv6 SSM prefix for all IPv4 SSM addresses,
and one specific /96 IPv6 ASM (non-SSM) prefix for all IPv4 ASM (non-
SSM) addresses.
An administrator may choose the exact prefixes used, and depending on
the prefix, also which IPv6 scope. The prefix must be in accordance
Venaas Expires June 15, 2009 [Page 3]
Internet-Draft An IPv4 - IPv6 multicast translator December 2008
with the IPv6 multicast address format defined in section 2.7 of [1].
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. For ASM it may be useful to use an Embedded-RP [2]
prefix based on an IPv6 unicast address of the translator.
The unicast addresses of multicast sources also need to be
translated. We recommend embedding all IPv4 unicast addresses into a
/96 IPv6 prefix. This allows different IPv4 unicast addresses to be
mapped to different IPv6 unicast addresses, and for IPv6 SSM joins to
address specific IPv4 SSM sources. Note that for ASM use, it may be
sufficient to map all IPv4 sources to one single IPv6 address. For
translating IPv6 sources into IPv4 sources, one may use a single
address, or a pool of IPv4 addresses. The same IPv4 address may need
to be re-used for different IPv6 sources. If the translator also
translates unicast packets, then it should use the same unicast
translation mechanism for source addresses in multicast packets. Due
to multicast RPF checks, the IPv4 and IPv6 unicast addresses used
need to be routed towards the translator.
3. Architecture
We propose that the translator makes use of PIM-SM (Sparse Mode) [3]
for IPv6. For ASM it should then be the RP for the /96 IPv6 prefix
used for ASM. This allows the translator to know which IPv4 groups
the IPv6 hosts join, and also to learn of IPv6 sources for those
groups. It is sufficient to support MLD if there are no IPv6 PIM
neighbors (e.g. a single link or MLD proxies).
With respect to the IPv4 network, it may be sufficient to behave as
an IPv4 multicast host. When it receives a PIM or MLD join for a new
IPv6 group corresponding to some IPv4 multicast group, x, it simply
joins the IPv4 multicast group. If it learns of an IPv6 source for
IPv6 group corresponding to some IPv4 multicast group, it will send
the IPv6 packets to the IPv4 group. As an RP, it may receive IPv6
PIM registers, it may then as a regular IPv6 RP, join towards the
source to receive packets natively. If it is an IPv4 host, it will
not know whether there are IPv4 receivers, and hence it must alway do
this.
One can improve on this by making the translator behave as an IPv4
RP, or be an IPv4 PIM router running MSDP to exchange information
about active IPv4 sources. The translator can then use MSDP to
signal its active IPv4 sources (that may be translated IPv6 sources)
so that it will receive PIM joins if there are IPv4 receivers for the
groups. It can also use MSDP to see if there are IPv4 sources for
Venaas Expires June 15, 2009 [Page 4]
Internet-Draft An IPv4 - IPv6 multicast translator December 2008
IPv4 groups that IPv6 hosts have joined.
Note that for SSM this is much simpler with no RP nor MSDP involved.
It may still be an advantage to act as an IPv4 PIM router, in order
to only do translation from IPv6 to IPv4 when there are IPv4
listeners.
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, using different prefixes for SSM
and ASM. Going the other direction, we simply extract the last 32
bits.
For the source addresses we propose a similar mapping from IPv4 to
IPv6, using some /96 unicast prefix. In the other direction we
suggest having a pool of IPv4 addresses (possibly just a single
address) that is used for all IPv6 multicast translated to IPv4. If
unicast traffic is translated, then similar translation should be
used for the multicast source addresses. Note that for RTP the
application can know the real source and tell streams apart, even if
they are translated into the same multicast source address.
One could consider using just a single IPv6 unicast address for all
IPv4 multicast translated into IPv6. For ASM it has the same issues
as using a single IPv4 unicast address for translating into IPv4.
However, for SSM one would like an IPv6 SSM join to uniquely specify
a corresponding IPv4 SSM join. In order to do this, the simplest is
what we propose above with a /96 prefix used for all IPv4 unicast
addresses.
5. Examples
To illustrate how the translator works, we will look at two examples.
In both examples we assume that there is no previous state in the
translator.
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 translator
is the DR for the host, it will receive an MLD membership report. If
Venaas Expires June 15, 2009 [Page 5]
Internet-Draft An IPv4 - IPv6 multicast translator December 2008
not, it will receive a PIM join since it is the RP for the group.
The translator will then get (*, G) state for the group. So far this
is normal PIM behaviour. The translator 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.
For SSM the translator would in addition check if the source in the
join is inside the /96 unicast prefix used. If this is the case, it
then uses the last 32 bits as the IPv4 source. It can then do a
source-specific IPv4 join.
When the translator 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 translator 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 computed using
the /96 unicast prefix. For SSM, the translator would also check
that it got an outgoing interface for the specific source.
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
translator 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 is 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 would be
chosen from a given pool of IPv4 unicast addresses (this may just be
a single fixed address).
If the translator is also an IPv4 PIM router, then we do some further
steps. For ASM, if the translator is an RP and uses MSDP, it should
announce the translated source in MSDP, and only forward translated
packets if it has a join for the group. For SSM, it should only
forward translated packets if it has a join for the specific source
and group.
6. 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.
Venaas Expires June 15, 2009 [Page 6]
Internet-Draft An IPv4 - IPv6 multicast translator December 2008
7. Security Considerations
When using such a translator one needs to take some care of scoping
and TTL values. Due to differences in IPv4 and IPv6 scoping, a
narrow scope might be translated into a wider one.
One may wish to limit who can access the translator. 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 translator implementation could
also offer a way of restricting which groups and sources should be
accepted.
8. Normative References
[1] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[2] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP)
Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[3] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", RFC 4601, August 2006.
Author's Address
Stig Venaas
UNINETT
Trondheim NO-7465
Norway
Email: venaas@uninett.no
Venaas Expires June 15, 2009 [Page 7]
Internet-Draft An IPv4 - IPv6 multicast translator December 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Venaas Expires June 15, 2009 [Page 8]