There is no Plan B: why the IPv4-to-IPv6 transition will be ugly

Twenty years ago, the fastest Internet backbone links were 1.5Mbps. Today we argue whether that's a fast enough minimum to connect home users. In 1993, 1.3 million machines were connected to the Internet. By this past summer, that number had risen to 769 million— and this only counts systems that have DNS names. The notion of a computer that is not connected to the Internet is patently absurd these days.

But all of this rapid progress is going to slow in the next few years. The Internet will soon be sailing in very rough seas, as it's about to run out of addresses, needing to be gutted and reconfigured for continued growth in the second half of the 2010s and beyond. Originally, the idea was that this upgrade would happen quietly in the background, but over the past few years, it has become clear that the change from the current Internet Protocol version 4, which is quickly running out of addresses, to the new version 6 will be quite a messy affair.

Legacy problems

Across the computing industry, we spend enormous amounts of money and effort on keeping older, "legacy" systems running. The examples range from huge and costly to small and merely annoying: planes circle around in holding patterns burning precious fuel because air traffic control can't keep up on systems that are less powerful than a smartphone; WiFi networks don't reach their top speeds because an original 802.11(no letter), 2Mbps system could show up—you never know. So when engineers dream, we dream of leaving all of yesterday's technology behind and starting from scratch. But such clean breaks are rarely possible.

For instance, the original 10 megabit Ethernet specification allows for 1500-byte packets. Filling up 10Mbps takes about 830 of those 1500-byte packets. Then Fast Ethernet came along, which was 100Mbps, but the packet size remained the same so that 100Mbps ethernet gear could be hooked up to 10Mbps ethernet equipment without compatibility issues. Fast Ethernet needs 8300 packets per second to fill up the pipe. Gigabit Ethernet needs 83,000 and 10 Gigabit Ethernet needs almost a million packets per second (well, 830,000). 

For each faster Ethernet standard, the switch vendors need to pull out even more stops to process an increasingly outrageous numbers of packets per second, running the CAMs that store the forwarding tables at insane speeds that demand huge amounts of power. The need to connect antique NE2000 cards meant sticking to 1500 bytes for Fast Ethernet, and then the need to talk to those rusty Fast Ethernet cards meant sticking to 1500 bytes for Gigabit Ethernet, and so on. At each point, the next step makes sense, but the entire journey ends up looking irrational.

The problem in the middle

Of course, change does manage to happen. We went from 10Mbps to 10Gbps Ethernet, from wired to wireless, and from a Web that was barely able to show blinking text to one running all manners of applications. We even gained the DNS and TCP congestion control only in the late 1980s. But the reason we were able to change all of these technologies is that they happen either above or below the Internet Protocol in the network stack.

Network protocols are built as "stacks" where a number of layers each provide a part of the required functionality. The famous OSI reference model has seven layers, but the TCP/IP stack has only four. Starting from the bottom and moving up, the (data)link layer knows how to send packets through cables or the air; the network layer knows about routing and addressing, allowing packets to find their way through the network; and the transport layer makes multi-packet communications work, and finally the application layer makes applications work over the network. These layers map to OSI layers 2, 3, 4, and 7, respectively. Each of these layers has many different protocols to choose from, except the network layer, which has only IP. Hence it looks like the waist in an hourglass.

The TCP/IP stack and OSI reference model

Ethernet operates at the datalink layer (and also on OSI layer 1, the physical layer), and supports complex networks of its own, but Ethernet networks are nonetheless limited in size and scope, and can be upgraded with relative ease. The transport layer, where TCP and UDP live, has some upgradability issues, but in principle, routers don't look beyond the network layer, so they don't care if a packet is TCP, UDP or some other *P. This means that changing to a new transport protocol just involves updating the end systems that send and receive the packets—the routers in the middle don't care. (Firewalls do care, hence the complications in practice.) The same is true for application protocols like HTTP, FTP, or SMTP. If your browser decides to start downloading webpages using FTP, that's between the browser and the remote server; the rest of the network doesn't care.

But in contrast to the other layers of the stack, IP is everywhere. The source of the packet needs to create a valid IP packet, which all the routers along the way must process in order to send the packet down the right path. And the destination must be able to decode the IP packet. So changing the Internet Protocol means changing all hosts and all routers.

via arstechnica.com

Posted via email from projectbrainsaver