Bug #4544
closed
PD not requested if no interfaces set to track6
Added by Jan Joris Vereijken over 9 years ago.
Updated about 4 years ago.
Description
Bug #4436 disable prefix delegation requests when no tracking interface is defined. This causes a regression in combination with Network Prefix Translation in a dual-WAN setup and a Unique Local Address range on the LAN interface: pfSense requests prefix delegation from both WAN interfaces, and uses NPT to perform translation for the ULA addresses on the LAN toward the respective delegated prefixes, e.g. for load balancing or failover purposes.
In the scenario, the prefix delegation on the WAN interfaces is required, but there is no tracking interface, because the LAN interface needs to be static IPv6 with the ULA addresses.
I have such a set-up, and upgrading from 2.2 tot 2.2.1 broke IPv6 for this reason.
Can we have more control over prefix delegation, so that we can re-enable it in scenarios like this one?
- Project changed from pfSense Packages to pfSense
- Status changed from New to Feedback
- Assignee set to Chris Buechler
there is a workaround for this, but I'll revisit the subject as a whole.
- Category set to Interfaces
- Subject changed from Bug #4436 causing regression on NPT setup to PD not requested if no interfaces set to track6
- Status changed from Feedback to Confirmed
- Target version set to 2.3.2
- Affected Version set to 2.2.x
updated subject is the issue. That case shouldn't cause it to skip requesting PD, for cases where the PD is actually static and people want to statically configure it, and cases like OP's with NPT.
- Assignee deleted (
Chris Buechler)
- Target version changed from 2.3.2 to 2.4.0
The code here is at fault.
https://github.com/pfsense/pfsense/blob/master/src/etc/inc/interfaces.inc#L3927
It should still include the 'send ia-pd' in the dhcp6c config even if there are no track interfaces.
With a short timeline on getting a 2.3.2 out, that's not a reasonable change to make there at this point, since this is an uncommon circumstance and has risk of introducing regressions for the common circumstances.
Can someone kindly review the PR before it's again too late even for 2.4?
- Status changed from Confirmed to Feedback
- Assignee set to Renato Botelho
- % Done changed from 0 to 100
PR has been merged, thanks!
- Status changed from Feedback to Resolved
- Target version changed from 2.4.0 to 2.3.4-p1
- Status changed from Resolved to New
- Target version changed from 2.3.4-p1 to CE-Next
I've reverted this change in order to fix #11005. A new approach should be used for that case
- Status changed from New to Resolved
- Target version changed from CE-Next to 2.3.4-p1
Patch was re-applied and this ticket remains the same
Also available in: Atom
PDF
Updated by 
Updated by Kill Bill 
Updated by 
Updated by