XCIDR

The acronym 'XCIDR' is what I called one of my pet projects that I was toying with when I was at college. Though it has not a lot to do with CIDR, I called it "eXtending the CIDR" to catch the spirit of CIDR's effect on the IPv4 address space. XCIDR aims at irrupting the address space of IPv4. XCIDR aims to increase the IPv4 address space atleast by a factor of 2, and at the most by a factor of 4. It tries to accomplish this feat while not requiring as wide a change in the IP network as a migration into IPv6 would require.

Let me explain. An aspirant, aspiring to increase the IPv4 address space, can do so by following one/all of the following strategies:

->find a better encoding for the address bits to pack-in more information,
->create a better allocation model or a better hierarchy of nodes in a network to increase the mileage of the address bits,
->increase the number of bits allocated to the address field.

I have no idea on how to optimize the existing power-of-two binary encoding scheme to employ the first option. The second option is explored by CIDR. The last option is the easiest one, and is explored by IPv6, and by me in XCIDR.

Simply increasing the number of bits in address field would work, but, you may ask, "isn't there IPv6 already here for it?". And you'd be right (and wrong too. Wait for a future post on truths about IPv6). But I don't intend to replace IPv6. What I want to do with XCIDR is to give the ailing IPv4 address space a couple of life breaths before it eventually reaches the end of the line. The trick is to keep the existing network/connected peers working with little or no change to them. Most important of all, the IP packet structure and the routing table structure shouldn't change. But there will be a change in the logic of IP packet handling and router logic. The DNS fields needs to be changed too to accomodate another field.


The idea:

The ideas behind my idea can be summarized in the following points:

->The Subnet masks don’t follow a power of two notation like the IP address. Rather they are made of contiguous ones (or for the pessimistic, zeroes). In other words, you won't find an subnet mask like 192.255.255.255. Non-contiguous subnet mask bits are extinct (which is why IPv6's subnet mask storage is different).
->CIDR says that you can use /30 to /0 aggregation. However, the only "useful" highest aggregation I've seen is /4 (multicast addresses).
->For example, a /3 address represents addresses from 31/3 to 224/3
It is difficult in the least to find a router that connects to such a large and paricular portion of the IP address space. This is because the address space is split into blocks and is owned by a variety of organizations. But such aggregation is not impractical at all. An admin working for a very major ISP may find himself in some circumstance to require this.
->But with /2, the networks get so big and fragmented that it is inconceivable (for me) that those two bits ever get touched. And a /1 aggregation, in fact, represents more than half the Internet.

With those realizations (or, assumptions), I plan to build a case for the uselessness of the first two bits in the subnet mask. In XCIDR, I plan to encode the extra IP address information into those two bits (Check "Workings" for why). Now I can do two things with these two "redundant" bits in the subnet field. One is to use both of them as extra IP address bits thereby tripling the IPv4 address space. I call this the XX implementation. Or, use one bit in the address field and the other bit bit as a subnet mask bit for the other bit. Though this option makes the increase in IP address space only twice as it is now, it may allow admins later to address the current CIDR network and the XCIDR networks seperately. I call this the XY implementation. (The 'X' represents an address bit and the 'Y' represents a subnet mask bit.)

I myself am in favour of the XX one, but more thought is required to establish one of them as the right model, as, obviously, only one of them can be implemented.


Workings:

Let us split the discussion of the working into two parts: Router-level and End-to-End.

Router-level:
How do peer-to-router and router-to-router communication work in XCIDR? A router's routing table looks something like this:

An Example Routing table

- Destination IP -	- Destination subnet -	- Interface -
10.16.0.0	255.254.0.0	1
192.168.1.0	255.255.255.0	2

The above example table is partial, in that Metric, gateway, status and other fields are omitted, but is complete enough in essentials for basic routing decision-making. A router, upon receiving a packet, extracts the IP address from the packet (the encoding is dealt in the "End-toEnd" heading) and checks in the "Destination IP" for a full match. If no match is found, the "Destination subnet" and "Destination IP" field are ANDed to see if the resulting network address encompasses the extracted IP. If so, the packet is routed over the corresponding interface. This much happens with non-xcidr routers.

With XCIDR, the extracted IP address would be of the form "XX.10.16.1.1" or "X.10.16.1.1" depending on whether XX or XY scheme was selected. To match such an IP address, the router will have to look at the first two bits of the subnet mask as well. The first two bits are internally considered as part of the IP address (in case of XY, only the first bit is considered part of the address, while the next bit is considered part of the subnet mask for the first bit). So now, even though the address and subnet fields of the routing table remain the same size, the computed destination address is of the form "X.10.16.1.1", which can be compared bit-by-bit with the one in the IP packet.


End-to-End:
So how does the end node send the extra two bits without modifying the IP v4 packet's address field? IP packets have a field called "Options". It has a 2 bit ID which allows for a total of 4 unique options to be set, of which 3 are already reserved. Option "11", the last one, is free as far as I can research (google). Each Option field allows for a custom sized payload. The extra address bit(s) can be sent via this. Routers can check this field along with the IPv4 address field to get the full XCIDR address.
But currently, the Options field is not "respected" by most devices and some routers as well. This is one thing that will have to be mandated with XCIDR.

But how will the end system know of the extra IP address field in the address of a server, say google.com? DNS. DNSes supply end nodes with the IP address of 'well-known' servers on the Internet given their domain name. But changing the returned address' width may break the existing devices and applications that rely on the 32bit DNS. How do you solve this? The only way I can think of is to return an additional field for the two (or one) extra address bit(s). I haven't studied the DNS packet structure closely enough, as of now, to conclude on a method.

If you have followed through the above points, then you would've noticed that hosts/routers/devices that are oblivious to the ways of XCIDR will not be able to address the "extra address space inhabitants". There has to be a mechanism for an end node or a router to know whether the destination end-node/router is XCIDR-capable. That mechanism may be as developed seperately. For example, an end node/router may check a router's XCIDR capablity by checking whether the router can recognize the Option field '11'. In the same manner, a DNS server may check an end node's XCIDR capablity by observing whether it recognizes and responds affirmatively to a DNS record with the extra address field.

In the end, what I've presented is just a short glimpse of a very long heart-throb of mine. It sometimes feels completely idiotic to even type this idea out, but sometimes it feels like I deserve an RFC for this :) I wanted to present a paper at the very least on my this idea, so many times. And every time I would scrap it. But now I am happy to have finally put it all down into words.