Subject: (ngtrans) draft-durand-ngtrans-nat64-nat46-00.txt

From: [email-masked]
Date: Wed, 17 Jul 2002 16:26:37 +0100

Alain,

Some comments on your nat64-nat46 draft:

NAT64
-----
Can we be confident that applications written by developers that don't know
about NAT64 will get some useful default behaviour? This is not a rhetorical
question - I genuinely would like to hear your thoughts about this.

The scalability solution doesn't prevent the NAT64 devices being single
points-of-failure.

NAT46
-----
The changed model of interworking deployment responsibility from the
providers of IPv6 services to the providers of IPv4 network connectivity is
interesting. I can't see too many IPv4 network operators deploying NAT46 for
their customers on the off-chance that there are some useful or interesting
IPv6 services that they might want to connect to. It is much more useful for
the providers of IPv6 services to be able to make their services accessible
to the global IPv4 community via NAT-PT. As I stated in my earlier mail
commenting on draft-durand-natpt-dns-alg-issues-00.txt, the problems with
NAT-PT as *implemented* are not as great as you imply. I agree the spec
could use some work.

General comments
----------------
I agree with you that there is a need for a scalable solution to the
translation interworking problem before serious deployment can happen.
However, I don't believe that NAT-PT is irredeemably broken and I think that
several of the ideas presented in this draft could easily be applied to
NAT-PT. There are already several quite mature implementations of NAT-PT and
improvement of the spec rather than re-invention is therefore extremely
desirable in my opinion. Let's fix the NAT-PT spec rather then generate yet
another mechanism.

 -- Mat.

---

From: Alain Durand <[email-masked]>
Date: Thu, 18 Jul 2002 03:25:41 +0200

> question - I genuinely would like to hear your thoughts about this.

For this to work, an IPv6-only OS implementation should have those 
properties:
1. the kernel should enable the node to send IPv4-mapped on the wire.
2. getnameinfo() and friends from the DNS stub-resolver library should 
return
     IPv4-mapped  addresses when the DNS resolution process has returned
     an A record.

> The scalability solution doesn't prevent the NAT64 devices being single

True. However, NAT64 enable to deploy multiple NAT64 boxes,
but each one is a local single point of failure, the draft should 
clarify this.

> IPv6 services that they might want to connect to.

The nice thing about NAT46 is that is can be implemented locally.
That is, it can deployed independently by an IPv4 ISP which wants
to offer the service to its customer. Say SIP becomes a reality
in 3G/IMS (IPv6-only) and a IPv4 ISP want
to enable SIP communications from its customer to3G/IMS,
deploying NAT46 becomes an interesting avenue.

> It is much more useful for

Again, the fact that an implementation could be made to work does not 
mean
there is no problem with the specification.

> NAT-PT.

Some of NAT-PT issues can be solved, some can not. Examples:
DNSsec cannot be made to work with NAT-PT.
NAT-PT cannot help the operation of DNS between IPv4 & IPv6.

> There are already several quite mature implementations of NAT-PT and

There might be a simple upgrade path from NAT-PT to NAT64
that could ease your concerns:
Configure the NAT-PT box to use the prefix ::ffff:0:0/96

	- Alain.

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Jul 2002 22:51:46 -0400

> NAT-PT cannot help the operation of DNS between IPv4 & IPv6.

that, and there's the fundamental problem that not all apps
get their addresses from DNS, and those addresses that are
obtained from DNS are not always used in the same place
where the lookup originates. 

Keith