[MLB-WIRELESS] [proposal] IP allocation (was: DNS, DHCP, static ip... )

[David Arnold]

-->"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