I guess we're going to discuss this draft on only
one list? This one?
1. Introduction
RFC 4966 published on July 2007 deprecates the NAT-PT tool, the
mechanism defined by the IETF to enable communications between
IPv4
only nodes with IPv6 only nodes, letting the dual-stack
approach as
the preferred mechanism to enable nodes to be able to communicate
with v6 and v4 nodes. However, there are several reasons why the
dual stack approach may not be adequate for a number of scenarios.
For once, the dual-stack approach imposes the management of two
networks in a site, the v6 one and the v4 one, increasing the
costs
of using IPv6.
I think that's a very weak argument in the next few years. The vast
majority of deployments will be dual stack routing - can you seriously
imagine doing anything else? If you want to make this argument, it
should
surely be made only as a long term consideration.
In addition, as IPv4 public address space is
depleted, it will no longer possible to access to IPv4 public
addresses, making dual stack nodes even less attractive.
Well, if I was implementing a new service, I would work very hard to
get a public IPv4 address for it, so I don't think this argument
works for servers and services for many years to come. It clearly
will apply to client systems much sooner. So I'd rather see the
problem expressed as: New populations of clients (and p2p hosts)
that have no public IPv4 address, but do have plentiful public
IPv6 addresses, which need to contact legacy servers (and p2p hosts)
that have a public IPv4 address (possibly NATted) but no IPv6
capability.
I don't think that changes the technical scenario.
3. Supported application behavior
The general purpose of NAT64 type of mechanisms is to enable
communication between a v4-only node and a v6-only node. However,
there is wide range of type of communication, when considering how
they handle the IP addresses.
That's true. But are we really aiming to solve all the scenarios
you describe? It seems to me that we probably can't, because
in any case the only safe assumption is that the legacy IPv4 system
is sitting behind a NAPT. And in any case, if we have a translator
with one IPv4 address fronting for 1000 IPv6 hosts, we automatically
inherit *all* the issues of NAPT, including dynamic port mapping
and the need for application level gateways for any address-dependent
applications.