Internet Engineering Task Force                                H. Miyata
Internet-Draft                                   Yokogawa Electric Corp.
Intended status: Informational                              May 14, 2007
Expires: October 24, 2008


                   Translator specification approach
                  draft-miyata-v6ops-trans-approach-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   IPv4 address is estimated to run out shortly. So as 
   [I-D.durand-v6ops-natv4v6v4] stated, we have to consider IPv6 only 
   node for smooth transition. On the other hand, IETF have deprecated 
   the NAT-PT with some reasons. And now we need to seek alternative
   solutions. Before talking specific technology, we need to consider
   overall strategy for translation technology.





Miyata                 Expires November 24, 2008                [Page 1]

Internet-Draft      Translator specification approach           May 2008


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  The Devices we have to take care . . . . . . . . . . . . .  . . 3
   3.  Translators in the market . . . . . . . . . . . . . . . . . . . 3
   4.  Translators in the future . . . . . . . . . . . . . . . . . . . 3
   5.  Proposal strategy  . . . . . .. . . . . . . . . . . . . . . . . 4
     5.1.  Current translator model description . . .  . . . . . . . . 4
     5.2.  New translator model specification  . . . . . . . . . . . . 4
     5.3.  Common translation rule . . . . . . . . . . . . . . . . . . 4
     5.4.  Translator unfriendly environment . . . . . . . . . . . . . 4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7































Miyata                 Expires November 24, 2008                [Page 2]

Internet-Draft      Translator specification approach           May 2008


1.  Introduction

   This memo will present an overlooking view on IPv6 deployment and
   some of the necessary technologies to achieve it.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  The Devices we have to take care

   As [I-D.durand-v6ops-natv4v6v4] stated, it is estimated that IPv4
   address exhaustion coming
   sooner, as early as 2010. So, preparation is required by then.
   In that time, there would be IPv4 devices and IPv6 devices. And the 
   IPv6 devices can consist of current type and new type. The new type
   means some devices which can co-exist translator very well(e.g., as
   proposed by [I-D.carpenter-shanti] and 
   [I-D.beijnum-modified-nat-pt]). The current type means some devices
   that does not care about translator(e.g., can not distinguish 
   translated address from native address). Also we could not expect to
   modify current IPv4 devices to adopt the environment using 
   translator.


3.  Translators in the market

   As described in [RFC4966], NAT-PT has some problems. On the other
   hand, there are some translator product in the market. They have 
   already known the problem of NAT-PT and have devised to be useful 
   although there are not well working standard translator 
   specification. It may not be the perfect solution but the products 
   can satisfy some requirements.


4.  Translators in the future

   There are some proposals for translation technology like 
   [I-D.carpenter-shanti] and [I-D.beijnum-modified-nat-pt]. Some of 
   them could require some modification on IPv6 devices to work with 
   translator nicely. It is desired approach to resolve most issues 
   listed on [RFC4966]. The important point here is design based on the
   requirements.





Miyata                 Expires November 24, 2008                [Page 3]

Internet-Draft      Translator specification approach           May 2008

5.  Proposal strategy

   Considering above mentioned situation, the new translators might not 
   be the solution for 2010. Of course we know that current of-the-shelf 
   translator would not be the final solution in long term view.
   But both are important to support smooth and rapid IPv6 deployment.


5.1. Current translator model description

   The current translation technology would help smooth IPv6 
   introduction around 2010. But it may not be the perfect solution. 
   So we should know the current technology. And we should consider 
   what kind of technology fits what kind of situation. And we should 
   give recommendation how to use it.
   The big advantage of this kind of document is not-keeping users and 
   developers waiting for the definition of new translation technology.
   This kind of document should be BCPs.


5.2. New translator model specification

   As we realized that translator is required. But current technology 
   may not be the perfect solution. So we need to define the 
   specification to resolve issues listed on [RFC4966].
   The big advantage of this kind of document is providing safety and 
   optimization.
   This kind of document would be RFCs.


5.3. Common translation rule

   In chapter 3 and 4 of [RFC2765](SIIT), there are translation rule.
   It is referred by NAT-PT, obsoleted by [RFC4966], and other 
   implementations may be compliant with the rule, since it is 
   reasonable and common rule. 
   It is useful to have such kind of documents. But now the ICMPv6 
   specification is revised by [RFC4443]. The translation rule should 
   be updated. This kind of documents should be independent from 
   specific translation technology. Especially, the common translation 
   rule for ICMP message is very important.


5.4. Translator unfriendly environment

   In IPv4 network, it is observed that some devices transmits IPv4 
   packet with value "1" in DF Field. And some filtering systems in IPv4 





Miyata                 Expires November 24, 2008                [Page 4]

Internet-Draft      Translator specification approach           May 2008

   network drop the ICMP error message. This combination makes 
   communication failure as follows. 
   When a translator translates the packet from IPv4 packet to IPv6 
   packet, the packet size is increased by the differences of IP 
   headers. So, when the Path MTU from translator to IPv6 destination is 
   1500 octets, the IPv4 packet with the size of 1500 octets can not 
   arrive at the IPv6 destination node. In this case, the intermediate 
   routers, include the translator, send ICMP Error Message, Destination 
   Unreachable(packet too big), but the message can not arrive at the 
   original IPv4 sender due to intermediate filtering system. Then the 
   IPv4 node can not learn the Path MTU.
   This problem is not only translator problem and happens in general.
   But, documenting this kind of issues should be helpful to provide the 
   interoperability between IPv4 node and IPv6 node.


6.  Acknowledgements

   Send the author comments if you want your name listed here.


7.  IANA Considerations

   This memo includes no request to IANA.


8.  Security Considerations

   Security issues associated with NAT have long been documented. 
   This memo itself has no security issue.


9.  References

9.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC4966]  C. Aoun, E. Davies, "Reasons to Move the Network Address
              Translator - Protocol Translator", RFC 4966, July 2007.

   [RFC4443]  A. Conta, S. Deering, M. Gupta, Ed., "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol 
              Version 6 (IPv6) Specification", RFC 4443, March 2006.




Miyata                 Expires November 24, 2008                [Page 5]

Internet-Draft      Translator specification approach           May 2008


9.2. Informative References

   [I-D.carpenter-shanti]
              Carpenter, B., "Shimmed IPv4/IPv6 Address Network
              Translation Interface (SHANTI)", 
              draft-carpenter-shanti-01 (work in progress), 
              November 2007.

   [I-D.durand-v6ops-natv4v6v4]
              Durand, A., "Non dual-stack IPv6 deployments for 
              broadband providers", draft-durand-v6ops-natv4v6v4-01 
              (work in progress), 
              February 2008.

   [I-D.beijnum-modified-nat-pt]
              I. van Beijnum, "Modified Network Address Translation -
              Protocol Translation", 
              draft-van-beijnum-v6ops-mnat-pt-00 (work in progress), 
              February 2008.




Author's Address

   Hiroshi Miyata
   Yokogawa Electric Corporation
   2-9-32 Nakacho, Musashino-shi, 
   Tokyo, 180-8750
   JAPAN

   Email: h.miyata@jp.yokogawa.com



















Miyata                 Expires November 24, 2008                [Page 6]

Internet-Draft      Translator specification approach           May 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Miyata                 Expires November 24, 2008                [Page 7]