On Thu, Aug 29, 2019 at 5:56 PM Roy Marples <roy%marples.name@localhost> wrote:
So dhcpcd currently parses NA messages to check if the node claims to be
a router or not because not every router will set it's lifetime to zero
when it ceases to be a router. This is expensive. We can do better. RFC
4861 6.2.5 only lists the requirement as should, not must so ideally
dhcpcd should still be able to function.
I just added a change to emit RTM_CHANGE without a lladdr for the
gateway to indicate that this happened. The current flow is this:
RTM_ADD no lladdr (ln entry created, dhcpcd ignores this)
RTM_CHANGE with lladdr (node reachable)
RTM_DELETE (node unreachable)
RTM_CHANGE no lladdr (node is no longer a router)
But I'm now starting to think this is the wrong thing to do as it's
overloading the intent - no lladdr with RTM_CHANGE could just mean it's
been cleared by admin - and requries a 2nd message to add the current
lladdr back for consistency. Would it be better to set RTF_BLACKHOLE in
one message to indicate no router, add a new RTF_NOTROUTER flag, or
something else?
Not sure I want to go down the RTM_NEWNEIGH route Linux has as that just
adds two flags with a new struct - is it a router and is it reachable.
We already have reachability checks, so it's litterally, is the NA a
router change or not.
This is how I follow the logic:
In the next paragraph, there is a requirement (MUST) to set the
lifetime to zero if the machine changes from a router to a host. This
is because the machine is possibly still up and running, just not a
router anymore. Makes sense.
In the paragraph you're reading, they use SHOULD. My guess is it might
be the case that the machine just goes down, or there is some other
mishap that means that a RA can't reliably be sent, and that's the
only reason why they say SHOULD. But it's not written that way, I'm
just interpreting it.