3 ms·
> In order to disambiguate what's the host and what's the port, you typically format the IPv6 address in square brackets, so fe80::4 on port 80 would look like
by yjftsjthsd-h 5mo ago
> In order to disambiguate what's the host and what's the port, you typically format the IPv6 address in square brackets, so fe80::4 on port 80 would look like this:
> [fe80::4]:80
I really do wish they'd just stuck with dots. Or if we must upend things, commit to the bit and change the character to separate ports.
- anyfoo 5mo agoYeah. I think that's actually my one, biggest gripe about IPv6, those damn colons. And those damn brackets that were made to mitigate the colons, that just cause more problems: Just yesterday I tried to use rsync (like I do all the time, in my mind there's no reason to use scp when rsync does everything better), but this time I needed to specify an IPv6 address. On the (admittedly ancient) rsync version that comes with macOS, this doesn't work: rsync foo 'user@[fe80::4]:/tmp' Note already, how I had to put the second argument in quotes, because otherwise the shell tries to expand the square brackets as filename expansion. But even then rsync just complains, because rsync itself separates host from path through colon. I think the only workaround is to do something like `rsync -e 'ssh user@[fe80::4] ...'`... but I just used an updated rsync from homebrew, which is of course the saner method. Still, just another colon/bracket-caused issue.
- ablob 5mo agoIsn't this just an issue with rsync? (or rather your ancient version of it) I think you'd run into the same issues when using an IPv4 address port combination. It was rsync's choice to use colon as an indicator in lieu of IPv6's existence. You'd be complaining all the same for other separator choices if rsync just happened to pick the same one. Nonetheless I do agree that the choice of colons isn't great due to how it ambiguates their meaning.
- anyfoo 5mo agoAbsolutely it is. But still, the colons and brackets often make things awkward, leading not only to such compatibility bugs, but to general usability issues. Colons and brackets are just too overloaded within both destination specifiers (e.g. for ports, paths...) and shell syntax, and probably other things, where as the dot '.' rarely is. I'm an avid user of IPv6 by the way, I don't share a lot of the criticism. For me personally it's a net positive. But this is a wart where I wish they went a different direction.
- sedatk 5mo ago> I really do wish they'd just stuck with dots Then it would get confused with domain names (e.g. babe.cafe).
- yjftsjthsd-h 5mo agoAh, right, because we threw in hex. That's fair, but then I return to: If we're doing that, we should have changed the port separator.
- nickburns 5mo agoIf it ain't broke!
- yjftsjthsd-h 5mo agoI contend that needing [] to disambiguate is absolutely broken.
- NewJazz 5mo agohttps://github.com/cloudnative-pg/cloudnative-pg/issues/10713 https://github.com/cloudnative-pg/cloudnative-pg/issues/1071... https://github.com/Qualys/Qualys-Helm-Charts/issues/4 https://github.com/Qualys/Qualys-Helm-Charts/issues/4
- kccqzy 5mo agoUsing hex is probably a mistake. We didn’t use hex for IPv4 and that worked really well.
- wpollock 5mo agoI wonder how many readers realized your joke here. For the ones who didn't, the 4-byte "magic number" that identifies Java .class files, in hex, spell "CAFEBABE".
- Doxin 5mo agoIt's also just sort of generally used as easily spotted value in a hex editor. similar to DEADBEEF, ABADBABE, CAFED00D, and probably a bunch more variations on the concept. CAFEBABE seems especially prolific, getting used for -- among other things -- poison value for memory pools in plan9 and MACH-O universal object files magic number[0] [0] https://en.wikipedia.org/wiki/Hexspeak https://en.wikipedia.org/wiki/Hexspeak
- deleted 5mo ago[deleted]