kind ping @ziaee.

Update copyright email to freebsd.

Update the copyright email to my freebsd account.
rebase to parent revision.

Add spdx tag to geneve header and replace its email with my freebsd email.

Final style check before landing.

In D55887#1279151, @thj wrote:

I think we should probably have tests check we do the correct things when we get a jumbogram. If these tests aren't run they don't really help with that.

I don't think the numbering gap is a problem, I'd leave the others alone.

Do you have any history for why these are disabled? I they are from the initial netflix work when the frag vulnerabilities came up?

@markj kind ping.

In D51866#1276038, @glebius wrote:

Hi! Writing this with my core@ (and srcmgr@) lurker hat on.

I'd like to see this due problem fixed and the tension between fellow committers released. Let's please go with this plan:

1. Let's abandon D52594. @meta can you please do this?
2. Let's replay all important feedback from D52594 into this review. @pouria and/or @meta, can you please replay? Just simple copy & paste. We want to have all discussion in one place.
3. Let's proceed with pushing the reviewed change to main. @hrs if you are limited on time, can you please yield the right to push to @meta and @pouria? Please don't block the process, unless you have a very strong design or coding concern wrt to the change. @hrs please provide information if you want or rather don't want that the pushed commit will be under your authorship?

kind ping @bz.

Thank you.
@bz Should I tag it with relnotes?

Appearantly, there is a difference between:

tools/build/options/makeman > share/man/man5/src.conf.5

and

./makeman > /usr/src/share/man/man5/src.conf.5

I didn't know I should run it inside its directory.
@bz done.

Address @bz comments.
I removed the comment and regenrated the src.conf.5.
The src.conf.5 regeneration will remove much more than my change.
Is that fine? @ziaee

Replace err(3) with errx(3) for better error message.

Add error message.

Add RTA_PRIORITY.

Remove bitwise mask.

There is a specific netlink attribute for metric.
Use that instead.

Update structure to make it compile separately.
+ fix minor issues.

Refactor to use union instead.
This is much more cleaner.

These changes can be tested in latter route revisions in the revision stack.

Also this revision will NOT change expected routing behavior (POLA) since we never allow users to set weight more than 24-bit.
Now we don't, but we use it for metric.
I intentionally used the term metric instead of administrative distance. You know the difference.

Here is how it works:

[root@ftsr1] [~] # route -n6 add -net 3fff::/64 -gateway 2a01:e140:10:10::6 -weight 33554435
change net 3fff::/64: gateway 2a01:e140:10:10::6 fib 0
[root@ftsr1] [~] # route -n6 add -net 3fff::1/64 -gateway 2a01:e140:10:10::1 -weight 2
add net 3fff::1/64: gateway 2a01:e140:10:10::1 fib 0
[root@ftsr1] [~] # route -n6 get 3fff::/64
   route to: 3fff::
destination: 3fff::
       mask: ffff:ffff:ffff:ffff::
    gateway: 2a01:e140:10:10::6
        fib: 0
  interface: vtnet0
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu       metric    weight    expire
       0         0         0         0      1500         2         3         0
[root@ftsr1] [~] # route -on6 get 3fff::/64
   route to: 3fff::
destination: 3fff::
       mask: ffff:ffff:ffff:ffff::
        fib: 0
      flags: <UP,GATEWAY,DONE,STATIC>
      nhops: 2
        via gw 2a01:e140:10:10::1 iface vtnet0 metric 0 weight 2 mtu 1500 table inet6.0
        via gw 2a01:e140:10:10::6 iface vtnet0 metric 2 weight 3 mtu 1500
[root@ftsr1] [~] # netstat -rn6W | grep 3fff
3fff::/64                         2a01:e140:10:10::1            UGS         0   1500           vtnet0
3fff::/64                         2a01:e140:10:10::6            UGS         0   1500           vtnet0
[root@ftsr1] [~] # netstat -On6W
Nexthop groups data

Also return the weight of selected nhop from nhgrp.

@kp @zlei Done.
Could you please review this again?
I just removed the support without netlink completely and successfully ran my tests.
There should be no nvlist interface/header left.
I also abandoned the support for ifconfig WITHOUT_NETLINK.

Remove nvlist/ioctl support.

kind ping @zlei

This LGTM, but here's an idea: why not do it the other way around?
It makes more sense not to acquire the lock on every vnet_destroy, since many modules don't require ifnet_detach_sxlock.
Of course it requires more work, but IMHO it's worth it.

LGTM

I want to work on metric or administrative distance too.
But I'm waiting on @melifaro response to some of my questions.

@bz
I'd appreciate if your review this again when you have time.
I won't proceed without your approval.

Address @bz comment.

Address @markj comment

Remove the whole EXPERIMENTAL kernel option as noted by @bz.

@bz done.

Address @markj comment.
Thank you

In D55850#1286321, @markj wrote:

Is proxy advertisement handling covered by your tests in review?

kind ping: @markj

Address @zlei comment.

In D56134#1286016, @zlei wrote:

For the commit message,

ndp: Remove anycast check in prelist_update

I think the word ndp is a bit misleading. I read it this is a change for the userspace one usr.sbin/ndp. I'd prefer nd6_rtr: xxx or nd6: xxx, to indicate the change is for the kernel part.

In D55449#1285908, @markj wrote:

Do you have any tests for this feature?

Fix some of the linter warning. rest is intentional.

ignore rti default route with lifetimer bigger than UINT16_MAX until I update its structure in another review.

Enable not yet part again.

In D55449#1285908, @markj wrote:

Do you have any tests for this feature?

Address @markj comments.
Thank you so much for your review.

Address @zlei comments.

I forgot I already had this one open, abandon in favor of D56202

kind ping: @bz @glebius @markj
I'm not in rush, however, I just can't continue my work on ndp without this anymore due to number of conflicts.

I didn't include the sys/netinet6/nd6_rtr.c part yet, so there is no dependency with other ndp revisions.
But I want to push them at once. (ofc, if approved)

@ae, that's where I said we would probably have conflict over the reserved flags.