dhcpcd-discuss

On Fri, 8 Dec 2017 10:49:24 +0000
Roy Marples <roy@xxxxxxxxxxxx> wrote:

> On 07/12/2017 22:59, Neal P. Murphy wrote:
> > I pulled and built master. Good news: -4 now properly doesn't listen on IPv6.  
> 
> Yay!
> 
> > dhcpcd doesn't report that it assigned ...:960::1/64 to eth3 or that it added the route, but it does report that it completed DAD for eth3. Nor does it report removing these things when exiting. Is it possible that dhcpcd somehow doesn't track this? Or doesn't track it in *my* case because I'm doing something odd?  
> 
> Correct.
> dhcpcd won't remove addresses or routes it didn't add, unless they will 
> conflict with what it wants to add (which on Linux isn't that too much 
> thanks to route metrics).
> 
> Now if dhcpcd loses track of something - like say you restarted it 
> without dropping prior and you get a different delegation, then this 
> won't be cleaned up as dhcpcd has stopped tracking it. I don't intend to 
> fix that case because it could potentially do something nasty as it 
> would be guesswork.
> 
> > 
> > Curious. When I 'ip link set dev eth3 down', it detects lost carrier and *does* remove everything (all routes, all global addresses, and doesn't touch the LL routes). Nice and clean. But when I 'ip link set dev eth3 up'; it restores everything *except* the /64 delegated to eth3 and the route for it.  
> 
> That's the linux kernel un-helpfully doing that.
> 
> So I think that's all the problems resolved now yes?
> I did just solve a problem where the non debug case spammed syslog each 
> DHCP6 reply when there was a prefix delegation if you're interested in that.

Roy,

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?
  - Should the kernel or dhcpcd assign the global /64 to eth3?
  - Should the kernel or dhcpcd assign the global /128 to eth3?
  - 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?
  - Why does the kernel assign eth3's /64 route instead of dhcp? 
  - Why does the kernel assign eth3's /128 route instead of dhcp?
  - 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.

Thanks,
Neal