More compact IPv6 addresses for VMs

[dave4445]

When creating a VM, it gets assigned a static IPv6 unicast address, however it is one based on its EUI-64. This produces a long, ugly address when a more compact one could be used.

Since VMs are assigned into rather small IPv4 subnet (ex /27), there is a quite limited amount of VMs per IPv6 subnet as well, a single sequential assignment would be easy using the lowest 8 or 16 bits of the IPv6 address leaving the rest zeros.

One could simply transpose the lowest byte of the IPv4 address into the lowest byte of the IPv6 address to guarantee uniqueness.

Example:

Currently VM has:

• 23.xxx.xxx.123/27
• 2602:fe2e:x:xx:yyyy:yyff:feyy:yyyy/64

This becomes:

• 23.xxx.xxx.123/27
• 2602:fe2e:x:xx::7b/64

[bswinnerton]

👋 @dave4445,

Thank you for writing in! I've often wondered if this was the right product decision, but you're right on the money that the original intent of this was to ensure uniqueness (using the MAC address of the virtual NIC with EUI-64).

As you probably gathered, the /27 is a shared subnet with other customers, and there are other /27's used depending on both the site and hypervisor that the customer's virtual machine has been deployed to. There are intentions to widen this network to a larger subnet in the future as well.

Unlike IPv4, the /64 is the customer's to use as they would like (and in some cases there are /48's allocated to customers who need a larger subnet). Originally I didn't want to assume that a customer would always be okay with using something like ::1 as the address of the VM if the entire /64 is theirs to use as they see fit, so I opted for the long and complex EUI-64 strategy.

But you bring up a good point that there are other ways to ensure uniqueness, even if there are multiple /27s employed.

Thank you for bringing this up. I'll keep this in mind as Neptune restructures its addressing strategy in the future.