dhcpcd-discuss

> You always need router advertisements to inform the nodes of the prefixes and their length to be used. These RAs also inform nodes whether these addresses covered by a prefix are considered to be on-link or not on-link

Exactly.  But dhcpcd does not seem to be taking this information into
account when creating the IPv6 address it subsequently assigns to an
interface:

  - dhcp6_addrequestedaddrs():

        a = ipv6_newaddr(ifp, &ia->addr,
                /*
                 * RFC 5942 Section 5
                 * We cannot assume any prefix length, nor tie the
                 * address to an existing one as it could expire
                 * before the address.
                 * As such we just give it a 128 prefix.
                 */
            ia->ia_type == D6_OPTION_IA_PD ? ia->prefix_len : 128,
            IPV6_AF_REQUEST);

  - dhcp6_findna():

        /*
         * RFC 5942 Section 5
         * We cannot assume any prefix length, nor tie the
         * address to an existing one as it could expire
         * before the address.
         * As such we just give it a 128 prefix.
         */
        a = ipv6_newaddr(ifp, &ia.addr, 128, IPV6_AF_ONLINK);

I think this is an overinterpretation of RFC 5942 Section 5, which
discusses the case of a client which "receives a Router Advertisement
message _with no on-link prefix advertised_" (emphasis mine) and then
_assumes_ the leased address belongs to a prefix which is on-link.  But
if the leased address belongs to a prefix which was present in a
previously received RA with the on-link flag set, no assumption will be
made and the client should use prefix length information from the RA
when configuring the address on an interface.  Meanwhile, dhcpcd always
sets the prefix length of the address to 128 bits (unless a prefix
delegation is involved, which is not the case discussed above).  I think
this is not the right thing to do.

-- 
Best regards,
Michał Kępień