ZARN-V6 (aka ZV6) Addressing

Like the RF Database Website project and Layer 2 Club concept, this proposal is the brainchild of the primary author Trevor Marvin. When writing in the first person, that is who I’m referring to... myself.

The Purpose

As part of a consistent theme in my life, I do not like unnecessary centralized authority. This is not to say that I’m an anarchist and reject all authority; only that I try to function in a way where the amount of centralized authority necessary is reduced to its practical minimum.

In the realm of computer networks, I extend this philosophy to the name-spaces of the protocols that the networks use for operation. In some cases, centralized authorities are necessary to dole out the unique assigned identifiers. When possible, I strive to have those identifiers generated in a way that does not require a centralized authority. (In the scope of this proposal, those identifiers are the unique IP addresses and ranges that are assigned to operators of devices on the network.)

In the best scenario, the only thing that will have a centralized authority is the specifiers of the protocol.

CJDNS / Hyperboria

With Respect to CJDNS / Hyperboria:

CJDNS and the Hyperboria network pretty much achieve my key philosophical goals. It provides the decentralized IP address allocation method. It is so relevant in this proposal that it warrants addressing it before continuing to the ZV6 standard.

It also does such in a way that has a nice side effect of providing a security mechanism that ZV6 does not intrinsically have. In most simple terms, your address on the Hyperboria network is related to the fingerprint (read "cryptographic hash") of your (asymmetrical) crypto-key. This pins your address to a key that can be used both encrypt and authenticate your traffic on the network.

The primary problem that I believe that CJDNS will suffer from is related to issues of scalability. The address space, at least for networks of computers (read as ‘subnets’), is flat. This is akin to the routing issues one would have with using Ethernet MAC addressing for one’s public address.

CJDNS does a decent job of tackling this issue by having their distributed lookup tables for finding capable routes.

But I believe that those distributed tables and procedure will have an inflection point where they will strain and falter in the scenario of a global network downfall. This would come from the loss of a couple luxuries that we seem to take for granted today:

When the links between networks are not as readily available (in that one has to transverse many other networks to reach a destination)
When the latency of the links is higher than we've come to expect
When the bandwidth to handle this network overhead becomes a large percentage of the available network bandwidth due to reduced available bandwidth

ZV6 Addresses

Enter the ZV6 Address Allocation Scheme:

ZV6 starts with considering the network’s physical location when assigning a range of IP addresses. One’s latitude and longitude can be reduced to a 48-bit value that has a granularity better than one foot. In essence, there is one of these unique 48-bit values at least every foot on the surface of this planet. Thus, in selecting a network range, you only need to coordinate with those in your immediate vicinity to select a unique value. (Granting, this method is not resilient against bad actors that would interfere with other communications. Protection against that threat has to come from other procedures.)

This 48-bit value becomes the basis for the network allocation. It’s also treated as an equivalent to the ASN numbers of the Internet (and certain network allocations are disallowed to prevent unnecessary ASN namespace collision).

It is my personal opinion that the centralized authority of IPv6 space is exceedingly stingy with the monetary costs for IPv6 allocations. I can see some logic in their approach with the messy state of IPv4 allocations in hindsight, but I believe that there is a better way. (I mean really Ford Motor Company. Your website is not even with the 19.0.0.0/8 allocation that you stingy bastards are still retaining. I gave serious thought to setting up there for some of my mesh network protocols.)

Thus, for this scheme, I propose squatting in an unallocated range of IPv6 space. In respect to other networks and operators (as your networking peers), you should not advertise or otherwise show that you are utilizing this part of the address space unless you know that the peer is aware of and is a participant in this project.

The range of IPv6 space that I have designated for this project is "A000::/16".

So taking this prefix and appending the 48-bit value described above, we now get a "/64" sized allocation for each autonomous network within the full network. This should certainly be enough for any single operator. (For the uninitiated, this is a network the size of a Internet of Internets. It is an address space around four billion times the size of the IPv4 Internet.)

Using a procedure dubbed foveal routing, routes near any particular router will be handled in the same way as many existing networks. (For example, in using a procedure like Open Shortest Path First (OSPF).) But destinations that are far from the router do not require retaining as much information. Given a router knowing its own location, the physical direction that a packet should be sent can be quickly derived from the destination address. A router, especially in a mesh, can then send the packet on an outgoing link which is most in the direction of the destination.

The core advantage of this scheme comes to routing, especially in a meshed network. It also limits the size of the kernel route table in routing computers, as networks that are near each other can easily be conglomerated into single route entries. By sliding the network mask value down from 64, larger and larger quadrangles of physical locations are described. Thus, the destination location of each packet does not need to be closely scrutinized as a properly set up kernel route table will intrinsically perform this direction calculation.

ZV4 Extensions

As a small extension to the above standard, a method for allocating IPv4 addresses is provided. The use of these addresses would usually be related to a smaller operational group of operators, often with a mesh of Ethernet hardware linking them. In the context of this website, that is the Layer 2 Club. This method provides a procedure for deterministically assigning a slice of 10.0.0.0/8 to users. (Or 19.0.0.0/8 if you want to show Ford that you’re displeased with their IPv4 greed.)

The method essentially takes the lower 24-bits of the 48-bit special location value to determine the lower three octets of a /8 IPv4 range. That address is then expanded by an amount, if desired, from the /32 IPv4 derived value. (Called zv4size in the context of this website.)

This method is only really intended for a smaller operational group as a convenient way to allocate IPv4 addresses for use internal to that group. The allocations repeat on a period in the order of miles, so even users within a city may have to adjust their locations to avoid collisions.

ZV6 Address Details

Details about Encoding and Decoding ZV6 Network Addresses:

The latitude and longitude values, taken as floating point numbers ranging between [-90, 90] and [-180, 180] respectively (north and east being positive), are each scaled into signed 24-bit integers. Those two resulting numbers are interlaced together to form the 48-bit network value, which is interpreted as an unsigned integer, with the most significant bit from the latitude value coming first and the least significant bit from the longitude value coming last.

The 48-bit value is treated as an Autonomous System Number (ASN) equivalent to existing ASNs. As such, ZV6 ASNs less than 2^32 are not allowed as they collide with the existing ASN standard. (This has the effect of not allowing any networks to exist between 0 and 0.70311 north latitude, and 0 and 1.40623 east longitude; but that entire area is in the Atlantic Ocean, south and west off the coast of Africa near the Gulf of Guinea.)

The 16-bit IPv6 prefix of 0xA000 is prepended to the 48-bit location value to generate a network with a mask size of 64.