> Perhaps my choice of wording wasn't exactly correct. Make it "does not 
> function in this capacity unless modified." But there's a missed point: add 
> in packet analysis and you're doing NAT. The boasted transparency of Plan 9 
> is a product of bringing most (or really all?) functions, including 
> networking, into a single framework. That single framework exists as an 
> application of networking, i.e. 9P, hence living in the application layer. 
> Descending to network layer is expulsion from the Plan 9 Eden.

I've tried to stay out of most of these, but I think this
might help you get a better feel for it.  First, don't
get too hung up on application vs. network layers.
The OSI protocols are  largely forgotten for a reason.
It's not bad as a conceptual model, but as soon as you
try to force any predefined definitions of layers on real
networks, you soon lose your grip on sanity.

So how to think about it?  First, it's *not* NAT,  because
there's no address translation going on.  So when importing
the router's /net, your messages are carried from your
machine to the router as part of 9P Twrite messages.  And
your responses come back with Rread messages coming
from the router to your machine.  Notice here that the
router doesn't get an IP datagram that it needs to pass
on.  Instead the router creates a TCP packet to carry the
message.  This is the fundamental difference.  The
encapsulation of the message in TCP/IP is done on the
gateway, obviating the need for any translation and
obviating the need for the router to care what is being
sent from your machine.

Using NAT, your machine does the encapsulating
of the message in TCP/IP and passes that packet to
the router.  Because the encapsulating IP datagram
carries the IP address of your machine,the router is
required to translate the address, hence the name,
NAT.  Because the router isn't transparent in the sense
that it doesn't pass what is sent from your machine
unchanged, protocols like ftp are a nightmare.  With
9P, there's no issue because what your machine sends
(only the ftp messages) are not changed or even looked
at by the router.

So bottom line: importing /net is not NAT in any
way.  It's so much cleaner than NAT and it falls out
for free from the structure of the system.  There's
not much better than getting functionality with no
additional code that is better in many ways than
the approaches that require special and kludgy
code.

BLS


Reply via email to