Network Working Group R. van der Pol
Internet-Draft NLnet Labs
Expires: July 28, 2003 S. Satapati
S. Sivakumar
Cisco Systems, Inc.
January 27, 2003
Issues when translating between IPv4 and IPv6
draft-vanderpol-v6ops-translation-issues-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 July 28, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
During the transition from IPv4 to IPv6 both protocols will be used
simultaneously. Most nodes will support both protocols and will be
able to communicate via both IPv4 and IPv6 transport. Problems arise
when a node only supports IPv4 and it wants to communicate with a
node that only supports IPv6. Translation between the two IP
protocols might be needed in some cases. This memo discusses the
problems involved in translation between IPv4 and IPv6.
van der Pol, et al. Expires July 28, 2003 [Page 1]
Internet-Draft Translation issues January 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Why is translation between IPv4 and IPv6 needed? . . . . . . 3
4. The basic elements of protocol translation . . . . . . . . . 4
5. The problems with translation between IPv4 and IPv6 . . . . 4
5.1 The problems with address translation . . . . . . . . . . . 4
5.2 The problems with address discovery . . . . . . . . . . . . 5
5.2.1 The problem of getting unwanted translated addresses . . . . 6
5.2.2 The problem of getting AAAA answers for A queries . . . . . 7
5.3 Scaling problems with NAT in large setups . . . . . . . . . 8
6. IPv4 NAT or NAT-PT? . . . . . . . . . . . . . . . . . . . . 8
7. When is translation between IPv4 and IPv6 needed? . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . 11
van der Pol, et al. Expires July 28, 2003 [Page 2]
Internet-Draft Translation issues January 2003
1. Introduction
During the transition from IPv4 to IPv6 both protocols will be used
simultaneously. Most nodes will be able to communicate via both IPv4
and IPv6 transport (dual stack nodes). When communicating to a node
that supports only one of the protocols, they choose that protocol.
When communication via both protocols is possible, they usually
default to IPv6. Problems arise when one node only supports IPv4
(IPv4-only) and the node it wants to communicate with only supports
IPv6 (IPv6-only). In some cases the nodes can still communicate by
using a proxy that supports both IPv4 and IPv6, e.g. by using an
HTTP proxy for web traffic. If no such proxies are available and the
nodes must communicate, translation between IPv4 and IPv6 could be
used as a last resort. This memo discusses the problems involved
with translation between IPv4 and IPv6.
2. Terminology
o IPv4-only node - A node that has an IPv4 stack and no IPv6 stack.
o IPv6-only node - A node that has an IPv6 stack and no IPv4 stack.
o dual stack node - A node that has both an IPv4 and an IPv6 stack.
It may be connected to an IPv4 network, to an IPv6 network or to
both.
o NAT - Network Address Translation. Usually, the translation
between a private (RFC1918) IPv4 address and a globally routable
IPv4 address and vice versa.
o NAT-PT - Network Address Translation, Protocol Translation. The
translation between IPv4 addresses and semantically equivalent
IPv6 address and vice versa.
o ALG - Application Level Gateway. A translator that knows how to
translate the payload of traffic of a particular application when
the payload contains IP addresses. Each application needs its own
specific ALG.
o DNS-ALG - An Application Level Gateway for DNS.
3. Why is translation between IPv4 and IPv6 needed?
If one node only supports IPv4 and the other node only supports IPv6,
no direct communication is possible. Fortunately, most nodes will be
dual stack, which means they support both IP versions. However,
nodes that are not upgraded yet support only IPv4. Problems arise
van der Pol, et al. Expires July 28, 2003 [Page 3]
Internet-Draft Translation issues January 2003
when IPv6-only devices are introduced in the internet. Those devices
can not communicate with IPv4-only nodes. When introducing such
devices several questions should be asked.
o Is communication with IPv4-only devices needed or is it acceptable
to support communication with dual stack and other IPv6-only nodes
only.
o Is it possible to use dual stack proxies? E.g., IPv6-only
appliances that offer web services can be reached via IPv4
transport by using dual stack HTTP proxies.
It should also be noted that IPv6-only nodes do not require
translation to function. E.g., they can use DNS or email services
when these services are setup with dual stakc in mind. These issues
are explained in [5] and [4]. For DNS resolving they can use a dual
stack caching forwarder. For outgoing email they can use a dual
stack mail drop. For incoming email they can use POP or IMAP via
IPv6 transport to fetch their email from a central email server that
receives email via IPv4 and IPv6 transport.
4. The basic elements of protocol translation
An obvious candidate for enabling communication between IPv4-only and
IPv6-only nodes is NAT-PT [2]. The NAT-PT mechanism has two
components, address and protocol translation as described in SIIT [1]
and address discovery. Address and protocol translation is the
processing of IP packets by a NAT; address discovery is the mechanism
by which an IPv4-only or an IPv6-only node discovers the "translated
address" to which packets should be sent. The NAT-PT specification
proposes to solve address discovery by using a DNS-ALG, as specified
in section 4 of NAT-PT [2].
5. The problems with translation between IPv4 and IPv6
Translation between IPv4 and IPv6 has many different problems. Some
of these problems are summarized in the next sections. Section
Section 5.1 summarizes the problems of NAT. Section Section 5.2
describes the problems with address discovery. Section Section 5.3
describes the scaling problems in large NAT setups.
5.1 The problems with address translation
Translation between IPv4 and IPv6 has all the problems of classic NAT
as described in RFC 2993 [3].
o It breaks applications that have IP addresses in the payload. NAT
only translates addresses in the IP headers, not in the payload.
van der Pol, et al. Expires July 28, 2003 [Page 4]
Internet-Draft Translation issues January 2003
ALGs must be used to translate addresses in the payloads.
However, each application needs its own specific ALG. Therefore,
it is hard to introduce new applications that need to use
addresses in the payload of there packets.
o It breaks security protocols like IPsec and DNSEC. The IPSec AH
header contains a hash of the IP header. If the IP header is
modified by the translator, the authencity of the packet is lost.
DNS-ALG cannot translate DNSSEC packets because it does not know
the private key of the signature(s).
o It breaks IP multicast. Protocols like PIM, SDR, RTP, etc. have
IP addresses in their payloads. NAT boxes need ALGs for all of
these. Few if any NAT boxes support all the ALGs needed.
o It is a bottleneck and a single point of failure, because the NAT
box needs to build state and therefore all the traffic must pass
the NAT box.
5.2 The problems with address discovery
During the transition phase from IPv4 to IPv6 there will be
IPv4-only, dual stack or IPv6-only nodes that want to communicate to
other IPv4-only, dual stack or IPv6-only nodes. When both nodes do
not speak the same version of IP, some translation will be needed.
The table below shows the preferred version of IP address with
respect to nodes A and B wanting to communicate with each other.
van der Pol, et al. Expires July 28, 2003 [Page 5]
Internet-Draft Translation issues January 2003
========================================================
| + A | | | |
| + | IPv4-only | dual stack | IPv6-only |
| B + | | | |
========================================================
| H | | |
| IPv4 H IPv4 | IPv4 | t(IPv6)->IPv4 |
| only H address | address | address |
| H | | |
--------------------------------------------------------
| H | | |
| dual H IPv4 | IPv4 or IPv6 | IPv6 |
| stack H address | address | address |
| H | | |
--------------------------------------------------------
| H | | |
| IPv6 H t(IPv4)->IPv6 | IPv6 | IPv6 |
| only H address | address | address |
| H | | |
========================================================
t(IPv6)->IPv4 means that some translation is involved which
produces some IPv4 address for an IPv6-only host.
t(IPv4)->IPv6 means that some translation is involved which
produces some IPv6 address for an IPv4-only host.
5.2.1 The problem of getting unwanted translated addresses
This section makes an important assumption: it assumes that the
NAT-PT acts as a bridge between two networks, one IPv4-only and the
other IPv6-only. As a result, the DNS-ALG will translate a DNS
request for a AAAA record coming from the IPv6 node into a request
for an A record, and vice versa. The problem is that address
translation does not know if the traffic originates from an
IPv4-only/IPv6-only node or from a dual stack node. When a dual
stack node A wants to communicate with an IPv4-only node B, the dual
stack node A gets either the IPv4 address of B (preferred) or an IPv6
address which is some kind of translation of the IPv4 address of B.
This latter situation is not wanted, because it means unnecessary
translation between IPv4 and IPv6. This is shown in the table below.
van der Pol, et al. Expires July 28, 2003 [Page 6]
Internet-Draft Translation issues January 2003
============================================================
| + A | | | |
| + | IPv4-only | dual stack | IPv6-only |
| B + | | | |
============================================================
| | | | |
| IPv4 | IPv4 | IPv4 | t(IPv6)->IPv4 |
| only | address | address | address |
| | | | |
------------------------------------------------------------
| |XXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXX|
| dual | IPv4 address or | IPv4 or IPv6 | IPv6 address or |
| stack | t(IPv4)->IPv6 | address | t(IPv6)->IPv4 |
| |XXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXX|
------------------------------------------------------------
| | | | |
| IPv6 | t(IPv4)->IPv6 | IPv6 | IPv6 |
| only | address | address | address |
| | | | |
============================================================
The boxes with XXX-es are the cases where address translation could
result in unwanted translation.
5.2.2 The problem of getting AAAA answers for A queries
Within an IPv6 NAT-PT domain, an application asking for an A record
could be returned a translated AAAA record.
RFC2766 [2] section 4.2:
"...the DNS-ALG on the NAT-PT device forwards the original AAAA/A6
query to the external DNS system unchanged, as well as an A query
for the same node. If an AAAA/A6 record exists for the
destination, this will be returned to NAT-PT which will forward
it, also unchanged, to the originating host.
If there is an A record for Node-C the reply also returns to the
NAT-PT. The DNS-ALG then, translates the reply adding the
appropriate PREFIX and forwards it to the originating device with
any IPv6 addresses that might have learned."
RFC2766 is not clear on how a DNS-ALG should treat answers to A
queries made by nodes within the NAT-PT domain. As a matter of fact,
one could fear that a careless DNS-ALG would also intercept them and
translate them into a AAAA form. In other words, nodes asking for an
A record could be returned a AAAA record. Although this may not be a
problem for simple IPv6-only applications, it may be a concern for
van der Pol, et al. Expires July 28, 2003 [Page 7]
Internet-Draft Translation issues January 2003
applications that 'walk through' the DNS structure and may pass
information to peers.
5.3 Scaling problems with NAT in large setups
In large networks NAT-PT and/or DNS-ALG boxes can become a serious
single point of failure, a bottleneck and a Denial Of Service (DOS)
target. It may be necessary to spread the NAT-PT and/or DNS-ALG
among several boxes. However, this is a very complicated operation.
The NAT-PT and/or DNS-ALG boxes need to build state about address
mappings. The setup must be carefully chosen, so that packets that
need to be translated are routed through the box that has the proper
state.
6. IPv4 NAT or NAT-PT?
Nodes on an IPv6-only network that want to communicate with IPv4-only
nodes do not necessarily need to use NAT-PT. If the nodes are dual
stack, they can use IPv4-in-IPv6 tunneling through the IPv6-only
network. In cases where there are only private IPv4 (RFC1918)
addresses available, it still makes sense to use IPv4-in-IPv6
tunneling combined with classical IPv4 NAT, because there is
extensive deployment experience with IPv4 NAT, but little experience
with NAT-PT.
7. When is translation between IPv4 and IPv6 needed?
Some argue that IPv6-only devices will show up on a large scale soon
because of new appliances that do not have enough memory to support
both IPv4 and IPv6. Others argue that the cost of a dual or hybrid
stack is not much more than that of an IPv6-only stack.
Others think translation is only needed in the final phase of the
transition from IPv4 to IPv6. Eventually, almost all nodes will be
IPv6 enabled and only a few legacy systems are still IPv4-only. When
communicating with those legacy systems, translation might be needed.
8. Security Considerations
As described in section Section 5.1 NAT-PT breaks security protocols
like IPsec and DNSSEC. Because all traffic needs to go through the
NAT boxes, these boxes can become a target for a DOS attack.
Some argue that an advantage of NAT is that there is no traffic
possible to an inside address/port until the NAT box has built state
for that address/port combination. That is only partially true. As
soon as the inside address/port has sent a packet outside, the NAT
box has state for that address/port combination and that address/port
van der Pol, et al. Expires July 28, 2003 [Page 8]
Internet-Draft Translation issues January 2003
combination is globally reachable. For security reasons, it is much
better to have a more controlled security meachanism.
A host inside a NAT-PT network when trying to traverse through the
NAT box gets an global address. However, this host can send packets
with different spoofed source addresses which will make the NAT box
exhaust its address pool. In this case, no other legitimate hosts
can communicate to the other side of the translator, because the
translator has no more addresses to give. This can be a serious
problem in large NAT-PT networks.
References
[1] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC 2765, February 2000.
[2] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[3] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[4] Nakamura, M. and J. Hagino, "SMTP operational experience in
mixed IPv4/IPv6 environements",
draft-ietf-ngtrans-ipv6-smtp-requirement-06 (work in progress),
July 2002.
[5] Durand, A., "IPv6 DNS transition issues",
draft-durand-ngtrans-dns-issues-00 (work in progress), June
2002.
Authors' Addresses
Ronald van der Pol
NLnet Labs
Kruislaan 419
Amsterdam 1098 VA
NL
EMail: Ronald.vanderPol@nlnetlabs.nl
van der Pol, et al. Expires July 28, 2003 [Page 9]
Internet-Draft Translation issues January 2003
Suresh Satapati
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose CA 95134
US
EMail: satapati@cisco.com
Senthil Sivakumar
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose CA 95134
US
EMail: ssenthil@cisco.com
Appendix A. Acknowledgements
The authors gratefully acknowledge the contributions of: Rob Austein,
Christian Huitema, and, Daniel Soohong.
van der Pol, et al. Expires July 28, 2003 [Page 10]
Internet-Draft Translation issues January 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 assignees.
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
van der Pol, et al. Expires July 28, 2003 [Page 11]
Internet-Draft Translation issues January 2003
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.
van der Pol, et al. Expires July 28, 2003 [Page 12]