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

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

[sqweek]

On Sun, Nov 16, 2008 at 8:39 PM, Eris Discordia
<eris.discordia@gmail.com> wrote:
>> aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22
>
> And in this case you
> don't have an imported /net and the fabled transparency.

 Obviously, a linux server is going to have a hard time importing /net
(in a useful way, at least until Glendix gets there).
-sqweek

[9fans] nat

[erik quanstrom]

>  Obviously, a linux server is going to have a hard time importing /net
> (in a useful way, at least until Glendix gets there).

i've got a lot of folk in the house who run whatever.
i'd really like to decommission the non-plan 9 machine.
the one thing i need from it is nat.  (and i don't want
to be stuck fiddling more stuff on the dsl appliance.)
doing nat just isn't that hard.  i just need to find the time.
this is about a summer-of-code sized project.  i don't think
it would require anything from the kernel.

- erik

Re: [9fans] nat

[erik quanstrom]

>> i've got a lot of folk in the house who run whatever.
>> i'd really like to decommission the non-plan 9 machine.
>> the one thing i need from it is nat.  (and i don't want
>> to be stuck fiddling more stuff on the dsl appliance.)
>> doing nat just isn't that hard.  i just need to find the time.
>> this is about a summer-of-code sized project.  i don't think
>> it would require anything from the kernel.
>
> I beg to differ.  NAT adds complications to the already complex IP.
> Adding NAT to the Plan 9 IP stack can only make it more fragile, why
> not leave the job to the appliances that have been designed and
> constructed to deal with the problem and have been subject to very
> broad testing?

perhaps you forgot to read the part where i said
i don't think this would require anything from the
kernel; the ip would not need modification.

- erik

Re: [9fans] nat

[lucio]

> i've got a lot of folk in the house who run whatever.
> i'd really like to decommission the non-plan 9 machine.
> the one thing i need from it is nat.  (and i don't want
> to be stuck fiddling more stuff on the dsl appliance.)
> doing nat just isn't that hard.  i just need to find the time.
> this is about a summer-of-code sized project.  i don't think
> it would require anything from the kernel.

I beg to differ.  NAT adds complications to the already complex IP.
Adding NAT to the Plan 9 IP stack can only make it more fragile, why
not leave the job to the appliances that have been designed and
constructed to deal with the problem and have been subject to very
broad testing?

++L

Re: [9fans] nat

[lucio]

> perhaps you forgot to read the part where i said
> i don't think this would require anything from the
> kernel; the ip would not need modification.

OK, I read it and promptly forgot it because none of the "canonical"
implementations of NAT I am familiar with seem to be able to operate
without kernel help.  Such canonical implementations tend to hook onto
the routing code (I'm not an authority, but I used to pay a lot of
attention to these details in a previous life) and are often carefully
micro-optimised because NAT (and IP filtering) tends to be quite
resource-intensive.

Running NAT at user level would, assuming I'm not totally off base, be
quite expensive and the hardware on which it runs would have to be
pretty powerful.

To crown it all, NAT still interferes very negatively with some of the
more modern protocols (VoIP comes to mind, but I have only a
superficial understanding, so please take this with a pinch of salt)
and special arrangements have to be made to deal with the problem.

Eris raised that question for FTP, a well-known example of NAT's
shortcomings, no matter where it is shoehorned.  In my opinion, in
Unix proxies are better solutions and in Plan 9 we all know what to
look for.  For the traditional workstation configurations, there is no
easy answer.

What do you (Coraid?) use NAT for, exactly?

++L

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

[Charles Forsyth]

> Obviously, a linux server is going to have a hard time importing /net
>(in a useful way, at least until Glendix gets there).

an existing library interceptor allows Linux to "import" networks via peculiar
setups of ssh, so i don't see why that mechanism couldn't more easily
read and write a remote /net via 9P.

Re: [9fans] nat

[Sergey Zhilkin]

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

Hello !

Look at 6in4(8) sources, it uses ipmux to get packets.
This will be the first step to NAT.

P.S.: I'm using hardware NAT (by Cisco)

2008/11/16 erik quanstrom <quanstro@quanstro.net>

> >  Obviously, a linux server is going to have a hard time importing /net
> > (in a useful way, at least until Glendix gets there).
>
> i've got a lot of folk in the house who run whatever.
> i'd really like to decommission the non-plan 9 machine.
> the one thing i need from it is nat.  (and i don't want
> to be stuck fiddling more stuff on the dsl appliance.)
> doing nat just isn't that hard.  i just need to find the time.
> this is about a summer-of-code sized project.  i don't think
> it would require anything from the kernel.
>
> - erik
>
>
>


-- 
С Уважением
Жилкин Сергей

[-- Attachment #2: Type: text/html, Size: 1257 bytes --]

Re: [9fans] nat

[Eris Discordia]

> most people have plenty of power to spare on their cpu
> servers and feeding a dsl modem at < 10mbit/sec is really
> trivial these days.  were you thinking of natting >1gbit?

Needless to say, very capable (Linux-based) DSL modems with highly
configurable built-in switch, router, NAT, and firewal are dirt cheap. Why
not use one? Use D-Link and you can buy two for the price of one ;-) If you
are brand-sensitive try Linksys or Netgear, though they are known to be
picky.

In case you insist on implementing NAT I assure you that you have at least
one intent reader for any comments on how implementing NAT on Plan 9
differs from UNIX clones.

--On Sunday, November 16, 2008 11:49 AM -0500 erik quanstrom
<quanstro@quanstro.net> wrote:

>> Running NAT at user level would, assuming I'm not totally off base, be
>> quite expensive and the hardware on which it runs would have to be
>> pretty powerful.
>
> most people have plenty of power to spare on their cpu
> servers and feeding a dsl modem at < 10mbit/sec is really
> trivial these days.  were you thinking of natting >1gbit?
>
> - erik
>

Re: [9fans] nat

[erik quanstrom]

> Running NAT at user level would, assuming I'm not totally off base, be
> quite expensive and the hardware on which it runs would have to be
> pretty powerful.

most people have plenty of power to spare on their cpu
servers and feeding a dsl modem at < 10mbit/sec is really
trivial these days.  were you thinking of natting >1gbit?

- erik

Re: [9fans] NAT

[Charles Forsyth]

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

what???
i send messages out and things come back.
what on earth are they doing?
sounds more of a PRAT than a NAT box

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

From: Lyndon Nerenberg <lyndon@orthanc.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] NAT
Date: Tue, 30 Sep 2003 15:25:29 -0600
Message-ID: <2147483647.1064935529@[192.168.42.6]>


On Tuesday, September 30, 2003 4:42 PM -0400 vdharani@infernopark.com
wrote:


>> more than a casual interest for me.  I'm not particularly trusting of
>> those little NAT firewall boxes that everyone seems so enamored with
>> these days.
> whats wrong with it? I think those boxes works well (and act as
> plug-and- play firewalls).

Only if all[*] of your internal hosts do the uPnP dance with the NAT box.
None of mine do.

--lyndon

[*] Well, the ones that need to communicate with the world at large. In
my case that's all of the hosts on my internal network.

Re: [9fans] NAT

[Lyndon Nerenberg]

On Tuesday, September 30, 2003 4:42 PM -0400 vdharani@infernopark.com
wrote:


>> more than a casual interest for me.  I'm not particularly trusting of
>> those little NAT firewall boxes that everyone seems so enamored with
>> these days.
> whats wrong with it? I think those boxes works well (and act as
> plug-and- play firewalls).

Only if all[*] of your internal hosts do the uPnP dance with the NAT box.
None of mine do.

--lyndon

[*] Well, the ones that need to communicate with the world at large. In
my case that's all of the hosts on my internal network.

Re: [9fans] NAT

[vdharani]

>> We (ehg, ynl) implemented a stateful IPv6-IPv4 nat
>> (address/port/protocol translator) in Plan9. Works fine.
>
> Any source available?
>
> I just learned today that my ISP charges $10 per month per extra IP
> address (how's *that* for a profit margin), so it has become something

> more than a casual interest for me.  I'm not particularly trusting of
> those little NAT firewall boxes that everyone seems so enamored with
> these days.
whats wrong with it? I think those boxes works well (and act as plug-and-
play firewalls).

> I realize that IPv6-IPv4 is a different kind of translation, but it
> would be nice to have something to start with.
this is for use in the IPv6/IPv4 network. if your ISP gives you IPv4
network connectivity, you wouldnt need it. am i right? or am i missing
something?

dharani

Re: [9fans] NAT

[boyd, rounin]

> At least if I have the code I have control.  I also have the
> responsibility, but it's better than having responsibility without
> control.

yup, gimme the code and get outa the way ;)

Re: [9fans] NAT

[Richard C Bilson]

> whats wrong with it? I think those boxes works well (and act as plug-and-
> play firewalls).

Plug-and-play is good, no question.  But you're placing your trust in a
vendor who has undoubtedly disclaimed all responsibility for providing
you with any real security.  You don't know what's going on under the
hood, and have no guarantee that the vendor is actually fixing security
problems, or that they will continue to do so.  There have been enough
network-accessible back-doors to make me nervous.

At least if I have the code I have control.  I also have the
responsibility, but it's better than having responsibility without
control.

> > I realize that IPv6-IPv4 is a different kind of translation, but it
> > would be nice to have something to start with.
> this is for use in the IPv6/IPv4 network. if your ISP gives you IPv4
> network connectivity, you wouldnt need it. am i right? or am i missing
> something?

The point is that they did stateful NAT, which is what I'm
considering.  If there is code available, I could potentially modify
it to do internal/external translation.

Re: [9fans] NAT

[vdharani]

> The first commerical NAT product, the Network Translation PIX Firewall
> was written using Plan 9.  Nat didn't bother us because the routers all
> trashed the IL anyway.
>
> Guess one of the reasons it was called Pix?

to mean Plan 9 (P - IX)? Right or wrong?

WOW, forget NAT. It feels good to know Plan 9 was used for building a
commercial network product.

Regards
dharani

Re: [9fans] NAT

[Richard C Bilson]

> We (ehg, ynl) implemented a stateful IPv6-IPv4 nat (address/port/protocol translator) in Plan9.
> Works fine.

Any source available?

I just learned today that my ISP charges $10 per month per extra IP
address (how's *that* for a profit margin), so it has become something
more than a casual interest for me.  I'm not particularly trusting of
those little NAT firewall boxes that everyone seems so enamored with
these days.

I realize that IPv6-IPv4 is a different kind of translation, but it
would be nice to have something to start with.

Re: [9fans] NAT

[boyd, rounin]

i think it's a terrible idea.  NAT'd UDP really requires state and that's
what TCP is (roughly).  but the port space is too small and with UDP
you have no idea for how long to wait or if the datagram will come back,
so you're open to a denial of service attack (the T's can be on the
inside too).

i've seen DNS's refuse UDP requests, which have been NAT'd,
'cos they don't come from port 53 -- argh ...

Re: [9fans] NAT

[Charles Forsyth]

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

i'm not sure it is inherently a bad idea.
it's as messy as it is (and frankly it's not that bad),
mainly because many important ipv4 things were designed
before it, and the ipv6 people apparently thought they
needn't even try, similar to the length field in 802.?

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

From: Richard C Bilson <rcbilson@plg2.math.uwaterloo.ca>
To: 9fans@cse.psu.edu
Subject: [9fans] NAT
Date: Tue, 30 Sep 2003 14:05:00 -0400 (EDT)
Message-ID: <200309301805.h8UI50l24099@plg2.math.uwaterloo.ca>

I realize that there are a number of reasons why network address
translation is a bad idea, but I'm curious: has anyone ever implemented
it using a plan 9 system, and, if so, what have your experiences been?

Re: [9fans] NAT

[Brantley Coile]

On Tue, 30 Sep 2003 15:44:26 -0400 (EDT), <vdharani@infernopark.com> wrote:

>> The first commerical NAT product, the Network Translation PIX Firewall
>> was written using Plan 9.  Nat didn't bother us because the routers all
>> trashed the IL anyway.
>>
>> Guess one of the reasons it was called Pix?
>
> to mean Plan 9 (P - IX)? Right or wrong?
Correct in one!  And it meant Private Internet eXchange, a pun on
PBX, but it still meant P9 as well.
>
> WOW, forget NAT. It feels good to know Plan 9 was used for building a
> commercial network product.
>
> Regards
> dharani
>
>
>
>

Re: [9fans] NAT

[ynl]

We (ehg, ynl) implemented a stateful IPv6-IPv4 nat (address/port/protocol translator) in Plan9.
Works fine.

- Lakshman

Re: [9fans] NAT

[Brantley Coile]

The first commerical NAT product, the Network Translation PIX Firewall
was written using Plan 9.  Nat didn't bother us because the routers
all trashed the IL anyway.

Guess one of the reasons it was called Pix?


On Tue, 30 Sep 2003 14:05:00 -0400 (EDT), Richard C Bilson <rcbilson@plg2.math.uwaterloo.ca> wrote:

> I realize that there are a number of reasons why network address
> translation is a bad idea, but I'm curious: has anyone ever implemented
> it using a plan 9 system, and, if so, what have your experiences been?
>

[9fans] NAT

[Richard C Bilson]

I realize that there are a number of reasons why network address
translation is a bad idea, but I'm curious: has anyone ever implemented
it using a plan 9 system, and, if so, what have your experiences been?