rfc3142.txt

RFC 的详细文档！

   TRT system to translate protocols that are not known to the TRT
   system.

   Normally users do not want to translate DNS query/reply traffic using
   the TRT system.  Instead, it makes more sense to run standard DNS
   server, or special DNS server that helps TRT system, somewhere in the
   site IPv6 network.  There are two reasons to it:

   o  Transport issue - It is a lot easier to provide recursive DNS
      server, accessible via IPv6, than to translate DNS queries/replies
      across the TRT system.  If someone tries to ask TRT to translate
      DNS packets, the person would put C6::X (where C6 is TRT reserved
      prefix and X is an IPv4 address of a DNS server) into
      /etc/resolv.conf.  The configuration is rather complicated than we
      normally want.

   o  Payload issue - In some installation it makes more sense to
      transmit queries/replies unmodified, across the TRT system.  In
      some installation it makes more sense to translate IPv4 DNS
      queries (like queries for AAAA record) into queries for A record,
      and vice versa, to invite traffic into the TRT system.  It depends
      on the installation/configuration at the user's site.





Hagino & Yamamoto            Informational                      [Page 6]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001


7.  Security Considerations

   Malicious party may try to use TRT systems akin to an SMTP open relay
   [Lindberg, 1999] for traffic to IPv4 destinations, which is similar
   to circumventing ingress filtering [Ferguson, 1998] , or to achieve
   some other improper use.  TRT systems should implement some sorts of
   access control to prevent such improper usage.

   A careless TRT implementation may be subject to buffer overflow
   attack, but this kind of issue is implementation dependent and
   outside the scope of this memo.

   Due to the nature of TCP/UDP relaying service, it is not recommended
   to use TRT for protocols that use authentication based on source IP
   address (i.e., rsh/rlogin).

   A transport relay system intercepts TCP connection between two nodes.
   This may not be a legitimate behavior for an IP node.  The document
   does not try to claim it to be legitimate.

   IPsec cannot be used across a relay.

   Use of DNS proxies that modify the RRs will make it impossible for
   the resolver to verify DNSsec signatures.

References

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

   [Postel, 1981.]   Postel, J., "Transmission Control Protocol", STD 7,
                     RFC 793 September 1981.

   [Hain, 2000.]     Hain, T., "Architectural Implications of NAT", RFC
                     2993, November 2000.

   [Yamamoto, 1998]  K. Yamamoto, A. Kato, M Sumikawa, and J. Murai,
                     "Deployment and Experiences of WIDE 6bone", in
                     Proceedings of INET98, 1998.

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








Hagino & Yamamoto            Informational                      [Page 7]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001


   [Lindberg, 1999.] Lindberg, G., "Anti-Spam Recommendations for SMTP
                     MTAs", RFC 2505, February 1999.

   [Ferguson, 1998.] Ferguson, P. and D. Senie, "Network Ingress
                     Filtering: Defeating Denial of Service Attacks
                     which employ IP Source Address Spoofing", RFC 2267,
                     January 1998.












































Hagino & Yamamoto            Informational                      [Page 8]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001


Appendix A. Operational experiences

   WIDE KAME IPv6 stack implements TRT for TCP, called "FAITH".  The
   implementation came from WIDE Hydrangea IPv6 stack, which is one of
   ancestors of the KAME IPv6 stack.

   The FAITH code has been available and operational for more than 5
   years.  The implementation has been used at WIDE research group
   offsite meeting, and IETF ipngwg 1999 Tokyo interim meeting.  At the
   latter occasion, we configured IPv6-only terminal network cluster
   just like we do in IETF meetings, and used a TRT system to support
   more than 100 IPv6 hosts on the meeting network to connect to outside
   IPv4 hosts.  From statistics we gathered SSH, FTP, HTTP, and POP3 are
   the most popular protocol we have relayed.  The implementation was
   also used in the terminal cluster IPv6 network at IETF48, IETF49 and
   IETF50.

   The source code is available as free software, bundled in the KAME
   IPv6 stack kit.

   Special DNS server implementations are available as "newbie" DNS
   server implementation by Yusuke DOI, and "totd" DNS proxy server from
   University of Tromso (Norway).

Acknowledgements

   The authors would like to thank people who were involved in
   implementing KAME FAITH translator code, including Kei-ichi SHIMA and
   Munechika SUMIKAWA.






















Hagino & Yamamoto            Informational                      [Page 9]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001


Authors' Addresses

   Jun-ichiro itojun HAGINO
   Research Laboratory, Internet Initiative Japan Inc.
   Takebashi Yasuda Bldg.,
   3-13 Kanda Nishiki-cho,
   Chiyoda-ku, Tokyo 101-0054, JAPAN

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


   Kazu YAMAMOTO
   Research Laboratory, Internet Initiative Japan Inc.
   Takebashi Yasuda Bldg.,
   3-13 Kanda Nishiki-cho,
   Chiyoda-ku, Tokyo 101-0054, JAPAN

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





























Hagino & Yamamoto            Informational                     [Page 10]

RFC 3142        IPv6-to-IPv4 Transport Relay Translator        June 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.



















Hagino & Yamamoto            Informational                     [Page 11]