As recent developments show, the current addressing scheme on the Internet (IPv4) is nearly depleted. There is, fortunately, a replacement scheme called IPv6 which should last some time. In fact, IPv6 has been around in one form or another since the 1980s. The age of the original discussions and specifications may have some relevance to some of the current designs related to the IPv6 protocol. It seems apparent to a mildly interested observer that some of these design decisions have or will have unfortunate consequences.IPv6 was already in development before the Internet exploded in popularity during the mid 1990s. What that means is that some of the original ideas behind IPv6 predate the massive commercialization of the Internet. This is an important fact to keep in mind while analyzing the protocol as it stands. However, for the purpose of this discussion, I will be largely ignoring that factor and will leave it to the reader to decide whether it applies to various situations.
Early drafts of the IPv6 specifications made a clear assumption that addressing would be strictly hierarchical and strictly aggregatable. The vision was that there would be a small number of “top level” aggregators which would delegate addresses to “next level aggregators” and so on down to the actual end network. None of the early literature is particularly clear exactly how the protocol designers imagined this would work in the real world. There are vague references to geography and so on, but no attempts to explain how this would map onto the real world Internet. Thus, while the idea seemed brilliantly simple, it simply does not mesh with the way networks interconnect in the real world.
This particular design principle has made itself known over the years as a distinct push against multihoming (one network connecting to multiple others). Multihoming is critical to handle high throughput and also to provide additional reliability in the face of one network having trouble. The ivory tower types decided that the way to handle multihoming was for each multihomed network to carry addresses from each of its peers. This seems an elegant solution in the examples involving only two or three networks. But it is a solution that only works for leaf networks, not those providing transit services in between. It also becomes very unwieldy when network A has four peers and network B has three peers. That means that there are twelve variations to determine how to connect from one network to the other. There is no possible way for either end system to be able to determine which paths are working. A little thought will reveal that this is a dumb solution, even if it only involves edge networks.
Even now, the ivory tower types still haven’t come up with a workable multihoming solution that preserves their strict aggregation idea which means the world is left with the same old solution used with IPv4. Even the real world types agree that that is not scalable enough for the future but because the ivory tower types refused to consider multihoming for so long, the crunch time arrived and the world had to proceed with the known working solution from IPv4.
Now let’s consider the mess with address assignments. The designers decided that hosts on the network would be able to get addresses and a default gateway on the network without having to do anything more than listen for periodic announcements from the routers, completely ignoring the fact that that idea failed miserably in IPv4 because it does not consider how a host will obtain information such as DNS servers. Instead, they said, “Thou shalt use DHCP to obtain name servers and other such information.” They also deliberately crippled DHCP running on IPv6 so that it cannot provide a gateway even though it can provide an address to the host. Brilliant. Apparently, router advertisements and DHCP were designed to work together thus neither is complete on its own. Thus, network operators must all use the One True Host Configuration Scheme which is defined to be two separate protocols running simultaneously. Completely ignoring the fact that different networks have different policies, different trust levels, and so on, the designers decided that there could only be exactly one way to dynamically/automatically assign host configuration details. Unsurprisingly, operators have been arguing against the crippled nature of both router advertisements and DHCPv6, and have been consistently rebuffed by the designers (IETF) while at the same time the designers claim to welcome operator input.
The final thing I will examine is NAT (Network Address Translation). The IPv6 designers decreed that NAT shall not be done. Period. End of story. However, since the inception of NAT in the IPv4 world, a number of circumstances where NAT proves useful for purposes beyond simply conserving addresses. Granted, NAT does tend to break end to end communication but this is an acceptable trade off for many networks. But instead of considering that there are many different uses of NAT, including insulating against provider changes for single homed sites, the designers of IPv6 and related protocols simply decreed that NAT was bad and must not be used. Fortunately for those who like NAT, the same ad hoc methods that work in IPv4 will work in IPv6 and it depends on router/firewall software rather than specific protocols so the ivory tower types really have no say in the matter.
A detailed examination of IPv6 and related protocols will reveal a number of cases of the ivory tower trap. Some of these cases are minor, and perhaps even laudable, but others, as we have seen, are not so minor. I invite you to study IPv6 in detail and consider every aspect of it from the perspective of real world network operations. How practical is each aspect of it in real situations? Does it just look good on paper in contrived examples or will it work in a much messier situation?
The point of this discussion is that protocols (or anything for that matter) should not be designed in absence of input from people with real world experience with the problem space. And that input must not be ignored because it does not mesh with the aesthetics of perfection that pervade the ivory tower. By studiously examining everything you design from the perspective of real world usage instead of contrived examples, you will have a much better chance of avoiding falling into the ivory tower trap yourself.