Posts by Nanashi

IPv6 is built to be better, but that's not the route to success

I'd fire you too with answers like that!

It's measurably faster (https://www.youtube.com/watch?v=76XbdedSrww), it's cheaper (no NAT, no split horizon DNS, no RFC1918 clashes, easier-to-understand network...) and it can be deployed incrementally and without outages.

If you need to replace networking gear at this point, either you're running stuff from 2005 still (so it's due for replacement anyway) or you bought v4-only hardware recently, which is your fault.

It sounds like you just don't know what you're doing. That's not v6's fault.

Re: Won't happen in my lifetime

You don't think going from 0.4% of the Internet’s client base to 38% over those ten years means anything?

At that rate, we'll be at 50% in three years. Predicting 10 years for something that ends up taking 13 years is pretty good going for long-term time estimates like this.

Re: If IPv6 had just been a sensible addressing extension then it would have worked

v6 is 128 bits because 64 isn't enough. EUI-64 addresses are 64 bits, and IP provides hierarchical allocation and aggregation on top of that, so it needs to be bigger than 64 bits. The next power of two up is 128.

Also, you might have noticed that deploying a new IP protocol is an extremely disruptive and expensive operation. We really don't want to have to do it again.

> A sensible alternative would have been to just extend the addressing from 32 bits to 64 bits with a direct map from IPv4 address aaa.bbb.ccc.ddd to IPv6 address 0.0.0.0.aaa.bbb.ccc.ddd

Ah, yes, but... how would this help? Even if you have a direct map, v4 hosts still couldn't talk to v6. In fact v6 already has a block allocated to this -- it's ::/96, allowing for ::aaa.bbb.ccc.ddd, exactly as you suggested. It's just not useful.

> One obvious (to everyone except the IPv6 designers) result is that routing in IPv6 is a nightmare needing far bigger routing tables than IPv4.

How is it a nightmare? v6 routing tables are much smaller than v4, due to the sheer size of the address space, which allows for significant aggregation. It's not hard to find ISPs with 500 v4 announcements and one single v6 announcement, covering the same network.

I'm also not sure about this "kitchen sinks" bit.

I think we should be glad the design of v6 was left to people who understood what they were talking about, not the many people in these comments who have no idea what the technical requirements are or how to meet them.

Re: People do not want it

The actual reality is that NAT does nothing to inbound connections. NAT changes the apparent source address of outbound connections; it does nothing to inbound ones. You can't call that "pretty good protection". It's no protection.

For your printer, it's possible to connect to it from outside your network by creating a v4 packet with the destination address set to "10.0.0.234" and sending it to your router. NAT won't block it.

Re: A fully working DNS...

Sure, and it's not like v6 stops you from doing that.

Put your router at <prefix>::1, DNS at <prefix>::53... that's pretty memorable. You'll remember your prefix easily enough after a while, or you can just look at `ipconfig`/`ifconfig` and copy it from there if you need to.

Also, having v6 doesn't mean you don't have v4, so nothing stops you from connecting over v4 to fix your DNS server -- unless you break your v4 somehow, in which case having v6 as an alternative is handy.

Re: IPv6

> But the biggest problem is the lack of interoperability. If you can't build an IPv6 network and see the whole world of IPv4 content, this means you have to build an IPv4 network as well (i.e. dual stack)

It doesn't lack interoperability. I'm posting from a v6-only machine, to this v4-only site, and it's working fine.

If the biggest problem in v6 is one that doesn't exist, then doesn't that mean it's doing a pretty good job?

Re: in IT for 27 years

> We'll remake the entire address paradigm with colons and hex, because we're engineers!!

They didn't remake the entire address paradigm. The addresses are still a block of binary and they're allocated and routed in the exact same way as v4, they're just 128 bits instead of 32.

Writing them in hex is to make them easier (not harder) to deal with: without it, the addresses would look something like "32.1.13.184.133.163.0.0.0.0.138.46.3.112.115.52", which is even more unwieldy, and subnetting when your numbers are written in decimal is much more of a pain than when they're in hex.

Using colons is to disambiguate v6 addresses from hostnames. Otherwise, an address ending in e.g. ".be" would look like a hostname under Belgium's ccTLD.

> And, especially in today's world, who in their right mind wants their IoT device to be directly addressable on the internet with its own 'front door'? Not anyone in their right mind, thank you very much.

If you're going to use a door analogy, get it right: it's like having a front door inside a gated compound. You've got the front door keeping people out, but they can't even get onto the grounds without going through security at the outer gate.

Note that the security of your house depends on the front door and the gate, not on whether your house has a number on the door. Removing the number just makes it harder for you to use the post system, which is unhelpful (because what's the point in an IoT device that can't communicate anywhere?).

Re: CGNAT is a problem for home servers on IPv4, issues with security on IPv6

What security/privacy implications are you even talking about? The situation is no worse on v6 than it is on v4: prefixes are either dynamic or static (mostly dynamic, like v4) and host IDs are randomized and changed frequently (so you can't track individual hosts on a network, like on v4 behind NAT).

v6 doesn't let people "nail you easily"... or at least, any easier than v4 does, because tracking on the internet is already pervasive on v4, but let's just ignore that part.

Re: People do not want it

v6 is not actually at all complicated; v4 tends to be more complicated in practice since you're stuck with also using NAT with it.

The "home NATing router" might be great protection, but none of that protection comes from NAT -- if you don't understand that, then that's a good demonstration of how complicated it is.

Re: Can't disagree with anything there

That's basically what v6 already did.

That's easy to do with v6 too. All you're saying here is that you're either incompetent or have never used v6 for any length of time.

APNIC: Big Tech's use of carrier-grade NAT is holding back internet innovation

Re: That old chestnut

> it’s like getting excited over smart motorways when actually what’s needed is more real lanes not repurposing an existing lane and adding technology that is continually exposed as flawed.

You've got your analogy backwards. NAT is the thing that's repurposing what we've got, and which is continually exposed as flawed. v6 is the thing that's giving us more real lanes.

NAT isn't a security layer. It's not necessary for security and gives you none; all it does is make your network more complicated, which makes its security properties harder to understand.

You'll still be behind a firewall, which will still be secure.

Re: The real problem with ipv6....

No, site local was dropped because it was awkward and pointless. There was no reasonable way to specify which site an address was in, and site local addresses gave no benefit over ULA, so they were just dropped.

Nothing to do with NAT, which is mostly pointless in v6 because of the vastly increased address space.

Re: I've said it before and I'll say it again

That doesn't help in the slightest. There are already multiple ways to indicate that a packet is a different type, two of which (the "IP version" header and the next protocol header) v6 already uses.

I said that you need to come up with something that v6 doesn't already do.

Re: The real problem with ipv6....

RFC7217 and privacy extensions fix the first problem. The second problem doesn't exist; I'm not sure where you got it from, but the top 16 bits are available for allocations. Link-local addresses are used by everybody as part of bootstrapping a global address.

A redesign to fix these problems that aren't problems wouldn't be a good use of anybody's time.

As for DHCP, v6 was developed before DHCP was common. The DHCP RFC only predates the v6 RFC by two years (1993 vs 1995), plus v6 was in development long before the 1995 RFC date and DHCP wasn't ubiquitous until the late 90s, long after the 1995 date. There were multiple other address autoconfig mechanisms in common use until then.

It's kinda unfair to blame them for being unable to predict the future, don't you think?

Re: I knew this would hapoen

> For a new addressing scheme to be adopted it HAD to be an extension of IPV4. This would have been trivial to do

Can you explain how?

The fundamental problem that needs to be solved is that v4 is limited to 32 bits. After all, if it wasn't, we wouldn't need a new protocol in the first place. Can you explain how to make a new protocol, with addresses longer than 32 bits, that extends v4 in the way you claim is trivial to do?

The reality is that this isn't possible, and all of the possible workarounds are supported by v6 (...meaning it's not 100% incompatible at all). I think it's a bit unfair to describe the people that designed v6 as "either too stupid or to full of hubris to even consider that" just because they couldn't do the impossible.

But perhaps all of them were wrong, and you're right, and it was actually trivially possible, in which case you'll be able to tell us how to do it.

Or was your own post the result of either stupidity or hubris?

Re: Addressing only the problem that v4 has?

This is basically what v6 did.

Re: Thanks, but no thanks

No it doesn't. It'll get an IP from the network's subnet, which is different for each network, so the left-hand half of the address will change when you move between networks. The right-hand half will be randomly generated and change regularly due to privacy extensions, so it'll change even if you don't move between networks.

(Of course your apps etc will still track you by IMEI, UUID or whatever, but that has nothing to do with v6...)

Re: I've said it before and I'll say it again

Those things are the backwards compatibility. How did you expect it to work? Magic?

v4 isn't forwards compatible to address spaces wider than 32 bits. That's not v6's fault; it's v4's fault. There's no way to make it "just work" without some form of backwards compatibility method, and that's what v6 implements -- because it's the only thing that's compatible with v4.

If you think I'm wrong about this, all you need to do is explain how they should've designed it to make it possible for a v4-only device to talk to a v6-only device. If you can describe a way to do it, you'll prove I'm wrong. Just remember that whatever you come up with needs to a) be something that v6 doesn't already do, and b) actually work.

I've asked a lot of "v6 should've been backwards compatible" people to do this, and not one has been able to. Perhaps you will finally be the one to share the secret...?

Re: I've said it before and I'll say it again

You don't need good drugs to see this. Between dual stack, Teredo, 6to4, 6rd, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E and more, v6 has plenty of backwards compatibility.

Why do you think it doesn't?

Re: That old chestnut

> When I'm running out of nails, I don't start thinking about buying a new hammer.

Sure you don't. But when the entire world is out of nails, and nobody can make any more of them, but you still need to nail stuff down, wouldn't you start thinking about using screws instead?

Re: I've said it before and I'll say it again

Why say it repeatedly when it's wrong? v6 is backwards compatible with v4.

Describe a method of backwards compatibility that would actually work with v4, and v6 most likely already has it or something functionally similar. There's at least a dozen different methods available, depending on what your use-case, limitations, goals etc are.

If there's anything v6 lacks, it's not backwards compatibility.

IPv6 still 5-10 years away from mainstream use, but K8s networking and multi-cloud are now real

Re: Is this the most sensible Gardner report ever?

The lack of what now? v6 is backwards compatible in many, many different ways. Describe a method of backwards compatibility that would actually work, and v6 most likely already has it or something functionally similar. There's at least a dozen different methods available, depending on what your use-case, limitations, goals etc are.

If there's anything v6 lacks, it's not backwards compatibility.

UK internet providers told to mind their MANRS and start following Border Gateway Protocol best practices

Re: though nobody noticed because they were IPv6

Actually no, it doesn't. They advertised 2400::/12, which is basically the entire of APNIC's space. Any legitimate users in APNIC are advertising routes that are more specific and thus have higher priority, so the announcement didn't affect them.

So no, the reason they didn't notice wasn't because it was v6.

China showing signs of brewing IPv6 eruption

Re: Privacy anyone?

Not privacy, no. v6 (at least with privacy extensions on, the default in most OSs) is no worse than v4 for privacy.

ISP logging knows who you are either way and it makes no difference whatsoever to account-based tracking (remember this is China where you often have to tie accounts to your real-world identity -- how is v6 supposed to cause any privacy issues compared to that?).

Asia’s internet registry APNIC finds about 50 million unused IPv4 addresses behind the sofa

Not really that many

Back in 2011, before IANA ran out, we were going through more than one /8 per month. Three /8s sounds like a lot, but it's only a few months of global demand... and that's at 2011 levels. The internet has gotten bigger since then, and a lot of people are running low on addresses.

Of course, these addresses are restricted to just the APNIC region rather than being a global pool, but on the other hand it sounds like the majority of them still belong to someone and they'll just be asking politely if those owners would like to give them up, which many might not.

This isn't going to obviate the need to do IPv6.

It could be 'five to ten years' before the world finally drags itself away from IPv4

Re: What has it got in its pocketses?

In practice most of them seem to be doing v6 properly, and even the ones that aren't doing it properly are at least providing one /64 so you can get a single network running. The abuse and charges that you're worried about haven't really materialized.

(Perhaps there might be a "yet" lurking there, since the companies doing v6 first are probably the companies that are more willing to do it right. But so far, remarkably, ISPs seem to have resisted the temptation. Even Comcast are delegating a /60, and they're routinely rated the worst company in America.)

But CLNS had all of the exact same compatibility problems with v4 that v6 has. You'd still be stuck with all of the same excuses that people are providing today for failing to do v6, just with the ISO as the bogeyman rather than the IETF.

On top of that, it also has a different networking model than v4, which probably wouldn't go down well with the people complaining that v6 (with an identical model to v4) changed too much from v4. Then there's the issue of hardware routing when your address length is variable. None of this would help.

We didn't really see much notable deployment of v6 from 4G itself. Many mobile companies rolled out a v4-only service on top of 4G (and many of those are still not doing v6 today). 4G supported v6 before 2013 because it was obvious it would be needed, but that doesn't mean that mobile networks started using it right away.

Re: That's pretty much all it does

If your attempt to fit the internet into 48 bits requires reaching for NAT, then 48 bits is too small. And in any case switching to this 48-bit address internally would involve the same amount of work that switching to v6 internally does.

Address exhaustion is exactly what v6 was designed to solve. "Expanded Addressing Capabilities" from 32 to 128 bits is the very first thing listed in the introduction of RFC 1883. AS numbers are an entirely unrelated issue. In fact your whole second paragraph is so silly that it reads as a deliberate troll.

Excessive is good! We want the address space to be too big, because the alternative is for it to be too small. The costs of the L3 address space being too small far, far outweigh the cost of the extra 32 or so bits in v6 (bits which, I note, are also used to increase security in a few places).

NAT does not itself make your internal machines unaddressable, and even a correct configuration will not prevent access to internal machines. Firewalls prevent access to machines, not NAT. In fact, if you have inbound port forwards configured then it lowers security compared to not having it by reducing the search space for servers -- instead of searching the entire subnet, you only have to search for open ports on the router of the subnet, which makes port scanning substantially easier. In the case of v6 it reduces a port scan of an entire network from requiring exabytes of traffic down to just a few megabytes.

You only have to look around this very thread to find people who argue against doing v6 even when there's a cost benefit to it. Porn sites are unlikely to be any different in that regard.

"small elite of academic's", really? The internet was long outside the control of any single entity by the 90s.

The work on a new version of IP happened too late to make it into Windows 95. Windows 95 was originally scheduled for release in 1993, although it was eventually delayed by two years, and I think it's unlikely they would've done the OS level work so close to the expected release date (and especially unlikely that they would've done it when already 1-2 years delayed). To be clear, there's a lot more work involved in increasing the address length than a single #define.

Even if they had, there would still be the issue of actually getting ISPs to provide the new version and getting people to use it, and getting developers to support it, "even though there's no point and nobody's using it". These are the parts that have taken the most time.

We only really started seeing v6 deployment take off once the RIRs started running out of space in ~2013. That timeframe would've been the same even if v6 had been in Windows 95.

Re: What has it got in its pocketses?

Do you mean a regular home CPE? That would be difficult, as very few of them don't support NAT.

This really should be obvious, but... the fact that NAT support is common in home CPEs does not mean that NAT is free to implement, or that the implementations never have bugs, or that it doesn't introduce additional complexity into networks or software, or that it can't cause problems. To be clear: it costs money to implement, the implementations have bugs, it makes networks more complicated, it adds complexity to software and it causes lots of problems. All of these issues are part of the cost, which you pay for either with money or with time, effort and frustration.

At the ISP side, NAT is done on routers that cost in the £10k-100k range. NAT may be an additional license cost, and it also imposes a performance hit that means you need to buy more of the expensive routers than you do without it. Since internet traffic is increasing over time, the additional costs of NATing that traffic also increase over time. Dual-stack ISPs see over half of their traffic flow over v6, which immediately reduces the cost of the routing hardware needed to NAT the remaining v4 traffic.

Depending on the ISP network, CGNATed traffic may need to be routed out of its way in order to reach one of their CGNAT routers whereas v6 traffic can be handed off early, which increases the latency of v4 traffic. This too is a cost you pay.

So, yes. The cost of NAT.

As for why v4 addresses are in demand, it's a combination of the cost of the workarounds required when you don't have enough address space (including but not limited to the stuff I just wrote three paragraphs about), and the fact that there are a large number of v4-only clients out there that you still want to provide service to. To be clear again: these are reasons to be doing v6, since the address shortage in v4 isn't going away.

The fact that you can continue to run v4 when you're also running v6 does not mean that v6 is broken.

I did wonder if I should include that part, because I suspected that people would zero in on it and ignore everything else I said. It seems my suspicion was on the mark.

Re: What has it got in its pocketses?

De-anonymization is about identifying the end user, not about the details of how traffic is tunnelled inside an ISP.

Isn't that what I said when I mentioned sparse allocations and aggregation? Allocations are made hierarchically and in large blocks in order to minimize fragmentation and the number of routing table entries needed, and all of this consumes address space.

Essentially, a majority of IP addresses "go unused" in order to make routing on the internet more efficient (but those addresses are actually in use, they're just being used to make routing more efficient rather than being used for assignment to an end host).

...which is why it's not enough for the IP:person ratio to be equal to or only very slightly higher than the number of devices that each person owns. You need to consider the various layers of allocations above the end device.

Re: What has it got in its pocketses?

It means that one third of the people hitting Google do so from TCP (...or UDP...) connections that have a v6 source address.

How the traffic is transported around inside the ISP is irrelevant to Google, who can't see any of those details.

Re: Hostnames

Thanks for the suggestion... although I'm not entirely sure what I'd discover that could change anything I've said.

v6 is already in many typical homes. It got there by having the same level of out-of-the-box usefulness and security as v4 does.

NAT and firewalls are two separate things. NAT doesn't provide any level of security for poorly configured/secured devices on the home network, but the firewall does and that's how home routers secure the network behind them, on both v4 and v6. We're already at the point you're saying we need to be at.

Re: That's pretty much all it does

"IPv6 nutters"? "Ivory tower"? Are we really going there? Again?

The people who designed v6 knew full well what would be involved. We ended up with what we did because there wasn't any other way to do it. v4 doesn't support addresses bigger than 32 bits, and fixing that involves replacing the IP stack with one that does support bigger addresses, and then plumbing that support through to everything that deals with IP addresses.

There's simply no way around this. You have to touch every system, because v4 is the layer of the internet that touches every system. The only methods that would help (things like 6to4, NAT64 etc) were used for v6.

Designing something that takes into account the limitations of the existing technology and of what can be done... is the exact opposite of an ivory tower.

If you're looking for people in ivory towers, perhaps you should look at the people who insist there's a way to make v4 somehow be forwards-compatible with bigger addresses without making any changes to v4 or any v4 devices. The people who are ignoring how both v4 and v6 work. Those are the people who are ignoring reality.

Incidentally, if you do have a way of designing a new protocol that's easier to deploy than v6 is, then feel free to prove me wrong by posting it -- so long as a) it actually works, and b) it's not something that v6 already does, because if it doesn't meet those two requirements it's just going to be another in the long list of dumb suggestions that don't actually help.

Re: If Only...

Not if you're paying attention. Gaming forums are full of people trying to "fix their NAT type", and they don't have much success when behind CGNAT. Games are using UPnP where they can, but people here keep complaining that UPnP is a security risk, and in any case it doesn't work so well behind CGNAT either. When they can't get a direct connection, games are relaying through central servers which adds latency and means you need the server to stay up to play the game. Similar problems abound outside of gaming too.

Yes, there are workarounds for many of the problems caused by NAT, but they're workarounds. The problems are still there, and the workarounds are expensive, and it's not necessary to pay that cost to stop people from accessing a server on your network.

Re: If Only...

Probably not hackers or the GCHQ/NSA. It's more likely to be gamers, people using VoIP, people wanting to reach their Nextcloud install or similar. These people aren't hackers.

It's okay to not want people from the internet to be able to connect by default, and it's okay to not want to change that. But you don't need NAT to stop people connecting, and in fact can't use NAT to stop people connecting, so not using NAT doesn't constitute a change to whether or not people can connect.

Yes? That's how I learnt v4 too, and I'd be willing to tick the v4 box on the same basis. If you're that afraid of running a network, then you already can't work in IT.

The risks aren't as big as you think they are... and the rewards are bigger than you think they are too. But I suppose you're not the only person who's afraid of new things.

Re: IPv6 isn't a very good solution?

They're not 4 bytes though, they're 4 octets. For computing architectures with 8-bit bytes, which is indeed common today, that's exactly equal to the length of 4 bytes, but that doesn't mean that the length of an IP address will change if you change the length of your bytes.

I was replying to a suggestion to change the size of a byte in order to get more addresses. Not only is this a non-trivial change to make, it wouldn't change the length of v4 addresses. (And even if it did, your bigger addresses would have the exact same compatibility problems with existing machines that v6 does...)

It's not enough because we're talking about layer 3 here, not layer 2. We aren't talking about MAC addresses, but IP addresses. They aren't allocated densely, but rather sparsely. The sparse allocation is critically important because it's how we scale the internet up to the scale of the internet. This is the entire reason we have IP in the first place rather than relying only on MAC addresses, and you can't just ignore it.

You're suggesting to allocate one /8 to each country, i.e. to use 8 bits of the address space to identify a country. With my lower-end allocations to end users, I'm suggesting to allocate 16 bits of address space to each user for their networks. Out of 48 bits, that leaves us with 48-8-16 = 24 bits of address space for the ISPs in each country. There are many countries, perhaps even most of them, that wouldn't fit into 24 bits of address space even in v4 land where the default end-user allocation size is often no addresses. As such, 48 total bits seems like it might very well be too few bits now, let alone in the future. That's why I don't think it'll meet the goal of giving us too many addresses.

To answer your last question: layer 2 is 64 bits for new protocols, and layer 3's routing and aggregation consumes additional address space, so we need something like 80-96 bits at L3 to handle the full L2 address space.

Re: I keep trying...

Psychic debugging time: PMTUD clamping. You might have it enabled for v4 but not for v6.

(I mean, I'd be happy to do non-psychic debugging too -- post a wget output of the failing URLs if you want, or at least tell us the sites in question.)

It doesn't obsolete your knowledge, because a significant fraction of your v4 knowledge applies to v6. It doesn't require expensive training courses; I learnt it from random web pages. It doesn't require a wholesale replacement of your entire infrastructure; you can replace each component during your normal refresh cycle. The security risks are not really any different to v4, and people's brains mostly don't lock up when dealing with v4.

If IPv8 was IPv4 with an additional two octets, then IPv8 would be too small. Deploying a new layer 3 protocol is an extremely long and expensive process. We absolutely do not want to do it more than once, so deploying a protocol that's too small would be a bad idea.

I'm also not convinced that making the protocol too small would give you universal buy-in. A lot of complaints don't seem to be based on reality, and most of the real problems involved in upgrading v4 will still exist regardless of how many bits you add.

It's really hard to put a specific duration on it, because it depends on how much you're willing to give up and how much time and effort you're willing to spend working around address space limitations, and on far too many parameters to get a proper handle on. But let's see what I can do.

In v6, you're supposed to get something between a /56 and a /48, with each network being /64. In other words, 256 to 65536 networks of effectively infinite hosts each. If we took the lower end of network count (256 networks, 8 bits) and dramatically reduced the number of hosts per network to 256 (again, 8 bits) and allocated out of a 48-bit space, then each user would get a /32 and there would be 2^32 (4 billion) /32s available.

Well, the standard allocation to end users in v4 is already either /32 or -- for phones or ISPs with CGNAT, which is probably billions of users -- absolutely nothing, and we're running out in v4, so with these allocation assumptions in a 48-bit space it seems like we'd be at least a significant fraction of the way to running out just with the current internet, let alone accommodating any future growth.

Deploying a new layer 3 protocol is an extremely long and expensive process. We only want to do it once, which means that providing far too many addresses is a design goal, so that we don't hit the point of having any reason to need another upgrade. I don't think 48 bits would meet that goal.

Re: What has it got in its pocketses?

Did anybody in your imagined conversation consider the cost of not rolling out v6? The cost of NAT, of dealing with RFC1918 clashes, of doing split DNS and VPNs and remapping, of the problems caused by CGNAT, of not being able to do things due to address exhaustion, of spending engineer time fixing problems in workarounds that just don't need to exist?

Probably not, since people ignore it constantly in the real world too, but that doesn't mean the cost isn't there.

Re: Not be simple

It's roughly the same design and architecture as v4, it just has longer addresses. There are some differences in the details but the overall design and architecture is unchanged. If you understand v4 then most of your knowledge of how it works can be transferred directly to v6.

v6 has many, many backwards compatibility methods. You can run both v4 and v6 side by side on the same networks. You've got NAT64, DS-lite, 6to4, Teredo and a number of other ways to provide v6 connectivity over v4 and connectivity to v4 hosts from v6. How can you say it's not backwards compatible when you have a whole host of backwards compatibility methods to use?

I'm considering the option of staying silent, but how is that going to help when people are spreading so much ignorant misinformation? I'd like to correct their misunderstandings, and I'd definitely like to stop the misinformation from spreading, and I don't see how I can do that by staying silent.

In that case you just copy/paste the address out of your /etc/resolv.conf file. Or type it out from memory, because it's not that hard to remember v6 addresses like 2001:db8:abcd::1; it's just your prefix plus "1". Or put it into /etc/hosts if your DNS breaks so often that this is such a big problem for you. Or connect over v4 -- one of the benefits of dual stack is that you can connect over one address family when you break the other one.