Re: [9fans] IL and NAT

[nigel@9fs.org]

[-- 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.