[yjftsjthsd-h]

> 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.

[sedatk]

> I really do wish they'd just stuck with dots

Then it would get confused with domain names (e.g. babe.cafe).

[yjftsjthsd-h]

Ah, 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.

[kccqzy]

Using hex is probably a mistake. We didn’t use hex for IPv4 and that worked really well.

[nickburns]

If it ain't broke!

[NewJazz]

https://github.com/cloudnative-pg/cloudnative-pg/issues/1071...

https://github.com/Qualys/Qualys-Helm-Charts/issues/4

[yjftsjthsd-h]

I contend that needing [] to disambiguate is absolutely broken.

[wpollock]

I 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]

It'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

[userbinator]

Dots and decimal, like 47806.51966.0.0.0.4919.57005.48879

[theamk]

reserve a TLD, like ".v6", and you are done.

URL parsers don't break, the amount of code to change is not that big, and many of the user-space applications can keep working with no changes at all, as long as they use high-level network libraries.

If you really hate this for some reason, use some other characters. How about underscores (_) for example? Those are not valid in DNS, so there is no chance of confusion.

Choosing colon when URLs were already using it is either very stupid or very mean.

[ianburrell]

There is the .arpa domain used for reverse lookups. ipv6.arpa is already used for that. But combining the ipv6-literal from Microsoft, gives ipv6-literal.arpa.

[anyfoo]

Yeah. 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]

Isn'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]

Absolutely 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.