No subject

document as I've written it saying anything different.  The hard part
is the network router's setup, not the client's.

> I disklike the vision of a user being only one computer, and much
> prefer the idea that this box is a gateway for n users.

I'm not sure I follow you.  The node's router will allow any number of
simultaneous clients to connect and use it.  If one of these clients
wants to hide more PCs behind NAT the node's router won't know and
this would be transparent.

> A dynamic mesh can deal with this easily, but at a cost of gobling
> up lots of IPs.  NAT, although evil, is my friend.

NAT within the network is not something I think is a good idea. I
think it won't give you a real network.  Perhaps we are talking about
different things?

> Comments:
>
> 1) Hierarchical structure does not work for mesh networks, varients of
>    mesh are the future.  OSPF will not be used for mesh networks, mesh
>    protocols will be.  Your definitions don't fit well with mesh networks
>    since everyone is a node and a router.

Which protcols would you recommend, so that I can read up on them?

> 2) OSPF not RSPF, RSPF handles radio links better.

Strangely enough RSPF is nice and I've used it over AX25 some time
ago. There's a problem though with 802.11 in that for a packet to be
sent from A to B some additional RTS and CTS packets are sent, and
this _requires_ a bidirectional link. RSPF assumes that if router A
says it can hear router B then it can setup a uni-directional link to
router B and talk to it, even if the replies come back from another
router C.  I don't think this will work with 802.11 as the MAC
protocol/layer won't allow this.  Perhaps if you know better you can
point me to some specs?

> 3) Dynamic configuration depends on a central authority, well this
>    sort of is related to #1 but is important enough to mention in it's
>    own right.  Frankly IP allocation in a mesh network is a bit more
>    difficult and attempting to use networks to reflect locality (what
>    I am attempting) results in sparse address space usage to allow
>    route aggregation to avoid routing table overload.  And there is
>    no central authority in the network, just loose cooperation at
>    nodes that link the various meshes to each other.

But if you have Melbourne Wireless and I'm part of MadridWireles
complete anarchy can't prevail.  Some sort of consensus as to
standards and practices need to exist if you really want to make a
city wide network which works.  Again perhaps we are trying to solve
different problems?

> 4) IP allocation depends on agreement of all groups which will not scale
>    since we're generally a bunch of anarchists.

This can be a problem, yes. If you don't want _ever_ to connect to
MadridWireless then fine you have no problem and can do whatever you
want.  If you consider it might be nice in the future to do this then
it helps if there are some rules, which have been commonly agreed.

>  NAT will save us, but this
>    will require globally unique IP name space that is much larger that the
>    RFC 1918 blocks.

The RFC1918 blocks is a clear hack. Why? Because if I go and ask for a
real class B block for Madrid RIPE will laugh in my face.  Maybe if I
go in a year or two's time with 100+ nodes running 24x7 then they just
might take me more seriously. I think other groups are in the same
situation.  I'd love to be able to use 44.x.x.x, the ampr.org address
space for this, but the person who requested this block had a vision
and radio hams worldwide can use this.  Ideally we need something
_similar_.

>  Fortunately we have the internet assigned IPs for that,
>    even though we may route those IPs over wireless.

I still think of wireless as just another medium, with unsual and
special properties.

> 5) It is dangerous to depend on RFC 1918 addresses routing outside their
>    immediate control.

If you agree with other groups on a common set of RFC 1918 addresses
there's no problem. If you can't agree you shouldn't try and "join up"
as my document suggests. At the end of the day this is
opt-in-if-you-like-it, nothing else.

>  Frankly the backbone/mesh network I am working on
>    will use the whole 10.x.x.x/8 space, sparsely.  These IPs were
>    allocated to do this type of thing, and frankly depending on anything
>    else is abusing the RFC IMHO.  Did I mention those addresses were
>    intended to be completely under local control?  Did I also mention
>    that the backbone nodes will be eating a good chunk of the 192.168.x.x/16
>    space negotiating unique links dynamically?

I guess everyone is free to choose the best method they see fit. If
you point me to a link of "how you would do it", I'd read it with interest.

Simon
--
Simon J Mudd,   Tel: +34-91-408 4878,  Mobile: +34-605-085 219
Madrid, Spain.  email: sjmudd at pobox.com,  Postfix RPM Packager

--
To unsubscribe, send mail to minordomo at wireless.org.au with a subject of 'unsubscribe melbwireless'  
Archive at: http://www.wireless.org.au/cgi-bin/minorweb.pl?A=LIST&L=melbwireless
IRC at: au.austnet.org #melb-wireless