Project

General

Profile

Actions

Bug #12173

closed

IPv6 RA DNSSL lifetime is too short, not compliant with RFC 8106

Added by Andrew W 3 months ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
IPv6 Router Advertisements (RADVD)
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
21.09
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

This issue is almost exactly the same as issue 11105 [1] but for the DNSSL setting.

The 'AdvDNSSLLifetime' value in the 'DNSSL' section of radvd.conf should be set to 3*MaxRtrAdvInterval (per [2]), otherwise the Lifetime value in the RAs is only set to MaxRtrAdvInterval (defaults to 20). On my home network with somewhat weak WiFi, these RAs were getting lost frequently enough to where Mac OS X would tell Chrome that network connectivity had changed, which would cause long-running file downloads to fail consistently. [3] Looks like these defaults lifetime values have been increased in radvd code [4], but values are still needed in radvd.conf for radvd 2.19 to override the low default values in that version.

Also, it seems like the 'Provide DNS configuration via radvd' checkbox in the UI doesn't accurately reflect the value of 'radvd-dns' in the config. When navigating to /services_router_advertisements.php, the box is always checked regardless of whether radvd-dns is currently set to 'disabled' or 'enabled'.

[1] https://redmine.pfsense.org/issues/11105
[2] https://datatracker.ietf.org/doc/html/rfc8106#section-5.2
[3] https://bugs.chromium.org/p/chromium/issues/detail?id=1231856
[4] https://github.com/radvd-project/radvd/pull/151

Actions #2

Updated by Jim Pingle 3 months ago

  • Project changed from pfSense Plus to pfSense
  • Category changed from IPv6 Router Advertisements (RADVD) to IPv6 Router Advertisements (RADVD)
  • Status changed from New to Pull Request Review
  • Target version set to 2.6.0
  • Affected Plus Version deleted (21.05)
  • Plus Target Version set to 21.09
Actions #3

Updated by Viktor Gurov 2 months ago

  • Status changed from Pull Request Review to Feedback
  • Assignee set to Viktor Gurov

Merged

Actions #4

Updated by Jim Pingle 2 months ago

  • Status changed from Feedback to In Progress
Actions #5

Updated by Jim Pingle 2 months ago

See notes on PR about problematic behavior after this was merged.

Actions #6

Updated by Viktor Gurov 2 months ago

Jim Pingle wrote in #note-5:

See notes on PR about problematic behavior after this was merged.

fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/352

Actions #7

Updated by Renato Botelho about 2 months ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions #8

Updated by Jim Pingle about 1 month ago

  • Status changed from Feedback to Resolved

This all looks correct now on current snapshots.

Actions

Also available in: Atom PDF