Do the default RA's need tweaking.

pst

@RobbieTT If I understand the problem correctly, the configuration that pfSense generates is correct according to RFC 8106 but RADVD which is part of FreeBSD only complies with RFC 6106. The change should therefore be made in FreeBSD as it not a "pfSense issue" as such.

RobbieTT

@pst said in Do the default RA's need tweaking.:

@RobbieTT If I understand the problem correctly, the configuration that pfSense generates is correct according to RFC 8106 but RADVD which is part of FreeBSD only complies with RFC 6106. The change should therefore be made in FreeBSD as it not a "pfSense issue" as such.

I'm not versed in the ins and outs of pfSense vs FreeBSD vs Netgate's upstream revisions of FreeBSD. It is way-over my head.

[edit:] FreeBSD 14 and current pfSense use radvd v2.19 (ie the latest) so it should be fully compliant with the later RFC.

The warning though was triggered by a pfSense change, albeit with a laudable aim, as referenced earlier.

️

pst

@RobbieTT said in Do the default RA's need tweaking.:

[edit:] FreeBSD 14 and current pfSense use radvd v2.19 (ie the latest) so it should be fully compliant with the later RFC.

One could only wish that was the case, but checking the source code and change log (https://radvd.litech.org/) there is no mention of RFC 8106. Implementation of other RFCs are mentioned though.

The configuration parser is written in YACC but quite easy to understand (radvd-2.19/gram.y):

| T_AdvRDNSSLifetime number_or_infinity ';'
                {
                        if ($2 > 2*(iface->MaxRtrAdvInterval))
                                flog(LOG_WARNING, "warning: AdvRDNSSLifetime <= 2*MaxRtrAdvInterval would allow stale DNS servers to be d
eleted faster");
                        if ($2 < iface->MaxRtrAdvInterval && $2 != 0) {
                                flog(LOG_ERR, "AdvRDNSSLifetime must be at least MaxRtrAdvInterval");
                                rdnss->AdvRDNSSLifetime = iface->MaxRtrAdvInterval;
                        } else {
                                rdnss->AdvRDNSSLifetime = $2;
                        }
                        if ($2 > 2*(iface->MaxRtrAdvInterval))
                                flog(LOG_WARNING, "warning: (%s:%d) AdvRDNSSLifetime <= 2*MaxRtrAdvInterval would allow stale DNS servers to be deleted faster", filename, num_lines);

                        rdnss->AdvRDNSSLifetime = $2;
                }

As you can see, the warnings that we get are only FYI as no change of the specified values take place. The non-compliance in the current software version (2.19) with RFC 8106 would be if AdvRDNSSLifetime is < MaxRtrAdvInterval which is rejected but should be allowed according to RFC 8106.

I agree that the warning was triggered by the pfSense change but the alignment with RFC 8106 should be made in RADVD (IMHO).

RobbieTT

@pst The default and example configuration file in v2.19 use the later x3 standard. The example text included with pfSense also uses the factor 10 sec x 3 = 30 seconds.

Joined-up, it is not.

️

pst

@RobbieTT There has been a change submitted to RADVD which align it to RFC8106:

https://github.com/radvd-project/radvd/commit/17c43bff200bbc1d4786eb917860a79db4f95c2e

Hopefully that will trickle through the system and end up in a pfSense release, at some point.

RobbieTT

@pst said in Do the default RA's need tweaking.:

@RobbieTT There has been a change submitted to RADVD which align it to RFC8106:

Thanks for that, very helpful.

It shows as a committ and the issue marked as closed over 2 years ago. Do we know where the air gap is between the issue being resolved and where we are now with pfSense?

[To me it looks like radvd itself has not been touched in over 2 years, suggesting that this package is not being maintained.]

️

pst

@RobbieTT No decision about a RADVD 2.20 release has been made yet (as of this post's date anyway), but voices has been raised:

https://github.com/radvd-project/radvd/issues/185

I don't know how long it will take after the 2.20 release before it ends up in pfSense as it needs to be integrated into FreeBSD first (I guess).

RobbieTT

@pst Not looking good - the last question on 2.20 is asking if downstream users are now expected to build from git, rather than a [2.20] tagged release.

That was in January 2023.

Indeed, there have been no releases since the original package maintainer retired in Jan 2021.

️

bearhntr

@RobbieTT

Is there a way to fix this? Is there a set of instructions on fixing it? I am not super-Linux proficient, simple-is as simple-does.

I just going through some of these logs on my pfSense+ 23.05.1-RELEASE (amd64) - Just installed the latest this AM.

I am one of those who hates seeing errors and warnings. <grin>

RobbieTT

@bearhntr
I've no idea, sorry!

️