How to ensure the Public Homenet Zone remains resolvable from Homenet Devices in the event of temporary loss of connectivity

[v6ops]

We don't want to replace internal names

But If I've configured an application on my laptop to use a name for mylightbulb.shed.rayshouse.org I'd still want to be able to resolve it if the laptop is connected to WiFi, even when the Internet link is down.

There's a few implementation details to consider for this: 1) how does my laptop resolve in the Homenet? Does it use a recursive resolver on the closest Homenet e.g. CPE2? Out of scope? 2) How does the recursive resolver running on Homenet CPE2 or my laptop know that Homenet CPE1 actually can resolve the name (CPE1 is a hidden master, and has no NS record in the Public Homenet Zone). Distribute a DNS forwarder to all Homenet CPEs via HNCP? 3) How does the recursive resolver on CPE2 or my laptop contact CPE1? (the server on CPE1 would typically bind to the WAN interface, which may be down). If it also binds to the internal LAN interface(s) on port 53 would that impact the internal naming service? (Maybe suggest assigning a dedicated loopback interface for the DNS server serving the Public Homenet Zone that can move between CPE devices on failure? That would also mean the AXFR and firewall config wouldn't have to change in the event of failover of ISP) Same DNS server process for internal and public names? What about the HNCP election then if there's 2 ISPs? 4) How to ensure any related records (required for DNSSEC) are cached?

[mcr]

I'm confused by the "still want" wrt WIFI. Is the alternative to WIFI, wired, or LTE?

If the laptop is typical stock, then it uses the DNS server that DHCP told it, which is on a CPE. I think that DNSSD makes this requirement stronger, and I'm sure that (MIF) provisioning domains also does that. (I think that provisioning domains is entirely IPv4 think, and that IPv6 should never need them)

Re: point 2. That's a good question. I think that we should take it to the WG. I think that point 4, about the records seems easy to me. But, maybe it's really about having CPE1 and CPE2's recursive resolver be aware of the public homenet zones, and aggressively cache them.

[v6ops]

I'm confused by the "still want" wrt WIFI. Is the alternative to WIFI, wired, or LTE?

I'm presuming my laptop is mobile, and I want to control the lamps using the same FQDN whether the laptop is at home or at work.

Wifi at work outside the Homenet (with Internet access) would be the alternative to wifi at home.

Obviously the laptop would always be able to resolve some GUA address at work, but the lamp itself might be temporarily unreachable if the associated ISP link is down. The results of any cached queries would also remain valid over moves of the laptop between networks.

If the laptop has a wifi connection in the Homenet, and the lamp also has the same wifi connection, but the upstream ISP link is down, I don't want resolution for the GUA to fail just because the upstream ISP connection is down. [I'm presuming that the GUA for the lamp will still remain valid for some time after the ISP link goes down due to the lifetime associated with the IA-PD lease and it won't get flushed from HNCP immediately.]

[mcr]

v6ops notifications@github.com wrote:

If the laptop has a wifi connection in the Homenet, and the lamp also has the same wifi connection, but the upstream ISP link is down, I don't want resolution for the GUA to fail just because the upstream ISP connection is down.

I agree strongly. Should we collect these things explicitely as requirements?

> [I'm presuming that the GUA for the lamp will still remain valid for
> some time after the ISP link goes down due to the lifetime associated with
> the IA-PD lease and it won't get flushed from HNCP immediately.]

Yes, I think that's reasonable.

-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

[mglt]

I would say that the document is mostly about outsourcing the homenet zone, that is moving the zone associated to the homenet to another provider. That the resolver can find the content of the homenet zone on the internet or in a more appropriated place is the purpose of the resolver or the naming architecture for the homenet zone. On the one hand, I believe that if we would like to remain resilient to internet disruption, the authoritative service may be provided within the homenet. This would mean that the Hidden master may have a internal secondary in the home. With two authoritative servers inside and outside the homenet, resolution should covered all situation. One downside is that we do not expect the internal secondary to be reachable from the outside which means that NS records may be different on the internet and on the homenet. I believe that such configuration is not a good idea as internal addresses may have the same value over different networks. Instead I would rather use HNCP to announce that an internal authoritative server is serving the zone within the homenet. This is what I think is happening when an authoritative server served .home.arpa.

The resolver should in my opinion should configure these domains and internal authoritative server as forwarders. But I believe that is in the scope of the naming architecture.

[mcr]

1. When CPE1 loses its uplink, and thus the PD becomes useable to outsiders, should CPE1 change it's zone AAAA records come from CPE2? i.e. foo.danielhome.example IN AAAA 2001:db8:1234::12 ; "ISP1234" IN AAAA 2001:db8:8765::12 ; "ISP8765" when ISP1234 link is down, should it remove ISP1234 AAAA record? What is the TTL of these records? Are they related to the DHCPv6-PD Lifetime?

2. If CPE1 and CPE2 be configured to be a hidden master for the same zone, would be have an election, ? NO, not in this document.