Managing link-local address
-
Is it possible to manage the link-local address for an interface?
In particular, I was wondering about using a link-local address of fe80::1 instead of a SLAAC address. The reason that I am looking at this is
- to allow the default route could be set the same in all subnets
- to allow the pfSense hardware to be swapped out without affecting client configuration
I see a lot of posts where pfSense has chosen fe80::1 on an interface, but haven't found an explanation of what selects it.
Is using fe80::1 as a default route a bad idea?
Appreciate any guidance. Thanks.
-
You seem to be answering your own questions.
fe80::1 is a good choice because it IS the same on all subnets, and it DOES allow the pfsense hardware to be swapped out without affecting the client configuration.–A.
-
Is there a way to configure pfSense to use fe80::1 for the link local address?
fe80::1 is a good choice because it IS the same on all subnets, and it DOES allow the pfsense hardware to be swapped out without affecting the client configuration.
-
Is there a way to configure pfSense to use fe80::1 for the link local address?
No. The same IP can't be assigned to multiple interfaces.
Not sure what problem that would be solving. Hosts with static gateways configured are going to have static IPs and a gateway within your public IPv6, not link local, so it's not hardware-specific. Everything that's dynamic will pick up the new IP immediately in the hardware swap scenario.
-
The problem being solved is that some devices require that the default route be a link local address, and will not accept a publicly routable address as the default route. Synology NAS devices are an example of this.
Using fe80::1 as the default route appears to be a strong trend, particularly for static subnets because it greatly simplifies deployments. There is a good write up about it here:
https://www.edge-cloud.net/2013/08/ipv6-link-local-addresses-as-default-gateway/
This also appears to be a "best practice" recommended by networking vendors such as Cisco.
FreeBSD itself appears to support it. From rc.conf man:
A link-local address can also be configured manually. This
is useful for the default router address of an IPv6 router so
that it does not change when the network interface card is
replaced. For example:ifconfig_ed0_ipv6="inet6 fe80::1 prefixlen 64"
https://www.freebsd.org/cgi/man.cgi?query=rc.conf&sektion=5&manpath=FreeBSD+10.2-RELEASE
-
At the moment pfSense sets the link local address of a 'Track interface' interface (i.e. interfaces set up via DHCP-PD) as fe80::1:1. It does not otherwise interfere with link local interfaces or expose any way to set them, so the automatically set value based on the MAC address of one of the interfaces is used (see sections 2.5.1, 2.5.4 and Appendix A of RFC 4291).
Manually setting link local addresses can permit foot shooting - though is still compliant with RFC 4291 to my reading so long as the 'global' bit is set to 0 (the global bit appears at 0200 in the fifth group of eight). In the 'Track interface' scenario, pfSense knows it is responsible for setting the addressing on the subnet. In a static IP scenario, this is not the case.
The question is why you need to set the default route. Can RA, which advertises a route using a link local address, not be used to allow discovery of the default route in your scenario?
-
The problem being solved is that some devices require that the default route be a link local address, and will not accept a publicly routable address as the default route. Synology NAS devices are an example of this.
Why don't you report this to Synology to get such obvious bug fixed?
-
Honestly, because I don't believe that requiring a link local address for the default route is a bug. In fact, if I were to take a strict and narrow view, I would have to view accepting a non link local address for a default route as a bug. RA packets, from which hosts are intended to build default router lists, are inherently link local addresses.
The problem being solved is that some devices require that the default route be a link local address, and will not accept a publicly routable address as the default route. Synology NAS devices are an example of this.
Why don't you report this to Synology to get such obvious bug fixed?
-
The use of a link-local address as the default gateway address is a good idea, specifically, because if you are using a global unicast address, it could change; DHCP renewal, different ISP, etc.
Sadly there doesn't appear to be any clear guidance in the RFCs about this, so vendors have implemented it as they see fit.That being said, if your prefix changes then your connected device's prefix must also change, via RA and/or DHCPv6. Also the same logic behind the reason that there is no default gateway option in DHCPv6, and why it makes sense to use a link-local address.
Ultimately, IMHO, the logic behind ALL of this is faulty at its core…as there are enough IPv6 addresses for every grain of sand on the planet, why not just give every human a /56 to do with as they please, instead of ARIN et.al charging $ for them...And they wonder why IPv6 adoption is slow...but I digress... and yes I know it would cause a routing table nightmare.
--A.
-
Good question. Again, I will point to my poster child, Synology. However it should be noted that both Windows and Mac also invite you to explicitly set the default router if you choose a static IPv6. I expect we will see this with many other systems as well. This is one of the reasons behind the fe80::1 proposal above.
The configuration approach they have is that if you are manually configuring IP, then you should provide all configuration information needed for basic operation (address, prefix, default route, dns server). One could take the position that requiring anything beyond the address and prefix is unnecessary as this information should be received via RAs.
However, I can think of a few of reasons why they would take the approach they have. First, they may wish to be functional in the absence of RAs. This may be a bit of a stretch, but what if the network admin disables them? What if there is a bug in the router? I understand vendors not wanting to stop working for mysterious reasons. Second, they may wish to allow explicit (local) setting of the default router preference or order. Is it reasonable to allow this? One can make arguments either way, but many systems are supporting it.
The third reason that comes to mind is "Why not? We support explicit settings with v4, so why shouldn't we support them with v6?" It is this reason that I expect to come up over and over again. You might call it conservatism, or you might call it laziness, but it's going to happen and we will have to deal with it.
Using fe80::1 as the default route for all subnets seems to be a reasonable approach that covers both dynamic (RA) and static configurations.
The question is why you need to set the default route. Can RA, which advertises a route using a link local address, not be used to allow discovery of the default route in your scenario?
-
Honestly, because I don't believe that requiring a link local address for the default route is a bug. In fact, if I were to take a strict and narrow view, I would have to view accepting a non link local address for a default route as a bug. RA packets, from which hosts are intended to build default router lists, are inherently link local addresses.
I agree it's a bug in the Synology. You're combining two entirely separate things there, dynamically addressed hosts are different from static. RAs have no relation, generally, to static IP hosts.
The use of a link-local address as the default gateway address is a good idea, specifically, because if you are using a global unicast address, it could change; DHCP renewal, different ISP, etc.
If you're using IPv6 space that could change, you shouldn't be putting static IPs on systems and hence will not configure a static gateway IP at all.
Allowing setting of the link local address is something to consider, but I still don't see where it's helpful outside of a Synology bug.
-
@cmb:
Honestly, because I don't believe that requiring a link local address for the default route is a bug. In fact, if I were to take a strict and narrow view, I would have to view accepting a non link local address for a default route as a bug. RA packets, from which hosts are intended to build default router lists, are inherently link local addresses.
I agree it's a bug in the Synology. You're combining two entirely separate things there, dynamically addressed hosts are different from static. RAs have no relation, generally, to static IP hosts.
The use of a link-local address as the default gateway address is a good idea, specifically, because if you are using a global unicast address, it could change; DHCP renewal, different ISP, etc.
If you're using IPv6 space that could change, you shouldn't be putting static IPs on systems and hence will not configure a static gateway IP at all.
Allowing setting of the link local address is something to consider, but I still don't see where it's helpful outside of a Synology bug.
You're right that one shouldn't be putting static IPs on systems if the prefix is likely to change, I'd really like to see entering addresses as ::AAAA:BBBB:CCCC:DDDD/64 so that it can be prefix independent, but I digress.
Since each and every IPv6 device MUST have at least a link-local address (fe80::/10), then it stands to reason that irrespective of what global address is acquires at any point in the future, if it uses the a link-local address as a default gateway, it will retain connectivity, even if the only connectivity required is outbound.
–A.
-
I don't believe that I'm conflating the two things. RAs provide neighbor discovery for routers regardless of static or dynamic addressing. It is entirely acceptable to use a static host address with no specification of a default route, and have the routing table determined via solicitation or RAs. This works with Linux and Apple at a minimum (I haven't tested Windows).
You could argue that it's a bug that Synology requires a default route when setting a static address. But requesting input of a default route appears to be pretty common practice. Microsoft and Apple at a minimum do this. And if you do put in a default route that is not link local, you still end up being dependent upon RAs or solicitation to find out how to get to the default route. In short, you are dependent upon link local for your first hop regardless.
Using fe80::1 as the default route makes a lot of sense to me. It seems to make sense to a lot of others given the number of people/orgs recommending this as a best practice. As the underlying OS supports it, I don't see a reason not to allow its use.
@cmb:
Honestly, because I don't believe that requiring a link local address for the default route is a bug. In fact, if I were to take a strict and narrow view, I would have to view accepting a non link local address for a default route as a bug. RA packets, from which hosts are intended to build default router lists, are inherently link local addresses.
I agree it's a bug in the Synology. You're combining two entirely separate things there, dynamically addressed hosts are different from static. RAs have no relation, generally, to static IP hosts.
-
Right. Sticking fe80::1 on every interfaces out there is best practice… OK. Good luck with this approach. Meanwhile, it works just for everyone without any similar nonsense.
-
Thanks Dok. As always, your heartfelt well wishes are greatly appreciated.
;)
Good luck with this approach.
-
I don't believe that I'm conflating the two things. RAs provide neighbor discovery for routers regardless of static or dynamic addressing.
No, neighbor discovery is via neighbor solicitation where you have a static gateway configured. Link local not involved at all either. For instance:
20:37:26.023291 IP6 fc00:160:11:33::230 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fc00:160:11:33::1, length 32 20:37:26.221249 IP6 fc00:160:11:33::2 > fc00:160:11:33::230: ICMP6, neighbor advertisement, tgt is fc00:160:11:33::1, length 32Using fe80::1 as the default route makes a lot of sense to me. It seems to make sense to a lot of others given the number of people/orgs recommending this as a best practice.
Who/where do you see it being recommended as a best practice? I've yet to see that from any official source, and very few random people on the Internet. The references to it are fraught with issues of devices that won't let you configure a link local gateway IP at all. That's a bug in the opposite way the Synology has a bug here, but still.
-
An easy one to point to is Cisco. fe80::1 is used as the default route in their IPv6 Network Fundamentals book. And in several of their test prep books.
If you google for "fe80::1" default route and read through a few pages, you will find lots of occurrences of people using this approach, ranging from universities to hosting groups.
Another good example of how common a solution this can be viewed as is Docker. If you enable IPv6 in Docker, fe80::1 is your default route. You can override it, but it's the default.
Different people have different views on best practice. And even the most stringent will generally agree that there is no best solution for all environments. There are always trade offs to be made, and this is one of those things. I believe it is a good idea to make the link local address configurable in the future as other network elements have done.
For my purposes I've moved ahead with using RAs for default route (except for Synology of course).
@cmb:
Who/where do you see it being recommended as a best practice? I've yet to see that from any official source, and very few random people on the Internet.
The references to it are fraught with issues of devices that won't let you configure a link local gateway IP at all. That's a bug in the opposite way the Synology has a bug here, but still.
-
Technically, there is no limitation to the number of interfaces that a system can have with the same link-local IP. https://tools.ietf.org/html/rfc4007#section-5
This is because the interface's name must appear in it's use in order to select it.ie: ping6 fe80::dead:c0de won't work because it won't know what interface to use. You must use ping6 fe80::dead:c0d%em0.
That being said, FreeBSD 10.2 is perfectly happy with 3 interfaces configured as fe80::1, besides lo0 is also fe80::1.
