IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
Posted Jan 6, 2016 3:56 UTC (Wed) by bojan (subscriber, #14302)In reply to: IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica) by Cyberax
Parent article: IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
Am I quite sure that when it comes to software (which is what an IP stack is), most things are possible, contrary to the "cannot be done" brigade harping on about insurmountable problems. Didn't seem to stop other protocol designers. Doesn't have to be "pretty", which seem to have been what IPv6 was all about. It just has to work.
Posted Jan 6, 2016 4:05 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (50 responses)
This is a bad idea for many, many reasons and it doesn't even solve the actual problem that we have right now. I.e. the lack of IPv6 on the server side and on the client side.
Posted Jan 6, 2016 4:27 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (49 responses)
You know, kinda like that idiotic 64-bit transition that didn't work. :-)
Posted Jan 6, 2016 4:39 UTC (Wed)
by pizza (subscriber, #46)
[Link] (7 responses)
And pray tell, how exactly will we "just upgrade the software" on _all_ hosts connected to the internet?
Posted Jan 6, 2016 5:38 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (6 responses)
Posted Jan 6, 2016 5:40 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
Posted Jan 6, 2016 5:49 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (4 responses)
Posted Jan 6, 2016 6:04 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Jan 6, 2016 6:08 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (2 responses)
Posted Jan 6, 2016 12:45 UTC (Wed)
by nye (subscriber, #51576)
[Link] (1 responses)
The proposal is 13 years old.
Posted Jan 6, 2016 17:08 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
Posted Jan 6, 2016 4:44 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (34 responses)
There's a joke in Russian that goes like this:
Rabbits come to an owl and ask: "Oh wise Owl, please help us! We're being chased and eaten by everyone: wolves, dogs, foxes and eagles!"
> You know, kinda like that idiotic 64-bit transition that didn't work. :-)
Posted Jan 6, 2016 4:56 UTC (Wed)
by pizza (subscriber, #46)
[Link]
You forgot to mention that existing 32-bit code is supported by continuing to maintain the entire 32-bit environment in parallel with the new 64-bit stuff, and the two cannot interact without something atively translating between them.
Come to think about it, that sounds an awful lot like IPv4/IPv6 dual stacks. :)
Posted Jan 6, 2016 5:00 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (32 responses)
As for the joke, that is exactly the opposite of what DJB's text says. Remember, the man is the author of quite significant pieces of software. He didn't pull his text out of his butt. He actually participated in all these discussions way back then. Yes, he is quite abrasive. Doesn't make him stupid.
But never mind the authority - it's irrelevant. Study the proposal and ideas.
And the proof of the pudding is in the eating. And we only get to eat 10% after two decades.
Your complaints about 64-bit transition are not genuine. Most of the stuff works in that transition, with minor details missing. IPv6 transition is the exact opposite of that. It mostly (90%) doesn't work.
Posted Jan 6, 2016 5:06 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (31 responses)
> Why don't you read that instead, carefully, so that you understand what he actually said so many years ago.
For example, what if my address is 1231278364187abcd123 and I want to connect to IPv4-only host 1.2.3.4?
Or what routing table should an IPv7-enabled host 2.3.4.5 use to send packets to 1231278364187abcd123 ? How are these routing tables distributed?
Posted Jan 6, 2016 5:35 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (16 responses)
It's not a holy text, but you obviously didn't read the it carefully. There is no IPv4-only host in DJB's proposal. Doesn't exist.
> How are these routing tables distributed?
The same way they are now. Just because one part of the address space may have a slightly different routing approach, doesn't mean things cannot work. If fact, with two separate networks (IPv4/IPv6), that is exactly what happens now.
Posted Jan 6, 2016 5:44 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (15 responses)
> The same way they are now.
> Just because one part of the address space may have a slightly different routing approach, doesn't mean things cannot work. If fact, with two separate networks (IPv4/IPv6), that is exactly what happens now.
Posted Jan 6, 2016 5:55 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (4 responses)
> Can't do this. Current routers use IPv4 prefixes for routing, they can't cope with full IPv7 addresses. You need to upgrade all of the core routers and route distribution protocols to do it.
I am 100% certain now you are just pulling my chain here, so I'll just laugh. :-)
Upgrade. Mentioned. 13. Years. Ago. Known. Even. Before. That. Time. ;-)
> I'm saying that DJB's approach would lead to exactly the same outcome in the end.
Nope. Remember that ping I tried? It would actually work. And I'd have to do diddly-squat. For me and everyone else out there on the internet. The one and _only_ internet. Not that second one...
Posted Jan 6, 2016 6:08 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
And if you invoke "just upgrade hardware" then keep in mind, that this router literally costs millions.
THAT'S what had been keeping IPv6 rollout for so long.
> Nope. Remember that ping I tried? It would actually work.
Posted Jan 6, 2016 6:16 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (2 responses)
> THAT'S what had been keeping IPv6 rollout for so long.
And your point is? Once you actually upgraded that router to do this new addressing thing, it's not very useful still, because all of the other admins now have to configure _another_ network (i.e. the new IPv6) to make it useful. Otherwise, it's just expensive hardware.
With IPv6 upgrade (instead of a separate network), once you complete the upgrade, everything is reachable. Not just IPv6 island.
Nobody ever said that the alternative plan wouldn't require cost, effort etc. Just that it would be more _useful_ immediately. And it's quite simple - because there would be just _one_ network.
> And it already does this on Windows. Next question.
Not true, if you don't have IPv6 configured. So, please don't treat false as true. Just because Windows programmers decided to know how to parse IPv6 addresses within their ping, doesn't mean the packets aren't travelling to an entirely different network.
Posted Jan 6, 2016 6:28 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
> 0123456789abcdef0123456789abcdef to 192.5.6.30: The client sends a UDP packet to the .com DNS server asking for the address of www.google.com. The client software, intermediate computers, and server software have all been upgraded to handle the client's extended address.
So until the client software, intermediate computers, and server software and hardware have all been upgraded to handle IPv7 addresses, these upgrades will be useless.
> Not true, if you don't have IPv6 configured.
> Just because Windows programmers decided to know how to parse IPv6 addresses within their ping, doesn't mean the packets aren't travelling to an entirely different network.
But... My home router was last upgraded in 2007 and doesn't support IPv7. What would happen in this case?
Posted Jan 6, 2016 8:30 UTC (Wed)
by bojan (subscriber, #14302)
[Link]
> Yes. And it's going to be the same with the hypothetical IPv7.
Nope, it won't. Even after you complete the upgrade of the backbone to IPv6 in the current scenario, it will still be largely useless, as I pointed out numerous times (there is a difference between creating/maintaining multiple parallel configurations and patching, as you well know).
And there is no IPv7. You are just confusing future Google searches.
> Since you hold the DJB's document in such high regard, allow me to cite the Scripture:
Oh, please. It's just a little document filled with common sense, by a guy who happen to be in the trenches when all this was going on. He was the guy with the hand in the air, saying not to take that path. Nobody listened. So, we ended up with 10% after 20 years. That's all.
> > 0123456789abcdef0123456789abcdef to 192.5.6.30: The client sends a UDP packet to the .com DNS server asking for the address of www.google.com. The client software, intermediate computers, and server software have all been upgraded to handle the client's extended address.
> So until the client software, intermediate computers, and server software and hardware have all been upgraded to handle IPv7 addresses, these upgrades will be useless.
Correct (minus the silly reference to v7, of course). Which is miles better than double useless (i.e. futher configuration required).
> So humor me this, suppose I have an IPv7 capable host with all the newest software written by DJB. I type: "ping 0123456789abcdef0123456789abcdef".
> But... My home router was last upgraded in 2007 and doesn't support IPv7. What would happen in this case?
The same thing that would happen if I connected my Nokia 101 to current 3G network. Wouldn't work. Nothing strange with having obsolete technology. I still have floppy disks at home, but no drive to use them. OK, I don't, but I could. :-)
I don't think why is it so hard to understand that this whole "hand in the air" thing happened many, many years ago. Another poster down below correctly pointed out that DJB's text was already too late anyway. I agree with that. People within IPv6 should have thought of all this in 1996. But, at least he tried to point out the mistake in an honest way. If they listened to him in 2001 or 2002, maybe another path could have been taken. Maybe.
It's way too late to do anything now...
Posted Jan 6, 2016 5:59 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (4 responses)
Maybe a spherical cow :-). In the real world we still have to support IPv4-only devices for the foreseeable future, so any device which speaks a new protocol will have to flawlessly speak the old one as well. You might be able to have a new protocol device talk to an old protocol one through translation but that just moves the complexity around, its not any less complex than just continuing to run the old protocol, which maintains full compatibility and fidelity.
Posted Jan 6, 2016 6:02 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (3 responses)
Do you also still support SSLv3?
Posted Jan 6, 2016 17:01 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (2 responses)
Posted Jan 7, 2016 1:02 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (1 responses)
Posted Jan 7, 2016 16:51 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Our phone system is powered from the exchange, not the home, power supply. So we have a fixed-line phone plugged into the wall (plus all our cordless, true). But that way, if we have a power outage, we still have a phone line.
Somebody tried to nick a 50KV power line near here a few years ago, and a large area was without power for about a week. Cordless phones died instantly without power to the base station. How long does a typical mobile battery last nowadays? With all these smartphone functions I can flatten mine in a day (and if the local mast dies it'll flatten itself transmitting at full power trying to find a mast!).
Okay, we were about 100yards outside the power fail area, but if we'd lost power our phone would probably still have worked because the local exchange would have had an emergency generator.
Cheers,
Posted Jan 8, 2016 0:04 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (4 responses)
> How did this happen? Were they magiced away by a unicorn?
You asked the wrong question. Are there any IPv7-only hosts in DJB's proposal. Because if there are, they won't be able to communicate with IPv4 hosts until the entire network is upgraded, and if there aren't then IPv7 doesn't solve the problem which is there are more computers than addresses - oh and stuff this nonsense about "only servers need IPv4 addresses" - the whole point of the internet is that any computer is BOTH client AND server.
Cheers,
Posted Jan 8, 2016 0:21 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Jan 8, 2016 13:25 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
The reason I asked is all these people saying IPv6 are a failure, are also saying that IPv7 solves the problem of computers not being able to connect. So as soon as you have IPv7 hosts without an IPv4, how are they supposed to talk to legacy hosts with an IPv4 but no IPv7 :-)
Oh - with new infrastructure - let's call it IPv6 :-)
Cheers,
Posted Jan 8, 2016 14:11 UTC (Fri)
by hummassa (subscriber, #307)
[Link]
IP address space size transition is a problem of the "what is the length of the shore" type. There are no proposed solutions that, once you work out ALL of the kinks, are simpler than the current v4-v6 transition.
That, added to the fact that the v4-v6 transition is already ongoing (with great penetration in some countries), should discourage the creation of new fantastic schemes.
Posted Jan 8, 2016 0:49 UTC (Fri)
by neilbrown (subscriber, #359)
[Link]
Yes they will, because NAT. NAT was always going to be have to be part of the transition. It may be horrible but the horror scales with size so you can make an economic decision when to suffer (or force your customers to suffer) with NAT, and when to transition to a more modern solution.
If many servers became IPv7 capable before many clients became IPv7 only, the pain of the NAT would be limited.
> the whole point of the internet is that any computer is BOTH client AND server.
"can be" rather than "is". An IPv7-only computer cannot be a server for an IPv4-only client. So that too becomes an economic question, "do I get an (expensive) IPv4 so every client can reach me" and "do I update to IPv7 so I can reach every server". If you don't have to make that decision until most computers support both it is genuine decision.
I really wish "The Internet" could have started charging $1 per year per IPv4 address, and 1c per year per IPv6 /64 (with a slow ramp-up for old customers and bulk discounts for ISPs). That would have raised funds to build out the core infrastructure, and would have moved people to IPv6 really quickly.
Posted Jan 6, 2016 16:32 UTC (Wed)
by paulj (subscriber, #341)
[Link] (13 responses)
Feasible.
Basically, combine NAT with a transport protocol option to add an extra identifier. Hell, there are option-specific options to do exactly this, see rfc6978.
Extending IPv4 via options would have been quite feasible and was in fact considered, however the proponents of coming up with a completely new Internet argued that parsing an option would be slow. As we all know, protocols that are undeployable to the extent the Internet is bursting at the seams address space wise and still only 10% have switched, are better than protocols that would be easier to deploy but might require hardware parsing pipelines to be a bit longer (and hell, they ended up parsing all kinds of crap in hardware _anyway_).
Other problems with IPv6: They dropped fragmentation. So we're stuck with 1500 max(MTU) on the Internet, maybe forever.
IPv6 is a salutary lesson: Don't let the hardware guys dictate your software packet formats.
Posted Jan 6, 2016 16:40 UTC (Wed)
by paulj (subscriber, #341)
[Link]
Posted Jan 11, 2016 15:36 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (8 responses)
Every ISP-supplied home router I've seen since 2000 blocks packets containing IP options on the forwarding path. How does UDP over newIP work if newIP depends on IP options which are dropped?
Posted Jan 11, 2016 16:21 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
Posted Jan 11, 2016 16:31 UTC (Mon)
by paulj (subscriber, #341)
[Link] (6 responses)
That's why the comment of mine you're replying to deliberately mentioned TCP, "IP has options, as has TCP." and wasn't specific on at which level you'd use the option, "You can include the expanded address space identifiers (src and dst) as an option.". ;)
At this stage, IPv6 hopefully can't fail. However, as per another comment, adoption of v6 is still sufficiently slow that if another, more useful (e.g. better transition) protocol came along that then people might favour adopting that. Unlikely at this stage, but not impossible.
Such a protocol might even go so further than the above, and do the extension at the HTTP(S) level. E.g. I can SSH into hosts that do not have any public IP addresses and are even behind firewalls, by making such hosts connect to Tor and publish a tor service on a Tor address. And note that this is possible directly with clients that support the SOCKS API to offload a lot of the networking details to the local Tor relay itself - no need to update the clients to deal with a new address family and protocol. Even non-SOCKS clients potentially still can access Tor services, if they're fairly standard in what they do network wise, using an LD_PRELOADED library to capture regular network API uses and divert to SOCKS.
And note that the host with Tor need not have any direct connection to the IPv4 Internet at all. All it needs is to be able to access a HTTP(S) proxy that has public Internet access. That host can then access the Internet, and other Tor-enabled hosts can access it.
See also LISP, which can also run v6 LISPed space tunnelled over v4 I think.
Posted Jan 12, 2016 0:21 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (5 responses)
I'm talking about routers sold in 2000, though, not just routers sold today. If 15 years ago, blocking IP options was normal in the forwarding path on home routers, what makes you think that it'd have succeeded as a transition plan?
Posted Jan 12, 2016 16:13 UTC (Tue)
by paulj (subscriber, #341)
[Link] (4 responses)
Posted Jan 13, 2016 0:19 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (2 responses)
On really cheap consumer routers of 2000-era vintage (typically running a repurposed RTOS, not Linux), that means no IP options, no TCP options (see also the fate of ECN). You're stuck with UDP encaps, and start to look a lot like Teredo.
Plus, of course, you face the same long term issue that Teredo and 6to4 would have faced if they'd taken off - the goal of this transition is to get rid of IPv4 completely, because the Internet has more hosts than it can fit into 2**32 addresses. Somehow, you need to migrate to a point where users who once had IPv4 are not privileged over users who were never able to get IPv4, and where users who never had IPv4 (and thus can't tunnel inside IPv4) are first-class citizens on the net.
Posted Jan 15, 2016 13:32 UTC (Fri)
by paulj (subscriber, #341)
[Link]
Posted Jan 15, 2016 13:37 UTC (Fri)
by paulj (subscriber, #341)
[Link]
Posted Jan 13, 2016 0:39 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
Posted Jan 15, 2016 1:44 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (2 responses)
I've just noticed one inaccuracy, which I'd like to correct; IPv6 does not drop fragmentation support. You can still fragment IPv6 packets at your sending host, and your recipient has to cope with reassembly, just like in IPv4. The change is that IPv6 implicitly turns the Don't Fragment bit on, so that routers don't quietly fragment your packets for you. This matches the current IPv4 defaults for most OSes - you must handle pMTU discovery instead, just like for IPv4.
Posted Jan 15, 2016 22:27 UTC (Fri)
by zlynx (guest, #2285)
[Link] (1 responses)
Those 40 byte packets were just ridiculous.
Posted Jan 15, 2016 23:50 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
1288 is now a new 1500 for IPv6.
Posted Jan 6, 2016 4:57 UTC (Wed)
by neilbrown (subscriber, #359)
[Link] (5 responses)
That was the 64-bit transition to Itanium, wasn't it?
IPv6 is to IPv4 as Itanium is to Pentium.
x86-64 is to x86 as X is to IPv4. Solve for X.
Posted Jan 6, 2016 5:04 UTC (Wed)
by bojan (subscriber, #14302)
[Link]
Posted Jan 7, 2016 13:18 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
Posted Jan 8, 2016 5:20 UTC (Fri)
by flussence (guest, #85566)
[Link] (2 responses)
Posted Jan 10, 2016 13:28 UTC (Sun)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
The address translation gateways cost a bunch of money. NAT on a 56k dial-up modem in 1996 was "basically free" for our Linux box, it's sort of free (actually hurts your perf but most users will never check) on home broadband routers - but NAT for an entire mobile phone network is a considerable amount of money in edge devices. The transition doesn't get rid of address translation overnight, but it changes what you're buying from CGNAT (every single connection that any customer makes, to anywhere, must go through these edge devices) to NAT64 and 464XLAT (only connections to an IPv4 server need translation). And that means as the IPv6 Internet grows, your need as a native IPv6 network for costly translation bandwidth actually shrinks.
Companies like T-mobile report getting somewhere towards half of the connections to IPv6 (the long tail means even though most servers are IPv4-only, most connections go to a handful of IPv6 capable sites like Google). The customer notices no difference, IPv6 Facebook looks very similar to IPv4 Facebook. But a line item on T-mobile's budget just got slashed because all those IPv6 native connections are cheap, no translation needed.
Now, if you're AT&T, is your plan to sit tight, cross your fingers that T-mobile blows up for some other reason and you'll never need to compete on price with somebody whose operating costs are lower than yours? Or would you be tasking people to get that same cost reduction for your network pronto ? Right.
Posted Jan 11, 2016 22:30 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
IPv6 Facebook looks slightly better than IPv4 Facebook - their metrics show that requests over IPv6 complete slightly faster than over IPv4, even when the network path is the same; their conjecture is that NAT adds a small amount of extra latency per connection, and on their use case (short connections transferring a small amount of data), that latency is noticeable.
And note that the key driver for IPv6's price advantage over CGNAT is that the IPv6 backup router just needs a complete routing table (a default route with local exceptions if that's appropriate, or a full DFZ table if necessary) and it's ready to take over when the primary router dies; VRRP can be configured to take over from a dead router in under a second, and connectivity over the top just sees a one-second blip before it recovers. Worst case in a well-run network, the backup router hasn't yet got the latest routes, and traffic takes a short detour before reaching its destination. CGNAT, however, also has to send state for every connection being tracked from the master to the backups; this is a lot more traffic than VRRP or equivalent heartbeats, and the worst case in a well-run network is now that a small number of live, in-use customer connections get dropped on the floor when the CGNAT dies unexpectedly (if the CGNAT loses power with 10 ms of traffic in the "state sharing" link's queue, the latest 10 ms of state updates are lost forever). Fixing this price difference is technically not possible, as the CGNAT cluster has more state to keep consistent between boxes than the routing cluster.
Posted Jan 6, 2016 4:24 UTC (Wed)
by pizza (subscriber, #46)
[Link] (10 responses)
Please, his text is a rambling, incoherent mess. About the only sane-ish thing mentioned there is the "automatically put all of IPv4 into the IPv6 address space", but in practice that would have some substantial pitfalls. The rest of his "proposal" basically amounts to "To migrate smoothly, first we have to get everyone to everyone to use newer software, and when that's done it will all just work when we flip the switch" -- That's like saying the secret to being rich is to start out being rich.
Even his "proposal" for DNS migration is insane -- DJB of all people should know that extending the length (and meaning of) DNS A records would break nearly every existing resolver out there.
> Am I quite sure that when it comes to software (which is what an IP stack is), most things are possible, contrary to the "cannot be done" brigade harping on about insurmountable problems. Didn't seem to stop other protocol designers. Doesn't have to be "pretty", which seem to have been what IPv6 was all about. It just has to work.
Wow, you've clearly never actually worked on real-world software. Sure, nearly anything is technically possible.. but that doesn't mean that said anythings are remotely sane or worth doing -- and anyone who's ever been handed a "doesn't have to be pretty, it just has to work" codebase can tell you that those are the most expensive approaches of them all.
Posted Jan 6, 2016 4:47 UTC (Wed)
by bojan (subscriber, #14302)
[Link]
IPv6 stands out as an exception to a general rule of making sure that things remain compatible. Instead, general replacement was in order. Sure. Looking forward to IPv12 already. It will be twice as good.
In terms of you actually understanding what DJB said, you are just being condescending on purpose. His proposal makes perfect sense and is done all the time. Examples include TLS and HTTP2, as I already pointed out. So, it's not just "crazy DJB" saying stuff like this. The "craziness" reaches far wider than that.
Posted Jan 6, 2016 5:18 UTC (Wed)
by butlerm (subscriber, #13312)
[Link] (8 responses)
That is why on a binary level you would do no such thing. On the bits on a the wire basis old style A records would be used for old style addresses, and the addresses they referred to would be publicly routeable on every network.
New style addresses (once usable) would use new style A records. Different on the wire, but the administrative user interface could be the same. None of this manually maintaining two different gratuitously incompatible network addresses for every host stuff.
Posted Jan 6, 2016 5:25 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
Posted Jan 6, 2016 5:36 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
Posted Jan 7, 2016 1:58 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (4 responses)
Just to make it 100% clear for someone reading all these threads years from now. What DJB proposed does not include a notion of an "old IPv4-only stack". So, this question is totally not applicable according to what he proposed.
Posted Jan 7, 2016 6:41 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Jan 8, 2016 18:55 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (2 responses)
We're in today's position. I cannot get a new IPv4 for reasonable money, but there are servers running old IPv4-only stacks, because the server admins have disabled the IPv6 stack because it's not classic IPv4. How, in DJB's world, was I going to be able to communicate from my DJB-IP only client to the server that won't talk DJB-IP because addresses are definitionally 32-bit?
Note that I'm talking about a situation that exists today, with a server that can route IPv6 from the server to me (so no adoption issues there), but where a software stack on top of the server knows that IP addresses are 32 bit, and thus while I can communicate with other software stacks on the same server via IPv6, I can't communicate with this legacy software stack via IPv6, because "IP addresses are 32 bit".
Posted Jan 9, 2016 0:56 UTC (Sat)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
Posted Jan 10, 2016 18:27 UTC (Sun)
by farnz (subscriber, #17727)
[Link]
That's part of today's transition route, and is what's being accused of being a failure. I want to know how DJB-IP solves this problem without using the techniques that we're using for transition today.
Posted Jan 6, 2016 13:16 UTC (Wed)
by pizza (subscriber, #46)
[Link]
In other words... the AAAA record?
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
So let me recap the text. DJB has exactly ONE suggestion: use the same address for IPv4 and IPv7 on the server side. That's it. There are no more actual suggestions.
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
And this is pure nonsense. It's simply impossible.
Owl thinks for a while and says: "You should become hedgehogs"
Rabbits go away in awe. The next day they return and ask: "Oh wise Owl, but how do we become hedgehogs?"
And Owl answers: "I gave you the answer. Now stop bothering me with such trivialities!"
No. You're confabulating. The actual 64-bit transition involved rewriting of a huge chunk of software, ugly hacks to support legacy 32-bit code, long transition periods and it is STILL not completely finished.
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
And hardware. Remember that most core routers are actually implemented in specially designed hardware.
Is it some kind of a holy text for you that needs careful interpretation? Can you simply sketch how IPv7 that is backwards-compatible with IPv4 is going to work? Just pretend that we're all here are complete dummies that need help to be able to even breathe.
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
How did this happen? Were they magiced away by a unicorn?
Can't do this. Current routers use IPv4 prefixes for routing, they can't cope with full IPv7 addresses. You need to upgrade all of the core routers and route distribution protocols to do it.
I'm saying that DJB's approach would lead to exactly the same outcome in the end.
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
I guess you REALLY have no clue. Let me ask you this: how an IPv4 core router that switches many 100GB of traffic can be made to understand full IPv7 addresses with just a software upgrade?
And it already does this on Windows. Next question.
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
Yes. And it's going to be the same with the hypothetical IPv7. Since you hold the DJB's document in such high regard, allow me to cite the Scripture:
True. It will report that there's no route to the host, which is a perfectly valid answer.
So humor me this, suppose I have an IPv7 capable host with all the newest software written by DJB. I type: "ping 0123456789abcdef0123456789abcdef".
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
> How did this happen? Were they magiced away by a unicorn?
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
Wol
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
Wol
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
Yes, there are. There's not enough IPv4 addresses for all hosts.
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
Wol
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
CGNAT is now a band-aid only
CGNAT is now a band-aid only
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)
IPv6 celebrates its 20th birthday by reaching 10 percent deployment (Ars Technica)