[Dnsmasq-discuss] No IPv6 router advertisements for subnets other than /64?

[Simon Kelley]

On 16/09/13 10:18, Quintus wrote:
> Hi there,
>
> I’m trying to divide my home network into useful IPv6 subnets. I’ve got
> a /64 network from SiXxs and wanted to use a /80 for cable clients and
> another /80 for wifi clients (with the other /80s staying unused for
> now). Here’s what I’ve tried for cable:
>
> -------------------------------------------------------------
> dhcp-range=set:wired6,2001:4dd0:ff00:8918:1::,ra-names,80
> -------------------------------------------------------------
>
> That is, I want clients to use stateless
> autoconfiguration within the subnet of 2001:4dd0:ff00:8918:1::/80 so
> they can make use of the IPv6 privacy extensions below that. However,
> dnsmasq refuses to start with this message:
>
> -------------------------------------------------------------
> prefix must be exactly 64 for RA subnets
> -------------------------------------------------------------
>
> What is the background of this restriction? As far as I know SLAAC
> doesn’t depend on a prefix length of /64... It could as well be /40
> or /80 or whatever (valid). Any chance this gets lifted in future
> versions of dnsmasq or do I have to use DHCPv6 for /80 subnets?
>

SLAAC works by generating addresses by composing the prefix and the 
so-called Interface Identifier.

RFC-4291 says: "For all unicast addresses, except those that start with 
the binary value 000, Interface IDs are required to be 64 bits long and 
to be constructed in Modified EUI-64 format."

and RFC-4862 says: "If the sum of the prefix length and interface 
identifier length does not equal 128 bits, the Prefix Information option 
MUST be ignored."

from which I deduce that the prefix length MUST be 64 when using SLAAC.

If you read the RFCs in detail, it is (as usual) rather more complicated 
than that, but I think that for all practical purposes in the situations 
where dnsmasq is used, it's true.

Looking at the code, simply removing the test in src/option.c is all 
that's required to remove the restriction, the code that generates 
router advertisements doesn't seem to depend on prefix-length==64. It's 
not been tested though, so no promises.


Cheers,

Simon.