[MLB-WIRELESS] [proposal] IP allocation (was: DNS, DHCP, static ip... )
darrend at natwide.com.au
darrend at natwide.com.au
Wed Nov 21 21:58:18 EST 2001
Here's another 2 cents from me (must be up to 6c on this thread)
I like their idea of node classification and subsequent address space
allocation, but I still feel that using geographics as a basis for
allocation is pointless. Given the fact that an AP can only handle a
limited number of connections, a class C allocation to each AP node should
be sufficient. Should they require more (ie nodes connecting to them wish
to run smaller subnets), then just give them more. We can still use dns for
identifying areas/AP nodes (see my previous post this thread), regardless
of the IP's allocated to them.
Darren Dreis
IT Manager
Nationwide Digital Products P/L
Tel 03 9548 9444 Fax 03 9548 9040
David Arnold
<arnold at dstc.mona To: melbwireless at melbwireless.dyndns.org
sh.edu.au> cc:
Subject: Re: [MLB-WIRELESS] [proposal] IP allocation (was: DNS,
21/11/2001 06:01 DHCP, static ip... )
PM
Please respond to
melbwireless
-->"Brad" == Longmuir, Brad <bradl at petermac.unimelb.edu.au> writes:
Brad> There is a very similar example here:
Brad> http://www.seattlewireless.net/index.cgi/IpAllocationProposal
ok, so, their approach seems to be purely geographic. they've also
retained half their address space for future expansion.
thinking about the structure of the network, i think a purely
geographic allocation model is probably more suitable for a community
wireless network than it is for a commercial wired network: our
aggregations are very likely to be based on geography, and there's far
less opportunity for "wormholes" between geographic areas (assuming
we're totally radio and have no economic disincentives to sane
connectivity ;-).
the following is roughly based on the SeattleWireless scheme, but
altered somewhat to cope with more geographical area, and an absence
of top-down structuring, since i think that is silly at this time.
so ...
1) people should suggest (in the node database) whether they want to
be a client-node (ie. one antenna linking into "The Network"), or a
CxNode (a local distribution hub, needs at least two cards and an
omni + one directional).
aside from the willingness (and finances) of the node owner,
geography plays a part in this: if you're in a hollow, in a ground
floor flat, you're probably not a good CxNode candidate ;-)
2) if there's an active CxNode already within range, you will get a
sub-allocation from them.
if there's no CxNode within range, and you're prepared to be a
CxNode, you'll get a /24 from either the nearest BxNode or from the
geographical allocation (if there's no nearby Bx).
otherwise, if there's no CxNode within range, and you are not able
to be a CxNode, then you have to wait until there is one ;-)
3) CxNodes will parcel out sub-allocations to clients within their
area.
i imagine there are two types here: single addresses, dynamically
allocated, and, small static allocations.
i'd suggest leaving this up to the discretion of the node owner,
but given people are going to want to have servers, i imagine that
NATing behind a single IP will suck, and so most people will want
at least a /30 (2 machines, incl router), and probably /28s and
/29s will be popular.
4) we have 24 bits of address space to play with. i'd suggest a
breakdown as follows:
0 0 0 0 0 1 1 0.0 0 0 0 0 0 0 0.0 0 0 0 0 0 0 0.0 0 0 0 0 0 0 0
10 | geog | BxNode | CxNode | clients
1 | 32 | 64 | 32 | per-node
ie.
- 5 bits of geographic breakdown, giving us 32 areas. a large-ish
chunk of this should be reserved for expansion.
- 6 bits of wide-area backbone node space, and,
- 5 bits of medium-area backhone node space. this gives a lot of
room to move within the backbone as we gradually build up a
spanning-tree and later a redundant mesh.
- 8 bits of local-space per CxNode. this will likely be shared
between /32 and slightly larger allocations depending on need.
4) for geographical allocations, i'd suggest a rough breakdown based
on the lat/long lines from the node map.
a simple scheme would be to forget about planned aggregation,
and allocate sub-geographical ranges incrementally as they are
required, and rely on the routing protocol handling /19 prefixes
(in the worst case) for each CxNode.
is there someone who has some routing experience who wants to say
whether this is ok or stupid?
alternatively, below is a (biggish) proposal that assumes we *need*
to get some aggregation. to foster that, i've gone for a diagonal
(NE/SW) split and also kept some spares in areas where i think we
might need some more room in future to (possibly) assist with
aggregation.
10.0.0.0/13 City
-37'45" and south to -38'00"
144'45" and east to 145'00"
10.0.0.32/13 North
-37'30" and south to -37'45"
144'45" and east to 145'00"
10.0.0.48/13 North East
-37'30" and south to -37'45"
145'00" and east to 145'15"
10.0.0.64/13 West
-37'45" and south to -38'00"
144'30" and east to 144'45"
10.0.0.72/13 North West
north of -37'45"
west of 144'45"
10.0.0.128/13 Inner East
-37'45" and south to -37'52.5"
145'00" and east to 145'15"
10.0.0.144/13 Inner ESE
-37'52.5" and south to -38'00"
145'00" and east to 145'15"
10.0.0.160/13 East
-37'45" and south to -38'00"
145'15" and east to 145'30"
10.0.0.176/13 Inner South East
-38'00" and south to -38'15"
145'00" and east to 145'15"
10.0.0.184/13 South East
south of -38'00"
east of 145'15"
10.0.0.192/13 Outer North East
north of -37'45"
east of 145'15"
10.0.0.8/13 reserved (City)
10.0.0.16/13 reserved (Inner West)
10.0.0.24/13 reserved (Inner West)
10.0.0.40/13 reserved (Inner North)
10.0.0.56/13 reserved (Inner North East)
10.0.0.136/13 reserved (Inner East)
10.0.0.152/13 reserved (Inner ESE)
10.0.0.168/13 reserved (East)
apologies for the length (and terseness) of this missive.
comments anyone?
d
--
To unsubscribe, send mail to minordomo at melbwireless.dyndns.org with a
subject of 'unsubscribe melbwireless'
Archive at:
http://melbwireless.dyndns.org/cgi-bin/minorweb.pl?A=LIST&L=melbwireless
IRC at: au.austnet.org #melb-wireless
--
To unsubscribe, send mail to minordomo at melbwireless.dyndns.org with a subject of 'unsubscribe melbwireless'
Archive at: http://melbwireless.dyndns.org/cgi-bin/minorweb.pl?A=LIST&L=melbwireless
IRC at: au.austnet.org #melb-wireless
More information about the Melbwireless
mailing list