I would like the server of my backend to point to a link-local IPv6 address (something like [fe80::020a:14ff:febe:36f8]). Like that I could reach a device on the local network, not having to care about it’s IPv4 configuration. However it doesn’t seem to work (I get a 503 service unavailable). With other IPv6 addresses for the same device (in my case [fd00:dead:beef:0:20a:14ff:febe:36f8]), all is fine, so it’s not a problem of IPv6 in general. I found a bug of wget here. It says there, that for link-local IPv6 addresses, the interface has to be specified and wget doesnt support that. Could this be the problem in HAProxy as well or can i do that somehow? Adding %eth0 sadly didn’t do the job.
Thanks a lot for any input
1 Like
It’s a terrible idea to use link-local IPv6 addresses for services. Please always use ULA’s in IPv6 for those use-cases.
Ok. Could you tell me what the reasons are?
We have ULAs working but here is why we thought link-local addresses would be cool:
We have HAProxy running on our embedded controller for home automation. We send some DALI (thats a light control protocol) gateways to the client and we dont know what kind of network setup he has. However we can connect to our controller remotely. With link-local addresses we could always reach the web-interface of that gateways (if they are in the same network) by just knowing the mac addresses: we binding a frontend to some port of our controller and set the backend server to the link-local address of the gateway. This I can even prepare upfront and my colleagues who dont know how to configure HAProxy have access right away.
ULAs work as well but its more complicated since i have to scan for ULAs on the network and find the one the gateway got by checking which mac address has which ULA first. Then i can set the server of my backend.
Or do you have a better solution for that scenario?
Thanks a lot
Well I was thinking about the normal use-case of a web server and haproxy load-balancing in front of it. In that case, you will always want a static setup, in IPv6 with ULA (or even global unicast), simply because you are setting it all up statically anyway.
Your use-case is exactly the opposite, so I can see how that makes sense for you.
I just checked both haproxy and nginx, they don’t support using link-local IPv6 addresses, because it requires additional magic around parsing the IPv6 address in the first place, finding the integer for this string ( if_nametoindex()) and finally setting the scope_id.
(more about link local socket impacts https://labs.ripe.net/Members/philip_homburg/whats-the-deal-with-ipv6-link-local-addresses )
Those are not bugs, those are simply additional features that are not implemented in most applications, because link-local addresses have a very limited use-case.
As a porter of software from ipv4 to ipv6 world, the real problem is parsing of addresses.
Way before 2000 the IPv6 API was pretty good: use getaddrinfo, and that’s it.
This has been described in rfc2133 from 1997.
But what happened then is that everybody started to copy code that was from before 1997, and made their own parsers.
If you hand over the parsing to getaddrinfo you are all set.
So most of the code today can not handle IPv6 link local because of not using getaddrinfo, and making their own parsers (i.e. based on software that was officially made obsolete by the POSIX standard 18 years ago I think)
Now back to haproxy: I imagine that haproxy has a more specialised approach of keeping addresses. And this is probably not compatible with the objects returned by getaddrinfo.
In my case I use socat between haproxy to bootstrap configuration of equipment. So I use socat to tcp proxy to the (Fixed EUI64) ipv6-ll of the equipment until I can configure an IPv4 that’s good for that network.
And when somebody moves the equipment, I lose access until I reconfigure it, either by telnet or by using socat again so I can reconfigure the IPv4.
ULA’s and GUA’s are in the hands of the local network maintainer. Advertising ULA or GUA is opening another can of worms.
(To be fair: socat is a wonder tool, doing everything right.)
Using link scope (or link local) IPv6 addresses for the backend servers in an HAPorxy setup would be a great use of link scope. This increases security, ease of use and reliability. The fact that the address is built around the MAC address makes the address predictable too, which contribute to the easiness.
Now, some may argue that managing MAC addresses is a pain. Not really as sen with garcol’s scenario. And, if it is a problem, then using mDNS solves it!! It tested it using ssh with success.
I suggest filing a feature request: