Subject: Re: on NAT-PT

From: [email-masked]
Date: Fri, 29 Nov 2002 15:57:36 +0900

>has any way been found as yet to accomplish end to end ipsec with nat.if
>not, will this require a modification in the way ipsec ah and ipsec esp
>works or will nat-pt will have to be revised alltogether (which i don't
>think is a very good proposition)? i think an urgent solution to this is
>required if nat/napt-pt is to be used at a larger scale.

	ipsec does not work over NAT.  period.
	(there are efforts in ipsec wg, but...)

itojun

---

From: "Thakur, Anand" <[email-masked]>
Date: Fri, 29 Nov 2002 12:31:51 +0530

regards
anand

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Thursday, November 28, 2002 11:44 AM
> To:	[email-masked]
> Subject:	Re: on NAT-PT 
> 
> >	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?

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sat, 30 Nov 2002 14:26:02 -0800

> (there are efforts in ipsec wg, but...)
Some of the routers supports IPsec pass through mode and works fine (at
least
with my limited experience) with ESP tunnel mode. As far as i can tell no
one
cares about AH.  IPsec pass through mode seems to work fine for home
scenarios
(my PC behind the NAT establishing a IPsec ESP tunnel to the corporate). Its
limitations
might prevent its use in large scale though.

-mohan

-mohan