Subject: on NAT-PT

From: [email-masked]
Date: Thu, 28 Nov 2002 13:46:37 +0900

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

---

From: [email-masked]
Date: Thu, 28 Nov 2002 15:13:46 +0900

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Nov 2002 10:16:19 +0100

I think we need an RFC which discusses the issues with NAT-PT
that are discussed for NAT-v4 in RFC 2993 and RFC 3027.
Maybe it could be quite short, if the issues are the same,
but it needs to be written.

   Brian

---

From: Ronald van der Pol <[email-masked]>
Date: Thu, 28 Nov 2002 14:56:45 +0100

> but it needs to be written.

I think we should also descibe the specific issues of translating
between address families. With dual stack hosts, there is the issue
of getting a translated address when un-translated communication is
possible. There is also the issue where to put these boxes (near the
v4-only host, near the v6-only host or somewhere in between). And
probably others.

	rvdp