Next, IPv6 addresses are of course 4 times larger than IPv4 addresses. Even if your IPv6 routing table has 5 times fewer entries, you're not getting a 5 times saving in memory. You're only getting a 5/4 times saving or tables that are 80% of the IPv4 - nowhere near as dramatic.
In IPv4 all 32 bits are used for routing, though on the backbone you tend to only accept /24s. In IPv6 the first 64 bits are used for routing, though on the backbone you tend to only accept /48s.
Either way, you only need twice as many bits in the CAM to handle an IPv6 route compared to IPv4. So what you call a 20% saving is more like a 60% saving. The picture is a bit more complicated, because two CAM entries at half the size is not the same as one of the full size. So you may have to decide at design time, how you are going to use that CAM.
Routing tables growing with the size of the network, in terms of # of entries - even if not at all fragmented.
I'd love to take part in solving that problem. Any realistic solution is going to start with a migration to IPv6. And I don't see how we could expect the solution to be deployed any faster, so if we start now, we could probably have it in production by 2040.
it is possible that IPv6 is actually too small to be able to solve routing scalability.
That algorithm has a major drawback. The address of a node depends on which links are up and which are not. You'd have to renumber your networks and update DNS, every time a link changing somewhere cause your address to change. If we assume that issue can be fixed, it doesn't really imply that addresses would have to be larger.
The algorithm in the paper assigns two identifications to each node. The first one could very well be the IPv6 address assigned to the node. The second address is computed based on the first address and structure of the network. However their routing looks awfully similar to source routing. So really the solution might just be to make source routing work.
I can think of a couple of other reasons to consider IPv6 addresses to be too short. That paper isn't one.
Teredo and 6to4 are two "automatic" tunnel protocols. Both embed IPv4 addresses inside IPv6 addresses. Due to the use of NAT, Teredo needs to embed two IPv4 addresses and a port number inside the IPv6 address. That doesn't leave room for a site-level-aggregator or host part. If you wanted one unified protocol which could replace both Teredo and 6to4, you'd need at least 192 bits in the IPv6 address.
After IPv6 showed up, people realized that it is sometimes convenient to embed cryptographic information inside the IP address. That was unthinkable with IPv4. With IPv6 it is doable, but you have to chose cryptographic primitives that are not exactly state of the art, due to 128 bits being a bit short for cryptographic values, and not all of them even being available for that purpose.