Internet Engineering Task Force H. Miyata Internet-Draft Yokogawa Electric Corp. Intended status: Informational December 23, 2007 Expires: May 15, 2008 Translator specification approach draft-miyata-v6ops-trans-approach-00 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 (2007). 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 June 25, 2008 [Page 1] Internet-Draft Translator specification approach November 2007 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 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Miyata Expires June 25, 2008 [Page 2] Internet-Draft Translator specification approach November 2007 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 June 25, 2008 [Page 3] Internet-Draft Translator specification approach November 2007 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, obsoluted 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. 6. Acknowledgements Send the author comments if you want your name listed here. Miyata Expires June 25, 2008 [Page 4] Internet-Draft Translator specification approach November 2007 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. 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-00 (work in progress), November 2007. [I-D.beijnum-modified-nat-pt] I. van Beijnum, "Modified Network Address Translation - Protocol Translation", draft-van-beijnum-modified-nat-pt-02 (work in progress), November 2007. Miyata Expires June 25, 2008 [Page 5] Internet-Draft Translator specification approach November 2007 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 June 25, 2008 [Page 6] Internet-Draft Translator specification approach November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 June 25, 2008 [Page 7]