Re: on NAT-PT

[itojun@iijlab.net]

>	there are some concerns raised in the working group meeting
>	with respect to NAT-PT.  it seems to me that the concerns does not
>	have enough technical ground (or there are some confusions in
>	understanding how NAT-PT works).  i don't see the need for revising
>	NAT-PT at all.  some clarifications on the document might be nice,
>	but no major re-work is needed, IMHO.

	more comments on other drafts.

	i'm not really defending NAT-PT itself, actually i would like to see
	less use of NAT-PT (i prefer dual stack approach).   i just don't see
	the technical ground for the voices like "NAT-PT is evil, need a
	revised version".

itojun


draft-durand-natpt-dns-alg-issues-00.txt
1.1

>   RFC2766 is not clear on how a DNS-ALG should treat answers to A
>   queries made by internal nodes. As a matter of fact, one could
>   fear that a careless a DNS-ALG would also intercept them and translate
>   them into a AAAA form.  In other words, nodes asking for a A record
>   could be returned a AAAA record. Although this may not be a problem
>   for simple IPv6 only applications, it may be a concern for applications
>   that 'walk through' the DNS structure and may pas information to peers.

	if you are an IPv6-only node and would like to communicate with IPv4-
	only node within the same site, you will still want to use NAT-PT
	translator, therefore it is okay for DNS-ALG to translate A responses
	into AAAA responses.

>   Second, the application has no way of knowing that the returned AAAA
>   address is actually not a real IPv6 one, but a IPv4 translated one.
>   It may be led to believe that it's a real one and think "It's IPv6,
>   so it has End to End IP connectivity, thus there will be no NAT in
>   the middle and I can use any IPv6 specific options"

	This is the whole point of NAT - you want NAT box be invisible
	from the NAT customers (in NAT-PT case, IPv6-only nodes).
	if the NAT is visible to the NAT customer, it is more like RSIP.

1.2

>   => The communication between a node within the NAT-PT domain and a
>   external dual stack host will select the translated path over the
>   native IPv6 path.

	It really depends on how your DNS-ALG treats dual stack FQDN.
	As far as I understand, DNS-ALG won't perform address rewrite (from A
	to AAAA) if an FQDN has both A and AAAA records.  Therefore, the
	point made in 1.2 looks moot.

1.3

>   NAT-PT ALG makes the assumption that the DNS traffic goes through the
>   NAT-PT box.
>
>   This is OK is DNS resolution is done over IPv4. However, if it is
>   done over IPv6, there is no reason why the DNS traffic will still go
>   through the NAT-PT box unless the NAT-PT box is also the default IPv6
>   router of the site.

	not necessary.  what NAT-PT really want are:
	- the translated prefix (P::/96) used by DNS-ALG gets routed towards
	  NAT-PT translator box.
	- NAT-PT translator box, as well as DNS-ALG be dual stack
	there's no requirement at all for NAT-PT translator box, nor DNS-ALG
	box, being a default router.

	i guess RFC2766 is a bit unclear about this point - you may want to
	check RFC3142 for better documentation.

1.4
	
>   Section 7.5 of RFC2766 says that NAT-PT is not deployable with DNS-
>   sec.  It would work if all the DNS resolution were done over IPv6,
>   but in a mixed environment as described in draf-ietf-ngtrans-dns-
>   ops-req-03.txt, this will be a problem.

	as written in the previous email meesage, why bother.
>>	(5) - when you rely upon DNS responses created on the fly, as well as
>>	a box that rewrites your data traffic, why this is a show-stopper?