dhcpcd-discuss

On 10/12/2017 05:50, Neal P. Murphy wrote:
> I found a way to cleanly clear all IPv6 addressing and routing:
>    sysctl -w net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.all.disable_ipv6=0'
> This works for specific IFs, too (use 'eth3' instead of 'all'). The kernel quickly restores the link-local stuff.
>
> I want to understand what is *supposed* to happen; that is, understand what dhcpcd is supposed to to itself, and what dhcpcd 'allows' the kernel to handle. So assume:
>    - I use eth0-eth3, with eth3 being the upstream (comcrash) connection; eth1
>      is not connected.
>    - I have as thoroughly disabled linux autoconf, RA, etc. as is possible using
>      sysctl or files in /proc.
>    - I have requested a 1/::/60 delegation (which seems to solve the problem with
>      comcrash sending a /64 instead of a /60).
>    - I asked dhcpcd to assign /64s to eth0, eth1, eth2 and, I think, eth3
>
> So I start dhcpcd and see the following IPv6 addresses and routes.
> ----
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>      inet6 2601:5ca:4400:11a1::1/64 scope global dynamic
>         valid_lft 3590sec preferred_lft 3590sec
>      inet6 fe80::290:bff:fe17:f27a/64 scope link
>         valid_lft forever preferred_lft forever
> 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>      inet6 2601:5ca:4400:11a3::1/64 scope global dynamic
>         valid_lft 3590sec preferred_lft 3590sec
>      inet6 fe80::290:bff:fe17:f27c/64 scope link
>         valid_lft forever preferred_lft forever
> 5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>      inet6 2601:5ca:4400:11a0::1/64 scope global
>         valid_lft forever preferred_lft forever
>      inet6 2001:558:6036:65:3581:f1b:17e2:ef18/128 scope global dynamic
>         valid_lft 3590sec preferred_lft 3590sec
>      inet6 fe80::290:bff:fe17:f27d/64 scope link
>         valid_lft forever preferred_lft forever
> ----
> ----
> 2001:558:6036:65:3581:f1b:17e2:ef18 dev eth3  proto kernel  metric 256  expires 3533sec
> 2601:5ca:4400:11a0::/64 dev eth3  proto kernel  metric 256
> 2601:5ca:4400:11a1::/64 dev eth0  proto dhcp  metric 202
> 2601:5ca:4400:11a3::/64 dev eth2  proto dhcp  metric 204
> unreachable 2601:5ca:4400:11a0::/60 dev lo  proto dhcp  metric 201  error -101
> fe80::/64 dev eth0  proto kernel  metric 256
> fe80::/64 dev eth2  proto kernel  metric 256
> fe80::/64 dev eth3  proto kernel  metric 256
> default via fe80::201:5cff:fe8e:ea46 dev eth3  proto ra  metric 205
> ----
>
> Questions:
>    - Should the default route be assigned via RA, even though RA is disabled? Or should
>      it be assigned via dhcp?

default routes only come through RA
even with RA disables in the kernel, dhcpcd will listen to it and create 
a default route.

>    - Should the kernel or dhcpcd assign the global /64 to eth3?
>    - Should the kernel or dhcpcd assign the global /128 to eth3?

dhcpcd

>    - Should eth3's global /64 be flagged 'dynamic'?
>    - How does the kernel know about the delegated /60 to assign the prefix in it I *want*
>      assigned to eth3? How does it know about the delegated /60 in the first place?

The kernel doesn't and won't

>    - Why does the kernel assign eth3's /64 route instead of dhcp?
>    - Why does the kernel assign eth3's /128 route instead of dhcp?

The kernel does that for all addresses.
Newer kernels support IFA_F_NOPREFIXROUTE which dhcpcd will use to tell 
the kernel not to add these
https://lists.fedoraproject.org/pipermail/kernel/2014-January/004840.html

>    - Should dhcpcd handle all of the above tasks that seem to have 'anomalous' results? Worded
>      differently, should dhcpcd handle all (or most) aspects of address fetching and assignment
>      and route assignment?
>
> Or, in other words, if all works right, what results should I expect to see? Which of these 'anomalous' results are most likely due to kernel bugs? If these weirdities are due to the kernel's autoconf interfering while it is supposedly disabled, I'll take them to the netdev group.


So just upgrade to a newer kernel.
I don't keep track of what kernel versions have what feature dhcpcd uses 
but for reference I'm using a 4.13 kernel.

I can see that one of your routes, dhcpcd failed to take care of.
It might very well be that uprading your kernel will allow dhcpcd to 
manage it correctly.

Roy