Current-Users archive

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

Re: IPv6 default route flapping



Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
>On Wed, Apr 21, 2021 at 02:21:51AM -0700, John Nemeth wrote:
>> On Apr 20, 21:13, Joerg Sonnenberger wrote:
>> } On Wed, Apr 21, 2021 at 12:54:36AM +0700, Robert Elz wrote:
>> } > It seems as if what is happening, is that the router is sending RA's with
>> } > the source-link addr option, which isn't being added to the neighbour
>> } > cache.
>> } > 
>> } > Then NetBSD is doing a NS to discover the address it ignored from the RA,
>> } > but instead of replying with a ND as would perhaps be expected, the router
>> } > is simply sending another RA (containing the relevant addr info, which would
>> } > answer the NS if processed).
>> } 
>> } I'm not entirely sure that the behavior of sending a RA as "answer" to a
>> } NS is valid under RFC 4861, but I also don't understand why the existing
>> } code (nd6_rtr_cache) doesn't cover this. That would be a good place to
>> } debugging this.
>> } 
>> } > I'd suggest putting RA processing back into the kernel to avoid this kind
>> } > of issue.
>> } 
>> } Except of course that it introduces back all the reasons for why it was
>> } removed in first place and ignores that it shouldn't happen.
>> 
>>      RA processing is fundamental to the operation of IPv6.  Removing
>> it was extremely stupid and not well thought out.  The decision
>> should be reverted.  I didn't have a problem with a sysctl to
>> disable it, but I have a huge problem with removing it completely.
>
>RA processing is not time-sensitive. It doesn't require any special
>interfaces. A correct and useful implementation requires non-trivial
>policy decisions. There are a lot of reasons for why it should not be
>part of the kernel and very few of why it should be. In fact, other
>systems never implemented it in the kernel or have similary moved it for
>pretty much the same reason.

One subsystem that made use of RA processing being in the kernel is
MobileIPv6, it used notifications from the kernel to work out that a
node has moved, I did get a suggestion from roy@ on an alternative way
to do this but haven't implemented it yet.

Think we need to make dhcpcd work with rump if it is the only way to do
RA processing.




Home | Main Index | Thread Index | Old Index