Re: [9fans] Do we have a catalog of 9P servers?

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


.

Relevant Pages

  • Re: Windows as Proxy Server vs. other firewall approaches.....
    ... NAT is stateful by definition. ... Here's how an incoming packet is handled: ... Where the SPI firewall becomes criticaly important is when the router is ... > knows that it is a proxy server. ...
    (microsoft.public.windowsxp.network_web)
  • Re: Duane Arnold re: SPI
    ... > router's NAT, which has the ability to drop them. ... The NAT takes the packet that was sent to ... the router the packet belongs too. ... have SPI that didn't work and has been completely removed from the firmware. ...
    (comp.security.firewalls)
  • Re: NAT and Keep State IP Rule
    ... > My router is a NAT router, I can also set a number of IP rules and ... You need to understand what NAT and Stateful Packet Inspection does, ... traffic never becomes WAN traffic leaving the network out to the Internet ...
    (comp.security.firewalls)
  • Re: protocol xx unreachable
    ... a tcpdump on the external interface shows a "protocol xx ... The routers in between cannot decode/mangle the packet without the endpoints ... For IPSec you should look at NAT-T which more or less wraps ... The ICMP packets are sent by the source (your router?) as here is some ...
    (comp.os.linux.networking)
  • Re: protocol xx unreachable
    ... a tcpdump on the external interface shows a "protocol xx ... The routers in between cannot decode/mangle the packet without the endpoints ... For IPSec you should look at NAT-T which more or less wraps ... The ICMP packets are sent by the source (your router?) as here is some ...
    (comp.os.linux.security)
Loading