last call for Hitachi's IPv6 over IPv4 Xlator draft for
Experimental RFC forwarding
Bob Fink
rlfink@lbl.gov
Fri, 28 Aug 1998 06:21:48 -0700
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