This page contains a suggested approach for allocating IPv6 addresses within the Mesh. Only two node types are used in this document, namely backbone and client nodes, whose meaning should be clear.
So, you want to get an IPv6 address for your node in the Brisbane Mesh? OK, then you will fall into one of these categories:
On the other side, if you are a backabone node with an address space already, here are some ways of dividing the address space up for peer backbone nodes:
You've got a single antenna and want to attach to a nearby server node.
Try these in order:
fec0:02::0060:1dff:fff7:2109
and your MAC address is 00:60:1d:1e:26:ee, then
your last-resort IP address is
fec0:02::0060:1dff:ff1e:26ee. (Can you see the pattern?)
You want to set up a point-to-point with a nearby (backbone) node who has just put up an antenna dedicated just for you.
Needs more work
You're the first node in an area, you can't connect to anywhere else and you've got plans to have people connect to you.
Note: Try as hard as you can to get an address space allocated to you from some nearby backbone node, because by allocating an address using the next step introduces complexity into the routing tables, and therefore increases the overhead of routing traffic.
If you've talked with other backbone nodes, and things look grim, then you can choose one of these two steps:
fec0::/10
(see RFC1884).
For example, the first seed prefix issued will be
fec1::/16.
The seed prefix fec0::/16 is specifically reserved for personal
(or sub-site) use and will not be routable on the Mesh.
You are already a backbone node with an address space and you want to give out addresses to your peers.
This section describes how to efficiently subnet for strongly tree-shaped networks.
We are mostly concerned with routing overhead, and not so much with
address space exhaustion. So, the following subnetting scheme is
described in the context of
site-local address spaces (i.e. those that start with fec).
In general, router addresses will be in the following form:
-----10----- ---6--- -------------48------------ -----64----- 1111 1110 11 | rrrr rr | aaa bbb .. ccc | 000 .. 000 | xxxxx..xxxxx SL prefix | seed id | NLA ident | zero | interface ID -------------network-part-------------- --------host-part--------
The first 16 bits identify the address space of a seed node, consisting of the 10-bit "site-local" prefix, and the 6-bit seed number.
The next 48 bits are broken up into 3-bit "next-level" addresses. The first of these indicate the address space delegated to "2nd level" peers, i.e those peers connected directly to the seed node. The next triple of bits after that indicating the address space of "3rd level" peers which are those directly connected to 2nd level peers, and so forth. There is sufficient space to split into 16 levels. (i.e. an n'th level host has a prefix of length 16+3(n-1) bits.)
The last 64 bits are the EUI-64 interface ID, which is derived from the network interface's 48 bit MAC address (by inserting ff:ff or ff:fe into the middle).
Let's go through an example.
Say you are a 4th level node
with a WaveLAN card with MAC address 00:60:1d:f7:21:09
and have been given the subnet prefix
fec1:2e80::/25 by your "upstream" (level 3) backbone.
Your 25-bit, level 4 subnet prefix can be broken up in the following way:
--f- ==e= ---c- ==1= -:2--==e==-8--- 1111 1110 11 00 0001 001 011 101 ------------ -- ---- --- --- --- S.L. prefix seed # L2 L3 L4
But what is your host's address?
Because your backbone node is "multihomed", you will have two addresses;
namely the one that your upstream provider sees, and the one that all your
clients see.
Your clients (and the rest of the mesh) should now know you as
fec1:2e80::0060:1dff:fff7:2109.
Aside: Actually, your upstream provider can reach you through 3 addresses:
fec1:2c00::0060:1dff:fff7:2109 (on his net),
fec1:2e80::0060:1dff:fff7:2109 (on your net),
fe80:0000::00e0:1dff:fff7:2109@wi0 ("link local" address).
After a while, your backbone node will attract a peer.
Let's say that this first peer wants an IPv6 address, but only
wants to act as a client and not route anything.
Let's also say that his network card has the MAC address
00:60:1d:f7:34:44.
First, you simply convert that MAC address to EUI-64
(i.e. 0060:1dff:fff7:3444)
and place that at the end of your subnet
(i.e. fec1:2e80::0060:1dff:fff7:3444) and that becomes
his mesh-routable address.
You tell him that his prefix length (netmask)
is 64 bits long
(i.e. fec1:2e80::/64)
and that you are his primary gateway to the mesh (default route, or
fec0:/16).
Everything chugs along nicely, until one day, along comes a peer who wants not only to be a client but also to be a router; there are some people around him living in a gully. So, you and he go to the trouble of setting up a wireless link over a longish distance, and now you have to carve up your subnet so that he can have his own to delegate out to his clients.
Since this is your first downstream backbone peer, you
choose the three bit number 001
(as 000 is reserved for your net.)
Recall (from the previous example) that your subnet prefix is
fec1:2e80::/25.
Simply add the three bits 001 to the end of it (to get
fec1:2e90::/28), and that becomes your downstream node's
new subnet.
This new prefix can be broken up in the following way:
--f- ==e= ---c- ==1= -:2--==e==---9- 1111 1110 11 00 0001 001 011 101 001 ------------ ------- --- --- --- --- S.L. prefix seed # L2 L3 L4 L5
Of course, both you and he need address management and routing software issues. [And this has to be researched and written up!] The hierarchical part of routing could be set up statically; or at least configured as the default case in any dynamic routing software. Try to use the link-local addresses of the interfaces for all routing paths.
A similar scheme can be used for 6to4-based address spaces, except that
seed nodes start off with 2002:WWXX:YYZZ/48 address spaces,
instead of fecn::/16, and 6to4 addresses are already
globally routable!
The primary benefit of carving the address space up in this fashion is that the backbone is then naturally addressable as a tree structure and routing is highly aggregatable. The maximum diameter of a site-local network partitioned like this and centred at just one seed node is 33 nodes. Other seed nodes should be reached beore this distance is exhausted.
Because only 3 bits are given out at any one time, and 000 is reserved for the upstream net, we reserve the TLA bit patterns of 110 and 111 to indicate virtual subnets that the node also owns. In this way, when a node gets its 6th and 7th clients, it can affix the bit patterns 110000 and 110001. This expands the number of clients to 21. Sites expecting more than 21 but less than 63 client nodes should consume a steps of 6 bits to begin with and reassess when they reach their 47th client.
The site-local address space is only meant to be valid in a site-local scope. Site-local scopes are defined in an IETF draft as:
o Site-local scope, for uniquely identifying interfaces within a single site only. A "site" is, by intent, not rigorously defined, but is typically expected to cover a region of topology that belongs to a single organization and is located within a single geographic location, such as an office, an office complex, or a campus. A personal residence may be treated as a site (for example, when the residence obtains Internet access via a public Internet service provider), or as a part of a site (for example, when the residence obtains Internet access via an employer's or school's site).
Using a site-local address space over an entire metropolis is significantly stretching the "single geographic location" statement.
The subnetting strategies described above contain examples that make use of the
fec0::/10 site-local address space.
This allows them to be just as applicable if we ever
acquire a large, globally routable IPv6 address block; or if we decide
to go with a 6to4 address space.
I think our main reason for using the site-local address space would be
the cost of acquiring a real IPv6 block, and the unreliability/reliance
of using an IPv4-derived "6to4" address block.
Another benefit of using the site-local address space is that we reinforce the image that the mesh is not being used for commercial traffic (since site-local addresses are not globally routable.) (Note that one could still theoretically route Internet traffic through the mesh in the form of VPNs and simple tunnels.)
Perhaps the major problem with using site-local addresses (or RFC1918 addresses)
is that we run the risk of colliding with networks that already use them.
In this case it will not be possible to directly connect them to the mesh.
One solution is to use IPNAT, but this has been found to be problematic, as
many higher level protocols (e.g. FTP, Quake) are broken by address translation.
Another 'solution' is to reserve a likely-looking part of the address
space in an attempt to mitigate the most likely collisions.
I've done that above, by reserving fec0::/16 for such
private ('site') use.
What other groups are doing: