Really need governments to start pushing harder on IPv6 adoption. We need sticks, not just carrots. My favorite is chaos engineering forced IPv4 downtime.
In the US, I really want the FCC to mandate that an ISP provides IPv6 connectivity in order to meet the criteria to be considered broadband (and access the subsidies related to that). Don't even care if the functionality is off by default / you have to call and agree the routing may be sub-optimal, whatever. I currently use HE tunnels but on top of additional latency, the HE <-> Cogent peering dispute still makes it difficult to access services over IPv6.
There should be rule that ISP with CGNAT must offer IPv6 as an alternative. The US doesn't use CGNAT as much as other countries, but would help people stuck behind crappy CGNAT.
Yeah I this is the bigger issue. CG-NATs break things, you shouldn't be able to sell a pooled IP CG-NAT only service as broadband connection. Looking at you MetroNet
Nah, we just need actual carrots. If something new is better than what people currently have, and you make it easy for them to get the new thing, people will naturally abandon the old thing. They'll do it happily. In fact, it will be hard to stop them from abandoning the old thing for the new thing.
IPv6 has failed at being better, being accessible, or both. Rather than punish people for failing to adopt something that isn't better or easy to get, either improve IPv6 so that it's actually attractive or admit defeat and start work on the next version that people will genuinely want.
The moment you start thinking "Let's make what people have now worse until they move to this other thing they don't want" its an admission that whatever you're pushing people to is shit.
> IPv6 has failed at being better, being accessible, or both.
I don't agree that it has. IPv6 is clearly better (no collisions between address space and thus no NAT requirement), and it's perfectly accessible to anyone who actually tries. I'm not by any means a top tier network guy but even to me IPv6 is dead easy to setup. The problem with the v6 transition is that people have very inaccurate views on one or both of those points (usually they falsely believe NAT provides security benefits, or they falsely believe IPv6 is a difficult thing to implement). I'm not sure how to fix this widespread misinformation but that is the problem from what I've seen.
IPv6 primarily solves a problem that most people either don't have ("I have IPv4 IPs already") or don't care about ("I don't know/care what my IP is") and it introduces a bunch of problems people didn't have before like worries over comparability with existing hardware/software (improving all the time) or even just "now I have to spend a bunch of time learning about how to correctly and securely implement this on my network" (still a problem)
Maybe one day in the distant future, IPv4 collisions/shortages will be an actual problem for most people. If that happens, those people will naturally make the switch. Until then, why would they?
It turns out a bunch of people actually like NAT. They like it so much that they pushed for solutions like NAT66 so that they can keep it even after switching to IPv6.
If IPv6 offered substantially better security/privacy, speeds, reliability, or introduced some new killer feature people didn't even know they wanted until they learned about it there wouldn't be any reason to try to force people to move to v6. Because it doesn't do any of that, and most people are happy with IPv4, they'll stick with what has been working for them.
Even 15 years ago IPv6 was much worse than IPv4 for most of the people. Only when the mobile operators has started to insist on it then the usage started to grow to significant numbers. Which showed the real problem with IPv6: lack of compatibility with IPv4. That was absolutely possible 30 years ago, but the designers decided that it would just complicate things.
I am tired of people claiming that you can make a "new Internet protocol that is compatible with IPv4".
No, backwards compatibility is not the problem here: IPv6-only hosts can easily connect to IPv4 hosts. Just append "64:ff9b::" to an existing IPv4 address, like so: 64:ff9b::8.8.8.8. Even prior to NAT64, we have plenty of schemes like 6to4 to bridge IPv4 and IPv6.
But no IPv4 hosts can ever connect to IPv6 hosts, or IPv7, or IPvInfinite for that matter. I will refer to my previous comment on why that is: https://news.ycombinator.com/item?id=46469336
I think the people complaining about compatibility are more talking about the concepts in IPv4 and IPv6. IPv6 could have been "everything is the same except the IP address is 16 bytes instead of 4". Instead there are new ways to do everything.
Addressing works differently (no broadcast, multicast everywhere, link-local is mandatory). Configuration works differently (SLAAC, RA, DHCPv6 is not a drop-in replacement for regular DHCP). Neighbor discovery replaces ARP and depends on ICMPv6 working. Fragmentation behavior changed. NAT is “not a thing” by design, which breaks a bunch of assumptions people built entire networks around.
The US government is pushing IPv6 for government sites and contractors.
I think there needs to be a push for IPv6-first networks for companies. ISPs in the US are pretty good about IPv6. But network engineers learned IPv4, and don't want to change what works, so companies lag behind. Changing existing networks is hard, but IPv6 is good candidate for new networks. This includes writing docs and eventually the education so IPv6 is the default.
It's a pity they have to make an entirely new RFC, rather than amend the old RFC. Having independent RFCs and not a single unified "internet standard" under version control is a bit of a bummer in this manner.
I think that's just incorrect. There are varying conventions for spaces vs no spaces around em dashes, but all English manuals of style confine to en dashes just to things like "0–10" and "Louisville–Calgary" — at least to my knowledge.
HMRC style guide: "Avoid the shorter en dash as they are treated differently by different screen readers" [0].
But I see what you mean. There used to be a distinction between a shorter dash that is used for numerical ranges, or for things named after multiple people, and a longer dash used to connect independent clauses in a sentence [1]. I am shocked to hear that this distinction is being eroded.
That guy's style guide seems to conflict with the Cambridge editorial services guidelines - though that is for books rather than papers:
> Spaced en rules (or ‘en dashes’) must be used for parenthetical dashes. Hyphens or em rules
(‘em dashes’) will not be accepted for either UK or US style books. En rules (–) are longer than
hyphens (-) but shorter than em rules (—).
Also on phones it is really easy to use em dashes. It's quite out in the open whether I posted from desktop or phone because the use of "---" vs "—" is the dead give-away.
These bootstraps essentially speedrun software history, and so they tell us a lot about how we got here, and why we write the things we write. But they also create perfect game to weite greenfield alternative bootstraps. The shortest, most readable bootstrap, is proof of the best abstractions, the best way of doing things.
It's a chance to finally put the sort of software stack / tech tree stuff on a more apples-to-apples basis.
I mean, my company buys them, I know at least one other that does too. Both are too technical I think to bother with a hardware support contract. But others might!
the service business that will get fast turn over repair for a business to pay the premium they pay to levono/ibm isn't that easy to do. But yeah, I am sure they could create an ecosystem of reparability that would increase their sales
My understanding is that Dell/Lenovo share a lot of parts to keep the third party repair business viable, because they sell a lot of next day replacement contracts.
reply