INTERNET-DRAFT
May 25, 2001
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-00.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 pro-
   gress."

   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-00.txt             [Page 1]


INTERNET-DRAFT           Expires in six month                 May 2001


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
   mapper. In order to allow IPv4 nodes and IPv6 nodes to directly
   communicate 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-00.txt             [Page 2]


INTERNET-DRAFT           Expires in six month                 May 2001


      +-----------+                               +-----------+
      | 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-00.txt             [Page 3]


INTERNET-DRAFT           Expires in six month                 May 2001


      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
         necessary, and then forwards the packets. Likewise, when
         receiving IPv6 multicast packets, it converts the IPv6
         headers into IPv4 headers, and then forwards the IPv4 pack-
         ets.


   (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.

   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
   corresponding to an IPv4 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 unicast 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



Tsuchiya            draft-ietf-ngtrans-mtp-00.txt             [Page 4]


INTERNET-DRAFT           Expires in six month                 May 2001


   IPv4 multicast group address, it registers a new entry, which con-
   sists 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.

   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."

   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
   ffxx::/96 and holds the IPv4 address in the low-order 32-bits. See
   section 4.


   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.



Tsuchiya            draft-ietf-ngtrans-mtp-00.txt             [Page 5]


INTERNET-DRAFT           Expires in six month                 May 2001


   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.

   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.






























Tsuchiya            draft-ietf-ngtrans-mtp-00.txt             [Page 6]


INTERNET-DRAFT           Expires in six month                 May 2001


"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.


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,



Tsuchiya            draft-ietf-ngtrans-mtp-00.txt             [Page 7]


INTERNET-DRAFT           Expires in six month                 May 2001


   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.


"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.





Tsuchiya            draft-ietf-ngtrans-mtp-00.txt             [Page 8]


INTERNET-DRAFT           Expires in six month                 May 2001


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 (ffxx::/96),
   and holds an IPv4 multicast group address in the low-order 32-bits.
   Its format is:

           |              96-bits                 |   32-bits     |
           +--------------------------------------+---------------+
           |           ffxx:0:0:0:0:0             | IPv4 multicast|
           |                                      | group address |
           +--------------------------------------+---------------+


5. Applicability and Limitations

   This section considers applicability and limitations.


5.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
   administrator. In order to apply it to large-scale network systems,
   it needs developing a new standard protocol between multicast
   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
   interaction 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



Tsuchiya            draft-ietf-ngtrans-mtp-00.txt             [Page 9]


INTERNET-DRAFT           Expires in six month                 May 2001


   as SSL. But to define a specific protocol for the interaction is
   out of scope of this memo.


5.2 Limitations

   In common with NAT [NAT], IP conversion needs to translate IP
   addresses embedded in application layer protocols. So it is hard to
   translate all such applications completely.


6. 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.


7. 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] Kjeld Borch Egevang and Paul Francis, "The IP Network Address
         Translator (NAT)", RFC1631, May 1994.

   [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.

   [AH] Kent, S. and R. Atkinson, "IP Authentication Header",
        RFC 2402, November 1998.





Tsuchiya            draft-ietf-ngtrans-mtp-00.txt            [Page 10]


INTERNET-DRAFT           Expires in six month                 May 2001


   [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
         Protocol (ESP)", RFC 2406, November 1998.


8. Acknowledgements

   The authors would like to thank the WIDE project for their many
   helpful suggestions.


9. 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: tsuchiya@kanagawa.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: hhiguchi@kanagawa.hitachi.co.jp

   Sunao SAWADA
   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: susawada@kanagawa.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: nozaki@kanagawa.hitachi.co.jp






Tsuchiya            draft-ietf-ngtrans-mtp-00.txt            [Page 11]


INTERNET-DRAFT           Expires in six month                 May 2001


10. Changes

   This memo has the following changes.

   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-00.txt            [Page 12]