pfSense

I found that the interface_track6_configure() function switches original link-local address to fe80::1:1
Why do we need to remove the original local-link address?
What if we add fe80::1:1 as an alias?

Once upon a time we started using fe80::1:1 as a predictable local address sort of like 192.168.1.1, but I don't think it ever really worked like we wanted. Browsers won't properly connect to scoped link local addresses, so most of the point of it is moot. We can probably remove any references to fe80::1:1 in the code at this point.

To review that properly for inclusion, it must be submitted as a pull request on Github: https://docs.netgate.com/pfsense/en/latest/development/submitting-a-pull-request-via-github.html

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

Feedback/QA - I've upgraded to 2.5.0-DEV current (2020-01-17 build), and everything is working as intended. Thanks.

Isn't it a potential issue when you use a fixed ip such as fe80::1:1 that another router or host has already claimed this ip?

Shouldn't it go through the neighbor discovery process for it's link local address?

I could envision 2 pfsense routers connected to the same interface, each have separate WAN interfaces and different Prefixes for redundant paths. If they are both trying to use fe80::1:1 it would fail I would assume.

This configuration is a perfectly valid configuration for ipv6.

(1) Rick - there is no WAN interface taking the alias fe80::1:1 -- its only on the IPv6 LAN interface. none of the routing advertisements on the LAN would be using it actually, if you review the PDF attached.

(2) On a WAN IPv6, yes there might be some issues doing the same, but that is not the situation with this alias as its only LAN. This is not done on all interfaces.

(1) The 1-liner mwexec setting the LAN link local alias can likely removed, yes. Services are actually using the link-local IP, which were not starting up on boot because of the old redefinition of the link-local, which is the reason for the bug. Since I dont have a full suite of component and unit test, the patch file supplied to you made the additional LAN6 alias.

He's talking about two routers attached to the same LAN, not WAN. For example, an HA pair. Or a case where you have a separate router for another purpose (e.g. dedicated VPN router or using another circuit isolated to its own router for whatever reason).

(4): HA comment: If you are using a HA pair, yes, they'd both have the same hard-coded alias, so that would seem problematic. That would happen with the old code base using the hard-coded link-local, and with the patch/fix supplied as well (same BEFORE/AFTER).

(5): Service/Socket Bindings (CORE ISSUES OF BUB): What is needed is to have the auto-assigned link-local used, as the FreeBSD kernel/IP stack is now designed to do. Outlined fully in write-up. It looks like the whole commit was reverted, which does not solve the issue for DHCPv6 and DNS services configuration. The fix without the IP alias or link-local redefinition to fe80::1:1 statement is needed.

Jim Pingle wrote:

He's talking about two routers attached to the same LAN, not WAN. For example, an HA pair. Or a case where you have a separate router for another purpose (e.g. dedicated VPN router or using another circuit isolated to its own router for whatever reason).

This is what I am talking about, internal side of the network where you have more than one router on a network link.

So this is an existing implementation issue that also affects those trying to use multiple prefixes in a single subnet. I am thinking especially those trying to use ULA in combination with GUA addresses for critical items such as dns servers where the ISP providers change prefixes.