XCIDR 2

This is basically a revision of XCIDR which I elaborated in my previous post. To reiterate, XCIDR is my uncertain brainstorm which aims to increase the IPv4 address space without resorting to IPv6 or it's required 'flag day' shifting of current IPv4 devices/applications.

To quickly recap, XCIDR relied on my observation of the first two bits of the subnet mask being unused. These two bits are encoded with IP address information to increment the address space by two or four depending on whether one of the bits is to be used as a subnet mask bit for the other one.

There's one more thing about the IP v4 subnet mask field: unlike the BCD encoding as in the address part, the subnet mask bits are pure binary (or whatever it is called). That is, to represent a number, say 13, in BCD you write it as '1101', while in pure binary it is writen as '1111111111111', or thirteen ones.

How did this come about, and why is it still being used? For this, we need to remember that the subnet mask is only the number of contiguous 1s to be ANDed with IP address for finding the longest-prefix-match. Sometimes ago when CIDR was just on the brains of it's creator, non-contiguous bit-masks were used as subnet masks. This scheme can split the network at more than one place. This requires a bit-mask instead of the BCD encoding.

But why non-contiguous subnet masks were introduced, nobody knew. But it was causing a lot of 'splitting'-headaches among the network admins. So it was advised against, but not made illegal, since it is perfectly compliant with the subnetting scheme. Which, in-turn meant that the 32 bit bitmask format stays. Later on, it was so hard, and hence unpopular, to have a non-contiguous subnetted network that routers stopped supporting it. Now, with CIDR and it's slash-notation, non-contiguous subnet masks are just plain illegal [link].

Which, as you might surmise, draws a case against the 32 bit subnet bitmask in present machines, and toward a 5-bit BCD encoded subnet mask. IPv6 makes this the standard. But IPv4 doesn't, as it would break all the current routers. True, but following the spirit of XCIDR, we might change the router and end-node logic without changing the IP, IGP/BGP/etc packet structure to acheive an increase in the size of IPv4 address space. I call this version of XCIDR as XCIDR2. It aims to increase the IPv4 address space from 2³² to 2⁵⁸ !

Here's how:
A subnet mask has 32 bits. Only the count of the number of 1s is needed off the subnet bitmask. The maximum number of 1s that can be in a 32bit field is 32. Representing it in BCD will require log₂32, or 5 bits. Now we are free to do anything with the remaining 32-5 = 27 bits.

If we are to allot some of the 27 bits to the IP address bits, then we need to allot extra subnet bits to the subnet mask to act as subnet mask bits for the new address bits. How to split the subnet mask bits now? With 5 bits the subnet mask can be used with a 32bit address field. Increasing the bit count by one will make the subnet mask 6 bits long. A 6 bit subnet mask in BCD can represent 2⁶=64 contiguous 1s (ones). This is more than enough, for when you add the remaining bits (27-1=26 bits) to the IP address, you get 32+26 = 58 bits.

So, finally what we have is an Ipv4 scheme with a 58 bit IP address, which can support about 288,230,376,151,711,744 hosts (288 quintillion). It's not much compared to an IPv6 address space, but can take care of any address space shortage before the IPv6 flag day, which by the way is not expected before the year 2025.

[Just for the 'ooh' factor: Ipv6, with its 128 bits, has been described thusly: If the earth were made entirely out of 1 cubic millimeter grains of sand, then you could give a unique address to each grain in 300 million planets the size of the earth.]

As in XCIDR, the IP address field and subnet mask field remains the same. This means that packet structures and routing tables need not be modified. Only the packet handling logic needs to be changed, both in the router and the end-nodes. The exact changes to the logic will be as in my XCIDR blog post. The only place it deviates from the plan is at the router.

As in XCIDR, we have an issue which can have many solutions. Then, it was the choice of XX and XY implementation. Now, it is the issue of choosing the division of the 26 extra address bits. The problem is obvious and straightforward: 8 is not a divisor of 26. This means that the highest octet in the address will not have 8 bits in them when you split it into 8 bit portions. 2 bits remain (26/8 = 3.25). In other words, the address will look something like this:
11.1111 1111.1111 1111. 1111 1111.1111 1111.1111 1111.1111 1111....

This question arises only because we are accustomed to such addreses which was introduced in a classful addressing system. With CIDR and VLSM, it makes no sense. Right? But we still 've got the human factor: Dealing with arithmetic involving upto 255 (2⁸) is better than dealing with arithmetic involving numbers upto 67,108,864 (2²⁶). So, I am gonna go with a partitioned space rather than an unpartitioned 26 bits. But how many bit partition will be the optimal? '13/13', or '2/8/8/8', or maybe a '10/16' scheme? I'll leave that discussion for later. For now, '2/8/8/8' bit scheme seems good and standard to me.

A router, will have to store an address of the form 4.255.255.255.255.255.255.255 in order to address an XCIDR2 network. This can be accomplished by storing the bolded part, as explained, in the subnet mask bits. When the router encounters an IP packet addressed to such a host, it simply concatenates the 26bits from the subnet mask and the 32 bit IP address in memory and runs the longest-prefix algorithm of CIDR just like always.

To address the issue of carrying the extra 26 bits in a standard IPv4 packet, I'll stick to the trick used in XCIDR of using the Options field in the IP packet. The reserved option mode ('11') can be used for this purpose. The only precaution a end-node/router will have to take is to ensure that the router it is sending the packet needs to be XCIDR compliant.

For all it's promise, XCIDR and XCIDR2 are far from realization because of the same problems plaguing IPv6: Less demand and cost of migration. And of course, the fact that this is a 'hack' at best is enough to turn heads...in the opposite direction :) But I am still keeping my fingers crossed for a chance at an RFC.