(ngtrans) last call for Hitachi's IPv6 over IPv4 Xlator
draft forExperimental RFC forwarding
Bob Fink
rlfink@lbl.gov
Mon, 31 Aug 1998 09:38:49 -0700
Regarding my "last call" for the Hitachi translator work, Kazuaki Tsuchiya has decided to split the draft up, so we will wait till he forwards the new one(s) before any more review.
Bob
=====
>Sorry, Bob.
>I'd like to follow your advice if I can do.
>But I want to divide into another draft about the IPv6 tool
>announced in this ngtrans-wg.
>
>Would you please give me for a while?
>I will try to write another draft about of the IPv6 tool.
>And I'd like to make the draft an Experimental RFC.
>
>
>Regards,
>-Kazuaki Tsuchiya, Hitachi,Ltd.
>
>
>
>At 06:21 98/08/28 -0700, you wrote:
>> ngtrans,
>>
>> The following I-D by Kazuaki Tsuchiya and others of Hitachi and WIDE has
>been presented in the past and now has an experimental implementation
>available (announced at this week's ngtrans meeting in Chicago). Thus I
>want us to ready this for being submitted for Experimental RFC status, so
>this is the equivalent of last call before forwarding to the IESG.
>>
>> Please send your comments to the ngtrans list by 11 September.
>>
>> For your refernce, I have included the RFC 2026 "Internet Standards
>Process" information on Experimental status:
>>
>> >4.2.1 Experimental
>> > The "Experimental" designation typically denotes a specification that
>> > is part of some research or development effort. Such a specification
>> > is published for the general information of the Internet technical
>> > community and as an archival record of the work, subject only to
>> > editorial considerations and to verification that there has been
>> > adequate coordination with the standards process (see below). An
>> > Experimental specification may be the output of an organized Internet
>> > research effort (e.g., a Research Group of the IRTF), an IETF Working
>> > Group, or it may be an individual contribution.
>>
>>
>> Thanks,
>>
>> Bob
>> _____________________________________cut here___________________________
>> INTERNET-DRAFT K. Tsuchiya, Hitachi
>> M. Sumikawa, Hitachi
>> Expires in six month K. Watanabe, Hitachi
>> Y. Atarashi, Hitachi
>> T. Miyamoto, Hitachi
>> K. Yamamoto, IIJ
>> J. Murai, Keio University
>>
>>
>> A Communication Mechanism between IPv4 and IPv6
>>
>> <draft-ietf-ngtrans-ipv4-ipv6-xlator-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 documents
>> at any time. It is inappropriate to use Internet-Drafts as
>> reference material or to cite them other than as ``work in
>> progress.''
>>
>> To learn the current status of any Internet-Draft, please check the
>> ``1id-abstracts.txt'' listing contained in the Internet-Drafts
>> Shadow 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
>>
>> In the late stage of the transition from IPv4 to IPv6, IPv4 lands
>> are interconnected by IPv6 ocean and it is necessary for an IPv4
>> node and an IPv6 to communicate directly. This memo proposes a
>> mechanism to enable such direct communication with extension name
>> servers, an address mapper, and translators for each IPv4 land.
>>
>>
>> 1. Introduction
>>
>> RFC1933 [TRANS-MECH] proposed mechanisms to transit IPv4 [IPv4] to
>> IPv6 [IPv6], including dual stack and tunneling, for the early
>> stage. IPv6 nodes are assumed to have IPv4 stack and IPv4 addresses.
>> In the late stage of the transition, however, the space of IPv4
>>
>>
>>
>> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 1]
>> INTERNET-DRAFT August 1998
>>
>>
>> address will be exhausted. So, an IPv4 address cannot be assigned to
>> dual-stack hosts. Moreover, IPv6-only hosts will appear for cost
>> reasons. It is expected that IPv4 hosts will retain for a long time,
>> even after appearance of IPv6-only hosts. Therefore, it is highly
>> desired to develop a mechanism to enable a communication between an
>> IPv4 host and an IPv6 host directly.
>>
>> Though a header conversion mechanism is defined in [HDRCNV],
>> interaction for an IPv4 host, an IPv6 host, a header conversion
>> router, and name servers is not mentioned. This memo describes an
>> entire scheme of direct communications between IPv4 hosts and IPv6
>> hosts. The scheme is applicable to environments where there are
>> multiple name servers and multiple site boundary routes thanks to
>> one "address mapper". It is not necessary to modify IPv4 hosts and
>> IPv6 hosts.
>>
>> This document uses the words defined in [IPV4], [IPV6], and
>> [TRANS-MECH].
>>
>> 2. Components
>>
>> In the late stage of the transition, IPv4 "land"s are interconnected
>> by IPv6 "ocean". A set of IPv4-only nodes in an organization is an
>> example of IPv6 island.
>>
>> The proposed system consists of extension name servers, one address
>> mapper, and translators. To implement communication between IPv4
>> nodes and IPv6 nodes, each IPv4 island needs to install such
>> components.
>>
>> Extension name servers have both IPv4 stack and IPv6 stack and
>> provides name service to IPv4 nodes and IPv6 nodes. Translators also
>> have dual-stack functionality and translates "language" of IPv4
>> nodes and that of IPv6 nodes. The address mapper is communicates
>> only with the extension name servers and the translators.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 2]
>> INTERNET-DRAFT August 1998
>>
>>
>> Figure 1 illustrates an IPv4 land which installed the proposed
>> system.
>>
>> +---------+ +-------- //
>> |IPv4 node| |
>> +----+----+ |
>> | |
>> +------+------+ |
>> | | |
>> |An IPv4 land | | IPv6 ocean
>> | | |
>> | | +------------------------+ | +---------+
>> | +--+ extension name servers +--+ |IPv6 node|
>> | | +------------+-----------+ | +---------+
>> | | | |
>> | | +------------+-----------+ | +---------+
>>
>> | | | one address mapper | | |IPv6 node|
>> | | +------------+-----------+ | +---------+
>> | | | |
>> | | +------------+-----------+ | +---------+
>> | +--+ translators +--+ |IPv6 node|
>> | | +------------------------+ | +---------+
>> | | |
>> +------+------+ |
>> | |
>> +----+----+ |
>> |IPv4 node| +-------- //
>> +---------+
>>
>> Figure 1
>>
>>
>> 2.1 Translator between IPv4 and IPv6
>>
>> The followings are examples of Translator between IPv4 and IPv6.
>>
>> (1) Proxy gateway
>>
>> An proxy gateway locates between an IPv4 host and an IPv6 host
>> and establishes both an IPv4 connection to the IPv4 host and an
>> IPv6 connection to the IPv6 host. The proxy gateway relays data
>> from the IPv4 host to the IPv6 host and vice versa.
>>
>> (2) Header conversion router
>>
>> A header conversion router locates between an IPv4 host and an
>>
>>
>>
>> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 3]
>> INTERNET-DRAFT August 1998
>>
>>
>> IPv6 host. When the router receives an IPv4 packet, the router
>> converts its IPv4 header to an IPv6 header then forwards it.
>> When the router receives an IPv6 packet, the router converts its
>> IPv6 header to an IPv4 header then fragments the packet if
>> necessary and forwards it.
>>
>> 2.2 Extension Name Server
>>
>> Extension name servers returns a "proper" answer in a response to
>> IPv4 node's request or IPv6 node's request.
>>
>> An IPv4 node typically requests one of extension name servers to
>> resolve 'A' record correspond to a host name. If 'A' record is
>> resolved, the server returns it. If only 'AAAA' record is available,
>> the server requests an address mapper to assign one IPv4 address
>> correspond to its IPv6 address. Then the server returns the assigned
>> IPv4 address to the IPv4 node.
>>
>> An IPv6 node typically requests one of extension name servers to
>> resolve 'AAAA' record correspond to a host name. If 'AAAA' record is
>> resolved, the server returns it. If only 'A' record is available,
>> the server requests the address mapper to assign one IPv6 address
>> correspond to its IPv4 address. Then the server returns the assigned
>> IPv6 address to IPv6 node.
>>
>> 2.3 Address Mapper
>>
>> An address mapper maintains an IPv4 address spool and an IPv6
>> address spool. An example of the IPv4 address spool is private
>> addresses(e.g number 10). An example of the IPv6 address spool is a
>> part of IPv6 space assigned to the organization where the IPv4 land
>> locates inside.
>>
>> When an extension name server or a translator requests one IPv6
>> address for an IPv4 address, the address mapper selects one IPv6
>> address from the IPv6 address spool and returns it.
>>
>>
>> When an extension name server or a translator requests one IPv4
>> address for an IPv6 address, the address mapper selects one IPv4
>> address from the IPv4 address spool and returns it.
>>
>> 3. Interaction Examples
>>
>> The following subsection explains communication from an IPv4 node to
>> an IPv6 node and communication from an IPv6 node to an IPv4 node,
>> respectively.
>>
>>
>>
>> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 4]
>> INTERNET-DRAFT August 1998
>>
>>
>> 3.1 Communication from an IPv4 node to an IPv6 node
>>
>> This subsection describes communication between an IPv4 node called
>> "host4" and an IPv6 node called "host6". The communication is
>> triggered by "host4".
>>
>> "host4" sends a query to an extension name server to resolves 'A'
>> record for "host6".
>>
>> The extension name server tries resolving both 'A' record and 'AAAA'
>> record for "host6" but only 'AAAA' record is resolved. Then the
>> server requests an address mapper to assign one IPv4 address
>> correspond to the IPv6 address.
>>
>> The address mapper selects one IPv4 address out of its IPv4 address
>> spool and returns it to the server.
>>
>> The server creates 'A' record for the assigned IPv4 address and
>> returns it to "host4".
>>
>> "host4" sends IPv4 data to "host6".
>>
>> The IPv4 data reaches a translator. The translator tries translating
>> the IPv4 data to IPv6 data but does not know how to translate. (For
>> example, a proxy gateway cannot create an IPv6 connection to "host6"
>> since the IPv6 address of "host6" is not available.) So, the
>> translator requests the mapper to tell mapping entries for the IPv4
>> source address and the IPv4 destination address.
>>
>> The mapper looks up its mapping table with the IPv4 destination
>> address and finds one IPv6 address for it. Then the mapper looks up
>> its mapping table with the IPv4 source address. In this case, there
>> is not a mapping entry so the mapper selects one IPv6 address for
>> the IPv4 source address. Finally, the mapper returns a pair of the
>> IPv6 source address and the IPv6 destination address to the
>> translator.
>>
>> The translator translates the IPv4 data to IPv6 data. (For example,
>> the proxy gateway creates one IPv6 connection to "host6" and relay
>> the IPv4 data.)
>>
>> The IPv6 data reaches "host6". "host6" sends new IPv6 data to
>> "host4".
>>
>> The IPv6 data reaches the translator. This time the translator has
>> mapping entries for the IPv6 source address and the IPv6 destination
>>
>>
>>
>> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 5]
>> INTERNET-DRAFT August 1998
>>
>>
>> address. The translator translates the IPv6 data to IPv4 data. (For
>> example, the proxy gateway just relays the data.)
>>
>> The IPv4 data reaches "host4".
>>
>> The following diagram illustrates the interaction above:
>>
>>
>> IPv4 extension address translator IPv6
>> node name server mapper node
>> "host4" "host6"
>>
>>
>> Resolve an IPv4 address for host6
>>
>> ---> Query of 'A' record for "host6".
>>
>> only 'AAAA' record is resolved.
>>
>> ---> Request one IPv4 address correspond to
>> the IPv6 address.
>>
>> Assign on IPv4 address.
>>
>> <--- Reply with the IPv4 address.
>>
>> Create 'A' record for the IPv4 address.
>>
>> <--- Reply with the 'A' record.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 6]
>> INTERNET-DRAFT August 1998
>>
>>
>> IPv4 extension address translator IPv6
>> node name server mapper node
>> "host4" "host6"
>>
>> Send data to host6
>>
>> =============================> IPv4 data
>>
>> Try translating but don't
>> know how to translate it.
>>
>> <--- Request IPv6 addresses
>> corresond to the IPv4 source
>> address and to the IPv4
>> destination address.
>>
>> One IPv6 address correspond to the IPv4
>> destination address is already
>> available. Assign one IPv6 address for
>> the IPv4 source address.
>>
>> ---> Reply with the IPv6 source
>> address and the IPv6
>> destination address.
>>
>> Translate IPv4 to IPv6.
>>
>> ===> IPv6 data
>>
>> Reply data to
>> host4
>>
>> <=== IPv6 data
>>
>> Translate IPv6 to IPv4
>>
>> <============================== IPv6 data
>>
>>
>> 3.2 Communication from an IPv6 node to an IPv4 node
>>
>> In a case where communication is triggered by "host6", its query to
>> resolve 'AAAA' record for "host4" is eventually delivered to one of
>> extension name servers. After interaction is symmetric to the case
>> described in Sention 3.1.
>>
>>
>>
>>
>> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 7]
>> INTERNET-DRAFT August 1998
>>
>>
>> 4. Security Consideration
>>
>> Header conversions of AH [AH] and ESP [ESP] are cryptographically
>> impossible. This is a big disadvantage of header conversion router
>> approach. On the other hand, it is possible to use AH and ESP in
>> proxy gateway approach.
>>
>>
>> 5. References
>>
>> [AH] Stephen Kent and Randall Atkinson, "IP Authentication Header",
>> Internet-Draft, July 1997.
>>
>>
>> [ESP] Stephen Kent and Randall Atkinson, "IP Encapsulating Security
>> Payload (ESP)", Internet-Draft, July 1997.
>>
>> [HDRCNV] Erik Nordmark, "IPv4/IPv6 Stateless Header Translator",
>> Inernet-Draft, July 1997.
>>
>> [IPV4] J. Postel, "Internet Protocol", RFC 791, September 1981.
>>
>> [IPV6] S. Deering and R. Hinden, "Internet Protocol, Version 6
>> (IPv6) Specification", RFC 1883, January 1996.
>>
>> [TRANS-MECH] R. Gilligan and E. Nordmark, "Transition Mechanisms for
>> IPv6 Hosts and Routers", RFC 1933, April 1996.
>>
>> 10. Author's Addresses
>>
>> Kazuaki TSUCHIYA
>> Server & Network Development Division, Hitachi, Ltd.
>> 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN
>>
>> Phone: +81-462-32-2111
>> Fax: +81-462-35-8325
>> Email: tsuchi@ebina.hitachi.co.jp
>>
>> Munechika SUMIKAWA
>> Server & Network Development Division, Hitachi, Ltd.
>> 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN
>>
>> Phone: +81-462-35-2111
>> FAX: +81-462-35-8325
>> EMail: sumikawa@ebina.hitachi.co.jp
>>
>>
>>
>>
>>
>> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 8]
>> INTERNET-DRAFT August 1998
>>
>>
>> Ken WATANABE
>> Server & Network Development Division, Hitachi, Ltd.
>> 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN
>>
>> Phone: +81-462-35-2111
>> FAX: +81-462-35-8325
>> Email: nabeken@ebina.hitachi.co.jp
>>
>> Yoshifumi ATARASHI
>> Server & Network Development Division, Hitachi, Ltd.
>> 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN
>>
>> Phone: +81-462-35-2111
>> FAX: +81-462-35-8325
>> EMail: atarashi@ebina.hitachi.co.jp
>>
>> Takahisa MIYAMOTO
>> Server & Network Development Division, Hitachi, Ltd.
>> 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN
>>
>> Phone: +81-462-35-2111
>> FAX: +81-462-35-8325
>> Email: t-miyamo@ebina.hitachi.co.jp
>>
>> Kazu YAMAMOTO
>> Internet Initiative Japan Inc.
>> Takebashi Yasuda Bldg.,3-13, Kanda Nishiki-cho,
>> Chiyoda-ku, Tokyo 101-0054, Japan
>>
>> Phone: +81-3-5259-6000
>> FAX: +81-3-5259-6001
>> EMail: kazu@iijlab.net
>>
>> Jun MURAI
>> Keio University
>> 5322 Endo, Fujisawa 252 JAPAN
>>
>> Phone: +81-466-47-5111
>> Fax: +81-466-49-1101
>> EMail: jun@wide.ad.jp
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 9]
>> -end
>>
>--------------------------------------------------------
>Kazuaki Tsuchiya (E-mail:tsuchi@ebina.hitachi.co.jp)
> Hitachi, Ltd. Server & Network Development Division
> Phone:+81-462-32-2111(ex.5835) Fax:+81-462-35-8337
>