LWN.net Logo

DJB was wrong... even if he was right too.

DJB was wrong... even if he was right too.

Posted Jan 26, 2011 22:47 UTC (Wed) by bojan (subscriber, #14302)
In reply to: DJB was wrong... even if he was right too. by khim
Parent article: LCA: IP address exhaustion and the end of the open net

> For his solution to overcome the real problem we'd need this magic function - and it just does not work.

That's bullshit and you know it. No such function is required.

Just consider this again:

> This problem was foreseen back in 1990; in response, a nice plan - IPv6 - was developed to ensure that we would never run out of network addresses. That plan assumed that the transition to IPv6 would be well underway by the time that IPv4 addresses were exhausted. Now that we're at that point, how is that plan going? Badly: currently 0.3% of the systems on the net are running IPv6. So, Geoff said, we're now in a position where we have to do a full transition to IPv6 in about seven months - is that feasible?

> To make that transition, we'll have to do more than assign IPv6 addresses to systems. This technology will have to be deployed across something like 1.8 billion people, hundreds of millions of routers, and more. There's lots of fun system administration work to be done; think about all of the firewall configuration scripts which need to be rewritten. Geoff's question to the audience was clear: "you've got 200 days to get this done - what are you doing here??"

20 years later, we are still in this mess and you're telling us DJB was wrong? Never mind DJB, just use common sense. People connected to the net have to connect again for no good reason whatsoever. They already have perfectly good addresses.

Imagine a country operating like this. One day they realise that their citizen numbers (call them SSNs) do not fit into the database field. So, what do they do? Call all existing citizens back to have their citizenship ceremonies (after applying that is) and be issued with brand new numbers. Of course, these citizens now have to give their new numbers to their employers, doctors etc. Yeah, sound like a _great_ plan. Never mind they could have added a few extra zeros to the front of each number.


(Log in to post comments)

Why should I imagine anything?

Posted Jan 26, 2011 23:32 UTC (Wed) by khim (subscriber, #9252) [Link]

Imagine a country operating like this. One day they realise that their citizen numbers (call them SSNs) do not fit into the database field. So, what do they do? Call all existing citizens back to have their citizenship ceremonies (after applying that is) and be issued with brand new numbers. Of course, these citizens now have to give their new numbers to their employers, doctors etc. Yeah, sound like a _great_ plan. Never mind they could have added a few extra zeros to the front of each number.

Why should I imagine that? You've perfectly described how registration numbers of cars were handled in USSR, for example. They changed the form at least five times. Radically - totally new form was introduced, not an extension of an old one. Usually new form was introduced but you were allowed to keep old form for a time, but few years down the road you needed to change it anyway. Essentially what IPv6 developers proposed to do - only they have no government to enforce the change.

20 years later, we are still in this mess and you're telling us DJB was wrong? Never mind DJB, just use common sense. People connected to the net have to connect again for no good reason whatsoever. They already have perfectly good addresses.

Well, they have... for now. When/if IPv6 will be mandated in some places it'll create pressure to switch. Till then we have no incentive to switch and I fail to see what can induce the switch - DJB folly or no DJB folly. You still have not examplained how "DJB transion plan" will magically solve the real problem (you need to introduce new IPv6-capable routers - and this is expensive thing to do).

Somehow IPv6 developers believed people will start transition before IPv4 addresses are exhausted - but it can only happen if government will mandate it. Without government intervention it'll happen few years after IPv4 addresses are gone (because for a time you can trade/buy them from existing organizations).

Why should I imagine anything?

Posted Jan 26, 2011 23:47 UTC (Wed) by bojan (subscriber, #14302) [Link]

> You've perfectly described how registration numbers of cars were handled in USSR, for example.

Three points here:

1. USSR does not exist any more. This could be one of the reasons. ;-)

2. Cars with all types of regos could drive just fine. I cannot drive at all on this new IPv6 highway with my IPv4 address.

3. You are required to register you car every year. You are not required to register you net address every year. If fact, many people/orgs/companies had them for many, many years.

You see, where I live, people still have old rego plates. Like "4" or "6". And they still work just fine. We found a way to interoperate with new ones like "XYZ123". It was _very_ difficult, but it eventually worked :-)

This is where you are wrong...

Posted Jan 27, 2011 0:23 UTC (Thu) by khim (subscriber, #9252) [Link]

2. Cars with all types of regos could drive just fine. I cannot drive at all on this new IPv6 highway with my IPv4 address.

Sorry, but no. In fact the last change was introduced exactly because you can not use old ex-USSR regos on new European highways. Some older nameplates are not legal to use in other places.

3. You are required to register you car every year. You are not required to register you net address every year. If fact, many people/orgs/companies had them for many, many years.

Well, this is the problem, isn't it? Price of IPv4 address will rise with time and network registrars will start revoking addresses if they organizations will not pay. Organizations will lose the luxury of "IP addresses for life" very soon. That's why I'm kind of surprised when people say DJB is right: IPv6 intrusion is not even started yet! Somehow the people perceive a time when IPv4 pools are exhausted as the end of said process (the crazy "you've got 200 days to get this done - what are you doing here??" line). No, it's not the end of the IPv6 migration process. It's not even the middle. It's the beginning. Prehistory. For the beginning of the process 0.3% penetration is actually surprisingly high.

1. USSR does not exist any more. This could be one of the reasons. ;-)

Actually it's the other way around: USSR does not exist anymore so such painless switches are no longer possible.

This is where you are wrong...

Posted Jan 27, 2011 1:10 UTC (Thu) by bojan (subscriber, #14302) [Link]

> For the beginning of the process 0.3% penetration is actually surprisingly high.

We are at the beginning? The problem was identified 20 years ago.

Yeah, it was identified, so what?

Posted Jan 27, 2011 8:18 UTC (Thu) by khim (subscriber, #9252) [Link]

We are at the beginning? The problem was identified 20 years ago.

And so what? The need for 64-bit computing was clear 20 years ago, 64bit CPUs were produced in about that time, yet people only started to switch when Joe Average started reaching 4GB limit. Before that intermediate solutions like PAE were used. Compare with IPv4 -> IPv6: till IPv4 adddress space is not exhausted people are using IPv4. Even when it'll be exhausted people will continue to use IPv4 with band-aids like multi-level NAT. Only when pain is acute enough they will start to switch.

The brave people who are using IPv6 today can be compared to users of POWER/MIPS/SPARC/etc: they are numerous enough to iron bugs, but there are few of them because most users just don't need an IPv6 today (just like yesterday people were perfectly content with Xeon and 32GiB of RAM in PAE mode).

This is how market works: it's organically incapable of jumping from one "good" solution to another "better" solution if the intermediate steps go "down" (and in case of IPv4 -> IPv6 switch they do go down no matter what DJB says). "Good" solution must become "bad" first... And it'll only happen by 2012 or later. So yes, it is the beginning.

Yeah, it was identified, so what?

Posted Jan 28, 2011 3:31 UTC (Fri) by bojan (subscriber, #14302) [Link]

You keep forgetting the most important thing: people could take their 32-bit apps with them and run them on their 64-bit machines. Immediately. No modification, no reconfiguration - the hard yards were done by software vendors. People cannot do that with their IPv4 addresses and connections and IPv6. Everything has to be done (essentially) from scratch. Software upgrades alone do not help.

Some people mention things like toredo and other 4/6 cruft. What good does that do, when you get _different_ addresses, so if you have things like DNS, firewalls, services etc. set up, you have to do it all over again. It is completely different. In fact, the simple fact of needing to _think_ whether and what you'll need to do is sufficient to show that this has been handled poorly.

Of course people start switching only when the need to. That's why many folks still run 32-bit OSes and apps on their 64-bit machines, without even knowing or caring they are really 64-bit. And yet, pretty much any server, PC or notebook you buy today can do 64-bits. If IPv6 transition was handled the same way, most folks out there would not even be aware there was a transition. They would already be on IPv6, not caring one iota about the new connections having real IPv6 addresses. They could still see everything, just like they always did. And these new connections could see them just fine.

Just go talk to your average network/system admin out there. Most of them have absolutely no idea what to do. If they introduce IPv6 to their network, they will have to spend years battling two completely separate setups (essentially, they are building their network from scratch). Initially, for no benefit at all. This never happened with amd64.

If you told them that to get IPv6 support, they needed to install at least version x.y.z on all of their equipment or even just change the equipment and reload the config, that would be way easier.

The amd64 example shows nicely how the market does it with minimal disruption. Remember, even Intel, the leader in the field, had to succumb to an architecture designed by an inferior competitor.

Yeah, it was identified, so what?

Posted Jan 28, 2011 4:07 UTC (Fri) by foom (subscriber, #14868) [Link]

> They would already be on IPv6, not caring one iota about the new connections having real IPv6 addresses.

You can repeat that 40 or 50 times, but it doesn't make it more true the more often it's repeated.

I will again claim that even with your version of the transition, ISPs still wouldn't have bothered to upgrade their routers to support the longer addresses faster than they have been doing now, nor would the manufacturers of dsl routers, cable modems, etc have upgraded their software (and configuration protocols) to support the long addresses any sooner.

They wouldn't bother supporting long addresses because nobody would use long addresses. Nobody would use long addresses because you couldn't talk to the majority of the internet (the part that still had at least one router on the path not supporting long addresses or with a host endpoint that didn't support long addressing). Until there was actually a forcing function, such as running out of short addresses. Just like with actual IPv6.

But, nobody can prove any "what ifs", so maybe it's time to just drop the whole discussion.

Yeah, it was identified, so what?

Posted Jan 28, 2011 4:39 UTC (Fri) by bojan (subscriber, #14302) [Link]

Let's assume you are correct.

This leaves us currently with a situation that requires upgrade (for some) and reconfiguration (for most). The alternative requires only upgrade (for some).

That is not a what if. That is a fact.

But yeah, let's drop it. I'm getting a feeling a moderator may suspend my account soon. I have too much time on my hands. Maybe I should go and start configuring IPv6 instead. :-)

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds