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.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
