pfSense

An example radvd configuration can be found here:
[http://sophiedogg.com/radvd-and-dhcpd6-server-configuration-for-dynamic-dns/]

Renato Botelho wrote:

PR has been merged. Thanks!

Tested on 2.5.0.a.20191011.1853

No RDNSS and DNSSL entries in /var/etc/radvd.conf with "Managed" or "Stateless DHCP" mode

Resolved

I think this change breaks ipv6 RFC compliance. The blogger article was written in 2012 and seems that the authors goal was to make ipv6 work like he was familiar with in ipv4.

I think that the way it was before the change, is the correct implementation. It is the responsibility of the Network Administrator to enter the correct DNS servers on the RA tab.

The “M - Managed Address Configuration Flag” when set, indicates that addresses are available via DHCP and “MAY” be used. The “M Flag” does not turn off RDNSS as far as I know.

RFC 8106 states that Hosts conforming to RFC4861 MUST extract DNS information from the RA messages, unless static DNS has been specified by the user. If there is DNS information available from multiple RAs and/or from DHCP, the host MUST maintain an ordered list of this information as specified in RFC 8106 Section 5.3.1. This section says that the host must maintain a table of the DNS and specifies the order they should be used.

I totally agree that when using "M" mode that RDNSS should not be disabled.

In fact, the change above only stops pfSense from automatically advertising the system defined DNS servers in the RA messages (RDNSS) when the user has left the DNS servers fields empty in the RA section of DHCPv6 configuration. If specific DNS servers are entered there, those will be advertised in the RA messages along with "M" flag set, so that should comply with the above.

Are you saying that the impact of this change, is that in the cases of "Managed" or "Stateless DHCP" then the bottom of the RA tab will have “Use same settings as DHCPv6 server” checked by default?

I can still uncheck and it goes back to the way it currently is?

There is no requirement that DNS advertised by DHCP be the same as that provided by RA. I could see a case where the DHCP DNS may point to a Windows AD DNS server, but for non-DHCP hosts, they should use the pfSense Interface which is currently the default.

If you require that I manually enter in DNS servers on the RA tab then with dynamic prefixes you have introduced a major extra step for me every time the prefix is changed.

I don’t see how this change helps anyone, when there is already a check mark at the bottom to use the DHCP servers as an option?

DNS via RFC 8415 (DHCP) and via RFC 8106 (RDNSS) are independent functions which is as the current pfSense implementation treats them. If you want them to be the same, there is already a mechanism to do that via the check mark, but that is not the default, and should break the current ability to use the interface addresses in the RA tab.

RFC 8106 anticipates that both can be used and provides a precedence order for the hosts.

5.3.1. Procedure in IPv6 Hosts
In the case where the DNS information of RDNSS and DNSSL can be
obtained from multiple sources, such as RAs and DHCP, the IPv6 host
SHOULD keep some DNS options from all sources. Unless explicitly
specified for the discovery mechanism, the exact number of addresses
and domain names to keep is a matter of local policy and
implementation choice as a local configuration option. However, in
the case of multiple sources, the ability to store a total of at
least three RDNSS addresses (or DNSSL domain names) from the multiple
sources is RECOMMENDED. The DNS options from RAs and DHCP SHOULD be
stored in the DNS Repository and Resolver Repository so that
information from DHCP appears there first and therefore takes
precedence. Thus, the DNS information from DHCP takes precedence
over that from RAs for DNS queries. On the other hand, for DNS
options announced by RAs, if some RAs use the Secure Neighbor
Discovery (SEND) protocol [RFC3971] for RA security, they MUST be
preferred over those that do not use SEND. Also, DNS options
announced by RAs via SEND MUST be preferred over those announced by
unauthenticated DHCP [RFC3118]. Refer to Section 7 for a detailed
discussion of SEND for DNS RA options.


Elbin Teh wrote:

I totally agree that when using "M" mode that RDNSS should not be disabled.

In fact, the change above only stops pfSense from automatically advertising the system defined DNS servers in the RA messages (RDNSS) when the user has left the DNS servers fields empty in the RA section of DHCPv6 configuration. If specific DNS servers are entered there, those will be advertised in the RA messages along with "M" flag set, so that should comply with the above.

I setup a 2.5 pfSense router and this change definitely breaks RDNSS. Looking at the packets on wireshark, there is no entry DNS or domain search list being provided.

I use Stateless DHCP and Managed on different subnets, and this change breaks ability of Android clients and other IOT type devices from getting DNS.

Looking in the /var/etc/radvd.conf shows the RDNSS and DNSSL entries are missing.

If you look at the last paragraph of the blog from 2012 that you referenced:

"One thing to note, I have found that Android devices (a 2.3 phone and a 3.2 tablet) don’t like to get IPv6 addresses from our DHCPd6 server; however everything else on the network (including other wifi devices) will correctly get addresses from the DHCPd6 server. Android devices will however get stateless autoconfiguration addresses from a radvd standalone setup. Perhaps this is a misconfiguration on my part, or an incompatibility in the Android OS; if you have any idea please let me know! Arf! "

Perhaps it is a Misconfiguration?

Hi,

I did some more research and investigation on this, and on further thought I think this needs to be revisited. However, I do not have the time to do this at the moment, but have prepared a PR to revert my initial changes to avoid breaking this!

https://github.com/pfsense/pfsense/pull/4111

I will revisit this when I can, as I did find some inconsistent behavior in some IPv6 clients when both DNS servers are define in RA (RDNSS) and in DHCPv6:
1) Some clients prefer the DNS Server in RA when both are present
2) Some clients prefer the DNS Server in DHCPv6 when both are present

Elbin Teh wrote:

Hi,

I did some more research and investigation on this, and on further thought I think this needs to be revisited. However, I do not have the time to do this at the moment, but have prepared a PR to revert my initial changes to avoid breaking this!

https://github.com/pfsense/pfsense/pull/4111

I will revisit this when I can, as I did find some inconsistent behavior in some IPv6 clients when both DNS servers are define in RA (RDNSS) and in DHCPv6:
1) Some clients prefer the DNS Server in RA when both are present
2) Some clients prefer the DNS Server in DHCPv6 when both are present

I set up a pfsense 2.5 and tested this today and based on my testing i opened https://redmine.pfsense.org/issues/9893

It should be the responsibility of the Network Administrator to make certain that the RDNSS is setup with the DNS servers they want to use. It could be the same as is configured via DHCPv6 or it could be different. In my use case I set DHCPv6 to point to a pihole DNS server and my RDNSS to point to my pfsense DNS. The reason is if my ISP was to change my ipv6 prefix then I would not have working DNS until I reconfigure the pihole.

The way pfsense 2.4.4 works gives you the ability to configure RDNSS as you are suggesting.

RFC 8504 Chapter 8 provides overview of Configuring Non-Address Information and states that IPv6 Router Advertisement Implementations MUST include support for the DNS RA option [RFC8106]. This has been in effect since 2017. What this means is that every Router Announcement must contain and RDNSS and DNSLL information in the packet. The host based on the M or O flag is expected to act appropriately.

Regardless as far as 1, and 2 above, RFC 8106 Chapter 5.3 spells out what hosts are to do when they receive DNS Servers from both DHCPv6 and RDNSS. The RFC's state that the hosts MUST support RDNSS and SHOULD support DHCPv6 for DNS. There are some hosts that just choose not to have a DHCPv6 client since it isn't mandatory.

Agreed it would be the responsibility of the network administrator to configure RDNSS or DNSSL or disable them completely.

In pfSense 2.4.4 using “Managed mode” or “Stateless DHCP” this was not possible as pfSense would either advertise the interface address of the DNS Forwarder or Resolver (if configured) or fallback to the system defined DNS server.

This also violates the specified RFC as it forces the network administrator to configure RDNSS or DNSSL in RA (which are optional configurations).

I’m sure the RA configuration in pfSense can be improved further to allow more flexibility and yet be in conformance of the RFC. For example, there could be a checkbox to allow to RDNSS or DNSSL to be unconfigured (hence disabled).

As per RFC 8106, section 1.1 specified that these are optional rather than MUST

RA-based DNS configuration is a useful alternative in networks where an IPv6 host's address is autoconfigured through IPv6 SLAAC and where either 
(i) there is no DHCPv6 infrastructure at all or 
(ii) some hosts do not have a DHCPv6 client. 
The intention is to enable the full configuration of basic networking information for hosts without requiring DHCPv6. However, for networks that need to distribute additional information, DHCPv6 is likely to be employed. In these networks, RA-based DNS configuration may not be needed.

Elbin Teh wrote:

Agreed it would be the responsibility of the network administrator to configure RDNSS or DNSSL or disable them completely.

In pfSense 2.4.4 using “Managed mode” or “Stateless DHCP” this was not possible as pfSense would either advertise the interface address of the DNS Forwarder or Resolver (if configured) or fallback to the system defined DNS server.

This also violates the specified RFC as it forces the network administrator to configure RDNSS or DNSSL in RA (which are optional configurations).

I’m sure the RA configuration in pfSense can be improved further to allow more flexibility and yet be in conformance of the RFC. For example, there could be a checkbox to allow to RDNSS or DNSSL to be unconfigured (hence disabled).

As per RFC 8106, section 1.1 specified that these are optional rather than MUST

[...]

You need to read to the end of the RFC. Section 1 is the rational why RDNSS was added to the Router Announcements.

It states in Section 1.2 that Hosts that conform to RFC 4861 Neighbor Discovery for IP version 6:

MUST extract DNS information from RA messages, unless static DNS
   configuration has been specified by the user.  If there is DNS
   information available from multiple RAs and/or from DHCP, the host
   MUST maintain an ordered list of this information as specified in
   Section 5.3.1.

In RFC language MUST means mandatory, so if the router is sending out Router Announcements per RFC 4861 it must include RDNSS and DNSSL information when the prefix information is sent out.

If the M or O flag is set, the client host should prefer the DNS provided by DHCP by way of an ordered list per Section 5.3.1.

I think the real issue is making certain that the RDNSS DNS Server is the correct DNS. Currently it can be manually set by the network administrator. The wording is pretty clear. Leave blank to use the system default DNS servers - this interface's IP if DNS Forwarder or Resolver is enabled, otherwise the servers configured on the General page.

The extract that you've posted is in Section 1.2 which immediately follows Section 1.1 (which describes how RDNSS in RA is a useful alternative and may not be needed in some cases).

Section 1.2 explains the case where DNS information is present in BOTH RA and DHCPv6 Options. In such a case, then IPv6 host MUST extract the DNS information from the RA messages along with the information from DHCPv6. However, the author does not mention that RDNSS and DNSSL are mandatory Options in IPv6 ND messages.

In Section 4, it is also suggested that an "IPv6 host CAN configure one or more RDNSSes via RA messages" and that "RA options for RDNSS and DNSSL CAN be used". "MUST" is not used.

The existing ND message (i.e., RA) is used to carry this information. 
An IPv6 host can configure the IPv6 addresses of one or more RDNSSes via RA messages. 
Through the RDNSS and DNSSL options, along with the Prefix Information option based on the ND protocol [RFC4861] [RFC4862], an IPv6 host can perform the network configuration of its IPv6 address and the DNS information simultaneously without needing DHCPv6 for the DNS configuration. 
The RA options for RDNSS and DNSSL can be used on networks that support the use of ND.

Shouldn't this be changed to a Feature Request?

The Requestor has not shown any documentation that this is a bug. Everything I have been able to test show that pfSense 2.4.4 is performing as the RFC's require.

Rather he has said that he has a unique requirement to disable RDNSS. His reasoning is that he has client hosts that are not RFC compliant and ignore the DNS servers precedence order specified in the RFC's. He hasn't provided data as to what these client hosts are. He also hasn't stated why he isn't able to just manually enter the same DNS servers into the RA tab as what he provides via DHCPv6,

The change he is requesting will make pfSense non-compliant with:

RFC 8504, Best Current Practice 220, IPv6 Node Requirements.

8.  Configuring Non-address Information

8.1.  DHCP for Other Configuration Information

   DHCP [RFC3315] specifies a mechanism for IPv6 nodes to obtain address
   configuration information (see Section 6.5) and to obtain additional
   (non-address) configuration.  If a host implementation supports
   applications or other protocols that require configuration that is
   only available via DHCP, hosts SHOULD implement DHCP.  For
   specialized devices on which no such configuration need is present,
   DHCP may not be necessary.

   An IPv6 node can use the subset of DHCP (described in [RFC3736]) to
   obtain other configuration information.

   If an IPv6 node implements DHCP, it MUST implement the DNS options
   [RFC3646] as most deployments will expect that these options are
   available.

8.2.  Router Advertisements and Default Gateway

   There is no defined DHCPv6 Gateway option.

   Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
   are thus expected to determine their default router information and
   on-link prefix information from received Router Advertisements.

8.3.  IPv6 Router Advertisement Options for DNS Configuration - RFC 8106

   Router Advertisement options have historically been limited to those
   that are critical to basic IPv6 functionality.  Originally, DNS
   configuration was not included as an RA option, and DHCP was the
   recommended way to obtain DNS configuration information.  Over time,
   the thinking surrounding such an option has evolved.  It is now
   generally recognized that few nodes can function adequately without
   having access to a working DNS resolver; thus, a Standards Track
   document has been published to provide this capability [RFC8106].

   Implementations MUST include support for the DNS RA option [RFC8106].

8.4.  DHCP Options versus Router Advertisement Options for Host
      Configuration

   In IPv6, there are two main protocol mechanisms for propagating
   configuration information to hosts: RAs and DHCP.  RA options have
   been restricted to those deemed essential for basic network
   functioning and for which all nodes are configured with exactly the
   same information.  Examples include the Prefix Information Options,
   the MTU option, etc.  On the other hand, DHCP has generally been
   preferred for configuration of more general parameters and for
   parameters that may be client specific.  Generally speaking, however,
   there has been a desire to define only one mechanism for configuring
   a given option, rather than defining multiple (different) ways of
   configuring the same information.

   One issue with having multiple ways to configure the same information
   is that interoperability suffers if a host chooses one mechanism but
   the network operator chooses a different mechanism.  For "closed" 
   environments, where the network operator has significant influence
   over what devices connect to the network and thus what configuration
   mechanisms they support, the operator may be able to ensure that a
   particular mechanism is supported by all connected hosts.  In more
   open environments, however, where arbitrary devices may connect
   (e.g., a Wi-Fi hotspot), problems can arise.  To maximize
   interoperability in such environments, hosts would need to implement
   multiple configuration mechanisms to ensure interoperability.

He is attempting to change the definition of the M and O flags from DHCP is available and SHOULD be used, to DHCP MUST be used even if you have to break the Host Client.

Jim Pingle wrote:

Yes, it should be a feature request (which I just changed). It should be made optional, off by default, and have a separate GUI option which makes it clear what will happen and what will break by enabling it.

I also pushed a commit to revert the change from the original PR.

Thanks.

I will probably be firing up my 2.5 test system then this weekend.

I only stumbled onto this issue after I had already found my own need for it and made a small patch for it. It's not exactly what the OP asked for as far as automatically enabling/disabling the options according to the RA mode, but it allows the user to manually override the behavior via some new toggles. May be good enough.
https://github.com/pfsense/pfsense/pull/4129

tested on 2.5.0.a.20200109.0836
works as expected,

but WebGUI looks weird -
unchecked by default, but "Unchecking this box disables the.. Use with caution, as the resulting behavior may violate some RFCs." note at the same time

Looks fine here in the latest Firefox and Chrome. Even so, I pushed a change to reword the help text a bit.