(ngtrans) draft-ietf-ngtrans-dual-stack-hosts-00.txt

[Kazuaki Tsuchiya <[e-mail]>]

Hi, ngtrans folks.

I'm very sorry to have kept you waiting. I have just now
submitted the following draft about the IPv6 migration tool
announced last ngtrans meeting in Chicago.

Thanks in advance.

-- Tsuchiya, Hitachi, Ltd.

--------------






INTERNET-DRAFT
November 16, 1998
Expires in six month
                                                  K. Tsuchiya, Hitachi
                                                  H. Higuchi,  Hitachi
                                                  Y. Atarashi, Hitachi



        Dual Stack Hosts using the "Bump-in-the-Stack" Technique

              <draft-ietf-ngtrans-dual-stack-hosts-00.txt>


Status of this Memo

   This document is an Internet-Draft. 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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
   dow Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).


Abstract

   Especially in the early stage of the migration from IPv4 to IPv6,
   it is hard to prepare IPv6 applications completely. This memo pro-
   poses a mechanism of dual stack hosts using the technique called
   "Bump-in-the-Stack" in the IP security area. The mechanism enables
   the hosts to communicate with other IPv6 hosts using IPv4 legacy
   applications.







Tsuchiya      draft-ietf-ngtrans-dual-stack-hosts-00.txt      [Page 1]





INTERNET-DRAFT                                           November 1998


1. Introduction

   RFC1933 [TRANS-MECH] proposed mechanisms to migrate from IPv4
   [IPv4] to IPv6 [IPv6], including dual stack and tunneling, for the
   early stage. Accordingly, hosts and routers are developed for the
   IPv6 migration. But there are few applications for IPv6 compared to
   IPv4, where a huge number of applications are available. In order
   to advance the migration to IPv6 smoothly, it is highly desirable
   to increase the availability of IPv6 applications to the same level
   as IPv4. But unfortunately this is expected to take a very long
   time.

   This memo proposes a mechanism of dual stack hosts using the tech-
   nique called "Bump-in-the-Stack" in the IP security area. The tech-
   nique inserts modules into the hosts which snoop data that flows
   between a TCP/IPv4 module and network card driver modules, and
   translate IPv4 into IPv6 and vice versa. It enables the hosts to
   communicate with other IPv6 hosts using IPv4 legacy applications;
   thus making it seem as if the hosts have applications for both IPv4
   and IPv6.

   This document uses the words defined in [IPV4], [IPV6], and
   [TRANS-MECH].


2. Components

   Dual stack hosts defined in RFC1933 [TRANS-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 other IPv6 hosts using IPv4 applications. The 3
   modules are a translator, an extension name resolver and an address
   mapper.

   Figure 1 illustrates a host which has the 3 modules described above
   installed.













Tsuchiya      draft-ietf-ngtrans-dual-stack-hosts-00.txt      [Page 2]





INTERNET-DRAFT                                           November 1998


   The proposed dual stack host
   +----------------------------------------------------------+
   |  +----------------------------------------------------+  |
   |  | IPv4 applications                                  |  |
   |  +----------------------------------------------------+  |
   |  +----------------------------------------------------+  |
   |  | TCP/IPv4                                           |  |
   |  |        +-------------------------------------------+  |
   |  |        |  +-----------+  +---------+  +------------+  |
   |  |        |  | extension |  | address |  | translator |  |
   |  |        |  | name      |  | mapper  |  +------------+  |
   |  |        |  | resolver  |  |         |  +------------+  |
   |  |        |  |           |  |         |  | IPv6       |  |
   |  +--------+  +-----------+  +---------+  +------------+  |
   |  +----------------------------------------------------+  |
   |  | Network card drivers                               |  |
   |  +----------------------------------------------------+  |
   +----------------------------------------------------------+
   +----------------------------------------------------------+
   |    Network cards                                         |
   +----------------------------------------------------------+
   Figure 1


2.1 Translator

   The translator translates IPv4 into IPv6 and vice versa using the
   IP conversion mechanism defined in [SIIT].

   When receiving IPv4 packets from IPv4 applications, the translator
   converts IPv4 packet headers into IPv6 packet headers, then frag-
   ments the IPv6 packets (because header length of IPv6 is typically
   20 bytes larger than that of IPv4), and sends them to IPv6 net-
   works. When receiving IPv6 packets from the IPv6 networks, it works
   symmetrically to the previous case, except that there is no need to
   fragment the packets.


2.2 Extension Name Resolver

   The extension name resolver returns a "proper" answer in response
   to the IPv4 application's request.

   The application typically sends a query to its name server to
   resolve 'A' records for the target host name. The translator snoops
   the query, then creates another query to resolve both 'A'  and



Tsuchiya      draft-ietf-ngtrans-dual-stack-hosts-00.txt      [Page 3]





INTERNET-DRAFT                                           November 1998


   'AAAA' records for the host name, and sends the query to the
   server. If the 'A' record is resolved, it returns the 'A' record to
   the application. In this case, there is no need for translation by
   the translator above. If only the 'AAAA' record is available, it
   requests the mapper to assign an IPv4 address corresponding to the
   IPv6 address. Then it creates the 'A' record for the assigned IPv4
   address and returns the 'A' record to the application.


2.3 Address mapper

   The address mapper maintains an IPv4 address spool. The spool, for
   example, consists of private addresses [PRIVATE]. Also, it main-
   tains pairs consisting of an IPv4 address and an IPv6 address in a
   table.

   When the resolver or the translator requests the mapper to assign
   an IPv4 address for an IPv6 address, it selects and returns an IPv4
   address out of the spool, and then registers a new entry into the
   table dynamically. The registration occurs in the following 2
   cases:

   (1) When the resolver gets only an 'AAAA' record for the target
   host name and there is not a mapping entry for the IPv6 address.

   (2) When the translator receives an IPv6 packet and there is not a
   mapping entry for the IPv6 source address.

   NOTE: There is one exception to above. When initializing the table,
   it registers a pair of its own IPv4 address and IPv6 address into
   the table statically.



3. Action Examples

   This section describes action of the proposed dual stack host
   called "dual stack," which communicates with an IPv6 host called
   "host6" using an IPv4 application.


3.1 Originator behavior

   This subsection describes the originator behavior of "dual stack."
   The communication is triggered by "dual stack."




Tsuchiya      draft-ietf-ngtrans-dual-stack-hosts-00.txt      [Page 4]





INTERNET-DRAFT                                           November 1998


   The application sends a query to its name server to resolve 'A'
   records for "host6."

   The resolver snoops the query, and then creates another query to
   resolve both 'A' and 'AAAA' records for the host name and sends it
   to the server. In the case, only the 'AAAA' record is resolved, so
   the resolver requests the mapper to assign an IPv4 address
   corresponding to the IPv6 address.

   NOTE: In the case of communication with an IPv4 host, the 'A'
   record is resolved. The resolver then returns it to the applica-
   tion, and there is no need for translation as follows.

   The mapper selects an IPv4 address out of the spool and returns it
   to the resolver.

   The resolver creates the 'A' record for the assigned IPv4 address
   and returns it to the application.

   NOTE: See subsection 4.3 about influence on other hosts caused by
   the assigned IPv4 address.




   The application sends an IPv4 packet to "host6."

   The IPv4 packet reaches the translator. The translator tries
   translating the IPv4 packet into an IPv6 packet but does not know
   how to translate the IPv4 destination address and the IPv4 source
   address. So the translator requests 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 destination address and the IPv6
   source address to the translator.

   NOTE: The mapper will register its own IPv4 address and IPv6
   address into the table beforehand. See subsection 2.3.

   The translator translates the IPv4 packet into an IPv6 packet then
   fragments the IPv6 packet if necessary and sends it to an IPv6 net-
   work.

   The IPv6 packet reaches "host6." Then "host6" sends a new IPv6
   packet to "dual stack."



Tsuchiya      draft-ietf-ngtrans-dual-stack-hosts-00.txt      [Page 5]





INTERNET-DRAFT                                           November 1998


   The IPv6 packet reaches the translator of "dual stack." The trans-
   lator gets mapping entries for the IPv6 destination address and the
   IPv6 source address from the mapper in the same way as before. Then
   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:




   "dual stack"                                        "host6"
   IPv4    TCP/  extension  address  translator  IPv6
   appli-  IPv4  name       mapper
   cation        resolver
     |      |       |         |       |           |      |
   <<Resolve an IPv4 address for "host6.">>       |      |
     |      |       |         |       |           |      |
     |------|------>|  Query of 'A' records for "host6." |    Name
     |      |       |         |       |           |      |    Server
     |      |       |---------|-------|-----------|------|------>|
     |      |       |  Query of 'A' and 'AAAA' records for "host6."
     |      |       |         |       |           |      |       |
     |      |       |<--------|-------|-----------|------|-------|
     |      |       |  Reply only with the 'AAAA' record.|
     |      |       |         |       |           |      |
     |      |       |<<Only the 'AAAA' record is resolved.>>
     |      |       |         |       |           |      |
     |      |       |-------->|  Request an IPv4 address |
     |      |       |         |  corresponding to the IPv6 address.
     |      |       |         |       |           |      |
     |      |       |         |<<Assign an IPv4 address.>>
     |      |       |         |       |           |      |
     |      |       |<--------|  Reply with the IPv4 address.
     |      |       |         |       |           |      |
     |      |       |<<Create the 'A' record for the IPv4 address.>>
     |      |       |         |       |           |      |
     |<-----|-------|  Reply with the 'A' record. |      |
     |      |       |         |       |           |      |
   Figure 2(1/2)








Tsuchiya      draft-ietf-ngtrans-dual-stack-hosts-00.txt      [Page 6]





INTERNET-DRAFT                                           November 1998


   "dual stack"                                        "host6"
   IPv4    TCP/  extension  address  translator  IPv6
   appli-  IPv4  name       mapper
   cation        resolver
     |      |       |         |       |           |      |
   <<Send an IPv4 packet to "host6.">>|           |      |
     |      |       |         |       |           |      |
     |======|=======|=========|======>|  An IPv4 packet. |
     |      |       |         |       |           |      |
     |      |       |         |<------|  Request IPv6 addresses
     |      |       |         |       |  corresponding to the IPv4
     |      |       |         |       |  addresses.      |
     |      |       |         |       |           |      |
     |      |       |         |------>|  Reply with the IPv6
     |      |       |         |       |  addresses.
     |      |       |         |       |           |      |
     |      |       |         |       |<<Translate IPv4 into IPv6.>>
     |      |       |         |       |           |      |
     |      |       |An IPv6 packet.  |===========|=====>|
     |      |       |         |       |           |      |
     |      |       |         |     <<Reply an IPv6 packet to
     |      |       |         |       "dual stack.">>    |
     |      |       |         |       |           |      |
     |      |       |An IPv6 packet.  |<==========|======|
     |      |       |         |       |           |      |
     |      |       |         |       |<<Translate IPv6 into IPv4.>>
     |      |       |         |       |           |      |
     |<=====|=======|=========|=======|  An IPv4 packet. |
     |      |       |         |       |           |      |
   Figure 2(2/2)



3.2 Recipient behavior

   This subsection describes the recipient behavior of "dual stack."
   The communication is triggered by "host6."

   "host6" resolves the 'AAAA' record for "dual stack" through its
   name server, and it then sends an IPv6 packet to the resolved IPv6
   address.

   The IPv6 packet reaches the translator of "dual stack." The trans-
   lator tries translating the IPv6 packet into an IPv4 packet but
   does not know how to translate the IPv6 destination address and the
   IPv6 source address. So the translator requests the mapper to



Tsuchiya      draft-ietf-ngtrans-dual-stack-hosts-00.txt      [Page 7]





INTERNET-DRAFT                                           November 1998


   provide mapping entries for them.

   The mapper checks its mapping table with each of them and finds a
   mapping entry for the IPv6 destination address.

   NOTE: The mapper will register its own IPv4 address and IPv6
   address into the table beforehand. See subsection 2.3.

   But there is not a mapping entry for the IPv6 source address, so
   the mapper selects an IPv4 address out of the spool for it, and
   then returns the IPv4 destination address and the IPv4 source
   address to the translator.

   NOTE: See subsection 4.3 about influence on other hosts caused by
   the assigned IPv4 address.

   The translator translates the IPv6 packet into an IPv4 packet and
   tosses it up to the application.

   The application sends a new IPv4 packet to "host6."

   The following behavior is the same as that described in subsection
   3.1.


   The following diagram illustrates the action described above:























Tsuchiya      draft-ietf-ngtrans-dual-stack-hosts-00.txt      [Page 8]





INTERNET-DRAFT                                           November 1998


   "dual stack"                                        "host6"
   IPv4    TCP/  extension  address  translator  IPv6
   appli-  IPv4  name       mapper
   cation        resolver
     |      |       |         |       |           |      |
   <<Receive an IPv6 packet from "host6.">>       |      |
     |      |       |         |       |           |      |
     |      |       |An IPv6 packet.  |<==========|======|
     |      |       |         |       |           |      |
     |      |       |         |<------|  Request IPv4 addresses
     |      |       |         |       |  corresponding to the IPv6
     |      |       |         |       |  addresses.
     |      |       |         |       |           |      |
     |      |       |         |------>|  Reply with the IPv4
     |      |       |         |       |  addresses.      |
     |      |       |         |       |           |      |
     |      |       |         |       |<<Translate IPv6 into IPv4.>>
     |      |       |         |       |           |      |
     |<=====|=======|=========|=======|  An IPv4 packet. |
     |      |       |         |       |           |      |
   <<Reply an IPv4 packet to "host6.">>           |      |
     |      |       |         |       |           |      |
     |======|=======|=========|======>|  An IPv4 packet. |
     |      |       |         |       |           |      |
     |      |       |         |       |<<Translate IPv4 into IPv6.>>
     |      |       |         |       |           |      |
     |      |       |An IPv6 packet.  |===========|=====>|
     |      |       |         |       |           |      |
   Figure 3



4. Considerations

   This section considers some issues with 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, which are typi-
   cally found in FTP [FTP]. So it is hard to translate all such
   applications completely.





Tsuchiya      draft-ietf-ngtrans-dual-stack-hosts-00.txt      [Page 9]





INTERNET-DRAFT                                           November 1998


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 may be exhausted and cannot be assigned to
   IPv6 target hosts if the host communicates with great many other
   IPv6 hosts and the mapper never frees entries registered into the
   mapping table once. To solve the problem, for example, it is desir-
   able for the mapper to free the oldest entry in the mapping table
   and re-use the IPv4 address for creating a new entry.


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.



5. References

   [SIIT] Erik Nordmark, "Stateless IP/ICMP Translator (SIIT)",
          Inernet-Draft, Work in Progress, November 1998.

   [IPV4] J. Postel, "Internet Protocol", RFC 791, September 1981.

   [FTP] J. Postel, J.K. Reynolds, "File Transfer Protocol", RFC959,
         October 1985.

   [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 1883, January 1996.

   [PRIVATE] Y. Rekhter, B. Moskowitz, D. Karrenberg,
             G. J. de Groot and E. Lear, "Address Allocation for
             Private Internets", RFC1918, February 1996.

   [TRANS-MECH] R. Gilligan and E. Nordmark, "Transition Mechanisms
                for IPv6 Hosts and Routers", RFC 1933, April 1996.

   [BUMP] D.A. Wagner and S.M. Bellovin, "A Bump in the Stack
          Encryptor for MS-DOS Systems", The 1996 Symposium on Network
          and Distributed Systems Security (SNDSS'96) Proceedings.



Tsuchiya      draft-ietf-ngtrans-dual-stack-hosts-00.txt     [Page 10]





INTERNET-DRAFT                                           November 1998


6. Acknowledgments

   The authors gratefully acknowledge the many helpful suggestions of
   the members of the WIDE Project, Kazuhiko YAMAMOTO, Jun MURAI,
   Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO.



7. Author's Addresses

   Kazuaki TSUCHIYA
   Server & Network Development Division, Hitachi, Ltd.
   810 Shimoimaizumi, Ebina-shi, Kanagawa-ken, 243-0435 JAPAN

   Phone: [phone]
   Fax:   [phone]
   Email: [e-mail]


   Hidemitsu HIGUCHI
   Server & Network Development Division, Hitachi, Ltd.
   810 Shimoimaizumi, Ebina-shi, Kanagawa-ken, 243-0435 JAPAN

   Phone: [phone]
   Fax:   [phone]
   Email: [e-mail]


   Yoshifumi ATARASHI
   Server & Network Development Division, Hitachi, Ltd.
   810 Shimoimaizumi, Ebina-shi, Kanagawa-ken, 243-0435 JAPAN

   Phone: [phone]
   Fax:   [phone]
   Email: [e-mail]














Tsuchiya      draft-ietf-ngtrans-dual-stack-hosts-00.txt     [Page 11]


--------------------------------------------------------
Kazuaki Tsuchiya (E-mail:[e-mail])
  Hitachi, Ltd.  Server & Network Development Division
    Phone:[phone](ex.2458)   Fax:[phone]