Bug #11105
closedIPv6 RA RDNSS lifetime is too short, not compliant with RFC 8106
100%
Description
https://forum.netgate.com/topic/158615/pfsense-ipv6-ra-rdnss-lifetime-is-too-short-not-compliant-with-rfc8106:
Is there a way to configure the lifetime for IPv6 RA RDNSS fields (type 25 and 31) in the pfSense IPv6 RA server? It appears that the default behaviour with pfSense is too short, and does not comply with RFC8106.
pfSense only offers three configurable values in the "Router Advertisement" UI - the "Minimum RA interval" (default 5 seconds), "Maximum RA interval" (default 20 seconds), and "Router lifetime" (default 3 * maximum RA interval).
Using these defaults, RA packets it sends have a router lifetime of 60 seconds as expected. However, the RDNSS fields have a lifetime of only 20 seconds! This causes them to occasionally expire if an RA packet is lost or if there is any jitter on the network.
RFC6106 specified that the lifetime SHOULD be bounded as: MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval
RFC8106 superceded this specifically to address this problem, and specifies that the value of Lifetime SHOULD by default be at least:
3 * MaxRtrAdvInterval
The pfSense behaviour (as tested with 2.4.5-RELEASE-p1) barely meets the RFC6106 recommendation, and is way below what RFC8106 considers the minimum for reliable operation.
Altering the MaxRtrAdvInterval in the pfSense UI doesn't help - pfSense appears to always set the lifetime of the RDNSS fields equal to MaxRtrAdvInterval.
Updated by Viktor Gurov almost 4 years ago
https://tools.ietf.org/html/rfc8106#section-5.1:
Lifetime 32-bit unsigned integer. The maximum time in seconds (relative to the time the packet is received) over which these RDNSS addresses MAY be used for name resolution. The value of Lifetime SHOULD by default be at least 3 * MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA interval as defined in [RFC4861]. A value of all one bits (0xffffffff) represents infinity. A value of zero means that the RDNSS addresses MUST no longer be used.
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/66
Updated by Brandon Jackson almost 4 years ago
Just including my post from the thread for a bit of attional info.
The radvd.conf is getting generated without AdvRDNSSLifetime defined, which from what I can find SHOULD default to 2*MaxRtrAdvInterval from what I am reading but it seems it is using just the MaxRtrAdvInterval.
Adding AdvRDNSSLifetime {3*MaxRtrAdvInterval} to the config should fix it, and not require waiting for radvd to be fixed.
Making this,
RDNSS 2001:470:****:1::3 2001:470:****:2::8 { };
into this.
RDNSS 2001:470:****:1::3 2001:470:****:2::8 {
AdvRDNSSLifetime 3060
};
3060 being my MaxRtrAdvInterval * 3
Updated by Jim Pingle almost 4 years ago
- Status changed from New to Pull Request Review
- Target version set to CE-Next
Updated by Renato Botelho almost 4 years ago
- Status changed from Pull Request Review to Feedback
- Assignee set to Viktor Gurov
PR has been merged. Thanks!
Updated by Viktor Gurov almost 4 years ago
- % Done changed from 0 to 100
Applied in changeset 54b3109f0b1978e22866117b6d93715eb8d78c29.
Updated by Jim Pingle over 3 years ago
- Status changed from Feedback to Waiting on Merge
- Target version changed from CE-Next to 2.5.1
Updated by Renato Botelho over 3 years ago
- Status changed from Waiting on Merge to Feedback
Cherry-picked to RELENG_2_5_1
Updated by Jim Pingle over 3 years ago
- Subject changed from IPv6 RA RDNSS lifetime is too short (not compliant with RFC8106) to IPv6 RA RDNSS lifetime is too short, not compliant with RFC 8106
Updating subject for release notes.
Updated by Viktor Gurov over 3 years ago
works as expected,
but now shows warning in routing.log:
routing.log:Mar 22 09:30:01 pf4 radvd[26608]: warning: (/var/etc/radvd.conf:24) AdvRDNSSLifetime <= 2*MaxRtrAdvInterval would allow stale DNS servers to be deleted faster
Updated by Viktor Gurov over 3 years ago
- Status changed from Feedback to Resolved