Non routable IPv6 registry proposal

[Phillip Hallam-Baker <[e-mail]>]

First off, before I start, can I please ask that nobody respond with 'that
is stupid, that is not how it works'. One of the reasons people avoid this
list is precisely the fact that they see proposals regularly shot down in
those terms. And especially so with proposals like this one which go
against positions some people hold which I consider 'ideological'. In
short, people who respond that something is wrong without taking the time
to explain or justify their position are disrespecting us all.

This idea comes from a discussion with Bob Frankston on Facebook, the idea
here is mine though, and not endorsed by anyone else. But it is my
experience that putting together a clear description of the problem is
usually the biggest obstacle in discovering a solution.

The proposal is to reserve a significant block of IPv6 space (e.g.
2002::/16) as non routable address space to be allocated in Class A/B/C
sized chunks on a permanent basis either through random assignment or by a
new registrar TBD for a negligible one-time fee ($0.10 or less). This would
provide significant operational benefits for large enterprises managing
complex networks.


The background to this proposal is as follows:

0) Nowhere does the 'end to end' principle demand that the source and
destination addresses on an IP packet remain constant.


1) NAT is here to stay. IPv6 does not eliminate the need for NAT except for
enterprises which 'own' their IPv6 address blocks.

I have IPv6 service from Verizon but I obviously can't use it on my
internal network because my IPv6 address changes every few months. This is
certain to be the case for virtually every residential Internet drop and
the vast majority of business customers.

The logical and widely adopted solution to this problem right now is to use
IPv4 internally within sites and to perform NAT at the network boundary.
Which works fine when you only have one site.


2) NAT multiplexing will become an increasing problem

Current NAT conflates two functions. The function of translating IP
addresses at the network boundary will continue to be motivated by
operational and security concerns that are not going to go away.

The function of multiplexing multiple hosts onto a single IPv4 Internet
address is never going to go away but only for the limited number of
Internet hosts that require that access. I have a very large number of IP
connected devices in the house but I really don't want the coffee pot
talking to the open Internet.

As people end up with thousands of devices inside their home, port
exhaustion at the NAT box and the ridiculous complexity of it all is going
to become a major headache. Sharing one IP address between 100 hosts works,
its not ideal but it works right up to the point where you decide that you
need fault tolerance and you are going to need two NAT boxes and the
mapping data has to be synchronized.


3) 10.x.x.x is not enough

Even today, there are very few enterprises that have 16 million active
hosts. But every enterprise of any size has multiple net 10 address spaces
and multiple conflicts between them.

Consider what happens when Alice's Bank buys Bob's bank. Even though Alice
and Bob diligently ensured that every machine in their separate networks
had a different IP address in their separate spaces, they both started
assigning subnets to branches starting with 10.0.0.x


Solution

The solution is to provide a non-routable space where address block
collisions are unlikely. Each enterprise that uses this space is assured
that the probability of collisions is small. This can also be used within
existing enterprises to regularlize mapping of the typical horrorshow of
hundreds of overlapping 10.x.x.x etc. spaces onto a different private range.

The only ways to avoid collisions are either to (1) randomly assign spaces
in a sufficiently large space or (2) have a registrar whose function is to
guarantee uniqueness.

The largest IPv6 space we could assign is a /16 giving us 2^112 addresses.
If we set the allocation chunk to 2^24 (cf net 10) we have 2^88 assignable
blocks. Which means that if these are assigned at random, there should be
less than a 50% probability of collisions until 2^44 assignments have been
claimed and are in use.

This is probably sufficient. But a registry model would make for more
efficient allocation of the space and allow the allocation to be bound to a
public key whose private part is held by the registrant.

The obvious model to use for this approach is an append only log (c.f.
Certificate Transparency, Blockchain) whose apex value is attested by the
registrar (no, proof of work is not acceptable).


The part I like about this model is that it provides quite a bit of
leverage when we look at questions of how to address DDoS attack and mobile
IP addresses. It allows us to effectively create the effect of a bump in
the stack without imposing a cost.

The Internet model is that routing happens in the network. But what if
that's not the only place we can route to advantage? This approach gives us
two separate IP address spaces. The public internet routing space and the
private space that gives a unique assignment to each device. It's a bit
like a MAC address but expressed as an IP address.

So this allows traffic patterns where as far as Alice's mobile and Bob's
desktop are concerned, a communication is established on the 2002://16 net
and is constant the entire time. But behind the scenes, those addresses are
being mapped to/from Internet routable addresses at the network boundary
and those mappings are changed dynamically as Alice moves about from her
home IP network, to her wireless provider, to her company provider. If she
is at home and a tree takes out her Fios (like happened to me), her mobile
provider simply kicks in without a pause.


[Yes, I know there are similar ideas. But having an assigned private
address space that is globally unique but not used for Internet routing
helps simplify those as well]