Reply to post: Re: 30 second ipv4 redesign?

Internet engineers tear into United Nations' plan to move us all to IPv6

Milton Silver badge

Re: 30 second ipv4 redesign?

In fairness it's actually a perfectly reasonable and obvious question, but in equal fairness it's already been well answered by at least two or three previous posts: routing.

Briefly: you could indeed prepend an extra byte and increase your address space nicely.

But soft! Consider ...

Obviously you'd need to upgrade a colossal swathe of networking soft- and hardware to make it work. At enormous expense. And a factor of 255 isn't much future-proofing: the Internet of Shyte, cars, phones, toasters and wearables, it's all going to gobble vast amounts of address space and, barring global catastrophe, at a non-linear growth rate. You certainly don't want to have to obsolesce all that new soft/hardware again in seven years' time.

So having considered just one prepended extra byte, you'd soon conclude that, since you're gonna have to upgrade a monstrous wodge of stuff, you might as well make the thing seriously future proof and, say, prepend four extra bytes. Really, there are endless reasons to do this, and not one good reason not to. An extant switch that can't handle an eight-byte address couldn't have handled a five-byte one any better.

Upon looking into how that IPv4 system works, though, you're reminded that none of these devices doing the work has a built-in register of the physical location, and how to reach it, of every address on Earth. That would be crazy, for reasons of scale, efficiency and the irritating fact that they change. (They'd spend longer constantly updating their staggeringly vast memories than actually passing traffic.) And those inescapably good reasons become all much more significant still, for tomorrow's almost unimaginably bigger world. You need to maintain a simple, efficient method that helps every device know where to send bytes without it having to stop and thumb through a dozen phone books.

Thus, routing: and the efficiency of sensible hierarchies. Having specified enough bytes for devices from here to Andromeda—which was, we now see, a sensible, inevitable choice—you realise that you can now afford to scatter those devices quite sparsely (which has no disadvantages) and that you can group, sub-group, and sub-sub-group them in ways which allow individual routing systems at almost any level in the routing hierarchy, given an IPv6 address, to know virtually instantly where next to steer a packet. A workable though imperfect analogy would be the STD phone network: seeing an 01623 code at the beginning of a number means you can immediately pass the call along to a "router" in Mansfield, rather than saying "Hmm, 01623123XXX", lemme go see whereabouts in the whole of Britain that might be ... this may take some time".

This is not the most efficient use of the size of IPv6 in terms of sheer numbers of practical addresses, but the beauty is that there are so many potential addresses that it doesn't matter. It is very efficient, though, in ensuring you can quickly, using minimal phone books, get through to the address you want.

The point of this is that taking your initial perfectly reasonable premise, and applying some cautious stepwise logic, you come right back to something that looks like IPv6 anyway. Hopefully it also explains why you absolutely must not 1:1 map legacy IPv4 to IPv6 addresses—because that undermines the absolutely essential principle of the new standard in being able to efficiently direct traffic.

When a political ignoramus at the UN says scornfully "How difficult can it be?" the answer is "The devil is, as always, in the detail."

Indeed, it doesn't matter whether the political imbeciles are talking half-baked crap about IP, backdoor encryption, badgers or jet fighters: the answer is always the same one—"The devil is in the detail."

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019