4 ms·

IPv6 as a metadata store

48 points by ton31337 9y ago

comboy 9y ago
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 9y ago
  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.
phkahler 9y ago
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.
shanemhansen 9y ago
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 9y ago
  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?
zkms 9y ago
This is why 128 bits for IPv6 wasn't a mistake -- it leaves plenty of room in the address space for things like this.
zkms 9y ago
This is why 128 bits for IPv6 wasn't a mistake -- it leaves plenty of room in the address space for things like this.
meirelles 9y ago
I'm not quite sure if it's good practice. We have many elegant/flexible alternatives to do things like this.

48 points by ton31337 9y ago

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 9y ago
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.

phkahler 9y ago

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.

shanemhansen 9y ago

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 9y ago
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?

zkms 9y ago

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

zkms 9y ago

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

meirelles 9y ago

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