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.

itojun


draft-wiljakka-3gpp-ipv6-transition-01.txt, page 9:

>    NAPT-PT introduces a number of limitations that are expected to be 
>    magnified within the 3GPP architecture. Some of these limitations 
>    are listed here:  
>       1. NAPT-PT is a single point of failure for all ongoing 
>         connections. 
>       2. Additional forwarding delays due to further processing, when 
>         compared to normal IP forwarding. 
>       3. Problems with source address selection due to the inclusion of 
>         a DNS ALG on the same node [NATPT-DNS]. 
>       4. NAPT-PT does not work (without application level gateways) for 
>         applications that embed  IP addresses in their payload. 
>       5. NAPT-PT breaks DNSSEC. 
>       6. NAPT-PT does not scale very well in large networks.  

	(1), (2), and (4) are inherent problem with NAT.  it is unavoidable.
	if you wish to avoid this, you'll need to make cellular node a dual
	stack node and make them use IPv4 directly (instead of using IPv6-to-
	IPv4 translation).

	(3) is incorrect, see below.

	(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?

	(6) - see below.

>    To minimize the problems associated with NAPT-PT, the following 
>    actions are recommended:  
>         1. Separate the DNS ALG from the NAPT-PT node. 
>         2. Ensure that NAPT-PT does not become a single point of 
>            failure. 
>         3. Allow for load sharing between different translators. That 
>            is, it should be possible for different connections to go 
>            through different translators. Note that load sharing alone 
>            does not prevent NAPT-PT from becoming a single point of 
>            failure. 
>    There are certain ways to fix the problems with NAPT-PT, one 
>    suggestion is [NAT64]. 

	(1) is not correct.  NAT-PT RFC does not specify where to place DNS-ALG.
	DNS-ALG and NAT-PT translation part can reside on different boxes.
	when there's only one IPv4 address available to the site, there's no
	other choice than to collocate DNS-ALG and the translation part.
	(RFC2766 seems to talk about this situation only, which might be
	the source of the confusion)

	(2) is not avoidable with NAT-PT, as it is a NAT (keeps state in
	translation part).  SIIT could be another choice, but there are
	some concerns like draft-itojun-v6ops-v4mapped-harmful-01.txt in
	the use of IPv4 mapped address on wire.

	(3) is not correct.  you can place the following boxes and perform load
	balancing between NAT-PT translation part.  see RFC3142 page 5 for
	more details.
	- multiple NAT-PT translation part, configured with different NAT-PT
	  translation prefix, and
	- DNS-ALG that returns addresses crafted from multiple different NAT-PT
	  translation prefix randomly

draft-huitema-ngtrans-unmaneval-01.txt, page 4:

>This section makes an important assumption: it assumes that the NAT-
>PT acts as a bridge between two networks, one IPv6-only and the
>other IPv6-only. As a result, the DNS-ALG will translate a DNS

	"and the other IPv4-only", i suppose.

>request for a AAAA record coming from the IPv6 host into a request
>for an A record, and vice versa. The problem is that address
>translation does not know if the traffic originates from an IPv4
>only/IPv6 only node or from a dual stack node. When a dual stack
>node A wants to communicate with an IPv4 only host B, the dual stack
>host A gets either the IPv4 address of B (preferred) or an IPv6
>address which is some kind of translation of the IPv4 address of B.
>This latter situation is not wanted, because it means unnecessary
>translation between IPv4 and IPv6. This is shown in the table below.

	the answer is simple - don't use DNS-ALG if you are a dual stack node.
	use DNS-ALG as your recursive resolver only when you are IPv6 only
	node (hence you use NAT-PT translation part if the ultimate
	destionation is IPv4-only).