RTF_NOTAROUTER?

[Roy Marples]

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.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andy Ruhl]

Post by Roy Marples
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
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.

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?

Andy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Andy Ruhl

Post by Roy Marples
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
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.

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.

Post by Andy Ruhl
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.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de