** [#ip_address_space_must_be_controlled_for_the_following_reasons IP address space must be controlled for the following reasons]

** [#to_allocate_in_a_way_that_satisfies_these_demands_requires To allocate in a way that satisfies these demands requires]

*** [#so_what_are_the__needs_of_requestor__ So what are the 'needs of requestor'?]

*** [#what_information_do_we_need_on_the_requestor_ What information do we need on the requestor?]

*** [#how_do_we_allocate_in_order_to_support_the_routing_architecture_ How do we allocate in order to support the routing architecture?]

!! IP address space must be controlled for the following reasons

* it is a limited resource

* controlled allocation required to allow for routing scalability

* administrative control needed to allow interconnection / uniqueness



!! To allocate in a way that satisfies these demands requires

* consideration of needs of requestor

** web based entry, eyeballs to assess?

* a system to record allocations

** database, backed up, identity of requestor, linked to node map?

* allocation based on location in topology

** as described in routing architecture



!!! So what are the 'needs of requestor'?

* how many wide area wireless interfaces in routing nodes (as defined in [AddressAllocation address allocation]) - now, and anticipated. This converts into the allocated and reserved number of IP addresses in backbone address range.

* how many clients do they expect to have (now and in future)

** connected on their site

** on other sites via subtended wireless to nodes that are not wide area routing nodes



!!! What information do we need on the requestor?

* node map identifier (e.g. CIA)

* verification password

* do we trust that drew has the rest?

** Drew: yes, we could even use the same password, and/or store this info in the current db

* an acknowledgement of the terms upon which addresses are assigned, e.g.

** the assignment may be withdrawn

** that they agree to configure systems within the bounds of the assignments in order to interoperate with other melbourne wireless nodes



!!! How do we allocate in order to support the routing architecture?

* need a way of allocating backbone IP to begin with

** the 512 addresses in 172.16.80.0/23

** There are 85 'going' nodes as of 20/5/02

*** The intent is that growth of nodes in the backbone is slowed, as new nodes are diverted into areas hanging off the backbone. If the backbone grows larger than 512 nodes OSPF will struggle anyway, we would need to split the backbones and have them peer with each other via BGP or the like.

** We will put all these in the backbone to begin

** Divide the area of metro into 16 regions of similar number of nodes

*** this is 32 addresses form backbone for each region

*** should we use electorates?!!