behave Working Group C. Perkins, Ed.
Internet-Draft WiChorus Inc.
Intended status: Standards Track February 17, 2009
Expires: August 21, 2009
Translating IPv4 to IPv6 based on source IPv4 address
draft-perkins-sourceipnat-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 21, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Perkins, Ed. Expires August 21, 2009 [Page 1]
Internet-Draft Source IP NAT for IPv6 February 2009
Abstract
A method is proposed to enable communications between an IPv4-only
node in today's Internet and an IPv6-only node, initiated by the
IPv4-only node. The communication depends on allocation of a flow
record and address triggered by a DNS query received for the target
v6-only node. DNS query conventions can be agreed upon to provide a
natural model for resolving IPv4 queries for IPv6-only nodes. The
NAT mechanism proposed demultiplexes multiple sessions through the
same dynamically allocated IP address, using flow records matching
the source address of incoming packets. This is in contrast to the
use of ports in NAT-PT boxes, which inhibits the support of incoming
traffic towards a node behind the NAT-PT.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Outgoing flows, initated by an IPv6-only device. . . . . . . . 8
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
6. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Security Considerations . . . . . . . . . . . . . . . 11
Appendix B. Using NAT for the DNS resolution . . . . . . . . . . 12
Appendix C. Dual-stack deprecated . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Perkins, Ed. Expires August 21, 2009 [Page 2]
Internet-Draft Source IP NAT for IPv6 February 2009
1. Introduction
As long as it is more difficult to deploy IPv6 nodes than IPv4 nodes
in today's Internet, adoption of IPv6 is going to be slow. The use
of NAT in today's Internet has created certain expectations and
operational conveniences, but at the cost of some important features.
In particular, communications are often not really bidirectional
since the device whose IP address is to be translated typically has
to initiate the communication.
In order to encourage the adoption of IPv6, it is likely to be
important to enable IPv6-only nodes to provide services to the
existing IPv4-dominant Internet. Otherwise, if services can be
provided for today's Internet only by assigning IPv4 addresses to the
service-providing nodes, there is decreased economic incentive for
moving to IPv6.
The approach may be compared to a specialized form of flow
management, where flows are identified by source and destination IP
addresses (usually also including additional information including
ports). The NAT box manages the flows, allocating and deallocating
resources, and managing the traffic (albeit intrusively) according to
the mutual needs of the source and destination networks.
Using the techniques proposed in this specification, communication
between IPv4 nodes and IPv6 nodes can be accomplished with minimal
requirements on the nodes and infrastructure:
o no dual stack
o no restriction to port-based communications
o no tunneling
o no changes to IPv4 or IPv6 hosts
Moreover, the approach is scalable because each IPv4 address used by
for the incoming flows can be shared by many different IPv6-only
devices.
Perkins, Ed. Expires August 21, 2009 [Page 3]
Internet-Draft Source IP NAT for IPv6 February 2009
2. Terminology
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 [1].
Perkins, Ed. Expires August 21, 2009 [Page 4]
Internet-Draft Source IP NAT for IPv6 February 2009
3. Overview
Suppose that an operator wishes to support a large population of
IPv6-only nodes. Later, it will be explained why this is preferable
compared to dual-stack approaches. Also, suppose that the operator
requires that the IPv6 nodes should have free access to the existing
IPv4 Internet, and that customers in the existing Internet should
also have free access to service-providing nodes in the IPv6-only
domain, as well as to any of the other nodes in the domain for which
such incoming communications would be valuable. This might, for
instance, greatly simplify real-time gaming and VoIP.
Here is a proposed sequence of events. Let v6dev.foo.net be the FQDN
for a v6-only node in the operator's domain. When a node in the IPv4
Internet wishes to establish a communication with v6dev, it sends a
IPv4 DNS query to the name server (denoted fooNS) for foo.net.
Suppose that the fooNS is programmed to supply an IPv4 address for
such IPv4 DNS queries, but there is no such IPv4 address record
available. Then, fooNS contacts the NAT box to get the required IPv4
address; in this context, the NAT box has the function of address
allocation. Then fooNS creates a DNS reply with the appropriate A
record. Importantly, fooNS does NOT store this A record for v6dev.
Every distinct DNS query for v6dev could conceivably get a distinct
IPv4 address allocation. The cache time for the A record is set to
the minimum (either 0 or 1, depending on policy).
When fooNS sends the request to the NAT box (call it fooNAT) for an
address allocation, fooNAT allocates the address (call it v6dev-IPv4)
and creates a flow record with the following information:
o v6dev-IPv4
o the time when v6dev-IPv4 was allocated
o the IPv6 address of v6dev
o which nameserver made the request
It also sets the status of the address allocation as "pending", and
sets a timeout (call it BIND_TIMEOUT) by which the allocation has to
be "established".
In due time, a packet will arrive at v6dev-IPv4, which is the address
of a network interface of fooNAT. Assuming this happens before the
expiration of BIND_TIMEOUT, fooNAT "establishes" the allocation by
associating the following additional information with v6dev-IPv4:
Perkins, Ed. Expires August 21, 2009 [Page 5]
Internet-Draft Source IP NAT for IPv6 February 2009
o the source address of the incoming packet (call it CNv4, for
"correspondent node IPv4")
o the source port of the incoming packet
o the time of arrival
o the updated status of "established"
o a new timeout, "WAIT_TIME"
Then, fooNAT does the address translation as detailed below and
delivers the IPv6 result to v6dev.
The translation is performed as follows: Suppose the incoming IPv4
packet has:
<source IP addr, dest IP addr> == <CNv4, v6dev-IPv4>,
where v6dev-IPv4 is an address of fooNAT Then the outgoing IPv6
packet gets:
<source IP addr, dest IP addr> == <IPv4-mapped addr of CNv4, v6dev>
The same rules apply for ICMP, GRE, and other protocols. Ports
remain unchanged. If it is desired to use another IPv6 prefix to
identify CNv4 to v6dev, the rule above can be easily modified as long
as v6dev is configured appropriately. Whichever prefix is used,
v6dev will use it to send packets back through fooNAT, which then
performs the reverse translation for delivery to CNv4 in the IPv4
Internet.
If, after the allocation is established, it happens that no packets
flow between v6dev and CNv4, then v6dev-IPv4 is deallocated for the
purpose of communications between v6dev and CNv4. v6dev-IPv4 may
remain in use for other purposes. fooNAT waits for WAIT_TIME to
receive or send a packet on the (v6dev, CNv4) flow before
deallocating the flow. Under the assumption that fooNS has not
cached v6dev-IPv4 as the IPv4 address of v6dev.foo.net, there is no
need to notify fooNS about the deallocation. If, in the future, the
no-cache assumption is relaxed, a notification of the deallocation
would be needed.
When the NAT box has allocated all of its available IPv4 addresses
for active or pending communications, it begins to overload the
available IPv4 addresses. Each IPv4 address can be allocated for use
of multiple distinct communications. The same IPv4 address can be
used for numerous different IPv6-only nodes, or even for multiple
Perkins, Ed. Expires August 21, 2009 [Page 6]
Internet-Draft Source IP NAT for IPv6 February 2009
distinct flows to the same IPv6-only device. Each such flow is
identified by source and destination IPv4 address and port numbers,
along with possibly other information to be specified. Each new IPv4
DNS query for one of the IPv6-only nodes served by fooNAT will
trigger another allocation of one of fooNAT's IPv4 addresses. It is
not clear what the maximum degree of overload should be.
When a new allocation (call it again v6dev-IPv4) has been made for
one of fooNAT's IPv4 addresses, incoming packets have to be inspected
to determine whether they contain a new IPv4 source address, not yet
associated with any other flow using v6dev-IPv4. If such a new
source address is detected, the new allocation is "established", the
new data is recorded, and the timeout is changed to WAIT_TIME.
In a nutshell, the incoming sessions are demultiplexed into the IPv6-
only domain based on incoming IPv4 source address, not based on
incoming source port number. Given the prevalence of NATs in today's
Internet, the source port number takes on additional importance,
because the same IPv4 address could actually be used by multiple
source computers with their IP addresses hidden from the Internet.
Because of this, the source port number should be used as an
additional demultiplexing index. In this way, multiple instances of
the same source IPv4 address could be used at the same NATv4 address
as long as port numbers were available and different for the
different instances of that IPv4 source address.
Perkins, Ed. Expires August 21, 2009 [Page 7]
Internet-Draft Source IP NAT for IPv6 February 2009
4. Outgoing flows, initated by an IPv6-only device.
These can be handled in any of the ways proposed, but perhaps the
simple v6v4 NAT proposals are most appropriate here. Problems with
v4-mapped addresses and other difficulties associated with NATs are
noted in RFC 4966, but it should also be pointed out that a majority
of today's Internet citizens do not seem to be overly concerned with
these limitations. We should make it our first goal to make these
typical users equally or more happy with IPv6, even if the NAT
solution is inherently restrictive. In fact, different outgoing NAT
boxes can be used for the outgoing flows, as long as the incoming
flow maintains enough traffic to avoid expiration of WAIT_TIME.
Perkins, Ed. Expires August 21, 2009 [Page 8]
Internet-Draft Source IP NAT for IPv6 February 2009
5. Acknowledgments
Thanks to Vijay Devarapalli, who provided useful ideas to make
important improvements in the proposal.
Perkins, Ed. Expires August 21, 2009 [Page 9]
Internet-Draft Source IP NAT for IPv6 February 2009
6. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Perkins, Ed. Expires August 21, 2009 [Page 10]
Internet-Draft Source IP NAT for IPv6 February 2009
Appendix A. Security Considerations
This is where the Security Considerations will go.
Perkins, Ed. Expires August 21, 2009 [Page 11]
Internet-Draft Source IP NAT for IPv6 February 2009
Appendix B. Using NAT for the DNS resolution
If the NAT box is used as the authoritative name server for a special
subdomain of foo.net, say for example v6only_domaim.foo.net, then
this design can be carried out without requiring changes to the
existing DNS infrastructure. It is a matter of discussion whether or
not it would be desirable to recommend the isolation of such v6-only
devices and their transient A records to such subdomains.
Perkins, Ed. Expires August 21, 2009 [Page 12]
Internet-Draft Source IP NAT for IPv6 February 2009
Appendix C. Dual-stack deprecated
There are three likely possibilities for a dual-stack implementation
o The IPv4 address is globally unique. This is very undesirable to
make as a requirement, since then we have accomplished nothing
towards the goal of making available more network-layer addresses.
o The IPv4 address is a private address, and there is a NAT box at
the border of the dual-stack domain. In this case, we have NAT.
Since IPv6-only hosts can work just fine with NATs, why require
dual stack?
o The IPv4 address is a private address, and the dual-stack node is
required to do tunnel processing on incoming v6-addressed packets
that it receives. This amounts to a substantial implementation
burden and, when communications occurs over a wireless medium,
even more overhead.
Perkins, Ed. Expires August 21, 2009 [Page 13]
Internet-Draft Source IP NAT for IPv6 February 2009
Author's Address
Charles E. Perkins
WiChorus Inc.
3590 N. 1st Street, Suite 300
San Jose, CA 95134
USA
Email: charliep@computer.org
Perkins, Ed. Expires August 21, 2009 [Page 14]