Avoid returning badkey error for EDDSA.

@ziaee
Thank you for reviewing the 53786 . I wanted to politely ping you on this revision, when you have a chance.

@glebius can I commit this revision?

LGTM
I also tested interface creation and destruction to advertise/withdraw its routes with bird3 (ospf) and openbgpd8.

LGTM.
I also tested with the CSUM_IP patch applied to if_epair.c:447 and saw good results.

Address @ziaee comments

I will test it with openbgp and bird.
I suspect that removing routes before detaching the actual interface might cause unexpected behavior in them.

Address @bz comment for manual.

Address @bz comments

In D54636#1250365, @ivy wrote:

the only purpose that RFC8781 mentions for having multiple PREF64s advertised is renumbering, in which case the lifetime of the deprecated prefixes should be set to zero. iiuc, this diff allows that by setting pref64lifetime0, pref64lifetime1, etc. - can i check i have that right?

P.S. Love the KAME project, but honestly, most of their userland code is weird.
For instance, I also have a branch for mobile ipv6 implementation, where I made a fair amount of changes to rtadvd, rtsold, rtadvctl, and others.
I have to say the layer of indirection in KAME code makes adding a single floating point number almost impossible without refactor.
I don't like their style of coding in userland either. However, To see if I should use our own style or simply follow existing, I checked the other revisions for these toolset found other developers simply didn't touch KAME style.

rebase to latest commit and cleanup unused var

Here is the output sample of rtadvctl:

% mdo rtadvctl -v show
bridge0: flags=<UP,TRANSITIVE,PERSIST> status=<RA_SEND> mtu 1500
DefaultLifetime: 10m
MinAdvInterval/MaxAdvInterval: 3m20s/10m
AdvLinkMTU: <none>, Flags: MO, Preference: low
ReachableTime: 0s, RetransTimer: 0s, CurHopLimit: 64
AdvIfPrefixes: yes
Next RA send: Thu Jan 15 00:58:25 2026
Last RA send: Thu Jan 15 00:58:06 2026
Prefixes (1):
2a01:e140:1234:5678::/64 (CONFIG, vltime=30d, pltime=7d, flags=LA)
DNSSL entries:
spmzt.net (ltime=15m)
PREF64:
2a01:e140:cafe:ff::/96 (ltime: 3m45s)
2a01:e140:dead:ff::/64 (ltime: 3m45s)

Change revision to add support for multiple PREF64 options.

leave trailing space on authors.adoc and add freebsd email uid to my pgp key for signing emails.

committers-src: Add myself (pouria@) with glebius@ as mentor

Convert action_show_pref64 from int to void and use assertion to address @zlei comment.

LGTM
also tested:

# kyua test -k /usr/tests/sys/netinet6/Kyuafile ndp
ndp:ndp_add_gu_success  ->  passed  [2.012s]
ndp:ndp_del_gu_success  ->  passed  [3.407s]
ndp:ndp_prefix_len_mismatch  ->  passed  [2.128s]
ndp:ndp_prefix_lifetime  ->  passed  [15.506s]
ndp:ndp_prefix_lifetime_extend  ->  passed  [0.078s]
ndp:ndp_slaac_default_route  ->  passed  [5.364s]

LGTM
tested:

IMHO, this case should not happen at all. Therefore, if there is a possible scenario, it maybe more appropriate to use KASSERT instead.

In D54561#1246664, @markj wrote:

The function is used in multiple compilation units, so to make it inline the definition would have to be in a header, probably nd6.h since that's where ND6_INFINITE_LIFETIME is defined.

You're right! it's definitely overkill. Thank you!

LGTM. Why don't you inline it? I know that the compiler will do ultimately what it wants. but at least we can suggest the right thing to it.

Why don't we allow new committers to use curve algorithms?
I can see that there are multiple ed25519 keys currently in use by committers, as reported by ./doc/documentation/tools/pgpkeyreport.
However, committer's guide states that checkkey.sh must be used to ensure the key is valid.
The checkkey.sh script does not allow committers to use curve algorithms. Is this ok or should we write an exception for curve algorithms?

Fix ability to modifying generic and link-specific attributes at the same time in geneve_clone_modify_nl

LGTM

I wasn't sure whether this change was necessary or whether my approach was correct. I thought this was a known issue that someone would address eventually, and no one had enough time to do it. If that's not the case, I'll close this revision.
@bz Thank you for your feedback. @zlei If a bug appears in the future and the team decides it should be fixed, I can help.