The main reason I haven't switched my networks to IPv6 is that I plainly don't want to support both protocols at the same time. If I could just switch over to IPv6 and leave v4 behind I would, but I just can't be bothered to do twice the work every time I setup a firewall or a router. Double the config, double the tests and on top of that you have to make sure everything inter-operates smoothly when IPv4 alone still just works.
As you mention in your other post it really is the "billion dollar mistake", it's obvious to me in hindsight that they should have made IPv6 completely backwards compatible with IPv4, no matter the cost. Have a deprecation procedure later on if you want to remove the hacks necessary to support IPv4. Have a clear and simple upgrade path, one step at a time.
Sure, having a clean new standard is compelling but clearly it's making things way more difficult that they ought to be. And that's how we end up more than 20 years after RFC1883 was released with "barely" 20% adoption. NATing was easier than IPv6, so people NAT'ed everything and the internet became the net.
> As you mention in your other post it really is the "billion dollar mistake", it's obvious to me in hindsight that they should have made IPv6 completely backwards compatible with IPv4, no matter the cost.
It's not a matter of cost, it's simply impossible.
IPv4 has a 32 bit field for the source address and a 32 bit field for the destination address, and every connection over IP needs to send packets back and forth between the two addresses. As soon as one party has a longer address, the other party has to know how to handle that, otherwise, they cannot possibly communicate.
The only point where compatibility would be possible to some degree is the network, but (a) that compatibility is in effect a tunnel, and there are lots of ways to tunnel IPv6 over IPv4 just fine, and (b) most of the global internet supports IPv6 just fine, and has been for a long time. The problem is the migration of the endpoints, not so much the network.
I actually started replying to your comment with my master plan to make an "IPv6 in IPv4" but I realized that I was probably going to make an ass of myself since plenty of much more clever people have worked on the subject for a long longer than I did.
But I guess my main issue with this is:
>(a) that compatibility is in effect a tunnel, and there are lots of ways to tunnel IPv6 over IPv4 just fine
I agree that no matter how you slice it, at some point if you want to transition you'll have to tunnel things. But why are there "lots of ways" to do it? Why isn't there one single, "it just works" way to add compatibility? IMO this should have been a core feature of the standard, bullet point #2, just below "add more addresses". Explain in details how the transition will be made, how you convert an IPv4 into IPv6 incrementally while not breaking anything. Sure it's hard to make a one-size-fits all, but all the corners you have to cut and just make it work.
Why isn't the IPv6 my ISP provides simply an extension of my IPv4? If my IPv4 is 216.58.213.174, why isn't the IPv6 216.58.213.174.[more stuff]? Why can I just concatenate my IPv4 public and NAT'ed LAN IP to get a valid IPv6? `ifconfig eth0 inet6 216.58.213.174:192.168.0.101/32` and here we go. It looks familiar, I understand what it means. You could even standardize it to make the IPv4 always be the low bytes of the IPv6 address or something like that, this way I don't have to worry about two sets of addresses.
Instead it's `ifconfig eth0 inet6 2001:41d0:000a:050d::1 prefixlen 128 accept_rtadv no_radr`. Ah. I'm sure there's a good reason to make those changes but I can't really be bothered to figure them out as long as IPv4 just works. I'll get around to learn it, eventually, maybe in a few months when I read an article on HN telling me that we're at 21% worldwide adoption.
> But why are there "lots of ways" to do it? Why isn't there one single, "it just works" way to add compatibility?
Well, for the same reason why there are lots of ways to tunnel IPv4 over IPv4? Some work through NAT, some don't, some encrypt, some don't, some allow for transport of packets that exceed the tunnel's transport PMTU, some don't, ... it's some form of tradeoff for different needs: If you are behind CGN of some crappy provider, you probably have to tunnel over UDP using small packets, if you are an ISP, that would be way too much overhead and you want to instead transport over raw IP in jumbo frames.
> Why isn't the IPv6 my ISP provides simply an extension of my IPv4? If my IPv4 is 216.58.213.174, why isn't the IPv6 216.58.213.174.[more stuff]? Why can I just concatenate my IPv4 public and NAT'ed LAN IP to get a valid IPv6?
Because that would not actually help anything. That would possibly make the user interface look a bit more familiar, but you would still need a completely new protocol underneath with all the same migration problems that we have now. And also, the differences at the user interface level are pretty minor, conceptually IPv6 really works much the same as IPv4, except with longer adresses. That they chose to use hex notation instead of decimal really is probably simply to make the notation shorter, and also the shorthand-notation for a run of zeros makes things a bit less unwieldy.
As for actually somehow reusing the existing address space, the existing global IPv4 routing table is massively fragmented with every larger ISP having tons of routes for disparate prefixes that they acquired over the years. That makes IPv4 backbone routers expensive. IPv6 is large enough that providers generally should never have more than one prefix, which makes the routing table a lot smaller.
But don't you think UI is extremely important in these situations? If you sold IPv6 as "it works like IPv4 but with 128 bit addresses" I'm sure it wouldn't seem nearly as daunting to make the switch. But when you start looking closely you realize that it's more than that.
Regarding the size of the routing table, is it really that much of a big deal? Is it significant in the ISP's expanses? I find that hard to believe.
Also, obviously the ISPs might want to use clever tricks to save on bandwidth and processing power but that's not really what I'm talking about. ISPs have the manpower and the knowledge necessary to deal with that difficulty.
The case I have in mind is what is, in my experience, 99% of the private networks today: you have a single public address, a NAT/Firewall/Router combo and then a handful of private subnets.
This is where the migration should be as simple, seamless, familiar and comfortable as possible. This is where people can't be bothered to spend one week understanding IPv6 and reconfigure everything and still not be certain that they won't break something. This is where having IP addresses that actually look like IP addresses matter.
> But don't you think UI is extremely important in these situations?
Well, yeah, that's why they invented a more compact notation than 207.170.223.70.213.170.133.129.131.136.235.244.33.54.210.133.
> If you sold IPv6 as "it works like IPv4 but with 128 bit addresses" I'm sure it wouldn't seem nearly as daunting to make the switch.
But ... it doesn't seem daunting? I mean, obviously, you seem to think so, but I didn't find anything daunting about it when I enabled IPv6 on my network and servers ~ 15 years ago.
> Regarding the size of the routing table, is it really that much of a big deal? Is it significant in the ISP's expanses? I find that hard to believe.
The current global IPv4 routing table has ~ 670,000 entries, the current global IPv6 routing table has ~ 41,000 entries, distributed over 58,000 and 14,000 ASes, respectively.
Mind you that a router has to do a routing table lookup for every packet, so tens to hundreds of millions of lookups per second for backbone routers. The CAM for routing table storage is one of the performance limiting factors of a router, and the larger it needs to be, the slower and/or more expensive it gets.
> The case I have in mind is what is, in my experience, 99% of the private networks today: you have a single public address, a NAT/Firewall/Router combo and then a handful of private subnets.
There were 6to4 or teredo, for example, which allowed for some of that. But part of the problem is that if you want to talk to IPv6 hosts over v4-only connectivity, you need to talk to some sort of gateway--the IPv6 host itself obviously doesn't have an IPv4 address (otherwise you could just as well speak IPv4), you yourself cannot directly speak IPv6, so ... you need some party that is connected to the IPv4 and the IPv6 networks to translate between the two. If that is supposed to provide good performance, your ISP needs to operate such a gateway. Which means it's not exactly an automatic solution either.
> This is where the migration should be as simple, seamless, familiar and comfortable as possible. This is where people can't be bothered to spend one week understanding IPv6 and reconfigure everything and still not be certain that they won't break something.
Well, for the most part, most end users really shouldn't need to do anything like that. Even less so that with IPv4, really: Your ISP assigns you a prefix, your router assigns addresses to your devices, and everything should just work.
If you actually want to do some fancy network setup or something ... well, really, it's not that difficult. Easier than v4, really.
> This is where having IP addresses that actually look like IP addresses matter.
But they look exactly like what IP addresses have looked like for the last almost 20 years! IPv6 IP addresses, that is ...
IPv6 could have done three things. First, embed the "legacy" address space. Second, have legacy-to-legacy connections use v4 on the wire. Third, strongly encourage existing user-maintained configuration (config file formats etc.) to remain perfectly valid as long as they don't use v6 addresses (or other v6 features.)
You are right, you'd still need a "legacy" address to connect to "true" v4 servers, but that address would be all you need, while most operating systems, routers, client and server software could be, technically, all-v6 all-the-time by now.
> software could be, technically, all-v6 all-the-time by now.
I started using v6 in the late 90s.
Software developed post-2000(-ish) should already be compatible. Unfortunately, there are a lot of developers that think this is hard/impossible (or they are lazy), and so we have software that is defunct by design.
> that address would be all you need
Regardless of how the address was represented, software would still need to be updated.
I stand corrected, RFC 4038 seems to be what I was looking for. But it seems to be a late addition, and OS support is optional. If developers think moving their apps to IPv6 is too complicated, I can't fault them.
> If developers think moving their apps to IPv6 is too complicated, I can't fault them.
I can. I'm a developer and it's easy to add support for IPV6 to apps.
Parsing and displaying IPV6 addresses? There are many libraries and articles for that. Connecting to a host name? Call one function and loop through the list of address structures returned and connect like normal with them skipping the ones that failed. Accepting connections? A little more tricky but since you're writing a server it's not difficult in comparison. The tricky part is figuring out what order you should bind to the socket or if you should use IPV4 mapped addresses.
And if you're using a higher level language or library then it becomes even easier. You just have to worry about the larger size of the address in both binary and text representation if you care about that at all (connecting to a host name you don't have to worry).
The only difficult bit is convincing management it's a good idea to support IPV6. But then the problem shifts from the technical to the political.
> Second, have legacy-to-legacy connections use v4 on the wire.
Just as IPv6 does?
> Third, strongly encourage existing user-maintained configuration (config file formats etc.) to remain perfectly valid as long as they don't use v6 addresses (or other v6 features.)
Just as is the case with IPv6?
> You are right, you'd still need a "legacy" address to connect to "true" v4 servers, but that address would be all you need
Just as it is now?
> while most operating systems, routers, client and server software could be, technically, all-v6 all-the-time by now.
If they implemented the extensions ... just as if they implemented IPv6 by now?
It sucks at being compatible with ipv4. The "billion dollar mistake" :-)
It also sucks at having software/hardware stacks nearly as well debugged as those for ipv4, which means running ipv6 at all is a security risk.
Nobody would switch for sundry technical advantages. The main driver for conversion is that ipv4 addresses are scarce. As soon as "we" seriously "move to ipv6", however, the scarcity driven pressure to convert is relieved. We're bound to reach an equilibrium that will include ipv4 for a long time, possibly forever.
> It sucks at being compatible with ipv4. The "billion dollar mistake" :-)
You cannot make it compatible. The whole point is address extension, and a legacy IPv4 endpoint cannot possibly talk to a new, extended-address endpoint.
> It also sucks at having software/hardware stacks nearly as well debugged as those for ipv4, which means running ipv6 at all is a security risk.
There is no "stack". The software above the IP layer is still UDP, TCP, HTTP, SMTP, ...
> Nobody would switch for sundry technical advantages.
Yeah, actually, lots of competent people do, because NAT and duplicate addresses just cause so many pointless problems.
> As soon as "we" seriously "move to ipv6", however, the scarcity driven pressure to convert is relieved.
Yep, the pressure to convert will be relieved because people simply won't bother setting up IPv4 in the first place at some point because it adds so much unnecessary complexity, so no need to convert. And once that happens, even the last holdouts will enable IPv6, at which point IPv4 will be a largely useless legacy protocol that just causes maintenance costs for nothing.
I've been writing all my socket code (this is embedded so plain C) to be automatically compatible with either IPv4 or IPv6 for, what, ten years? I thought everybody did that (it's best practice).
Don't most higher level languages also just do this by default under the hood?
- NAT and CG-NAT for big networks is complex, resource-intensive.
- Fragmentation on IPv4 requires more work/complexity from routers.
- Some of my friends seem to think that calculating /29 IPv4 networks is simple, but I don't deal with this often and it really annoys me (yes, even with ipcalc). Not to mention the number of addresses lost due to routing (I often use link-local addresses on IPv6).
Start moving now, progressively, or you'll be forced to do it in a rush later on. This isn't too different than https adoption. Those who minimized its importance ("oh, that's just internal communication, it can be plain http") got seriously bit.
Meh, not major problems. Those will inevitably go away as more and more people adopt ipv6.
However, I feel as though maybe developing countries might stubbornly stay on ipv4. They're already double-NATing right now, and it's likely that developed countries will sell off their ipv4 ranges once they've made the switch.
Brazilian here. Not sure if I'm part of the "developing country" category, but most major ISPs already give ipv6 for home users. I've been using ipv6 since a few years without even realizing until I entered the router and saw an ipv6 address along with an ipv4.
From the article: "It’s not like they’re bumping it by a buck and making a little bit more money. They are really tanking sales and it kind of has a ripple effect to us, being a small company trying to do demand planning"
The relevant Econ 101 buzzword isn't "supply and demand," it's "agency problem".
Amazon is "tanking sales" unilaterally, while the supplier manages stock on assumptions of higher sales at the regular, lower price point.
The problem is not that they built some product and monetized with ads. The problem is they injected themselves into a product they didn't build. Worse yet, they're open source projects.
If you can't see the distinction between this and the examples you mention, you really don't qualify to make sarcastic comments.
Exactly. And don't forget about the proliferation of the internet-of-shit devices, which are blasting everything they can learn about your home network to every company involved.
HN is specifically geared towards people who make a living coding things in the new "surveillance economy." This particular example (to go along with the dotnet command line issue) is just a difference in degree, not kind. They're mad that someone else is abusing their trust and privacy.
That is a narrow way to look at things and is not the full picture. Plenty of people protested and still protest Google's unethical business practices.
Brand power! I get totally nauseated every time tools/frameworks/programming languages get adopted just because they have the Google brand on it, when there are perfectly better alternatives.
> Economics and politics haven't caught up with this yet.
That seems unlikely. Political and economic leadership throughout the "White West" has been subsidizing and expanding the non-productive underclass for decades.
Have you ever observed typical homeopathy users—middle to upper-middle class mothers of young children—in their natural habitat?
I have. They're all "true believers" in that they really think homeopathic remedies are useful, for themselves and their kids. And yet, despite that, they also exhibit a well developed instinct on when not to rely on homeopathy and send themselves or the child off to a "real" medical practitioner. Strange, isn't it?
It ceases to be inexplicably strange if you think about their shared belief in homeopathy as a socially evolved strategy about how to keep themselves and (more crucially) their children away from doctors in those plentiful cases of minor sniffies where a doctor is overkill and actually more likely to do harm than do any better than "doing nothing".
The sad thing is that society doesn't allow a mother to just "do nothing". Where there's no accepted alternative, she "must" visit a doctor, lest she be accused of neglecting her duty to care for her children.
That's why it seems that some parts of society—and not the stereotypically "stupid" ones at all—have evolved mechanisms that afford them social license to avoid the doctor when the doctor is more likely to do harm than good.
SO, as a placebo it's performing a useful function? Alternatively, develop a backbone and do what you think is right regardless of criticism.
No, homeopathy is the art of selling water to people who need medicine, and telling them its medicine. Its actually evil, in the sense that its lying to make money, and hurting somebody who trusts you. As mentioned, at best there's no harm because there was no need. But nowhere in the process is there any reason to believe instinct will magically kick in when real medicine is needed.
Your thesis leaning on the reality of social pressure seems plausible. And not wasting doctor's time with trivial complaints clearly has social value.
But what about the opposite case: Serious complaints left effectively untreated while the disease progressing under "homeopathic treatment"?
http://whatstheharm.net/homeopathy.html
Wouldn't even one such case have to be weighted more heavily than a hundred wasted 15-minute doctor's appointments?
This is why US antitrust law focuses on harm to consumers, not companies. I don't see much harm to consumers if Google refuses to do business with websites that annoy consumers. Google already has a lot of rules that websites have to follow in order to be eligible for AdSense.
I don't know if that's true that it's an abuse of their position. Here's the paragraph from their policies:
> Sites showing Google ads should be easy for users to navigate. Sites may not change user preferences, redirect users to unwanted websites, initiate downloads, include malware or contain pop-ups or pop-unders that interfere with site navigation.
That all seems reasonable to me. They don't want to be associated with garbage websites.
And my personal opinion is that this kind of thing is exactly what G should be doing with their market position.
No consumer, anywhere, in the history of ever, has wanted things to pop under their browser window stealthily. As such, G abusing their position to hurt companies that do it is a good thing. Those companies should be hurt, and preferably die a terrible, terrible death.
If and when G uses their market dominant position to do something which hurts consumers, then things should be investigated. But an action like this, which has no negative consequences for users, should be applauded.
Google AdSense already has a bunch of requirements in place for sites that want to run their ads -- content restrictions, restrictions on traffic sources, limits on the number of ad units on the page (including ads from other networks), etc. Many of these restrictions are in place because Google's advertisers won't want to run their ads on pages that don't meet those requirements, and Google's new limitations on popunder ads probably fall into that category as well.
Alas, while Russian (and Chinese) general disinterest in f'ing with you does help, their equally developed general disinterest in your well-being means they might have incentive to sell or trade with entities more... interested.
For private individuals that move makes sense. For nation states (with the exception of NK because they're so broke) - a financial incentive isn't enough.
Petya with M.E.DOC is a good example, Russians burned quite a significant attack infrastructure there. They could have sold that access to "someone" but the price (under $1mil in my opinion) isn't worth the sort of chaos it caused in ukraine (majority of companies in ukraine used that software I believe). My point is, if they did backdoor kasperskyOS, it wouldn't be used for a financial end, maybe to "show off" their capability, a retaliation to your government screwing with them,etc... but certainly not a financial end.
Frankly, I'd be happy if governments stay out of securiing civilians when it comes to computers and the internet. Tired of being a meaningless pawn to be discarded whenever convenient to do so.
