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

[Alain Durand <[e-mail]>]

On Wednesday, July 17, 2002, at 05:26 PM, [e-mail] wrote:

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

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
> points-of-failure.

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

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

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

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


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

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

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.