dhcpcd-discuss

On 27/09/17 12:01, harald.albrecht wrote:
> Your config looks fine to me. But what worries me is that you get two addresses with different prefixes when using SLAAC and DHCPv6 simultaneously. This may indicate towards the cause of your problem, but I don't see how at the moment.

Yes, that looks wrong to me.

> As for the prefix information, there's a simple rule set to know (which isn't written in the RFCs as this is implementation architecture knowledge):DHCPv6 IA-NA --> IPv6 address table --> /128 single IPv6 address route in route table.RA router advertisement:router lifetime>0 (sic!) --> IPv6 route table: creates default route via router.PIO prefix information option:A=1 --> IPv6 address table (with Linux noprefixmgt) --> /128 single IPv6 address route in route table.L=1 --> IPv6 route table with direct subnet route. **THIS** is the important one required for DHCPv6.L=0 --> IPv6 route table with indirect subnet route via router which send the RA.MSRO more-specific route option: --> IPv6 route table with subnet route via router which send the RA.Hope this clarifies your question.

Is the "more-specific route option" RFC 4191?  I don't know about that.
I can see an oblique reference in the radvd.conf man page.

Here's the output of "ip -6 route" if it helps:

fd70:a6a5:a58b:0:ffff:ffff:ffff:fff7 dev eth2  proto kernel  metric 256
expires 1424sec pref medium
fd70:a6a5:a58b::/64 dev eth1  metric 207  mtu 1280 pref medium
fd70:a6a5:a58b::/64 dev eth2  metric 208  mtu 1280 pref medium
fd70:a6a5:a58b:2::/64 dev eth1  metric 207  mtu 1280 pref medium
fd70:a6a5:a58b:2::/64 dev eth2  metric 208  mtu 1280 pref medium
fd70:a6a5:a58b:2::/64 dev eth1  proto kernel  metric 256  expires
86070sec pref medium
fd70:a6a5:a58b:2::/64 dev eth2  proto kernel  metric 256  expires
86070sec pref medium
fd70:a6a5:a58b:2000::/52 dev eth1  metric 207  mtu 1280 pref medium
fd70:a6a5:a58b:2000::/52 dev eth2  metric 208  mtu 1280 pref medium
fd70:a6a5:a58b:2000::/52 dev eth1  proto kernel  metric 256  expires
86070sec pref medium
fd70:a6a5:a58b:2000::/52 dev eth2  proto kernel  metric 256  expires
86070sec pref medium
fe80::/64 dev eth0  proto kernel  metric 256  pref medium
fe80::/64 dev eth1  proto kernel  metric 256  pref medium
fe80::/64 dev eth2  proto kernel  metric 256  pref medium
fe80::/64 dev eth3  proto kernel  metric 256  pref medium
default via fe80::a00:27ff:fe5d:6607 dev eth1  metric 207  mtu 1280 pref
medium
default via fe80::a00:27ff:fe5d:6607 dev eth2  metric 208  mtu 1280 pref
medium


                  Graham

> Best regards,
> Harald
> 
> -------- Ursprüngliche Nachricht --------Von: Graham Breed <graham.breed@xxxxxxxxxxxxxx> Datum: 27.09.17  12:43  (GMT+01:00) An: "harald.albrecht" <harald.albrecht@xxxxxxx>, dhcpcd-discuss@xxxxxxxxxxxx Betreff: Re: [dhcpcd-discuss] DHCPv6 addresses being assigned with /128
>   prefixes 
> On 27/09/17 11:33, harald.albrecht wrote:
>> As I'm not sure that I understand your problem correctly, please cut me some slack in case I did so.
>> DHCPv6 assigns only IPv6 addresses, so that's the reason why you are seeing /128. In order to use DHCPv6 for address assignments, you definitely need a router advertising the required IPv6 prefix matching your IPv6 address. Without the router advertisements, no prefix route is being generated in the routing table, so DHCPv6 on its own is pretty useless. There's even RFC 5942 "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" ... which also tackles the broken kernels that guess /64 prefixes from IPv6 addresses. See, in particular, section 4 "Host Rules", item #1.
> 
> Yes, I've been chasing through the RFCs and I can see this warning about
> not guessing, but I can't find where the information is supposed to be
> supplied.  The router advertisement looks correct to me from the point
> of view of not knowing what dhcpcd is looking for.  If I enable DHCPv6
> and SLAAC on the same subnet on the same interface, I get two addresses
> assigned with different prefixes.
> 
>> And DHCPv6 prefix delegation is not for assigning IPv6 addresses with prefixes, but for use with routers, et cetera.
> 
> Right.  I'm not using that.
> 
>> So, did you make sure to advertise the required /64 prefix to use with the DHCPv6 assigned IPv6 /128 addresses?
> 
> Here's my radvd.conf from the server (with separate prefixes for DHCPv6
> and SLAAC):
> 
> interface swlan0
> {
>     AdvManagedFlag on;
>     AdvOtherConfigFlag off;
>     AdvSendAdvert on;
>     AdvDefaultPreference high;
>     AdvLinkMTU 1280;
> 
>     prefix fd70:a6a5:a58b::/64
>     {
>         AdvOnLink on;
>         AdvAutonomous off;
>     };
> 
>     prefix fd70:a6a5:a58b:2::/64
>     {
>         AdvOnLink on;
>         AdvAutonomous on;
>     };
> 
>     prefix fd70:a6a5:a58b:2000::/52
>     {
>         AdvOnLink on;
>         AdvAutonomous on;
>     };
> 
> };
> 
> The `/52` is there to check that dhcpcd is reading the prefix correctly.
>  It is, in this case.
> 
> 
> Oh, yes, and I forgot the dhcpcd version.  I'm using 7.0.0-rc2 but also
> tested with 6.11.3.  I'm not using any of the standard hooks because
> this is an embedded platform where we use the binary with our own hooks.
> 
> 
> 
>                   Graham
> 
> 
>> Best regards,
>> Harald
>>
>> -------- Ursprüngliche Nachricht --------Von: Graham Breed <graham.breed@xxxxxxxxxxxxxx> Datum: 27.09.17  12:14  (GMT+01:00) An: dhcpcd-discuss@xxxxxxxxxxxx Betreff: [dhcpcd-discuss] DHCPv6 addresses being assigned with /128 prefixes 
>> Hello!
>>
>> I'm running dhcpcd for plain DHCPv6 address assignment (along with
>> DHCPv4 and SLAAC).  Everything works except the DHCPv6 addresses are
>> being created with /128 prefixes where I want /64.  The router
>> advertisements look correct and if I enable "AdvAutonomous" on the same
>> subnet on the same link I get SLAAC addresses (from dhcpcd) with the
>> correct prefix.
>>
>> I don't know where the prefix should come from and why it's not working.
>>   I found a section of code for "RFC 5942 Section 5" but I patched it and
>> it doesn't help so I don't think that's the problem.
>>
>>
>> Here are some logs as the address gets assigned:
>>
>> Sep 27 08:59:35 [5605]: eth1: broadcasting SOLICIT6 (xid 0x32576f), next
>> in 0.9 seconds
>> Sep 27 08:59:35 [5605]: eth1: ADV
>> fd70:a6a5:a58b:0:ffff:ffff:ffff:fff8/128 from fe80::a00:27ff:fe5d:6607
>> Sep 27 08:59:35 [5605]: eth1: broadcasting REQUEST6 (xid 0x8f2ce2), next
>> in 1.0 seconds
>> Sep 27 08:59:35 [5605]: eth1: REPLY6 received from fe80::a00:27ff:fe5d:6607
>> Sep 27 08:59:35 [5605]: eth1: adding address
>> fd70:a6a5:a58b:0:ffff:ffff:ffff:fff8/128
>> Sep 27 08:59:35 [5605]: eth1: pltime 1125 seconds, vltime 1800 seconds
>> Sep 27 08:59:35 [5605]: eth1: renew in 562, rebind in 900, expire in
>> 1800 seconds
>> Sep 27 08:59:35 [5605]: eth1: writing lease `/var/db/dhcpcd/eth1.lease6'
>> Sep 27 08:59:35 [5605]: eth1: waiting for DHCPv6 DAD to complete
>>
>>
>> Here is the configuration:
>>
>> debug
>> script /usr/sbin/dhcpcd_hook.py
>> logfile /var/log/dhcp_client.log
>>
>> # Request nameservers from the server
>> option domain_name_servers
>>
>> # From the example config:
>> # Use the hardware address of the interface for the Client ID.
>> clientid
>> # Rapid commit support.
>> # Safe to enable by default because it requires the equivalent option set
>> # on the server to actually work.
>> option rapid_commit
>> # Respect the network MTU. This is applied to DHCP routes.
>> option interface_mtu
>> # A ServerID is required by RFC2131.
>> require dhcp_server_identifier
>>
>>
>> I'm running Linux 4.1.35.  net.ipv6.conf.eth1.accept_ra is 0.
>>
>>
>> The arch-rival dhclient works correctly on a different machine with the
>> same DHCPv6 server.
>>
>>
>>                    Graham
>>
> 

-- 
------------------------------

*Graham Breed*
Systems Developer, ApplianSys

ApplianSys House
Harry Weston Road
Coventry CV3 2UB

www.appliansys.com

*Our sales team sells by referral:*
Less time looking for customers, more time looking after them

ApplianSys Limited registered in England & Wales #: 07608382 at ApplianSys
House, Harry Weston Road, Coventry CV3 2UB