On Mon, Sep 23, 2024 at 12:25:15PM +0200, Chris Hofstaedtler wrote: > * Pierre-Elliott Bécue <p...@debian.org> [240923 11:34]: > > I like ifupdown. It's simple and just works. > > I find this quite funny, given a recent discussion about IPv6 dad > issues with ifupdown on #debian-admin.
The "discussion" was about ifup@eth0 being in a failed state on a particular server due to a DAD failure and someone having to manually intervene. Chris, what behaviour do you expect here? Below I'm going to assume what you're getting at is that we should continue to retry DAD. To me going to a stable failure state seems desirable. Continuing to re-try for IPs could cause instability in the face of legitimate address conflicts: when the owning machine reboots the conflicting machine would now win the IP due to continous retrying. The change in owner would cause disruption to services entirely unrelated to the machine that was just rebooted. Sounds like the setup for a very drawn out and frustrating debugging story to me. --Daniel PS: I was wondering if the RFCs have anything to say on the matter: [ADDRCONF] says: > 5.4.5. When Duplicate Address Detection Fails > > [...] If the address is a link-local address formed from an interface > identifier, the interface SHOULD be disabled. [Enhanced DAD] while not directly applicable seems to be under the impression that manual intervention is the "current behaviour": > 3.3. Operational Considerations > > [...]the noncompliant device would > follow current behavior and disable IPv6 on that interface due to DAD > until manual intervention restores it. [ADDRCONF]: RFC 2462 - IPv6 Stateless Address Autoconfiguration [Enhanced DAD]: RFC 7527 - Enhanced Duplicate Address Detection
signature.asc
Description: PGP signature
