
IPv6 as a metadata store - ton31337
http://blog.donatas.net/blog/2017/05/08/ipv6-metadata/
======
comboy
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.

~~~
schmichael
Using IPv6 addresses for sharding pushes shard routing metadata down into IPv6
that in an IPv4 network would have to be stored using DNS or an external data
store.

The fact that applications need to support the logic for using the metadata
(the address encoding scheme) doesn't diminish the fact that the metadata
itself is encoded in IPv6 addresses. All sharding schemes require an
application to support the logic for processing the sharding metadata.

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

~~~
cosinetau
I was with you until I thought about scale at really large levels. For
everyday networking applications, you are correct. But could those very narrow
use cases have very positive consequences on the scale of Amazon or Google?

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

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

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

