Non routable IPv6 registry proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux