IPv6 Router Advertisement flags (M and O) - are they being set/used correctly by pfSense?

ChrisJenk

In RFC 4861 it discusses the M (Managed) and O (Other) flags in IPV6 Router Advertisements. It says this:

  M              1-bit "Managed address configuration" flag.  When
                 set, it indicates that addresses are available via
                 Dynamic Host Configuration Protocol [DHCPv6].

                 If the M flag is set, the O flag is redundant and
                 can be ignored because DHCPv6 will return all
                 available configuration information.

  O              1-bit "Other configuration" flag.  When set, it
                 indicates that other configuration information is
                 available via DHCPv6.  Examples of such information
                 are DNS-related information or information on other
                 servers within the network.

    Note: If neither M nor O flags are set, this indicates that no
    information is available via DHCPv6.

In pfSense, when configuring Router Advertisements for the local network One has several options. Three of them refer to the M and O flags:

Managed: M and O both set.
Assisted: M and O both set.
Stateless DHCP: M not set, O set.

I have observed (using radvdump) that the RAs generated by pfSense do indeed correspond to the above in terms of the configured mode and the settings of the M and O flags (my network also uses DHCP6).

My first question is why does pfSense set the O flag for Managed and Assisted mode when according to RFC 4861 the value of thsi flag is irrelevant?

My second question is how does pfSense handle RAs that it receives where the M flag is set but the O flag is not. Specifically an RA of this format:

#
# radvd configuration generated by radvdump 2.19
# based on Router Advertisement from fe80::b6f9:5dff:fe30:993f
# received by interface ix3
#

interface ix3
{
        AdvSendAdvert on;
        # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
        AdvManagedFlag on;
        AdvOtherConfigFlag off;
        AdvReachableTime 0;
        AdvRetransTimer 0;
        AdvCurHopLimit 64;
        AdvDefaultLifetime 180;
        AdvHomeAgentFlag off;
        AdvDefaultPreference medium;
        AdvSourceLLAddress on;
}; # End of interface definition

The reason for asking is that my ISP is sending RAs in this format and pfSense is not using them to configure the upstream router (and thus IPv6 connectivity does not work). My ISP also uses DHCP6 and pfSense does correctly get its IPv6 address via DHCP6. Even more strangely, this was all working just fine until midnight last night (2024-07-28@00:00:00) when suddenly pfSense stopped setting the router based on the received RAs. I've rebooted several times but it is still not working as it used to. Is this due to a problem in the RAs sent by my ISP or something else? I haven't made any changes to my pfSense configuration for several weeks.

JKnott

@ChrisJenk

WAN side and LAN side are different connections. The RAs on your LAN should reflect what you configure, not what the ISP does.

ChrisJenk

@JKnott Yes, I'm well aware of that. I was just contrasting the flags in RAs that pfSense generates to the ones arriving from my ISP.

My specific questions are:

Are these RAs from my ISP valid (it would seem so).
Will pfSense process them correctly.

My ISP/WAN connection uses DHCP6 and so relies on RAs to get the default router. What I am seeing is that either pfSense most of the time (apparently) ignores these RAs or (occasionally) does use the router from the RA to assign the default IPv6 router but then that gets undone after some arbitrary time (the default IPv6 route disappears). This only started happening yesterday so I;m trying to figure out why and what is causing it. Nothing has changed on my side for several weeks but it's hard to see what my ISP could be doing to cause this.

JKnott

@ChrisJenk

Well, I you'll have to see what the flags are when whatever fails.