Comment by simoncion
16 hours ago
> 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
Or are you talking about load balancing, which is its own thing? Either way, this situation is inherently *not* boring, so the way you solve it is going to be quite a bit more complex -regardless of IP protocol version- than the very boring single-upstream situation.
> 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.
> The only ways you'll get multiple addresses for a given host are to either hard-code them, or use DNS
mDNS exists. As does SIP and SMB.
I first discovered the ULA/GUA issue when my TimeMachine backup dropped mid-session when I was testing Internet connection failover. Apple later fixed it by allowing multiple SMB sessions in parallel and preferring IPv4 connections. I have a pure IPv6-only network, as I said.
The same issue happens with SIP, as phones send their own addresses during the media connection negotiation.
(I have another funny story about SIP: Asterisk used to send a Cartesian product of available codecs and IP addresses, so if you had IPv6 privacy addresses on, it eventually accumulated enough of them to overflow the MTU, causing connections to silently drop)
1 reply →