Subject: RE: (ngtrans) NAT-PT DNS ALG issues

From: "Christian Huitema" <[email-masked]>
Date: Fri, 22 Feb 2002 08:38:18 -0800

> Anyway, do you have a suggestion about how to proceed? your draft only
> points to "issues"...no suggestions. As a co-author I have no problems
if
> the WG wants to review and change the spec. My only problem is
time...of
> which I have very little to spend on this. I can contribute maybe but
I
> will need help if any changes are required.

I personally believe that the transition will happen in three phases:
first, enable all IPv4+NAT capable nodes to also become IPv6 capable;
second, upgrade the network to provide native IPv6 connectivity in
parallel to IPv4+NAT services; third, simplify the network by removing
IPv4 capabilities. We may debate whether upgrading the hosts or
upgrading the routers will happen first; Randy points out that networks
are being upgraded faster than we assume, which is pure good news. In
any case, there will clearly be a parallel movement during which both
hosts and routers are being upgraded, and both will be dual stack.

NAT-PT is clearly a "third phase" product, something that is needed by
those networks who wish to simply remove internal support for IPv4.
(DSTM occupies the same niche.) This means that such products are less
urgent than phase 1 products such as 6to4, Shipworm/Teredo, or the
management of configured tunnels. It also means that we have some time
to "do it right."

"Do it right" means, at a minimum, correcting the issues pointed out by
Alain. Basically, the entire text about munging DNS packets in transit
should be replaced by a simple statement that NAT-PT implementations
MUST NOT rewrite the content of DNS queries or DNS responses. However,
DNS rewriting is the solution proposed by NAT-PT for "NAT-PT discovery",
the process by which a node discovers the routing prefix that will lead
packets to the NAT. 

As we prohibit DNS rewriting, we have to assume that the IPv6 host will
be involved in the translation process. When it tries to reach an IPv4
only site, the host will discover that the site must be reached through
an address in the old "AF_INET" domain. The socket API has a provision
for that: when a program builds a socket, or uses an address, it
specifies its type. It is not rocket science to imagine that the host is
somehow configured with a "NAT-PT prefix", and that the TCP-IP stack
automatically transforms a request to "connect to AF_INET/1.2.3.4" into
"connect to AF_INET6/NAT-PT:PREFIX::1.2.3.4". (There will indeed be no
translation if the host actually has IPv4 connectivity.) Obviously, as
we rewrite NAT-PT, we have to provide hosts with a solution for
discovering this prefix.

The NAT-PT prefix discovery solution has to fit the intended deployment
strategy. Since we are speaking of a "phase 3" service, we have to
assume that the NAT-PT will be installed "in the IPv6 network"; we
should not assume that all services are local to the site, and we should
also not assume that there is a single provider. We should evaluate all
the possible alternatives: a single fixed prefix known by all hosts, an
anycast address used for service discovery, a DNS record of some sort,
etc.

The next question is, who is writing the new NAT-PT draft?

-- Christian Huitema

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 22 Feb 2002 10:11:47 -0800

George Tsirtsis wrote:

> First of all a disclaimer. I am not surprised that several
> problems have
> surfaced with DNS-ALGs; what I am surprised about is the fact
> that it was
> ever allowed to be part of a standards track RFC :-0  Even at
> the time I was
> arguing that this (and anything NAT related) should be at best
> Informational.

If the situation of IPv6-only & IPv4-only nodes is going to exist we do
need a standard way of translating, so your contribution was valuable.

> I am not a huge fun of NAT-PT, I have never
> promoted it as a
> serious solution to anything, certainly not as solution for large
> deployments (e.g.: 3G) and I am actually surprised it ever became so
> popular....eehhm, please do not ask me why I wrote the draft :-)

Primarily because people have NAT fever and anything that looks like
their current solution seems easier to understand than the totally new
and unknown.

> management of configured tunnels. It also means that we have some time

Actually I have been telling customers that NAT-PT fills a very specific
niche where there is a legacy system that they want to make available to
IPv6-only nodes (like 3G phones) but upgrading that system is not worth
the effort because it will be replaced within a short timeframe. In this
context it matches the NAT-PT to a single system and would be used
earlier than your scenario of removing IPv4 support, but we agree it
should not be considered a primary or urgent mechanism.

Tony