Please add RFC 3378 to the reference section.

I would suggest putting entries in /etc/defaults/rc.conf into each rc.d scripts, instead of maintaining rc.d/routed and defaults/rc.conf.d/routed separately. I already added the necessary framework a long time ago, but it was not populated. The change based on the idea looks like the following. It should work without any change to rc.subr:

In D51778#1185473, @kp wrote:

In D51778#1185229, @hrs wrote:

I am also curious about why the PPPoE implementation sticks to only /128 LLAs for the link. When creating a pppoe interface as IPv6-capable one, it should get a /64 LLA because of AUTO_LINKLOCAL flag. Does pfSense disable this address assignment?

We assign an initial LLA based on the IPV6CP, which results in an address with with a destination address. Just like we get for IPv4.
Configuring a point-to-point address seems appropriate for a point-to-point link.
That destination address means we have no choice but to use /128 (see https://cgit.freebsd.org/src/tree/sys/netinet6/in6.c#n934), and that in turns means the router advertisement handling code ends up not being able to figure out what unique address bits to use. Not without this patch, anyway.

Looks good to me. Please do not forget to update .Dd line, too.

Could you explain why a simple type casting is not enough?

In D51866#1185261, @zlei wrote:

So is it now the time to unconditionally turn IPv6 PMTU on for gif(4) ?

Another choice can be, use IPV6_MINMTU initially, and switch to the better path discovered MTU when available, so the tunnel will not be blocked on PMTU process. I have not test if that is possible, just a thought.

D51866 is created because another approach seems reasonable.

Just curious, but why do you want to use automatically-generated LLAs? If you manually assign and use fe80::53/64 to the DNS server, for example, you can use it consistently without editing the configuration even when changing NICs on it.

I am also curious about why the PPPoE implementation sticks to only /128 LLAs for the link. When creating a pppoe interface as IPv6-capable one, it should get a /64 LLA because of AUTO_LINKLOCAL flag. Does pfSense disable this address assignment?

I have no objection to adding the xECP in the kernel message, but I would like to see them in a sysctl node like dev.xhci.N.xecp, too.

In D45855#1160514, @kenrap_kennethraplee.com wrote:

In D45855#1160497, @hrs wrote:

Could you explain your configuation and behavior change in more detail?

Sure thing. I use the following in my rc.conf which enlarges the virtual terminal fonts from being small after loading a drm-kmod driver during the booting process:

allscreens_flags="-f spleen-16x32"

After doing a src tree build upgrade today this functionality had stopped. By manually removing both set -o noglob and set +o noglob lines, I restored the original functionality.

The problem is that allscreens_flags relies on the pathname expansion in two places:
https://github.com/freebsd/freebsd-src/blob/4deb9760a9d84d5861ee45162ffebe83f13503b8/libexec/rc/rc.d/syscons#L237-L243
https://github.com/freebsd/freebsd-src/blob/4deb9760a9d84d5861ee45162ffebe83f13503b8/libexec/rc/rc.d/syscons#L381-L387

In D45855#1160402, @kenrap_kennethraplee.com wrote:

This change introduced a regression where my allscreens_flags settings gets ignored at boot.

Looks good to me.

@melifaro Could you explain the motivation for excluding manually-added prefixes from ICMPV6CTL_ND6_PRLIST? I could not find the reason in the review comments for the original change. As I wrote in the description, this sysctl is to list all prefixes in kernel. If a use case needs to pick up a subset of prefixes, it should be handled after getting the whole list.

Looks good to me.

Update the diff to use dnvlist_get_number().

Removing the NI_NUMERICHOST flag except for multicast addresses looks good to me.

The change basically looks good to me, but I added some comments.

I did not test the functionality yet, but I will give it a try with IPv4 and IPv6 configurations.

In D37930#861889, @jlduran_gmail.com wrote:

Also failing this test:

% ping -c1 192.0.2.1
PING 192.0.2.1 (192.0.2.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 0

--- 192.0.2.1 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss