Re: IPv6 default route flapping

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

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.

} > I have another reason for wanting that ... I run a reasonably current HEAD
} > kernel (9.99.80 from mid Feb at the minute, though I can upgrade that as
} > soon as there's a reason) but a fairly old userland (8.99.12 from late Jan, 
} > 2018)
} > 
} > Upgrading the kernel without upgrading userland is supposed to be supported.
} 
} Are you really arguing that non-essential functionality should be kept

     It is essential functionality.  Arguing otherwise is just silly.

} in the kernel just because it was once present? That doesn't strike me
} as very useful at all...

     Also, we should not be forced to use one particular application
to get basic IPv6 functionality.  dhcpcd started out as a simple
DHCP client and then grew into being a full blown network manager
as well as encompasing half the IPv6 stack.

     If nothing else, consider the case of trying to rescue a broken
system.  You shouldn't have to run an over complicated program just
to enable basic network functionality (the day will come when you
will be on a network that doesn't run IPv4, or have useful services
on IPv4).

}-- End of excerpt from Joerg Sonnenberger