IPv6 as a metadata store

I think I don't get it. Is it really a metadata store if you need to know this metadata in order to compute the IP?

If you know how your system splits the IPs then yes, knowing the IP you can reason about what it handles, but the same works for ipv4 or even better, for hostnames.

So it sounds like there are really 2 use cases here.

Use case 1: I give you an IP, can you find any useful information in that IP such as rack, datacenter, etc?

Use case 2: I'm less certain of this: I assign a big subnet to a smaller number of nodes and that subnet is essentially your "ring" size for something that shards. Allowing you to always send data for shard #1 to the same ip.

I'm definitely not a fan of the latter. I'd rather most app developers treat an IP as an opaque piece of data. 128 bits is alot of addresses but it's really not that much space for metadata.

I would like to see a standard for converting lat/long into a portion of the IP address - something between 32 and 64 bits. I realize this is not going to make routing trivial and it doesn't work with mobile, but think about it:

If a specific value of the first byte indicated that a specific part of the remaining IP address was a geo location, we could easily filter on location without any outside information. Packets could be routed using the other bits (ISP or other subnet info) first, or routed to approximate location prior to dealing with the other bits. So My ISP given a packet could either: 1) take it as far as possible before handing it off, or 2) get it off their network ASAP but the others would have an easy time figuring out where it goes. This would separate "who needs to handle this" from "where does this go" in a somewhat useful way.

I'm not quite sure if it's good practice. We have many elegant/flexible alternatives to do things like this.

This is why 128 bits for IPv6 wasn't a mistake -- it leaves plenty of room in the address space for things like this.