Re: on NAT-PT

[<juha.wiljakka@nokia.com>]

Itojun,

thanks for your comments below; sorry for the very late reply!

-----Original Message-----
From: ext itojun@iijlab.net [mailto:itojun@iijlab.net]
Sent: 28 November, 2002 06:47

	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.

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

JW: Right.. I am afraid that the dual stack won't work for all the scenarios (like IMS scenario 1). Furthermore, availability of public IPv4 addresses is not too good in many large (3GPP) networks; use of  private v4 addresses together with v4 NATs won't make the situation better..   Do you think that listing these problems in our document is ok? Should we write some clarifying text that v4 NAT has same type of problems (i.e. not only NAT-PT)?

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

JW: Well, I wouldn't necessarily say that it is a showstopper, the problem is just mentioned here.

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

JW: OK... What would be your (text) suggestion; forgetting this recommendation? Alain D. commented in his mail that the DNS-ALG part in the "v6 to v4" case needs to removed from the NAT-PT document. 

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

JW: Thanks for the pointer; I agree that avoiding it to become a single point of failure is not an easy task.

	(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

JW: I will have a look at RFC3142.

Thanks,
		-Juha W.-

P.S. I agree with Brian Carpenter that we need a document discussing the issues with NAT-PT; after that we can see more clearly, how (/ whether) we shall revisit the NAT-PT RFC.