Subject: Re: (ngtrans) NAT-PT -05 INput

From: George Tsirtsis <[email-masked]>
Date: Sat, 3 Apr 1999 10:33:46 +0000 (GMT)

Jim,

First of all thanks for the review. I hope I answered all your points
but let me know if you have more.

Here we go...

On Wed, 31 Mar 1999, Jim Bound wrote:

> Bob, Tony, Alain, George, and Suresh,
> 
> First I think we need to resolve the issues of SIIT as you reference
> that spec but I have some issues I will state below.
> 
> 1.  You state NAT-PT supports end-to-end.  That is simply not the case
> or you need to define end-to-end in terms of NAT.  This I believe could
> be misleading to the market to see the word end-to-end.  Also I think
> the way to state this is end-2-end in the nomenclature.
> See: draft-carpenter-transparency-00.txt as I too define e2e and NAT-PT
> is far from transparent.  Also text I sent on deployment list as to what
> constitutes e2e IMO.  

Jim, I think NAT-PT has one of the most complete and sincere
"applicability statements" and "security considerations" sections plus
section 6 on "NAT-PT Limitations". I find hard to beleive that anyone will
missunderstand what NAT-PT is.

> 
> 2.  The spec needs a lot of editing.  It appears the use of "articles"
> is missing in many sentences "a", "an", "the".  But this is editing.
> 

Yes and Margaret is taking care of that, although I am getting a bit weary
of the fact that NAT-PT is getting special treatment on the "editing"
front, I am waiting to see the same treatment on other drafts... 

> 3.  Under: 3.1 NAT-PT Outgoing Sessions (IPv6 to IPv4)
> 
>       If the outgoing packet is not a session initialisation packet, the
>      NAT-PT  SHOULD  already  have  stored some state about the related
>      session, including assigned IPv4 address and cached parameters for
>       the  translation.   If this state does not exist the packet SHOULD
>      be silently discarded.
> 
> What if it is a UDP session?  Something should be stated if its not a
> TCP SYN start.
> 

There is no deterministic way to know the start of UDP sessions.
draft-ietf-nat-terminology-01.txt at section "2.1.3. Start of session for
TCP, UDP and others" is talking about it and we could add this here as
well. 
Suresh, do you agree?

> 4.  Use of PREFIX::1.2.3.4 on incoming and outgoing sessions.  
> 
> You don't ever state how this PREFIX is assigned to an IPv6 node on the
> V6 domain behind the NAT-PT.  But more importantly how it may be routed
> on the V6 Network?  How the PREFIX plays in the topology.
> 
> FRom section 3.2:    
> 
>       Say the IPv6 Host A wanted to set up a TCP session with  the  IPv4
>      Host  C.
> 
>       Host A creates a packet with:
> 
>       Source Address, SA=FEDC:BA98::7654:3210 , source TCP port  =  3017
>      and Destination Address, DA = PREFIX::132.146.243.30,  destination
>      TCP port = 23.
> 
> How did Host A "know" the PREFIX for the DA?

In section 4.2.1 DNS ALG, it clearly states that the PREFIX:: is added by
the NAT-PT during the translation of a DNS A record to a AAAA record. This
way PREFIX:: is part of the IPv6 routing and configured by the network
administrator and there is no constrain for the hosts to know about
"translatable addresses" ala SIIT, although these could be used as well.

> 
> 5.  Under section 4 IPv4 Address Assignment
> 
> 4.1 V4 Address assignment for outgoing connections
> 
>       Outbound session start is based on identifying the first packet of
>      a session. For ex: SYN, !ACK for TCP sessions.
> 
> Please reference UDP too or some example?
> 
>       V6 hosts learn the address of V4 hosts from the DNS server in  the
>      V4  domain or the DNS server internal to the V6 network. We recom-
>      mend that DNS servers internal to V6 maintain mapping of names  to
>      IP  V6  addresses  for  internal  hosts and possibly some external
>      hosts.  External DNS servers in the V4 domain maintain  name  map-
>      ping for external hosts (i.e., V4 hosts) alone.
> 
> Why is this different than what DNS already does?  I don't see why your
> saying this text in the spec and your recommendation is the norm?  It
> appears you are stating the obvious?  So I am missing something in the
> text above can you tell us why you say this above?
> 

What we try to make sure here is that DNS entries for IPv6 ONLY hosts
should not be retained by IPv4 ONLY DNS servers and vice versa. Note that
this can happen because of temporary assignement of IPv4 addresses to IPv6
hosts (and vice versa). So, that is why we also say that DNS replies that
have been translated by NAT-PT should not be cached.

>       4.2.1 DNS Application Layer Gateway (ALG) support
> 
>          In figure 2 above, when Host C name resolver makes a name  look
>         up  request  for  Host A, the lookup query is redirected to the
>         DNS server on the V6 network. Considering that NAT-PT is resid-
>         ing   on the border router between V4 and V6 networks, this re-
>         quest datagram would traverse through the  NAT-PT  router.  The
>         DNS  ALG on NAT-PT  would modify  the DNS Queries going into V6
>          domain as follows:
> 
> Do you want to ref DNS-ALG?  Also in the first sentenced I think you
> want to say "directed" not redirected because this is what DNS does as
> the norm. 

Should be "directed".

>  NAT-PT is intercepting all DNS queries, but what else?

Sorry, what else are you thinking about? DNS-ALG will intercept DNS
queries and DNS replies that cross NAT-PT.

> This
> is why I ask if you want to reference another spec that supports an IPv6
> DNS-ALG example?   The one for NAT now only supports IPv4 in the NAT WG
> maybe we need one for IPv6 too, so this WG can parse that as DNS for
> NAT-PT is a pretty big part and will affect users normal DNS processing
> and all the configuration possible with Firewalls etc.

The DNS-ALG will NOT affect "users normal DNS processing" apart from the
stated fact that DNSSEC will not work.

> 
>             a) For Host Name to Host Address Query requests:
>                Change the Query type from "A" to "AAAA".
>             b) For Host address to Host name query requests:
>                Replace the V4 address octets (in reverse   order)   pre-
>               ceding  the string "IN-ADDR.ARPA"  with the corresponding
>               V6 address (if there exists a map) octets in reverse  or-
>               der.
> 
> IN-ADDR.ARPA should say ip6.int above.
> 

Yes, thanks.

> Also I think you need to address A6 and the binary labels for the
> reverse records.  This will complicate and increase the DNS packet 
> intercepting at the NAT-PT and should be discussed later as a "pain" to 
> using this mechanism or appropriate wording.  
> 

Yes, I have been thinking about it. In principle you are correct that A6
records are more "painful" for the DNS-ALG but the operation does not
change. We can add A6 records in the text, although I hope by the time A6
records are available IPv6 will have taken over the world and NAT-PT is
not going to be needed any more :) ...day dreaming... ;)

> 
>          In the opposite direction, when DNS response traverse from  the
>         DNS  server  on  V6 network to V4 host, the DNS-ALG once  again
>         traps the DNS packet and would:
> 
>             a)  Translate  DNS  responses  for  "AAAA"  records into 'A'
>            records,
>             b) Replace the V6 address sent by the V6 DNS server with the
>            V4 address internally assigned by the NAT-PT router.
> 
> Here A6 type records may be requested multiple times by a client v6
> resolver as it tries to find the top level DNAME zone.  This complicates
> the query at the NAT-PT and could imply state for the DNS processing
> within the NAT-PT for processing.  Also if IPv4 comes back the V6 node
> now must deal with that in the V6 resolver code and this should be
> discussed in this spec or in an updated DNS-ALG NAT spec.
> 

Again it is just more precessing but the principle of operation still
works. We can add a note about that though...

>          If a V4 address is not previously assigned  to  this  V6  host,
>         NAT-PT would assign it this time. The TTL values on all DNS re-
>         source records (RRs) passing through NAT-PT would be set to  0.
> 
> Is the NAT-PT dynamically updating the DNS or just keeping state in the
> NAT-PT.  If using dynamic updates then this is scary because NAT-PT
> cannot support DNSSEC and this problem should be stated in the spec if
> dynamic updates to DNS MUST be supported without security.  I gave you
> folks this input on the existing DNS-ALG for IPv4 privately as input too
> last week.  

At the moment that draft does not say anythink about dynamic DNS. This is
just state on the NAT-PT! Remember that no DNS server is aware of
DNS-ALG's existence--> that is why DNSSEC does not work across a 
NAT-PT!

> 
>          This  technique  is  also  useful for outgoing communication as
>         well. We saw that a v6host that needs to communicate with  a v4
>         hosts needs to use a specific prefix (PREFIX::) in front of the
>         IPv4 address of the v4host. The above technique allows the  use
>         of this prefix without any configuration in the hosts. E.g.: In
>         Figure 2, Host-A makes a name look-up on the  Host-C.  The  DNS
>         query  goes  to  the v6 DNS server and from there to the v4 DNS
>         server outside the v6 stub domain after it has been  translated
>         by  the  NAT-PT.  The  reply follows the same route but now the
>         NAT-PT translates the reply adding the appropriate prefix.  So,
>         if the reply is:
> 
>             HostC    A     132.146.243.30, it is translated to
>             HostC   AAAA   PREFIX::132.146.243.30
> 
> Again how does a user determine the PREFIX to configure?  Some examples
> and discussion is needed IMO.  
> 

The start of the paragraph that you quote states exactly what happens. As
I said before PREFIX:: is configuration on the NAT-PT.

> And if it is an A6 RECORD what is the affect as they are distributed
> unlike AAAA records.  You folks need to address A6 Records.
> 
> You should state that the PREFIX will not be an IPv4 Mapped or IPv4
> Compatible Address too.

PREFIX can be anything the administrator decides but it is bad
idea to make it the same with the mapped ot compatible prefix. But do we
need to state this? "mapped" are illegal on the wire and "compatible" are
only for tunnel end point! It could, however, be the "translatable" prefix
(ala SIIT).

> 
> 6.  In section 5.4 FTP ALG
> 
> You need to address the EPRT and EPASV commands being replaced in IPv6
> FTP with prt and passv as they are different.
> 

Suresh, can you comment on this?

> thanks
> /jim

Regards
George
-----------------------------
Internet Transport Research |
BTLABS                      |
--------------------------------------------------------------------------
Notice: This contribution is the personal view of the author and does not
necessarily reflect the technical nor commercial direction of British
Telecommunications plc.
--------------------------------------------------------------------------

---

From: Bob Fink <[email-masked]>
Date: Sat, 03 Apr 1999 17:00:38 -0800

George,

>but let me know if you have more.

Thanks for being so responsive on this.

...
>front, I am waiting to see the same treatment on other drafts... 

I agree with you. You just happen to be the convenient target at the moment.

Let me reassure you that all will get the same scrutiny (we just haven't
seen Jim's new AIIH/DTI draft yet :-).

Thanks,

Bob

---

From: [email-masked] (Pyda Srisuresh)
Date: Mon, 5 Apr 1999 06:34:14 -0700 (PDT)

Below is my addendum to George's responses.

<... snip>

> TCP, UDP and others" is talking about it and we could add this here as
Sounds good.

<... snip>

> have been translated by NAT-PT should not be cached.

Jim - If you believe, the text is stating what is currently the NORM, it
      should be OK to leave the text in there. The idea is to discourage
      spreading a single DNS Zone across V4 and V6 realms.

<... snip>
> Suresh, can you comment on this?

Sure, RFC 2428 talks about EPRT and EPSV extensions. 
EPRT,  which has the following format requires protocol Number translation
(AF #1 to AF #2, or vice versa) and Address translation (from V4 address 
in ASCII to V6 address in ::: notation or vice versa). Nothing 
substantially different from PORT and PASV commands. <tcp-port>  
translation is also required in the case of NAPT-PT.
   EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>

EPSV doesnt seem to require any NAT translations.

> George

regards,
suresh

---

From: Jim Bound <[email-masked]>
Date: Tue, 06 Apr 1999 08:52:53 -0400

Hi George,

>missunderstand what NAT-PT is.

I agree.  But NAT-PT is not end-to-end as you call it.  I think saying
it is wrong.

>front, I am waiting to see the same treatment on other drafts... 

I think they all need editing.  BIS and XLATOR needs work too.
Whick I will be sending input on soon.

One thing I have noticed that is important.  In the English language the
use of "articles" 'a, an, the' are pretty much not correct in specs by
persons to whom this is not their native language.  I even mess it up
myself often.  They are important to be placed correctly because it can
change the meaing of a sentence.

>TCP, UDP and others" is talking about it and we could add this here as

As the all work in NAT does not apply to IPv6 then I think NAT-PT needs
its own terminology section for NGTRANS.

I think that UDP cannot be identified needs to be stated in the
applicability statements.

So how are you caputuring a DNS UDP packet?

>"translatable addresses" ala SIIT, although these could be used as well.

OK I could have misread it.  So are you saying that no node in NAT-PT
scenario EVER sends a packet from its interfaces with
PREFIX::ipv4.address.type.NAT-PT.  That it is always done by the NAT-PT
router?  

If so OK.

>have been translated by NAT-PT should not be cached.

OK just say that?  I don't think you need all the other words in the
spec.  This is standard DNS stuff.

>queries and DNS replies that cross NAT-PT.

Just that DNS is the only protocol being intercepted?

What about when the packet is fragmented DNS UDP?  

>stated fact that DNSSEC will not work.

Performance is part of "Normal Processing" by my customers definitions,
sorry for not making that clear.  Intercepting and munging DNS packets
will cost.

>not going to be needed any more :) ...day dreaming... ;)

They will be a pain for all proposals.  

NAT-PT will be needed for all transition for sometime.
Which is why I am trying to review it as best I can.

>works. We can add a note about that though...

What I was worried about here was the fact that if UDP is used how does
a NAT type box keep track of the multiple messages that may occur
because of A6 records from the resolver?  For starters?

>DNS-ALG's existence--> that is why DNSSEC does not work across a 

Hmmm.  OK.  So NAT-PT changes the content of DNS queries and responses
btw the two parties?  

Do we need to specify more than just DNSSEC don't work but that this is
a serious "trust the person in the middle" issue?

>I said before PREFIX:: is configuration on the NAT-PT.

I am fine with the explanations for Destination Address in the IP Header
my concern is the Source Address from a V6 Host ever being PREFIX::....
because then the Host would have to know that PREFIX.  But I think your
telling me this can never happen.

We might want to just make sure this is all clear, but I will read it
again.

>only for tunnel end point! It could, however, be the "translatable" prefix

OK put these limitations in.  I am discussing translatable with Erik
now.

>Suresh, can you comment on this?

OK I will await the response.

thanks 
/jim

---

From: [email-masked] (Pyda Srisuresh)
Date: Wed, 7 Apr 1999 08:29:57 -0700 (PDT)

Jim,

My responses below.

> I agree.  But NAT-PT is not end-to-end as you call it.  I think saying

Let me add some clarification here. 

NAT-PT allows (in many cases, except as noted below) hosts in a V4
network to transparently communicate with destinations in a V6
network and vice versa. 

NAT-PT devices (without the inclusion of ALGs) do not examine or
modify transport payload. For this reason, NAT-PT devices are
transparent to applications in many cases. There are three areas,
however, where NAT-PT devices can cause difficulties: 

1) There is no disambiguous way to translate certain types of V6
   packets into V4 packets and vice versa [Refer SIIT]. In such 
   a case, NAT-PT will loose the end-2-end semantics during 
   protocol translation.

2) When an application payload includes IP address, NAT-PT
   cannot accomplish end-2-end transparency. An ALG wil be 
   required to examine and/or modify the payload.
  
3) When end-to-end security is needed, NAT-PT cannot accomplish
   end-2-end transparency. Then again, IPsec objective was not to
   allow end-2-end security between nodes in different realms. 
   Both end nodes of a security association must participate with 
   V4-only or V6-only addresses.

<... snip>

> So how are you caputuring a DNS UDP packet?

Would the following text be OK with you?

There is no deterministic way of recognizing the start of
a UDP based session or any non-TCP session. A heuristic approach
would be to assume the first packet with hitherto non-existent
session parameters (namely src IP address, destination IP address,
protocol, src port no, destination port number) as constituting
the start of new session.

A DNS UDP packet is recognized by the fact that its source or 
detination port no. would be 53.

<... snip>
> What about when the packet is fragmented DNS UDP?  
NAT-PT would need to assemble the fragments together first 
and then translate prior to forwarding.

<... snip>

> OK I will await the response.

I already sent my response in the weekend. About the same time,
I also sent my responses on DNS-ALG draft in a separate e-mail.
If you havent recieved either one of them, let me know, I will
forward my copy one more time.

regards,
suresh

---

From: Jim Bound <[email-masked]>
Date: Thu, 08 Apr 1999 00:50:15 -0400

Hi Suresh,

>      spreading a single DNS Zone across V4 and V6 realms.

OK.  Saying that might be good.

>   EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>

I am just saying that we should not just worry about PORT but EPRT too.

>EPSV doesnt seem to require any NAT translations.

As long as the port numbers are not an issue when NAT-PT uses ports?
You might be correct.  I need to look at this for that part of NAT-PT.

thanks
/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 08 Apr 1999 01:03:52 -0400

Hi Suresh,

  
>   V4-only or V6-only addresses.

Then lets put an adjective in front of e2e statements for translation
like "some" "certain"...etc.. 

SIIT has this issue too.

The reason I am being so intense about this is that too many users are
using NAT thinking e2e is always there until I ask them if they are
doing this or that or want to do this or that.  Then they say "yep" that
will be a problem with NAT for me when I do this or that.  Even though
the specs are for us programmers, just in case a user reads them in a
sparse way I think e2e statements for any spec that does NAT should have
an adjective qualifier.

<... snip>

>detination port no. would be 53.

OK with me.

>and then translate prior to forwarding.

I don't think NAT-PT should capture this per se but clearly somewhere
when implications of NAT are discussed for UDP this should be noted.

<... snip>

>forward my copy one more time.

ACK.  I am wondering if the PASV or EPSV command has port issues for
when NAT-PT uses a single address and parses by port #.  As I replied on
the DNS ALG response in other NAT mail (not NGTRANS)...

But yes you did address it and I had not read that when I responded.
But if there is a PASV port issue it will affect RSIP and others using
port # space maybe but I need to look at that.

thanks
/jim

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 8 Apr 1999 06:41:38 +0000 (GMT)

On Thu, 8 Apr 1999, Jim Bound wrote:
> >.... 

I think adding something is not a problem. we could say "e2e when ALGs are
not in use" or something like that. We can do this off line. 

> when implications of NAT are discussed for UDP this should be noted.

I think this is covered by SIIT which talks about how you deal with
fragments.

BTW, I am going away for a week and might or might not have e-mail access
during that time.

Thanks

George

---

From: [email-masked] (Pyda Srisuresh)
Date: Thu, 8 Apr 1999 08:10:13 -0700 (PDT)

Hi Jim,

<... snip> 
> I am just saying that we should not just worry about PORT but EPRT too.
Yes. It is a valid comment.

> You might be correct.  I need to look at this for that part of NAT-PT.

You are right. In the case of inbound FTP session using NAPT-PT, if the 
EPSV command has a port argument, that must be translated.

We will expand the FTP-ALG section to include support for EPRT and EPSV
commands. 

> /jim

Thanks.

regards,
suresh

---

From: [email-masked] (Pyda Srisuresh)
Date: Thu, 8 Apr 1999 08:18:34 -0700 (PDT)

Hi Jim,

> sparse way I think e2e statements for any spec that does NAT should have

OK.

<... snip>
> when implications of NAT are discussed for UDP this should be noted.
OK.

> the DNS ALG response in other NAT mail (not NGTRANS)...

I replied to this on a different thread.
You are right. EPSV does require port translation in the case of NAPT-PT, 
when EPSV is followed by a port number.

> port # space maybe but I need to look at that.

Sure. But, that is another thread and another subject ...

Thanks.

regards,
suresh