This document outlines the role of IPv6 in the Brisbane Mesh, and makes a recommendation for address allocation
The Brisbane Mesh project is a cooperative data network. Like most networks, there is a requirement for unique identification ("addressing") of individual nodes. IPv4 addressing recommendations have been described in an accompanying document [see IPv4-2002 WG].
IPv6 is an IETF standard for both addressing nodes and for packet headers. This document is concerned with recommending a scheme for allocating addresses to participants in the network.
The mesh is assumed to be a large collection of fixed, site-to-site links that change only slowly over time. Sites that are connected are most likely to be geographically proximate, and the number of links per node is expected to be low, resulting in a network graph that is strongly tree-like rather than highly connected.
The relationship between the mesh network and the global internet is currently 'disconnected', although in the future this may change; having globally routable addresses for participants' hosts is a preference. Routers within the mesh need not have globally-unique addresses, but they certainly should have mesh-wide unique addresses for the purposes of diagnostics and analysis. Internet connectivity can still be achieved using IPNAT, multi-homed proxies or other services.
Overhead in routing protocols such as BGP and OSPF can be minimised by exploiting route aggregation; that is, when the network is physically connected in a hierarchy, the same way that addresses are arranged in a subnet hierarchy.
[Note- it might be useful to look at http://www.itee.uq.edu.au/~mesh/ipbrowse/ while reading this]
This section describes options for choosing the initial 'block' of IPv6 addresses to allocated individual addresses from. How to break this block up is handled by the next section (section 3). Instead, follows are a list of possible starting points for address selection.
Addresses are able to be chosen from anywhere in the entire IPv6 space.
This is bad, because the standards reserve large chunks of the space for things like multicast, IPv4 and site-local use. Software written to use standard IPv6 allocated hosts would not work properly.
fec0::/10)The site-local address space corresponds to RFC1918 for IPv4. Again, some software may rely on these addresses being free. The meaning of 'site' is also probably closer to 'node' than it is to the mesh network as a whole. (the mesh scope is probably best matched with words such as 'organisation' or 'enterprise'.)
In addition, people at home may already be using site-local addresses for their home network, and such addresses would conflict.
fee0::/11)
This divides the site-local address space into two. By convention then,
home users could use the lower half (fec0::/11)
for site-local use,
but know that the upper half (fee0::/11) is for the mesh.
Similar problems could arise if that half is already in use.
2???:????:????:????/48)
It costs about USD$5000 with ongoing annual costs (USD$2500 pa) to get
a licence from APNIC to use a /48 block.
The block would be internet routable.
The restriction on the /48 block is that the lower 64 bits are
interface MAC addresses. Practically, this leaves only 32 bits
for dividing up amongst the mesh routers.
This is a possible solution if a benefactor can be found that will buy such addresses - however it would have to be a long-term committment. The cost per address decreases though as utilitisation increases, so if incorporation occurs, this would be a certain candidate for expenditure of membership fees.
a000::/3)This is risky because IANA could allocate this subnet for something one day, and then the mesh users would have to renumber if they were connected to the internet. On the other hand, if users want to get access to the commodity internet, then they would probably be given an addr by their ISP.
Still it means there is a high likelihood of uniqueness, but we'd be operating outside the (costly) structure of IANA.
5f??:????:wwxx:yy??::/64)Test addresses are described in RFC1897. Bascially, it acknowledges future renumbering of the system. However, the addresses are not properly routable in the global internet.
2002:wwxx:yyzz::/48)If someone aready 'owns' an IPv4 address, this can be converted into a 6to4 address [RFC3056], resulting in a 48-bit subnet. Again, the lower 64 bits are reserved for interface ID (MAC addr), so the effective subnet size is 16 bits.
8000::/3)This subnet scheme is not documented. Perhaps it might be something like a quadtree-encoding of latitude, longitude and altitude?
For example, if your node's location is latitude X, longitude Y, altitude Z, and you would write these in binary as xxxxxxx, yyyyyyy, zzzz such that the lat/long have 50 bit precision and the altitude has 25 bit precision (maybe with 1 bit indicating negative), scaled to make maximum use of bits: e.g. 359.9° = 11111111..)
Then you form the address of a node like this:
1 0 0 (so as to place
the address in the 8000::/3 subnet).
The address should then appear like this (in base 2):
100yxyxy xyxyxyxy : xyxyxyxy xyxyxyxy : xyxyxyxy xyxyxyxy
: xyxyxyxy xyxyxyxy : zxyzxyzx yzxyzxyz : xyzxyzxy zxyzxyzx
: yzxyzxyz xyzxyzxy : zxyzxyzx yzxyzxyz
This means that geographically-proximate nodes will have very similar prefixes, which assists routing. Unfortunately, if a site moves, it would have to renumber!
(Technically, this is also an allocation scheme: the starting point is
8000::/3)
I cannot find anyone using this address space.
Hosts and routers are allocated numbers according to owner's whims. A central registry/database of addresses is maintained, and addresses are allocated in a first-come, first-served manner.
Such a scheme would result in uneven use and exhaustion of the resource, and extreme routing overhead. The only benefit from this scheme is that the 'uniqueness' criterion is maintained.
(This scheme is described here only for completeness.)
Addresses are allocated using the node's ID from the online web database.
Problems: would have to reserve a predetermined number of bits; say 16 bits - meaning that the node IDs run out at 216. Node ID reuse would also be an interesting problem.
Using nodeids doesn't exploit physical proximity, and therefore, routing overhead might be significant. If links change only slowly, then this may not be such a problem. It just means big tables on the routers; but with RAM and CPU prices going down and performance going up, this might be acceptable.
Individual ("seed") nodes are given big chunks of the address space, and they then divide that space up amongst their direct peers.
Administrative costs are then bourne by everyone; although policing of it would be problematic (how to keep fairness; resolve disputes?)
heirarchically allocated addresses make routing overhead lower.
Using a scheme similar to that in section 2.8, subnets are determined directly from a node's physical location.
This scheme allocates initial seed nodes using addresses based on section 2.8, and then delegates allocation to the seed nodes as per section 3.3.
The address space would be broken up as follows:
| fixed prefix | seed geography | next-level hierarchy |
|---|---|---|
| 3 bits | 9 + 8 bits | 108 |
Latitudes and longitude would need to be scaled to the integer ranges of 0 through 511, and 0 through 255 with 0 indicating the meridian and the south pole.
Worked example: a seed site at -27.48° latitude, 153.21° longitude
would become
rint((-27.48 + 90)*256/360), rint(153.21*512/360), or
(44,218). In binary this is (001011002, 0110110102),
which when interleaved (longitude first) is 001011001111001002.
Thus, after inserting 100 at the beginning, the prefix for
the seed node is 1000 0101 1001 1110 0100, or
859e:4000::/20.
The working group recommends the following schemes to be used by the Brisbane Mesh: