Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Homenet hostnames stop working when ISP is disconnected #4

Open
toreanderson opened this issue Nov 18, 2015 · 2 comments
Open

Homenet hostnames stop working when ISP is disconnected #4

toreanderson opened this issue Nov 18, 2015 · 2 comments
Assignees

Comments

@toreanderson
Copy link

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):

  1. An DHCPv6 IA_NA-assigned address from the ISP prefix (let's assume 2001:db8::547)
  2. A SLAAC-assigned address from the ISP prefix
  3. A SLAAC-assigned ULA address
  4. 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.

@fingon
Copy link
Collaborator

fingon commented Nov 20, 2015

This is odhcpd bug (hnetd ULAs will not get given to clients currently if GUA is up); will be fixed sooner or later by sbyx (assigned).

@toreanderson
Copy link
Author

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants