RE: on NAT-PT

["Thakur, Anand" <Anand.Thakur@hpsglobal.com>]

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

> -----Original Message-----
> From:	itojun@iijlab.net [SMTP:itojun@iijlab.net]
> Sent:	Thursday, November 28, 2002 11:44 AM
> To:	v6ops@ops.ietf.org
> 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?