Re: on NAT-PT

[Brian E Carpenter <brian@hursley.ibm.com>]

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

itojun@iijlab.net wrote:
> 
> >       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?