A brief draft about the "source_IP-NAT" idea

Abstract:

A method is proposed to enable incoming communications
based on address allocation when a DNS query is received
for the target node.  Certain 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 IP address using 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.

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.

Technical 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 the NAT box (call it fooNAT) gets the request for
an address allocation, it associates the following
information to the address (call it v6dev-IPv4) it
provides to fooNS:
- the IPv6 address of v6dev
- the time when the address was allocated
- which nameserver made the request.
It also sets the status of the address allocation as
"incomplete", and sets a timeout (call it BIND_TIMEOUT)
by which the allocation has to be "completed".

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 "completes" the allocation
by associating the following additional information
with v6dev-IPv4:
- the source address of the incoming packet
    (call it CNv4 for "correspondent node IPv4")
- the source port of the incoming packet
- the time of arrival
- the updated status of "complete"
- 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 = CNv4
   dest IP addr = v6dev-IPv4,
      which is an address of fooNAT

Then the outgoing IPv6 packet gets:
   source IP addr = IPv4-mapped address of CNv4
   dest IP addr = 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 completed, 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 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 "completed", 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.


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, as long as the incoming flow maintains
enough traffic to avoid expiration of WAIT_TIME.


Dual-stack deprecated

There are three likely possibilities for a dual-stack
implementation

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

- 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?

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