Title needs a small fix, it should be `ping ff02::1` (with two colons) to be a valid IPv6 address, match the actual command, and match the original title.
IPv6 link-local addresses based on MAC address are neat, I use that in production.
We build a machine containing six cameras. All of them come with the same default IPv4 address, but the MAC address is based on the serial number, so the IPv6 address is, too. Employees enter the six serial numbers by scanning Datamatrix codes in order, and I can calculate the IPv6 addresses from that, connect and change their IPv4 addresses all in parallel.
Ten years ago I did the same thing on a different product with weird ARP shenanigans. The IPv6 approach is way faster and cooler.
Time to rant: why can’t I have a URL, in whatever format (special type of IPv6 address would work, although the available bits are a bit crunched), where the URL includes a public key? Then people could use HTTPS to communicate with local devices for which there is no practical way to provision certificates?
Public keys should be rotated which would expire links. I think just having trust on first use would bridge most of the gap for local devices.
.. Now if we could get local socket support for talking to your own device and avoid arbitrary port reservation on localhost, that would make me happy.
> Public keys should be rotated which would expire links.
Sometimes public keys should be rotated, and this would indeed expire links. And sometimes they shouldn’t be (a key pair in a TPM-like device in an embedded system would make a lot of sense).
> I think just having trust on first use would bridge most of the gap for local devices.
This has the exact same key rotation problem. And you can get quite close to TOFU with an HTTP page that links to a a hypothetical HTTPS+key link.
It is indeed broadcast for all intents and purposes. IPv6 noticed that broadcast was just a specific case of multicast and decided to conceptually subsume it. One of the very minor changes that IPv6 brought along. "Broadcast" is just shorthand for "multicast to everyone".
Well they also expanded multicast into "limited group multicast" with the way Duplicate Address Detection works. There's a lot of cleverness baked into IPv6.
I added discovery support to scuttlebutt for link-local addresses to create "routerless" (no DHCP/SLAAC/Manual address assignment) self-repairing networks. Always wondered how broadcast worked, so appreciate the detailed writeup.
Never heard of this trick, I go to try it and... nothing. TFA may have some funky network setup to allow this.
Also calling web browsers made by "stupid people" without even properly evaluating the effectiveness of your own network hack seems rather hypocritical. :)
> [The Fine Article / OP] may have some funky network setup
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)
On Arch, I get "ping: Warning: IPv6 link-local address on ICMP datagram socket may require ifname or scope-id => use: address%<ifname|scope-id>", and it doesn't work unless I do so.
Oh, interesting! Which ping have you got? Mine comes from the iputils-ping Debian package, which the man page confirms it's part of some broader iputils set of tools. I see there is also inetutils-ping which provides the same /bin/ping and /bin/ping6 commands, is that perhaps the one you've got?
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...
Do you have a link-local v6 address on that device? My first attempt `ping ff02::1%enp9s0` didn't work because I use VLANs and don't actually get addresses on the base device, using the VLAN virtual device (in my case `ping ff02::1%lan`) worked for me.
Yea I figured -6 was superfluous but I put it in because another commenter made a big deal out of ping vs ping6 (a distinction that's been gone in Arch for a while).
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
The same command works fine on my Debian and OpenWRT boxes, but not on my Arch desktop.
Is your result "nothing" because you 1) have IPv6 turned off, 2) are running a restrictive reverse firewall, 3) didn't pay attention to the fact that you likely have to specify your ethernet interface explicitly, 4) didn't notice that you need to use `ping6` instead of `ping`, 5) have device isolation on your wifi network, 6) any of a number of other things?
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 :)
1. Fully working IPv6 network.
2. No restrictive firewall (pings work just fine in unicast contexts)
3. Used "ping ff02::1%enp34s0" exactly as the article suggests.
4. What year is it? "ping6" hasn't been a thing for well over a decade now that standard ping works with IPv6 just fine.
5. Not even using WiFi.
6. Too vague to respond.
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.
So your network interface is enp34s0? And the results you get are...
"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).
"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."
Thanks! I have been on HN since 2014 and I still hadn't figured out WTF people were talking about with TFA. I just assumed it was some kind of reference to the article but I didn't realize the F was for fucking.
The stupid people thing annoys me, because you see so much of "man, the people doing this must be stupid for not doing that" in so much conversation, which ignores the reality that so many things are outside of an individual's control, and I think blaming individuals rather than systems leads to a lot of bad systems hanging around forever unchanged, as it tends to become a thought-terminating idea, just "don't be stupid".
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.
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.
Since you are making valid points and being downvoted for the pleasure.
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.
It may be different on newer MacOS but on mine you will need ping6
> ping6 ff02::1%en1
for example.
I wasn't able to get it to work on Windows (I can get the command to work in WSL but it seems to sit alone in an internal network). Any advice welcome.
Wasn't it that you have to specify the interface with something like -i in Windows? Or was that Nmap maybe... I don't have Windows to test with here, but have you checked the --help or /? to see if it allows specifying an interface with a separate option?
It can also be that there are simply no other devices responding to this on your network, especially if those are also Windows (more infos/options in my other comment https://news.ycombinator.com/item?id=40503155)
I'm on Windows and I have the same issue. I specified the interface with the % notation (it clearly does something, because if I put a wrong interface number, it gives me "general failure" instead of a timeout). The flag -i is for TTL, not interface.
However, if I do the same from my rpi, a few devices respond (my tv box, the rpi itself, etc)... including my windows machine!
Get your interface id first, you're looking for the IDX number. There might be several.
ping ff02::1%LAN_INTERFACE_ID
So, example:
```
ping ff02::1%22
```
Windows ping wrt the firewall is not very smart, it won't let the response packets through. So you need to disable your firewall to see systems responding.
Sadly, ping won't display the src address. It will state that "ff02::1%22" responded... But if you look in wireshark you can tell the other systems on your network received and responded to the packet.
This doesn't help. Windows "ping" deals with ipv6 addresses just fine. It's the multicast part that seems to be the issue. If you try `ping ff02--1s20.ipv6-literal.net` (assuming your network interface is 20), the reply says that it's pinging ff02::1%20.
