INTERNET-DRAFT November 9, 2001 Expires in six month K. Tsuchiya, Hitachi H. Higuchi, Hitachi Multicast extensions to dual stack hosts using the "Bump-In-the-Stack" Technique (mBIS) 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 This memo describes a mechanism which allows existing hosts to speak in IPv6 multicast using existing IPv4 multicast applications. The hosts can get capability for speaking both in IPv4 multicast and in IPv6 multicast. Tsuchiya draft-tsuchiya-mbis-00.txt [Page 1] INTERNET-DRAFT November 2001 1. Introduction It is highly desirable to make the availability of IPv6 applica- tions increase up to the same level as IPv4 in order to go ahead with the transition from IPv4 to IPv6 smoothly. But this is expected to take a very long time unfortunately. In the especially initial stage of the transition it is hard to provide a complete set of IPv6 applications. Also lots of IPv4 hosts will possibly go on running for its success for a long time even after the transi- tion starts. So BIS [BIS] proposes a mechanism of dual stack hosts using the technique called "Bump-in-the-Stack" in the IP security area. The mechanism allows the existing hosts to communicate with other IPv6 hosts using existing IPv4 unicast applications. This memo describes "multicast extensions to BIS", mBIS. mBIS allows the existing hosts to speak in IPv6 multicast using existing IPv4 multicast applications. The hosts can get capability for speaking both in IPv4 multicast and in IPv6 multicast. This memo uses the words defined in [IPV4], [IPV6], and [MECH]. 2. Components Dual stack hosts defined in RFC2893 [MECH] need applications, TCP/IP modules and addresses for both IPv4 and IPv6. The proposed hosts in this memo have 3 modules instead of IPv6 applications, and communicate with IPv6 multicast groups using existing IPv4 multi- cast applications. They are an IGMP/MLD interpreter, a translator, and an address mapper. Figure 1 illustrates the structure of the host in which they are installed. Tsuchiya draft-tsuchiya-mbis-00.txt [Page 2] INTERNET-DRAFT November 2001 +----------------------------------------------------------+ | +----------------------------------------------------+ | | | IPv4 multicast applications | | | +----------------------------------------------------+ | | +----------------------------------------------------+ | | | TCP/IPv4 | | | | +-------------------------------------------+ | | | | +-----------+ +---------+ +------------+ | | | | | IGMP/MLD | | address | | translator | | | | | |interpreter| | mapper | +------------+ | | | | | | | | +------------+ | | | | | | | | | IPv6 | | | +--------+ +-----------+ +---------+ +------------+ | | +----------------------------------------------------+ | | | Network card drivers | | | +----------------------------------------------------+ | +----------------------------------------------------------+ +----------------------------------------------------------+ | Network cards | +----------------------------------------------------------+ Figure. 1 Structure of the proposed dual stack host 2.1 IGMP/MLD interpreter It interprets IGMP messages sent out from IPv4 multicast applica- tions, creates proper MLD messages, and sends the MLD messages to a network. Also it interprets MLD messages on the network, creates proper IGMP messages, and tosses the IGMP messages to the applica- tions. (1) When the application joins in a group, the application typi- cally sends an IGMP report message. It interprets the message, creates a proper MLD report message for joining in an IPv6 multi- cast group corresponding to the group, and sends the MLD report message to the network. (2) When the application leaves from a group, the application may send an IGMP leave message. It interprets the message, creates a proper MLD done message for leaveing from an IPv6 multicast group corresponding to the group, and sends the MLD done messages to the network. (3) When it interprets a MLD query message on the network, it creates a proper IGMP query message for exploring whether the application is joining in an IPv4 multicast group corresponding to Tsuchiya draft-tsuchiya-mbis-00.txt [Page 3] INTERNET-DRAFT November 2001 the group, and then it tosses the IGMP query message to the appli- cation. (4) When it interprets a MLD report message on the network, it creates a proper IGMP report message for reporting that someone is joining in an IPv4 multicast group corresponding to the group, and then it tosses the IGMP report message to the application. NOTE: The application never sends an IGMP query message, and it also never interprets a MLD done message on the network. See [IGMP] and [MLD]. 2.2 Address mapper It maintains an IPv4 address spool. The spool, for example, con- sists of private addresses [PRIVATE]. Also, it maintains a table which consists of pairs of an IPv4 address and an IPv6 address. The registration occurs in the follow- ing cases; (1) When initializing the table, it registers a pair of its own IPv4 address and IPv6 address into the table statically. (2) According to the host user's request, it registers a pair of an IPv4 address and an IPv6 address into the table statically. This happens when the host user binds an IPv4 multicast address to an IPv6 multicast address which he is to join in. NOTE: In case of unicast, a target host's IPv6 address and a tem- porary IPv4 address can be united dynamically, thanks to DNS. But there is no common mechanism for multicast which is applicable to DNS in unicast. Each multicast application uses a uniquely dif- ferent mechanism for binding a multicast group name with an IP address. So it is hard to bind an IPv4 multicast address to an IPv6 multicast address dynamically. (3) When the translator requests an IPv4 address corresponding to an IPv6 address, it selects and returns an IPv4 address out of the spool, and registers a new entry into the table dynamically. This happens when the translator receives an IPv6 (unicast/multicast) packet and there is not a mapping entry for the IPv6 source address. Tsuchiya draft-tsuchiya-mbis-00.txt [Page 4] INTERNET-DRAFT November 2001 2.3 Translator It translates IPv4 into IPv6 and vice versa using the IP conversion mechanism defined in [SIIT]. When receiving IPv4 multicast packets from the applications, it converts IPv4 packet headers into IPv6 packet headers, then frag- ments the IPv6 packets if necessary (because header length of IPv6 is typically 20 bytes larger than that of IPv4), and sends them to a network. Also when receiving IPv6 multicast packets from the net- works, it works symmetrically to the previous case, except that there is no need to fragment the packets. 3. Action Examples This section describes action of the proposed dual stack host called "dual stack," which communicates with an IPv6 multicast group called "host6" using an IPv4 multicast application. NOTE: "host6" means not one host but a party of belonging to a group. (1) Behavior when joining in a group The user of "dual stack" has to bind an IPv4 multicast address to an IPv6 multicast address of the group in which he is to join, and ask the mapper to register them into the table in advance. When the application joins in a group, the application typically sends an IGMP report message. The message reaches the interpreter. The interpreter tries to create a proper MLD report message for joining in the IPv6 multicast group corresponding to the group, but does not know how to translate the IPv4 source address and the IPv4 destination address (the group address). So the interpreter asks the mapper to provide mapping entries for them. NOTE1: The group address is equal to the IPv4 destination address. The mapper checks its mapping table and finds entries for each of them, and then returns the IPv6 source address and the IPv6 desti- nation address to the interpreter. NOTE2: The mapper registers its own IPv4 address and its own IPv6 address into the table in advance, so the mapper can surely find an entry for the IPv4 source address. See subsection 2.2. Tsuchiya draft-tsuchiya-mbis-00.txt [Page 5] INTERNET-DRAFT November 2001 NOTE3: When the mapper fails in finding an entry for the IPv4 des- tination address, it indicates that the user of "dual stack" would like to join in the IPv4 multicast group as is. In the case the mapper reports failure to the interpreter, and the interpreter sends the IGMP report message to a network as is. There is no need for the IP conversion as shown later. The interpreter creates a proper MLD report message and sends the MLD report message to a network. The following diagram illustrates the action described above; "dual stack" "host6" IPv4 TCP/ IGMP/MLD address translator IPv6 appli- IPv4 inter- mapper cation preter | | | | | | | |=============>| An IGMP report.| | | | | | | | | | | | |-------->| Request IPv6 addresses corresponding | | | | to the IPv4 addresses. | | | | | | | | | | |<--------| Reply with the IPv6 addresses. | | | | | | | | | |<< Create a proper MLD report. >> | | | | | | | | Router | A MLD report.|==========================================>| | | | | | | | Figure. 2 Behavior when joining in a group (2) Behavior when leaving from a group When the application leaves from a group, the application may send an IGMP leave message. The message reaches the interpreter. The interpreter tries to create a proper MLD done message for leaving from the IPv6 multicast group corresponding to the group. The fol- lowing behavior is the same as that described in (1). (3) Behavior when receiving a MLD query message When the interpreter interprets a MLD query message on the network, the interpreter tries to create a proper IGMP query message for exploring whether the application is joining in an IPv4 multicast group corresponding to the group, but does not know how to translate the IPv6 source address and the IPv6 destination address Tsuchiya draft-tsuchiya-mbis-00.txt [Page 6] INTERNET-DRAFT November 2001 (the group address). So the interpreter asks the mapper to provide mapping entries for them. NOTE1: The group address is equal to the IPv6 destination address. The mapper checks its mapping table and finds entries for each of them, and then returns the IPv4 source address and the IPv4 desti- nation address to the interpreter. NOTE2: When the mapper fails in finding an entry for the IPv6 des- tination address, it indicates that "dual stack" is not joining in the group. In the case the mapper reports failure to the inter- preter, and the interpreter discards the MLD report message. NOTE3: When the mapper fails in finding an entry for the IPv6 source address, the mapper selects an IPv4 address out of the spool for it, and registers a new entry into the table. The interpreter creates a proper IGMP query message and tosses it up to the application. The following diagram illustrates the action described above; "dual stack" "host6" IPv4 TCP/ IGMP/MLD address translator IPv6 appli- IPv4 inter- mapper cation preter | | | | | | | Router | A MLD query.|<==========================================| | | | | | | | | | |-------->| Request IPv4 addresses corresponding | | | | to the IPv6 addresses. | | | | | | | | | | |<--------| Reply with the IPv4 addresses. | | | | | | | | | |<< Create a proper IGMP query. >> | |<=============| An IGMP query. | | | | | | | | | | Figure. 3 Behavior when receiving a MLD query message Tsuchiya draft-tsuchiya-mbis-00.txt [Page 7] INTERNET-DRAFT November 2001 (4) Behavior when receiving a MLD report message When the interpreter interprets a MLD report message on the net- work, the interpreter tries to create a proper IGMP report message for reporting that someone is joining an IPv4 multicast group corresponding to the group. The following behavior is the same as that described in (3). (5) Behavior when receiving an IPv6 packet bound for an IPv6 multicast group One of "host6" sends an IPv6 packet bound for the IPv6 multicast group. The IPv6 packet reaches the translator in "dual stack." The translator tries to translate the IPv6 packet into an IPv4 packet, but does not know how to translate the IPv6 source address and the IPv6 destination address. So the translator asks the mapper to provide mapping entries for them. The mapper checks its mapping table and finds entries for each of them, and then returns the IPv4 source address and the IPv4 desti- nation address to the translator. NOTE1: When the mapper fails in finding an entry for the IPv6 des- tination address, it indicates that "dual stack" is not joining in the group. In the case the mapper reports failure to the transla- tor, and the translator discards the IPv6 packet. NOTE2: When the mapper fails in finding an entry for the IPv6 source address, the mapper selects an IPv4 address out of the spool for it, and registers a new entry into the table. The translator translates the IPv6 packet into an IPv4 packet and tosses it up to the application. The following diagram illustrates the action described above; Tsuchiya draft-tsuchiya-mbis-00.txt [Page 8] INTERNET-DRAFT November 2001 "dual stack" "host6" IPv4 TCP/ IGMP/MLD address translator IPv6 appli- IPv4 inter- mapper cation preter | | | | | | | | | | An IPv6 packet.|<==========|=========| | | | | | | | | | | |<------| Request IPv4 addresses | | | | | corresponding to the IPv6 | | | | | addresses. | | | | | | | | | | | |------>| Reply with the IPv4| | | | | | addresses. | | | | | | | | | | | | |<> |<=====|=======|=========|=======| An IPv4 packet. | | | | | | | | Figure. 4 Behavior when receiving an IPv6 packet (6) Behavior when sending an IPv6 packet bound for an IPv6 multicast group The application sends an IPv4 packet bound for the IPv4 multicast group corresponding to the IPv6 multicast group. The IPv4 packet reaches the translator. The translator tries to translate the IPv4 packet into an IPv6 packet, but does not know how to translate the IPv4 source address and the IPv4 destination address. So the translator asks the mapper to provide mapping entries for them. The mapper checks its mapping table and finds entries for each of them, and then returns the IPv6 source address and the IPv6 desti- nation address to the translator. NOTE1: The mapper registers its own IPv4 address and its own IPv6 address into the table in advance, so the mapper can surely find an entry for the IPv4 source address. See subsection 2.2. NOTE2: When the mapper fails in finding an entry for the IPv4 des- tination address, it indicates that the user of "dual stack" would like to send the IPv4 packet to the IPv4 multicast group as is. In the case the mapper reports failure to the translator, and the translator sends the IPv4 packet to the network. There is no need for the IP conversion as shown later. Tsuchiya draft-tsuchiya-mbis-00.txt [Page 9] INTERNET-DRAFT November 2001 The translator translates the IPv4 packet into an IPv6 packet and sends it to the network. Finally the IPv6 packet reaches "host6." The following diagram illustrates the action described above; "dual stack" "host6" IPv4 TCP/ IGMP/MLD address translator IPv6 appli- IPv4 inter- mapper cation preter | | | | | | | |======|=======|=========|======>| An IPv4 packet. | | | | | | | | | | | |<------| Request IPv6 addresses | | | | | corresponding to the IPv4 | | | | | addresses. | | | | | | | | | | | |------>| Reply with the IPv6| | | | | | addresses. | | | | | | | | | | | | |<> | | | An IPv6 packet.|===========|========>| | | | | | | | Figure. 5 Behavior when sending an IPv6 packet 4. Considerations This section considers some issues of the proposed dual stack hosts. 4.1 IP conversion 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. 4.2 IPv4 address spool and mapping table The spool, for example, consists of private addresses [PRIVATE]. So a large address space can be used for the spool. Nonetheless, IPv4 addresses in the spool will be exhausted and cannot be assigned to IPv6 target hosts, if the host communicates with a great number of other IPv6 hosts and the mapper never frees entries registered into the mapping table once. To solve the problem, for example, it is desirable for the mapper to free the oldest entry in the mapping table and re-use the IPv4 address for creating a new entry. Tsuchiya draft-tsuchiya-mbis-00.txt [Page 10] INTERNET-DRAFT November 2001 4.3 Internally assigned IPv4 addresses IPv4 addresses, which are internally assigned to IPv6 target hosts out of the spool, never flow out from the host, and so do not nega- tively affect other hosts. 4.4 Versions of IGMP and MLD IGMP and MLD have several versions. So, when creating a proper IGMP message corresponding to a MLD message, and when creating a proper MLD message corresponding to a IGMP message, it is necessary to give attention to the versions. 5. Applicability and Limitations This section considers applicability and limitations of the pro- posed dual stack hosts. 5.1 Applicability The mechanism can be useful for users in the especially initial stage where some applications not modified into IPv6 remain. And it can also help users who cannot upgrade their applications for some reason after all applications have been modified. The reason is that it allows existing hosts to speak in IPv6 multicast using existing IPv4 multicast applications, and that they can get capa- bility for speaking both in IPv4 multicast and in IPv6 multicast even if they do not have IPv6 multicast applications as a result. Note that it can work in cooperation with a complete IPv6 stack. They can speak in IPv4 unicast or in IPv6 multicast using IPv4 applications via the mechanism. Also they can speak in IPv6 multi- cast using IPv6 applications via the complete IPv6 stack. 5.2 Limitations It allows existing hosts to speak in IPv6 multicast using existing IPv4 applications, but this can not be applied to IPv4 applications which use any IPv4 option since it is impossible to translate IPv4 options into IPv6. Similarly it is impossible to translate any IPv6 option headers into IPv4, except for fragment headers and routing headers. So IPv6 communication having the option headers may be rejected. In common with [NAT], IP conversion needs to translate IP addresses embedded in application layer protocols. So it is hard to translate Tsuchiya draft-tsuchiya-mbis-00.txt [Page 11] INTERNET-DRAFT November 2001 all such applications completely. It may be impossible that the hosts using the mechanism utilize the security above network layer since the data may carry IP addresses. 6. Security considerations This section considers security of the proposed dual stack hosts. The hosts can utilize the security of all layers like ordinary IPv4 communication when they speak in IPv4 multicast using IPv4 applica- tions via the mechanism. Likewise they can utilize the security of all layers like ordinary IPv6 communication when they speak in IPv6 multicast using IPv6 applications via the complete IPv6 stack. How- ever, unfortunately, they can not utilize the security above net- work layer when they speak in IPv6 multicast using IPv4 applica- tions via the mechanism. The reason is that when the protocol data with which IP addresses are embedded is encrypted, or when the pro- tocol data is encrypted using IP addresses as keys, it is impossi- ble for the mechanism to translate the IPv4 data into IPv6 and vice versa. Therefore it is highly desirable to upgrade to the applica- tions modified into IPv6 for utilizing the security at communica- tion with IPv6 hosts. 7. References [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. [PRIVATE] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot and E. Lear, "Address Allocation for Private Internets", RFC1918, February 1996. [MECH] R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [IGMP] W. Fenner, "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [IPV6] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [MLD] S. Deering, W. Fenner, B. Haberman, "Multicast Listener ,br Discovery (MLD) for IPv6", RFC 2710, October 1999. Tsuchiya draft-tsuchiya-mbis-00.txt [Page 12] INTERNET-DRAFT November 2001 [SIIT] Erik Nordmark, "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [BIS] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts using the 'Bump-In-the-Stack' Technique (BIS)", RFC 2767, February 2000. 8. Acknowledgements The authors would like to thank the WIDE project for giving lots of helpful suggestions. 9. Authors' Addresses Kazuaki TSUCHIYA Enterprise Server Division, Hitachi, Ltd. 1 Horiyamashita, Hadano-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, Hadano-shi, Kanagawa-ken, 259-1392 JAPAN Phone: +81-463-87-6771 Fax: +81-463-87-7341 Email: hidemitsu.higuchi@itg.hitachi.co.jp Tsuchiya draft-tsuchiya-mbis-00.txt [Page 13]