On Mon, Feb 19, 2024 at 8:08 AM Hunter Fuller <hf0002+nanog@uah.edu> wrote:
On Mon, Feb 19, 2024 at 9:17 AM William Herrin <bill@herrin.us> wrote:
There's also the double-ISP loss scenario that causes Joe to lose all global-scope IP addresses. He can overcome that by deploying ULA addresses (a third set of IPv6 addresses) on the internal hosts, but convincing the internal network protocols to stay on the ULA addresses is wonky too.
In the real world today, most applications seem to use mDNS and link-local addresses to keep this connectivity working. (I am guessing Joe's Taco Shop uses something like Square, and just needs his register to talk to his printer. This already works with mDNS and link-locals today.)
Hi Hunter, Yes and no. The client application has to be programmed to understand link-local addresses or it can't use them at all. You can't just say "connect to fe80::1." Even if there's an fe80::1 on your network, it doesn't work. The client app has to also carry the interface identity into the stack (e.g. fe80::1%eth0) in order to use it. IPv6 link local addresses can't be expressed as a regular DNS target the way ULA and RFC1918 addresses can. No way to add that "%eth0" to the AAAA record. They only work with multicast DNS because the matching interface is known based on which interface was used to send the multicast query. And of course link local is -strictly- link local. If you want one subnet to communicate with another, you have to do it with global scope or ULA addresses. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/