Subject: (NAT) Requested changes to NAT Terminology draft

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 1 Jun 1999 07:20:08 -0700 (PDT)

Folks,

Many people responded to Keith's comments and my response to Keith's
comments. Specifically, there was a lot of e-mail exchange on the 
subject of "routing realm". I gather, most people feel "addressing 
realm" is a better choice than "routing realm" and is less confusing.
Will do.

As for the use of term "transparent", I havent heard much comments.
Let me make one more attempt to paraphrase what was said by both
parties to solicit additional input. 

Keith is of the view that the term "transparent" should be used only
in the context of NAT being invisible to end host applications; not
in the context of data exchanged between applications and their 
operation.

The draft states, NAT devices provide routing (i.e., layer 3 intermediate 
node forwarding) transparency for applications to communicate with hosts 
in a different realm. This is the only context in which the term is used.  
NAT devices are application unaware and do not change packet payload.

Hmm... is there a diagreement here? Thats all for now. Have a nice day.

cheers,
suresh
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Andrew Brown <[email-masked]>
Date: Tue, 1 Jun 1999 10:53:27 -0400

>NAT devices are application unaware and do not change packet payload.

nat devices don't do routing.  the routing is done by something that
was already there before nat was invented.

and nat devices are not "application unaware" and do "change packet
payload".  the ftp protocol requires specific support in the nat in
order to function through the nat.  and dcc (within irc) is "just
plain broken"(tm) by nat.

-- 
|-----< "CODE WARRIOR" >-----|
[email-masked]             * "ah!  i see you have the internet
[email-masked] (Andrew Brown)                that goes *ping*!"
[email-masked]       * "information is power -- share the wealth."
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Keith Moore <[email-masked]>
Date: Tue, 01 Jun 1999 10:40:59 -0400

Thanks for agreeing to make the change about "routing realm".

As for "transparency" it often seemed like the word, or the word
"transparent" was used too frequently, and in other cases the use
seemed like an attempt to over-state the utility of NATs.  
(Personally, I'm not sure what "routing transparency" is, as 
distinguished from simply "routing".)

And there definitely is a disagreement about whether NATs change 
the packet payload - I would say that they do, because the source 
address and destination address have always been available to
applications and many applications depend on these addresses.  
To me this makes them a part of the payload.

Rather than doing another review of the document and suggesting 
changes to each use of "transparent" or "transparency", I would
merely suggest that during your next editing pass you examine
each use of those words and consider whether (a) the meaning
would be the same if you omitted the word, or (b) the meaning is
ambiguous and could be clarified by a change in words, or (c) the use 
of the word would be considered inappropriate by someone who was trying
to emphasize the limitations, rather than the benefits, of NATs.
(I'm sure you'll agree that NATs have both benefits and limitations)

Still, this is largely an issue of style rather than substance.
I wouldn't object to publication of the revised document on this issue.
But I would appreciate any effort to clarify the use of "transparent".

Keith

-

---

From: Pravin <[email-masked]>
Date: Tue, 1 Jun 1999 11:25:36 -0700 (PDT)

andrew, i want add real time streaming protocols like real audio/video 
as well to the list.

- pravin

> plain broken"(tm) by nat.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
" we can not step into the same river again"
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 1 Jun 1999 13:17:43 -0700 (PDT)

> distinguished from simply "routing".)
Routing happens in an addressing realm with a unique set of 
routable addresses.

Transparent routing refers to routing datagrams between disparate
addressing realms. Routing by itself cannot do this as the addresses
overlap between the realms or are recognised in one realm, but not
the other. 

> applications and many applications depend on these addresses.  

Many do not, as well. 

> To me this makes them a part of the payload.

Payload, as I understand, is data, without including protocol headers. 

Hope, the following text from section 7.0 helps.

   NAT devices are application unaware in that the translations are
   limited to IP/TCP/UDP/ICMP headers and ICMP error messages only.
   NAT devices do not change the payload of the packets, as payloads
   tend to be application specific.
	     
   NAT devices (without the inclusion of ALGs) do not examine or
   modify transport payload. For this reason, NAT devices are
   transparent to applications in many cases. There are two areas,
   however, where NAT devices often cause difficulties: 1) when an
   application payload includes an IP address, and 2) when end-to-end
   security is needed.

> (I'm sure you'll agree that NATs have both benefits and limitations)
OK. As far as I can tell, most (if not all) of the use is 
in the context of tranparent routing.

> But I would appreciate any effort to clarify the use of "transparent".

OK. Fair enough.

cheers,
suresh

-

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 1 Jun 1999 13:27:53 -0700 (PDT)

> was already there before nat was invented.
Sorry. We disagree. 
Layer-3 intermediate node forwarding, which is what RFC 1812 calls routing, 
is a required functionality for a NAT device.

> payload".  

Nope. Take a look at the draft. ALGs do that.

>            the ftp protocol requires specific support in the nat in
> order to function through the nat.

Thats called FTP-LAG.

>                                     and dcc (within irc) is "just

May be so. Do you know why? I would appreciate if you could send an e-mail 
on why this happens in a seperate e-mail thread. Thanks.

cheers,
suresh
-

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 02 Jun 1999 11:46:32 -0400

> To me this makes them a part of the payload.

Moreover, because the source and destination network-layer addresses
are part of the transport-layer pseudoheader, transport layer
checksums also need to be modified by a NAT.  This is unquestionably a
modification of the network-layer payload...

NAT's provide less transparency than routers, and treat less of the
packets going through them as opaque objects.  

						- Bill
-