[MLB-WIRELESS] National IP allocation and routing sche me??

[Simon J Mudd]

evilbunny at sydneywireless.com (evilbunny) writes:

> >> Inter AP routing wouldn't matter, the only issue is with client's
> >> being able to access servers...
> 
> SJM> Really?  If the node's router provides services like SMTP or IRC there is a
> SJM> clear need to allow connections between the servers. It also is much
> SJM> easier if you use a different address space for inter-node links from
> SJM> "client IPs" (something which hasn't been mentioned much before) as IP
> SJM> filtering can be implemented much easier if you can distinguish
> SJM> "router" ips from "client" ips.
> 
> I think you missed one slight issue, for the client to talk to the
> router it will obviously need to be on the same subnet, or at least
> know how to talk to it...

Not really.  Obviously the "client's subnet" contains an IP used by
the router (otherwise the subnet would be isolated).  However the
router having "inter-node links" will also have other subnets on
different interfaces.  The clients will probably use the router's IP
(on the same net) as the default route, not needing to know anything else.

> IPv6 is the only hope for a world wide parallel network such as what's
> being proposed could happen...

I agree.  However most of us don't have the necessary experience, and
many OSes aren't yet ready to run ipv6.  As ipv6 becomes more popular
I can see a definite need to push the wireless groups over to IPv6,
while at the same time supporting the previous ipv4.

> SJM> Preassigning addresses "just in case" is great, but is not probably
> SJM> realistic.  Other large radio networks like the ampr.org network (used
> SJM> by radio hams) did this and a great part of the allocated space is
> SJM> simply not used.  If we use dynamic routing protocols it's no longer
> SJM> difficult to add more disjoint addresses to those that are being used
> SJM> and this is much more "address friendly" than some of the selections
> SJM> being suggested here.
> 
> Little problem with efficiency however, by tacking on later this
> can do serious damage to route updates as links go up and down...
> Because you can't summarise the routes more simply...

That's true.  However I had envisaged blocks of subnets being assigned
to an area (32 or 64 subnets perhaps) and then aggregating these
routes (if possible).  This scales a little better.

Also if the major ISPs can work with huge nets then why can't we.  The
other point to think about is that at some stage perhaps renumbering
may be necessary for a group of nodes/subnets.  If we warn people that
they shouldn't consider client IPs as being 100% static and fixed then
if a renumbering/reorganisation of IPs is needed this shouldn't be so
hard.

> SJM> It's just a shame that there is no easy way to agree a global
> SJM> assignment mechanism and to use that.  Now it doesn't matter much, but
> SJM> in the future if the wireless networks grow as a lot of us hope then
> SJM> things will become much more complicated.
> 
> It's not a matter of agreeing or disagreeing, we're building our own
> internet (please no semantics) effectively with the potential to go
> world wide, how much address space do you suppose this is likely to
> take up?

I don't know, but I agree that if the expected explosion in use of
wireless devices exist the current RFC1918 addresses will be
insufficient for a worldwide wireless network.  Then again if you
think about it the address space may not fit easily on the current
Internet's address space ignoring problems about getting the required
real addresses allocated.

That's why I think we have to be aware of the potential problem and
also have to sparsely allocate the addresses needed.  This is no
different really to how RIPE, ARIN and others currently assign public
addresses if I'm not mistaken.

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 majordomo at wireless.org.au
with "unsubscribe melbwireless" in the body of the message