= IP Addressing =

== Approaches to IP Addressing ==

== IP Address Ranges ==

The two main options are:
 * Public addresses without NAT. This option is nice if you can manage it, but it is often difficult to get IPv4 addresses allocated in any reasonable quantity.
 * Private or otherwise NATed addresses. Can be a little annoying at times, as NAT is not perfect, but anyone can do it.

Below are some approaches to private and public addressing that are either common, or have potential.

=== Private Addresses ===

There are three main address ranges that are typically used for private networks: (1) 10.0.0.0/8; (2) 192.168.0.0/16 and (3) 172.16.0.0/12. These are defined in RFC1918.  The IP network allocated for [https://en.wikipedia.org/wiki/Zero_configuration_networking Zeroconf networking] (169.254.0.0/16) can also be used for network nodes.

These have the advantage of being well known, and reasonable in size. However, the [wikipedia:Birthday_problem birthday paradox] causes some problems. For example, 192.168.0.0 has only 65536 addresses, which means that if people choose an IP address at random, a collision is likely with a network of only 256 nodes. It is a bit better with 10.0.0.0/8, where the 16.7x10^6^ addresses means that a collision is likely after about 4,000 nodes. This all assumes random address allocation, and people are rarely random! A common solution here is to have some kind of IP allocation system, but these are not fool-proof.

There are ways to mitigate the problem the Birthday Paradox presents by probing the local network to determine if a given IP address is in use or not.  Success has been gotten by pseudorandomly generating RFC1918 addresses and using the [http://linux.about.com/library/cmd/blcmdl8_arping.htm arping] utility to ask if any node has claimed it, and either backing off and trying again or claiming it for use depending on what the utility returns.  arping is included in the standard GNU iputils package, so chances are it is available on any Linux machine you try it on.

Another problem with the public IP address ranges is that many networks use them, so NAT is required between networks, causing potential for further entertaining problems.

IPv6 should be a good solution here, as it does offer truly unique IP addresses based on the MAC address of your wifi/ethernet card.  However, the long addresses can cause trouble for the traffic overhead of the mesh. Inverted list compression techniques could be applied here, for example, [wiki:InterpolativeCoding interpolative coding], which can compress lists of ascending numbers surprisingly well.

=== Squatted Public Addresses ===

Some networks pick a large existing IP allocation, for example an allocation by a military organization that they assume their network will never need to connect to.

Amateur radio operators have been allocated [https://en.wikipedia.org/wiki/AMPRNet a block of IP addresses] for use with TCP/IP-over-packet radio use (44.0.0.0/8).  It may be possible to squat on this address space due to how little use it reputedly sees these days.  Additionally, there is a subnet in Network 44 (44.128.0.0/16) which is considered equivalent to those outlined in RFC1918 that could be used for experimentation.  To date, whether or not this has been tested is unknown.

=== Class E Addresses ===

Class E is 240.0.0.0/4, i.e., 256 million IP addresses at the top of the range. These will never be allocated because ordinary routers typically will not handle them correctly, because they are marked for experimental use only. However, on a mesh, we provide our own routing, so this is unlikely to be a problem. Moreover, meshes are surely experimental!

We could set up an allocation scheme among our networks to allocate globally unique Class E addresses to meet our needs for many years to come. This would allow very easy federation of our networks.