rfc2767.txt

RFC 的详细文档！

     |      |       |         |       |           |         |
     |      |       |         |       |<<Translate IPv6 into IPv4.>>
     |      |       |         |       |           |         |
     |<=====|=======|=========|=======|  An IPv4 packet.    |
     |      |       |         |       |           |         |

                  Figure 2 Action of the originator (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 then sends an IPv6 packet to the IPv6 address.

   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 destination address and
   the IPv6 source address. So the translator requests the mapper to
   provide mapping entries for them.





Tsuchiya, et al.             Informational                      [Page 7]

RFC 2767               Dual Stack Hosts using BIS          February 2000


   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 the influence on other hosts caused by
   an IPv4 address assigned here.

   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.






























Tsuchiya, et al.             Informational                      [Page 8]

RFC 2767               Dual Stack Hosts using BIS          February 2000


   The following diagram illustrates the action described above:

   "dual stack"                                           "host6"
   IPv4    TCP/  extension  address  translator  IPv6
   appli-  IPv4  name       mapper
   cation        resolver
     |      |       |         |       |           |         |
   <<Receive data 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 Action of the recipient

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, which are
   typically found in FTP [FTP]. 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



Tsuchiya, et al.             Informational                      [Page 9]

RFC 2767               Dual Stack Hosts using BIS          February 2000


   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.

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
   negatively affect other hosts.

5. Applicability and Limitations

   This section considers applicability and limitations of the proposed
   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 certain applications for
   some reason after all applications have been modified. The reason is
   that it allows hosts to communicate with IPv6 hosts using existing
   IPv4 applications, and that they can get connectivity for both IPv4
   and IPv6 even if they do not have IPv6 applications as a result.

   Note that it can also work in conjunction with a complete IPv6 stack.
   They can communicate with both IPv4 hosts and IPv6 hosts using IPv4
   applications via the mechanism, and can also communicate with IPv6
   hosts using IPv6 applications via the complete IPv6 stack.

5.2 Limitations

   The mechanism is valid only for unicast communication, but invalid
   for multicast communication. Multicast communication needs another
   mechanism.

   It allows hosts to communicate with IPv6 hosts 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 inbound communication having the option headers may be
   rejected.





Tsuchiya, et al.             Informational                     [Page 10]

RFC 2767               Dual Stack Hosts using BIS          February 2000


   In common with NAT [NAT], IP conversion needs to translate IP
   addresses embedded in application layer protocols, which are
   typically found in FTP [FTP]. So it is hard to translate 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.

   Finally it can not combine with secure DNS since the extension name
   resolver can not handle the protocol.

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 communicate with IPv4 hosts using IPv4
   applications via the mechanism. Likewise they can utilize the
   security of all layers like ordinary IPv6 communication when they
   communicate with IPv6 hosts using IPv6 applications via the complete
   IPv6 stack. However, unfortunately, they can not utilize the security
   above network layer when they communicate with IPv6 hosts using IPv4
   applications via the mechanism. The reason is that when the protocol
   data with which IP addresses are embedded is encrypted, or when the
   protocol data is encrypted using IP addresses as keys, it is
   impossible for the mechanism to translate the IPv4 data into IPv6 and
   vice versa. Therefore it is highly desirable to upgrade to the
   applications modified into IPv6 for utilizing the security at
   communication with IPv6 hosts.

7. References

   [SIIT]       Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC
                2765, February 2000.

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

   [FTP]        Postel, J. and J. Reynolds, "File Transfer Protocol",
                STD 9, RFC 959, October 1985.

   [NAT]        Kjeld B. and P. Francis, "The IP Network Address
                Translator (NAT)", RFC 1631, May 1994.

   [IPV6]       Deering, S. and R. Hinden, "Internet Protocol, Version 6
                (IPv6) Specification", RFC 2460, December 1998.





Tsuchiya, et al.             Informational                     [Page 11]

RFC 2767               Dual Stack Hosts using BIS          February 2000


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

   [TRANS-MECH] Gilligan, R. 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.

   [NAT-PT]     Tsirtsis, G. and P. Srisuresh, "Network Address
                Translation - Protocol Translation (NAT-PT)", RFC 2766,
                February 2000.

8. Acknowledgements

   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, at large.

9. Authors' Addresses

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

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

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

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

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

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




Tsuchiya, et al.             Informational                     [Page 12]

RFC 2767               Dual Stack Hosts using BIS          February 2000


10.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Tsuchiya, et al.             Informational                     [Page 13]