IPv6 prefix is not fully applied when its size is greater than 64 bits

Hello,

I ran an update over my zone’s IPv6 “section” using a call similar to https://dynv6.com/api/update?hostname=myhostname&token=mytoken&ipv6=2a02:2f0a:b700:5356:8f0d:f98a:2995:d201/96.

The IPv6 prefix was correctly updated, by considering the 96 bits specified size, as I can see it in UI displayed as 2a02:2f0a:b700:5356:8f0d:f98a::.

I also have an AAAA record defined, for example having the data specified as ::57bb:6602.

The problem is that the resulted address in this case is 2a02:2f0a:b700:5356::57bb:6602 instead of the desired 2a02:2f0a:b700:5356:8f0d:f98a:57bb:6602. Obviously, only the first 64 bits from the stored prefix are considered instead of the expected all 96.

Can this be considered a bug? If not, would it be possible to add support for prefix sizes greater than 64 bits?

Many thanks!

Did you find the mistake in your deliberations?

Unfortunately no, I still consider this valid. However, my knowledge about IPv6 is pretty limited, I didn’t pretend to be an expert.

Meanwhile I switched to the standard 64 bits prefix size, but for one of my Docker networks I’m using a 80 bits prefix, as I don’t need SLAAC, so I would still like to have a solution for this or an explanation of why it would be a non-sense, for instance.

Regards!

Like IPv4, IPv6 consists of two parts, one for the network and one for the host. The one for the network is called prefix and is 64 bits long. So you cannot specify a 96-bit prefix. Everything after bit 64 belongs to the host. I don’t know what Dynv6 does if you update your prefix with a /96 notation. But I think they ignore everything after bit 64. That also explains 2a02:2f0a:b700:5356::57bb:6602. The first 64 bits as prefix and then the specified 64 bits as host address (::57bb:6602 is correctly interpreted as :0000:0000:57bb:6602).

The reason why the /xx notation makes sense is that some providers, for example, assign /56 addresses, so that you could use 8 bits for your own subnets.