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]