Also calling web browsers made by "stupid people" without even properly evaluating the effectiveness of your own network hack seems rather hypocritical. :)
It is very common (or perhaps almost ubiquitous since most routers will respond, idk) to get responses and works by default for most devices. It will not work if you:
- Have no IPv6 devices on your network
- The hosts on your network have a firewall that filters the packets or configuration that disables pinging (I think Windows disabled ping by default since Vista)
- You have some fancy network with host isolation (trading usability for security), often seen with enterprise vendors
- It autodetected the wrong interface to send the packets out on. I don't know how ping does this, perhaps it tries to just send it everywhere. Can't quickly find it but the Arch wiki says you have to specify the interface (for me it works without, so clearly that's not exactly accurate, but I imagine it may not do what you want)
For anyone wanting to replicate this "provides" query on Debian, I use `apt-file search /bin/ping` to list what packages have a file with that name -- this will also match `/usr/bin/ping6` (both prefixes and suffixes will match) but that was fine in this case. (If you just do `apt search ping` or something, you get a huge list of any package mentioning the word ping, which may be what you want when searching for something more broadly; and if you use `apt search /bin/ping` it comes up empty because it doesn't have file path data.)
Edit: now that I had looked up which utility it is, I figured I'd check the "is documentation enough" on how it finds which interface to use. It looks to me like it is `getaddrinfo` that decides it: https://github.com/iputils/iputils/blob/master/ping/ping.c#L...
> pkgfile $(which ping)
core/iputils
$ ping -6 ff02::1%eth2
You shouldn't need `-6`, given it's a v6 address.
I do have a link local address directly on that NIC. I also use VLANs sometimes, but none are configured right now on this link. Slightly edited below to hide my MAC but:
$ ip -6 address show dev eth2 | grep link
inet6 fe80::aef0:b837:fafa:fefe/64 scope link noprefixroute
You seem to be here to complain more than to actually learn, else you'd've said what results you got, and you'd communicate better by not using acronyms without context (TFA: trans fatty acids? Thanks for asking?)
Regarding the comment about web browsers being made by stupid people, we're all allowed to have opinions. Most of the common web browsers have tons of stupid design choices, and generalizing that stupid design choices come from stupid people just sounds like a flippant remark, not a denigration of a whole group of people. The people I know who work on web browsers would wholeheartedly agree with the author's comment (I've heard many similar sentiments).
The information in this article is useful, and everyone even remotely in IT would benefit by keeping this page bookmarked :)
"The Fucking Article." Etymologically derived from "RTFM," but now mostly used as a casual abbreviation to refer to the article that a comment thread is about. People who have traumatic childhood memories of soap in their mouths sometimes pretend it stands for "The Fine Article" or "The Featured Article."
That's the context: "ping ff02::1%enp34s0" just doesn't get any responses at all. And yes, I have both global and link local IPv6 addresses on the interface.
Apparently not?
"PING ff02::1%enp34s0(ff02::1%enp34s0) 56 data bytes"
...and nothing else at all?
> What year is it? "ping6" hasn't been a thing for well over a decade now that standard ping works with IPv6 just fine.
Ummm... Perhaps that's true about your specific OS, but there are plenty of other OSes for which this isn't true, like macOS and the BSDs.
> Too vague to respond.
I was trying to make the point that you were the one being too vague. We can guess at things, but saying "nothing happened" is not the same as saying, "I did this thing, and this is the result I got", where the result isn't described as "nothing" ;)
> "PING ff02::1%enp34s0(ff02::1%enp34s0) 56 data bytes"
> ...and nothing else at all?
Correct, at least until I send ^C and get a report of 100% packet loss.
> Perhaps that's true about your specific OS, but there are plenty of other OSes for which this isn't true, like macOS and the BSDs.
It's true on Linux and FreeBSD anyway, the two OSes I have installed in my home. Granted, FreeBSD does hardlink ping6 to the same binary for ancient script compatibility, but the standard ping works just fine. OpenBSD is the same. The days of IPv6 being a weird experimental protocol requiring separate commands are long over (I can't check Mac OS, don't own any Apple products).
Often, something is (seemingly) bad because of a lack of time or other resource, because a boss or standard told them to make it bad, because there is some bigger issue being avoided, etc...
Especially when it comes to browsers, vendors are making trade-offs, and supporting a very rare case like this when URLs are often very sensitive security-wise seems like one I could understand being wary of. Does a user understand what devices they are connecting to in that situation?
It's probably intended as a joking remark, maybe even an "all people are stupid" thing poorly done, but even so, I think it perpetuates a bad way of thinking about flaws in software.
The platform-specific nature of <zone_id> makes it difficult to impossible to validate the well-formedness of the URL (see https://tools.ietf.org/html/rfc4007#section-11.2 , as referenced in 6874, to fully appreciate this special hell). Even if we could reliably parse these (from a URL spec standpoint), it then has to be handed 'somewhere', and that opens a new can of worms.
This sentiment is the fundamental attribution error [1] in a nutshell: "Others do stupid things because they're stupid, I do stupid things because stupid circumstances and other people made me" :)
And while I can see that it's being used flippantly here and not intended as an insult, I still don't think it's fair to the many decidedly non-stupid browser devs out there.
[1] https://en.wikipedia.org/wiki/Fundamental_attribution_error