tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]


On 30/08/2019 05:42, Andy Ruhl wrote:
On Thu, Aug 29, 2019 at 5:56 PM Roy Marples <> 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.

After more thought, we can ignore the NA.
For all OS's I've checked, the NA router flag is set on if it's a router or not, NOT if it's ceased advertising as the RFC describes.
This is likely because the advertising software isn't part of the kernel.

As such, they all trigger the MUST clause you mentioned and thus we can safely ignore this now.

I've added a large comment to dhcpcd describing this just incase my brain farts on it again.

So I'm wondering who would send an RA with a nonzero lifetime field
with the intention of not being a router anymore. Makes no sense. Does
it happen? And what is the cost of ignoring it? How long does it take
to decide the router is down?

Pretty sure that's not compliant, so we can ignore it.
In NetBSD's case it's when it's unreachable, or more technically when the llentry for the routers address is removed.


Home | Main Index | Thread Index | Old Index