I don't think any IP version was made in with sorting as a feature, its just a by product of the representation.
This post also highlights a major thing I discovered when deploying and using IPv6, which is that you don't "Lift and shift" IPv4 to IPv6.
This is one of the reason its hard to deploy, because people cannot use the same IPv4 concepts to IPv6. For unknown reason they do, they will find the same problem they had with v4.
Ekaros · 30d ago
Also IPv4 does have some allowed weird notations. Like 127.1 is equal to 127.0.0.1 or can represent it as decimal number. Or hex notation. Or some tools support octal...
Which some also do not sort nicely. Specially when combined.
andix · 30d ago
Those representations for 127.0.0.1 work too, just try to ping them:
If you think these are weird I have bad news about ipv6
mystified5016 · 30d ago
Anecdata but I have never seen shortened IPv4 notation. I've only ever seen the full decimal notation.
nimbius · 30d ago
the sheer size of ipv6 alone means a lot of the 'old ways' get left behind.
"sorting by ip" for example is eschewed in favor of router advertisements where hosts pick their own subnet delegations.
one of the ways you track all of this is using a dhcp6 server with dns updates turned on. the subnet delegation is picked up by the client, which in turn pings dhcp6 and reports its IP for update in the DNS server.
kstrauser · 30d ago
Another is to use mDNS so that you can skip adding a service for something that’s automatic by default.
fragmede · 30d ago
> a dhcp6 server
If only it were that easy.
schoen · 32d ago
Such a program in Python could be
python3 -c 'import ipaddress, sys; print("\n".join(sorted(ipaddress.IPv6Address(x).exploded for x in sys.argv[1:])))'
It takes the IP addresses to be sorted on the command line.
Or, re-abbreviating them by removing zeroes and attempting to use :: where possible:
python3 -c 'import ipaddress, sys; print("\n".join(str(ipaddress.IPv6Address(y)) for y in sorted(ipaddress.IPv6Address(x).exploded for x in sys.argv[1:])))'
Both of these versions will crash if given input that isn't syntactically valid as an IPv6 address.
sargstuff · 32d ago
IPv6 addresses are typically written in canonical text representation recommended by RFC 5952[0].
1) Regular expression / seamingly lost art of sprintf formatting are some methods to normalize 001:db8::2:1 to something usable for sorting aka 2001:db8:0000:0000:0000:0000:0002:0001. Perhaps restoring to rfc 5952 format when printing sorted results.
2) Modify hex to 'sortable utf-16 characters', modify back post sort[1]
$ echo "2a00:1450:400e:80c::200e
2606:4700::6810:85e5
2a03:2880:f145:82:face:b00c:0:25de
2603:1030:c02:8::14
2603:1030:20e:3::23c
2603:1030:b:3::152
2603:1020:201:10::10f
2603:1010:3:3::5b" | ch --structure 'ip IPv6' --query "SELECT ip FROM table ORDER BY ip"
2603:1010:3:3::5b
2603:1020:201:10::10f
2603:1030:b:3::152
2603:1030:20e:3::23c
2603:1030:c02:8::14
2606:4700::6810:85e5
2a00:1450:400e:80c::200e
2a03:2880:f145:82:face:b00c:0:25de
fragmede · 32d ago
It's ipv6. Seems like the "standard" thing to do would be to write and name a utility called sort6 which properly handles ipv6 addresses.
Ekaros · 30d ago
Isn't that Unix philosophy? Make tool that does one thing well. That is sort IPv6 addresses.
Gabrys1 · 32d ago
I imagine you wrote this sarcastically, but I do like this a lot!
fragmede · 32d ago
The original sort (and ping, and traceroute) could just have been updated to handle the newer format, rather than creating new utilities, was my non-sarcastic point. :)
thesuitonym · 30d ago
True of ping and traceroute, but sort is not a network utility, so editing it to specifically handle IPv6 addresses is kind of a weird idea. Not necessarily a bad idea, but it makes sense that nobody has done it.
Probably better in this case would be to have a small program that expands IPv6 addresses that you could then pipe into sort. That would be more in-keeping with the Unix Way™.
fragmede · 30d ago
> Probably better in this case would be to have a small program that expands IPv6 addresses that you could then pipe into sort. That would be more in-keeping with the Unix Way™.
I went and wrote this and then realized you'd need two utilities. One to expand the addresses, and one to minify the addresses, so your pipeline would be:
The unix philosphy is do one thing and do it well. Ideally sort does sorting very well, including sorting of ipv6 addresses. Ergo, sort should handle ipv6 address sorting.
Symbiote · 30d ago
It could be reasonable to extend sort to support a hexadecimal numeric sort. It already supports numeric (decimal) and human-readable with SI prefixes (2k, 1G).
thesuitonym · 29d ago
Hexadecimal sort is already the same as alphabetic sort. The main problem with IPv6 addresses is that zeroes get truncated all over the place. :: could mean :0000: or :0000:0000:0000:. It's not impossible to solve by any means, but pure hexadecimal sort wouldn't work.
pantalaimon · 30d ago
How often do you need to sort IP addresses to begin with?
j16sdiz · 30d ago
When you have lots of addresses and subnets, and want to see which addresses goes into what subnet
fragmede · 30d ago
especially since ipv6 can be multi-homed. on corporate networks you ended up with difficult configurations and need to figure out why the packets are going the wrong way frequently.
blueflow · 30d ago
Usually ping6 and traceroute6 are symlinks to the regular util, not a different program.
hinkley · 30d ago
`sort -n` works remarkably well on `du`’s output
fragmede · 30d ago
there's sort -h for eg du -sch *'s output.
hinkley · 30d ago
Works great if the first column represents sizes. Not so great with IP addresses I suspect.
xnorswap · 30d ago
At least IPv6 addresses aren't "middle-endian" like UUIDs can be.
blueflow · 30d ago
This is not a UUID problem, this is a Microsoft problem from the 90s. Just don't use Microsoft software (</s>) and use big endian as specified by the standard.
WorldMaker · 30d ago
It is a general UUID specification problem. The dashes represent a struct breakdown. That struct has internal endian issues. That struct is also weirdly laid out in a "made sense at the v1 time way" that doesn't make sense for versions after 1. Why is the version number in the middle? Why is the relatively static "Machine ID" at the end? If you were trying to cluster your sort by machine, you have to sort things "backwards". That's what SQL Server did, and why you might blame it on being a Microsoft problem, trying to avoid clustered index churn by assuming GUIDs were inserted by static Machine IDs. That assumption broke hard in later Versions of UUID when "Machine ID" just became "random entropy". But the idea to sort like that in the first place wasn't wrong for v1, it had a good sense to it. Just like it makes sense to sort v7 UUIDs by timestamp to get mostly "log ordered" clustered indexes. At least there the sort data is all up front, but it crosses "struct field" boundaries if you are still relying on the v1 chunking.
(Ultimately UUID v1 was full of mistakes that we all will keep paying for.)
UUID sort orders get wild indeed. I have been down that rabbit hole.
ggm · 32d ago
for all addresses, v4 and v6 this is what I used to do
1) convert to a non-space-zeros-compressing hex string
2) sort on the hex string
3) convert back through inet_ntop()
Only a minor variant needed to deal with prefix/len sort order.
andix · 30d ago
I'm creating all those tiny shell helper scripts now with AI. One of the things AI is really good at.
prompt: create a bash command to sort a text file of ipv6 adresses per line. sort numerically (128 bit representation) but keep the full line as originally formatted
That’s launching Python once per address. Why not just pipe it into a short Python script at that point?
andix · 30d ago
I know, this could be a follow-up prompt. But I tested it and it works well.
It's just to demonstrate how easy it is to solve those problems without spending an unnecessary amount of time on them.
kstrauser · 30d ago
Legit.
0points · 32d ago
1. Convert to numeric representation
2. Sort
3. Convert back
yuliyp · 30d ago
If you're sorting data on a command line, you probably have some matter of control over how it's generated. So just fully-expand it and then text sorting just works. Pretty simple?
neuroelectron · 30d ago
Trivial Task Has No Standard
wpm · 32d ago
Almost as if using hex values for IP addresses was a bad idea.
oldnetguy · 30d ago
Agreed. By using decimal, you can explain to the average person what an address is and be able to work with them. IPv6 totally eliminates that.
There is an argument that end users and consumers shouldn't need to concern themselves with this but in the field that this is not true.
fragmede · 30d ago
How often do consumers (ie not network professionals) need to do CIDR or anything more advanced than read off an address? Is reading 64512 colon 65152 colon colon 7237 that much easier over a bad phone connection than fc00:fe80::1c45? By the time you're that deep with someone non-technical having them read an address over the phone, you've already lost
whalesalad · 30d ago
I have yet to use ipv6 and I will try to make it to my grave without adopting it.
dfc · 30d ago
Your cell provider is not using ipv6?
kstrauser · 30d ago
This is an odd website for bragging about avoiding common, widely used technology.
neilalexander · 30d ago
Weird take, but you do you.
floating-io · 30d ago
Not really that odd. It's easy to live without IPv6 until someone creates the IPv6-only killer app, and that makes it... not worth the hassle for most folks.
I'm in a moderate-to-high technology area in the grand scheme. They laid fiber here roughly two years ago, and lit it about a year ago, whereupon I immediately subscribed.
They don't offer IPv6. At all. That should tell you just how unimportant IPv6 is perceived as outside of its core cadre of proponents. Note that this is not a commentary on how important it actually is; just on perception.
In short, nobody cares.
mrweasel · 30d ago
> It's easy to live without IPv6 until someone creates the IPv6-only killer app
This was a few years ago, but the majority of Danish ISP wasn't offering IPv6, because "there's is no demand from customers". Well, the customers also aren't demanding IPv4, they are demanding internet access. How you deliver it is not interesting to anyone but a small niche segment of the market. If you could somehow make it work over IPX, then 95% of customers would be fine with that, it's not something they care about.
pastage · 30d ago
It does not work like that, what you get is big deployments using ipv6 and some strange ipv4 setup so there are more and more clients using ipv6. On the server side you will start to see more and more clients using ipv6. About 40% of our customers use ipv6. They can still access ipv4 though it is just that their network provider prefers having them on ipv6.
Ip version is not a selling point, unless you are on the server.
WorldMaker · 30d ago
Not just a network provider preference. It is an OS-level preference in most consumer hardware today. (The "Happy Eyeballs" protocol, among other things. OSes will send IPv6 first, then after a delay send IPv4 and after that favor whichever one is "quickest"/"healthiest".) It's also a natural preference over things like STUN/"UPnP" to avoid NATs, especially CGNATs.
patchtopic · 30d ago
The 85% of French and 75% of India adopting it don't care, they just use it :-)
Most consumer networks are IPv6 by default. Most cellular networks are IPv6-only/IPv6-native today with big DNS64/NAT64 gateways to the IPv4 web. Most consumers don't know or care, they just use IPv6, daily.
A lot of the holdouts on IPv4-only traffic are corporate traffic. A lot of corporate traffic acts like it wants a separate internet anyway, and a lot of companies hoarded IPv4 spaces for long enough that they don't see the increasing costs of IPv4 addresses hit their bottom lines yet enough to care. It's a fascinating dynamic. Maybe corporations will just buy the remaining IPv4 internet entirely and keep it as their own separate but not equal network.
This post also highlights a major thing I discovered when deploying and using IPv6, which is that you don't "Lift and shift" IPv4 to IPv6.
This is one of the reason its hard to deploy, because people cannot use the same IPv4 concepts to IPv6. For unknown reason they do, they will find the same problem they had with v4.
Which some also do not sort nicely. Specially when combined.
"sorting by ip" for example is eschewed in favor of router advertisements where hosts pick their own subnet delegations.
one of the ways you track all of this is using a dhcp6 server with dns updates turned on. the subnet delegation is picked up by the client, which in turn pings dhcp6 and reports its IP for update in the DNS server.
If only it were that easy.
Or, re-abbreviating them by removing zeroes and attempting to use :: where possible:
Both of these versions will crash if given input that isn't syntactically valid as an IPv6 address.1) Regular expression / seamingly lost art of sprintf formatting are some methods to normalize 001:db8::2:1 to something usable for sorting aka 2001:db8:0000:0000:0000:0000:0002:0001. Perhaps restoring to rfc 5952 format when printing sorted results.
2) Modify hex to 'sortable utf-16 characters', modify back post sort[1]
3) avoid utf-8 / utf-16 issues, use relevant python libraries to handle ipv4/ipv6[2][3],[4]: ip2n < file | sort -n | n2ip
----------------------------
[0] : https://datatracker.ietf.org/doc/html/rfc5952
[1] : https://stackoverflow.com/questions/5797369/unix-sort-utilit...
[2] : https://stackoverflow.com/questions/75522231/how-to-sort-ipv...
[3] : https://www.geeksforgeeks.org/convert-ip-address-to-integer-...
[4] : https://ipfind.com/blog/how-to-convert-ip-address-to-integer...
Probably better in this case would be to have a small program that expands IPv6 addresses that you could then pipe into sort. That would be more in-keeping with the Unix Way™.
I went and wrote this and then realized you'd need two utilities. One to expand the addresses, and one to minify the addresses, so your pipeline would be:
vs The unix philosphy is do one thing and do it well. Ideally sort does sorting very well, including sorting of ipv6 addresses. Ergo, sort should handle ipv6 address sorting.(Ultimately UUID v1 was full of mistakes that we all will keep paying for.)
For the record it is Java with the worst possible UUID sort algorithm, sorting parts of it as signed numbers: https://devblogs.microsoft.com/oldnewthing/20190913-00/?p=10...
(Friends don't let friends use Java. /s)
prompt: create a bash command to sort a text file of ipv6 adresses per line. sort numerically (128 bit representation) but keep the full line as originally formatted
result:
It's just to demonstrate how easy it is to solve those problems without spending an unnecessary amount of time on them.
2. Sort
3. Convert back
I'm in a moderate-to-high technology area in the grand scheme. They laid fiber here roughly two years ago, and lit it about a year ago, whereupon I immediately subscribed.
They don't offer IPv6. At all. That should tell you just how unimportant IPv6 is perceived as outside of its core cadre of proponents. Note that this is not a commentary on how important it actually is; just on perception.
In short, nobody cares.
This was a few years ago, but the majority of Danish ISP wasn't offering IPv6, because "there's is no demand from customers". Well, the customers also aren't demanding IPv4, they are demanding internet access. How you deliver it is not interesting to anyone but a small niche segment of the market. If you could somehow make it work over IPX, then 95% of customers would be fine with that, it's not something they care about.
Ip version is not a selling point, unless you are on the server.
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Cloudflare reports slightly lower 40% IPv6 adoption globally https://radar.cloudflare.com/adoption-and-usage
A lot of the holdouts on IPv4-only traffic are corporate traffic. A lot of corporate traffic acts like it wants a separate internet anyway, and a lot of companies hoarded IPv4 spaces for long enough that they don't see the increasing costs of IPv4 addresses hit their bottom lines yet enough to care. It's a fascinating dynamic. Maybe corporations will just buy the remaining IPv4 internet entirely and keep it as their own separate but not equal network.