| |||||||||||||
DJB was wrong... even if he was right too.DJB was wrong... even if he was right too.Posted Jan 27, 2011 13:49 UTC (Thu) by foom (subscriber, #14868)In reply to: DJB was wrong... even if he was right too. by bojan Parent article: LCA: IP address exhaustion and the end of the open net
> > Getting everyone using routers with IPv6 support is the tricky part. But that's required no matter what!
> Well, yeah. If the plan to have v4 embedded into v6 was followed, this would have been around years ago. And you wouldn't even know you had it.
So why would anyone have added support for an IPv4 "long address" option which wasn't even being used by anyone? They wouldn't have, any more than they added IPv6 support. Both things are equivalent: addition of a new feature to your software that none of your customers are going to actually use.
My router could have added IPv6 support 10 years ago, too, without me knowing it. But it didn't.
Cable modems didn't get IPv6 support until DOCSIS 3.0, which only *just* started showing up in new devices. It looks like they've also released an addendum to DOCSIS 2.0 to allow older hardware to add IPv6 support -- in November 2010. So *maybe* firmware upgrades for older devices might add IPv6 support in the future (but I'm not holding my breath)...
(Log in to post comments)
DJB was wrong... even if he was right too. Posted Jan 27, 2011 20:08 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
software developers are frequently willing to add features that aren't yet needed (just to get bragging, marketing rights), but only if those new features are not huge and invasive.
the 'implement a new stack, with mandatory features that are complex, and largely unknown' aspect of IPv6 made it a major project, not something that could be added in easily.
Hardware Posted Jan 27, 2011 21:15 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
And yet all the _software_ developers who matter did just this. I was using IPv6 _software_ ten years ago, maybe closer to fifteen now. Our biggest worry in _software_ is Microsoft Windows 95, long obsolete and unsupported, but widely used for the same reason people are still watching TVs with dial tuners (yes, really, they are even in countries with DVB - backward compatibility is a bitch)
So software is great, it's enough to have IPv6 in your house, share it with a few friends in a tiny startup's office, or even across a few hundred hosts if you can afford a beefy FreeBSD box as a router. All these things were being done last _century_ in preparation for the transition we are now undertaking.
But that only gets you so far. Eventually (today probably somewhere about gigabit speed) it is only cost effective to switch IP with custom hardware designed for that specific purpose. Eventually the cost of wider addresses doesn't vanish, but instead dominates. And there the story changes.
Hardware Posted Jan 27, 2011 21:31 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the latest generation of networking technology always requires custom ASICs, back in the 90s you needed ASICs for 10Mb switching.
this is part of the problem, by designing IPv6 so that everything had to change we have these problems. If this was something backwards compatible, that could run through existing devices in the middle without them having to change (think of it as being similar to tunneling, but with every ISP being a potential tunnel termination point without having to configure it explicitly) then we would not have to deal with the ISPs support or lack of it as an issue, only the question of getting enough endpoints to support it.
this wouldn't have solved the problem entirely, but it would have helped.
And if you are claiming that all developers who matter have implemented IPv6, please go back to the earlier post that pointed out that no current generation game console supports IPv6, many printers don't support IPv6, let alone other, smaller embedded systems.
Hardware Posted Jan 28, 2011 16:13 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
Again, the scenario where any ISP can offer valid tunnel endpoints and have them automatically used without explicit configuration by the user _already exists_
The ISPs don't provide such tunnels because the tunnel would _cost money_ and they don't want to spend money.
DJB was wrong... even if he was right too. Posted Jan 27, 2011 22:09 UTC (Thu) by bojan (subscriber, #14302) [Link]
> Both things are equivalent: addition of a new feature to your software that none of your customers are going to actually use.
Equivalent? I can't even test IPv6 without obtaining a new address. I could if my IPv4 worked instead. That's why it would get included - it would be actually useful at some point to people _connected_ to the net. In fact, we wouldn't even be talking about the address crunch.
> My router could have added IPv6 support 10 years ago, too, without me knowing it. But it didn't.
Yeah, of course it didn't. Where would you get an IPv6 address from anyway?
DJB was wrong... even if he was right too. Posted Jan 28, 2011 15:09 UTC (Fri) by zlynx (subscriber, #2285) [Link]
> Where would you get an IPv6 address from anyway?
Did you miss that every IPv4 address is automatically assigned an entire IPv6 network of its own in the 2002::0 range?
Here is mine, for example: 2002:4051:69fa::1 You should be able to get the web page at http://[2002:4051:69fa::1] or http://oberon.zlynx.org/ The DNS has both A and AAAA records.
See the 4051:69fa? That's my IPv4 address: 64.81.105.250
If home routers were preconfigured with 6to4 and radvd, every home user would already be on IPv6.
Sure, an inefficient IPv6 that is tunneled through IPv4, but it sets the stage for moving to ISP assigned addresses later on.
DJB was wrong... even if he was right too. Posted Jan 28, 2011 15:53 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
You can test almost everything via a tunnel. The various _automatic_ tunnels which other people have mentioned all use your IPv4 address in order to assign you an IPv6 unicast subnet for your use.
In this scenario you are an IPv6 island, connected to other IPv6 islands by tunnel. If they _wanted to_ ISPs could compete by providing a tunnel endpoint closer to their subscribers, so IPv6 would work faster on their network than on a competitors. Technologies like 6to4 even made this very easy by using an anycast address, so the ISP can put the tunnel endpoint anywhere with no config change for the user. The natural endpoint of such competition would be native IPv6, no tunnels.
But the major ISPs as we've tried repeatedly to explain, do not care. If the closest endpoint is on another continent, why should they care? Providing the minimum possible service is a cost saving. So if you try to use such a tunnel, expect poor performance and zero technical support from your ISP. It's just not in their interest to care.
Have I told the story about the cable TV company who added a "digital surcharge" to pay for equipment upgrades ready for digital cable? I bet you're thinking that they had to do that - to pay for the upgrades, right? Nope, there were no upgrades. It was just another way to get more money. When digital cable actually arrived they couldn't offer it, because their equipment was too old. No matter, the customers still have money, just charge them again.
|
|||||||||||||