Comment by cyberax
17 hours ago
OK, do you _think_ my questions were that easy?
> Advertise the addresses offered by the primary uplink, then retire those addresses
Prefix withdrawal doesn't work reliably on Android. And neither is it required to work, btw. Neither does this solution allow for load balancing, as all traffic will just go through one connection.
Bonus points: triangular routing to your local NAS through the router.
> How do you prevent your printer from "breaking" when its ISP-provided DHCP lease on its globally-routable IPv4 address expires? How about when the ISP refuses to renew the lease on the printer's current globally-routable IPv4 address and forces it to get a new one?
Printers get an RFC1918 address and don't care about global connectivity.
> How to solve this with IPv6? Use ULAs! They're the equivalent of 1918 space in the IPv6 world.
They're not. IPv6 is nothing like IPv4 operationally. Back to my challenge, ULA will NOT work.
The scenario is very simple: the printer gets a ULA prefix and a GUA prefix. Your computer also gets a GUA and a ULA from the same router.
So far so good.
Now the uplink goes down, and the router withdraws the prefix. The printer sees the withdrawal and removes its GUA address. Your computer misses it, and still has the GUA and the ULA addresses.
Whoops. The printing is now broken somehow. Why?
> Prefix withdrawal doesn't work reliably on Android.
Works fine on the Android hardware I have. Are you attempting to retire prefixes that have an infinite lifetime? That doesn't work, and I don't think it's supposed to work.
> Neither does this solution allow for load balancing...
As I said
> Printers get an RFC1918 address and don't care about global connectivity.
Okay, so why are you complaining about your printer being broken by GUAs that you're not permitting it to have? ;)
> IPv6 is nothing like IPv4 operationally.
For anyone who's not an IP stack developer, network hardware developer, or Enterprise sysadmin it absolutely is. And other than the fact that every endpoint is able to get a global address in v6, the sysadmin-visible differences between v4 and v6 are minor. RAs instead of... well, nothing, and DHCP for both.
> Whoops. The printing is now broken somehow. Why?
Exactly.
Why isn't your DHCPv6 server putting either both the GUA and ULA, or -better- only the ULA addresses in your LAN's DNS server? This Just Works™ on dnsmasq, which is one of the most widely-deployed DNS+DHCP servers on SoHo gear. [0] dnsmasq's default TTL for hosts added to the DHCP lease file appears to be 0, so -worst case- your sleepy computer tries to continue its conversation with the printer a couple of times, does ND and discovers that the IP it was using is gone, then looks up the hostname again and gets the new address of the printer. I think the trendy term for this back in the 2000s was "self-healing".
If you're going to retort "But we don't use dnsmasq in the companies I'm sometimes talking about!"... well, if you can't figure out how to not register upstream-controlled GUA addresses for your LAN hosts in your DNS, then do what dnsmasq does and serve them up with a TTL of 0.
[0] To head off the "Android doesn't really do DHCPv6" retort: Even though Android refuses to use anything other than DHCPv6-PD for managed address assignment, -AFAIK- Android still sends DHCPv6 ADDR_REG_INFORM messages for addresses it autogenerates on networks with either the "OtherConfig" or "Managed" flags set. I haven't bothered to set up my Linux systems to do this, but I'd be surprised if Windows and Darwin systems didn't do this.
> Why isn't your DHCPv6 server putting either both the GUA and ULA, or -better- only the ULA addresses in your LAN's DNS server?
I don't have a LAN's DNS server or a DHCPv6. BTW, I have had an IPv6-only home network for 10 years, with NAT64 and 464XLAT.
You still haven't solved my puzzle or even understood what's happening. The current source address selection rules result in hosts prefering a GUA address pair over ULA. This _will_ result in broken connectivity when GUA addresses change.
There is currently no standards-compliant way to solve my challenge, except getting an ASN, an IPv6 assignment, and announcing it through your uplinks. Which I've also done in my home network, btw.
There's an in-progress RFC to change this, by preferring ULA-ULA address pairs over GUA-GUA. So it might be usable some time in the 2030-s ( https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda... ).
And no, this is not a theoretic problem. It affects protocols like SIP or even mDNS that exchange the IP addresses. They will consistently prefer unstable GUAs over ULAs.
> I don't have a LAN's DNS server or a DHCPv6.
Yeah, that's why you think that this is a "puzzle".
Though, it does invalidate every complaint you've made about IP source address priority. The only ways you'll get multiple addresses for a given host are to either hard-code them, or use DNS [0]. Given that you're not using DNS, then you either have automation to update all those hard-coded configs, or you do it all by hand. Either way, you're deliberately recording addresses that you don't control for your LAN hosts, and considering it a "puzzle" when you have trouble reaching those LAN hosts when your upstream provider changes their address.
[0] Given that every resolver I've ever used pulls data from '/etc/hosts', I'm considering that to be part of DNS for the purposes of this conversation. I'm also considering Avahi and friends to be DNS. [1]
[1] And if you've talked to any long-term Avahi user, you've certainly heard about its habit of -on daemon or host restart- erroneously considering host name of the machine it's running on to be "in use" and appending a "-N" to the end of it. The remarkable eagerness of Avahi to engage this collision-avoidance mechanism makes it entirely unsuitable for discovery of LAN hosts whose hostname is actually important. This fact breaks my heart, but Avahi has been doing this shit for a very, very long time, so it's probably never going to get fixed.
2 replies →