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]

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

1. Convert to numeric representation

2. Sort

3. Convert back

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.

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.

I imagine you wrote this sarcastically, but I do like this a lot!

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

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

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

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.

How often do you need to sort IP addresses to begin with?

When you have lots of addresses and subnets, and want to see which addresses goes into what subnet

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.

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

    cat ipv6-addrs.txt | ipv6expand | sort -V | ipv6minify

vs

    cat ipv6-addrs.txt | sort -6

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.

Usually ping6 and traceroute6 are symlinks to the regular util, not a different program.

`sort -n` works remarkably well on `du`’s output

if you're using gnu sort, there's sort -h for du -ch's output

Works great if the first column represents sizes. Not so great with IP addresses I suspect.

Isn't that Unix philosophy? Make tool that does one thing well. That is sort IPv6 addresses.

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.

Almost as if using hex values for IP addresses was a bad idea.

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.

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

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.

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.

Those representations for 127.0.0.1 work too, just try to ping them:

  0177.1 (octal, 2 stripped 0s, decimal one)
  017700000001 (octal)
  2130706433 (decimal)
  127.0.0x1
  0x7f.0x0.0x0.0x1
  127.000.000.001

If you think these are weird I have bad news about ipv6

Anecdata but I have never seen shortened IPv4 notation. I've only ever seen the full decimal notation.

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.

Another is to use mDNS so that you can skip adding a service for something that’s automatic by default.

> a dhcp6 server

If only it were that easy.

I have yet to use ipv6 and I will try to make it to my grave without adopting it.

Your cell provider is not using ipv6?

This is an odd website for bragging about avoiding common, widely used technology.

Weird take, but you do you.

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.

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

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.

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.

The 85% of French and 75% of India adopting it don't care, they just use it :-)

https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

More interestingly, it looks like a year from now IPv6 is going to make up the majority of Google's global traffic.

Cloudflare reports slightly lower 40% IPv6 adoption globally https://radar.cloudflare.com/adoption-and-usage

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.

At least IPv6 addresses aren't "middle-endian" like UUIDs can be.

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.

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

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)

UUID sort orders get wild indeed. I have been down that rabbit hole.

clickhouse-local is very handy for these tasks:

    $ 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

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?

Trivial Task Has No Standard

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

result:

  while read -r ip; do
    printf '%032x %s\n' \
      "$(python3 -c 'import ipaddress,sys; print(int(ipaddress.IPv6Address(sys.argv[1])))' "$ip")" \
      "$ip" 
  done < ipv6.txt | sort | cut -d' ' -f2-

That’s launching Python once per address. Why not just pipe it into a short Python script at that point?

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.

Legit.