9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] IL and NAT
@ 2000-11-18  3:21 geoff
  2000-11-18 13:53 ` Theo Honohan
  0 siblings, 1 reply; 14+ messages in thread
From: geoff @ 2000-11-18  3:21 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

I'm not sure; it's certainly possible that individual applications do
such things.

The usual problem with ftp is that by default ftp clients, especially
older ones, tend to trigger connections back from the target system to
port 20.  ftp's so-called ``passive'' mode forces the connections to
be placed from the initiating system and avoids this problem.


[-- Attachment #2: Type: message/rfc822, Size: 1786 bytes --]

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] IL and NAT
Date: Fri, 17 Nov 2000 22:02:08 -0500
Message-ID: <20001118030208.7775.qmail@g.bio.cse.psu.edu>

| Contrary to what Scott just said, it's not each application that has
| to be added to a NAT router, but each protocol that rides directly on
| IP (or beside it).

Isn't it the case that some applications, like ftp, encode ip address
and port information in application layer traffic, which NAT has to
account for?  Linux seems to have code to handle that sort of stuff
(linux/net/ipv4/ip_masq*).

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [9fans] IL and NAT
@ 2000-11-18 18:42 nigel
  2000-11-18 19:00 ` Theo Honohan
  2000-11-18 19:24 ` Boyd Roberts
  0 siblings, 2 replies; 14+ messages in thread
From: nigel @ 2000-11-18 18:42 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]

Before we are too down on NAT implementations, there is a distinction
between NAT and NAPT, according to various RFCs and associated
documents.

NAT means what is says: address translation.  NAPT means address and
port.  You can simply translate addresses and maintain the port, but
this means that typically only one internal node can communicate.If
you do this, then the protocol is irrelevant, and IL would pass
through.

In fact, since it has been mentioned, Lucent devices (neé Ascend),
worked this way until it became apparent that Cisco had implemented
NAPT and they rolled out the full monty. They called it "single address
translation".

Once you choose to translate ports as well, as has been said, you need
to understand where the ports are; for TCP and UDP it is in the same place,
so they get done. It is completely unsurprising that other protocols aren't.

ICMP gets done because it's dull if you can't traceroute and ping. It takes
hacks, but it can be done.

FTP is depressing. Anyone out there designing protocols: take note, don't
embed IP addresses in the stream.

Others are as bad, or insoluble: luckily, they are less important, like IRC
or RealAudio.

On top of this, to create some 'reliability', commerical NAT routers
have a list of TCP and UDP ports which they are prepared to translate.
'Known good' if you like.  My Pipeline 75 does not do POP3
automatically.  I had to tell it to, despite the protestations of the
manuals.  I looked for a software update, but since Lucent bought
them, this doesn't happen any more.  Some other products, I
understand, refuse straightforward protocols like POP3 despite best
efforts.

So, the summary is use 9p over TCP, not IL, unless you can rewrite
your router. This is becoming easier since both FreeBSD and Linux
have WAN drivers, and NAT code.

As it happens, all translation in FreeBSD is done using a library,
with plug-ins for various awkward protocols.  Fix the library, and all
the various translators (natd, pppd, pppoed) would all fall into
line. Modifying the implementation to do IL would be straightforward
I think.


[-- Attachment #2: Type: message/rfc822, Size: 2026 bytes --]

From: Theo Honohan <theoh@chiark.greenend.org.uk>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] IL and NAT
Date: Sat, 18 Nov 2000 13:53:50 +0000
Message-ID: <E13x8RD-0007iy-00@chiark.greenend.org.uk>

geoff@x.bell-labs.com wrote:
> scott wrote:
> >
> > Isn't it the case that some applications, like ftp, encode ip address 
> > and port information in application layer traffic, which NAT has to 
> > account for?  Linux seems to have code to handle that sort of stuff 
> > (linux/net/ipv4/ip_masq*). 
>
> I'm not sure; it's certainly possible that individual applications do
> such things.

I think Scott's right.  All viable NAT products do this, although it's not
strictly part of NAT.  A search for "NAT" on Cisco's site confirms
that they support the use of "PORT" in ftp, and a slew of features of
other protocols that would otherwise be broken by NAT.

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [9fans] IL and NAT
@ 2000-11-18 14:04 presotto
  0 siblings, 0 replies; 14+ messages in thread
From: presotto @ 2000-11-18 14:04 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 154 bytes --]

we don't do any in home stuff, that all goes off with avaya and Microelectronics,
our 2 current spin offs.  Orinoco (aka wavelan) also goes with micro.

[-- Attachment #2: Type: message/rfc822, Size: 1510 bytes --]

From: anothy@cosym.net
To: 9fans@cse.psu.edu, cnielsen@pobox.com
Subject: Re: [9fans] IL and NAT
Date: Sat, 18 Nov 2000 01:32:53 -0500
Message-ID: <20001118063257.01E01199F7@mail.cse.psu.edu>

//That said, I have some sway with Cisco's
//development team, so I _might_ be able to
//get them to implement support for IL.

ooh, that'd be embarasing. Cisco supporting a
protocol developed at Bell Labs that Lucent's
own products don't support. er, or does Lucent
not do that sort of thing any more? maybe we
should go talk to Avaya...
-α.

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [9fans] IL and NAT
@ 2000-11-18  6:32 anothy
  0 siblings, 0 replies; 14+ messages in thread
From: anothy @ 2000-11-18  6:32 UTC (permalink / raw)
  To: 9fans, cnielsen

//That said, I have some sway with Cisco's
//development team, so I _might_ be able to
//get them to implement support for IL.

ooh, that'd be embarasing. Cisco supporting a
protocol developed at Bell Labs that Lucent's
own products don't support. er, or does Lucent
not do that sort of thing any more? maybe we
should go talk to Avaya...
-α.


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [9fans] IL and NAT
@ 2000-11-18  0:17 geoff
  2000-11-18  0:50 ` Christopher Nielsen
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: geoff @ 2000-11-18  0:17 UTC (permalink / raw)
  To: 9fans

NAT routers generally have to rewrite port numbers (not just IP
addresses) for protocols that use them, and ports numbers are at
different offsets and of potentially different sizes in different
protocol's headers.  IL's port numbers appear later than TCP's and
UDP's, for example.  NAT routers will generally understand the headers
of TCP, UDP and ICMP at minimum, but I haven't encountered one yet
that understood IL (even Lucent's own).

Contrary to what Scott just said, it's not each application that has
to be added to a NAT router, but each protocol that rides directly on
IP (or beside it).



^ permalink raw reply	[flat|nested] 14+ messages in thread
[parent not found: <cnielsen@pobox.com>]

end of thread, other threads:[~2000-11-18 19:24 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-11-18  3:21 [9fans] IL and NAT geoff
2000-11-18 13:53 ` Theo Honohan
  -- strict thread matches above, loose matches on Subject: below --
2000-11-18 18:42 nigel
2000-11-18 19:00 ` Theo Honohan
2000-11-18 19:24 ` Boyd Roberts
2000-11-18 14:04 presotto
2000-11-18  6:32 anothy
2000-11-18  0:17 geoff
2000-11-18  0:50 ` Christopher Nielsen
2000-11-18  1:19 ` Boyd Roberts
2000-11-18  3:02 ` Scott Schwartz
     [not found] <cnielsen@pobox.com>
2000-11-17 23:48 ` Christopher Nielsen
2000-11-17 23:56   ` Scott Schwartz
2000-11-18 14:20   ` Steve Kilbane

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).