You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My ISP did maintenance today. That essentially broke internal communication in my homenet. I'll try to explain what happened below.
Background: My ISP provides native dual-stack. So normally, a host is assigned with a total of four addresses (ignoring link-locals and privacy extensions):
An DHCPv6 IA_NA-assigned address from the ISP prefix (let's assume 2001:db8::547)
A SLAAC-assigned address from the ISP prefix
A SLAAC-assigned ULA address
A private IPv4 address out of 10.0.0.0/8
In the normal situation, the host's host.port1.rtr1.home. name resolves to two of the above (1 and 4).
However, when the uplink to the ISP goes away, things start happening. The ISP-assigned IPv6 prefix is deprecated, and IPv4 stops working completely. Furthermore, the AAAA record of host.port1.rtr1.home. changes from 2001:db8::547 to an ULA address like fd00::547 - which isn't assigned to any local interface on the host at all. I assume that this address is the one the host would end up receiving if it were to restart its DHCPv6 client, but this doesn't happen automatically just because the ISP was disconnected.
This means that any attempt to contact host.port1.rtr1.home. from another host somewhere else in the homenet ends up failing while the ISP link is down.
I assume avoiding this situation is precisely the reason why ULAs are used in the first place. However, I think that in order for this to actually work, the IA_NA handed out by the DHCPv6 server probably needs to be from the ULA prefix even though the ISP connection is up, so that it will continue working after an ISP is down.
The text was updated successfully, but these errors were encountered:
After having been a Hnet user for half a year or so, I've come to the conclusion that I really, really, want the internal .home hostnames to resolve only to the ULA addresses of the nodes. (In addition to the RFC1918 addresses, if IPv4 is enabled.) I do not want them to resolve to GUA addresses delegated from the upstream ISP(s).
The reason for this is simply that the ULAs are stable (assuming a workaround/fix for sbyx/hnetd#52 is in place), while addresses from a delegated ISP prefix are not. When the hostnames are used for tasks such as mounting a shared filesystem from a NAS appliance, it does not really help that the hostnames are updated the moment the delegated prefix changes either, because the mount is anchored in a defunct address.
(Of course, this presumes that ULAs are enabled in the first place.)
My ISP did maintenance today. That essentially broke internal communication in my homenet. I'll try to explain what happened below.
Background: My ISP provides native dual-stack. So normally, a host is assigned with a total of four addresses (ignoring link-locals and privacy extensions):
In the normal situation, the host's
host.port1.rtr1.home.
name resolves to two of the above (1 and 4).However, when the uplink to the ISP goes away, things start happening. The ISP-assigned IPv6 prefix is deprecated, and IPv4 stops working completely. Furthermore, the AAAA record of
host.port1.rtr1.home.
changes from 2001:db8::547 to an ULA address like fd00::547 - which isn't assigned to any local interface on the host at all. I assume that this address is the one the host would end up receiving if it were to restart its DHCPv6 client, but this doesn't happen automatically just because the ISP was disconnected.This means that any attempt to contact
host.port1.rtr1.home.
from another host somewhere else in the homenet ends up failing while the ISP link is down.I assume avoiding this situation is precisely the reason why ULAs are used in the first place. However, I think that in order for this to actually work, the IA_NA handed out by the DHCPv6 server probably needs to be from the ULA prefix even though the ISP connection is up, so that it will continue working after an ISP is down.
The text was updated successfully, but these errors were encountered: