Juliusz Chroboczek <j...@irif.fr> writes: >> In the current implementation, a single daemon per registration zone. > > Right. Either it could be elected by HNCP, or the daemons could run an > election among themselves.
Yeah, this makes sense if this mechanism is also used inside the homenet (to register under dot-home, say). For a globally visible zone (where you'd presumably only install globally routable addresses) the daemon could also be outside the homenet. >> The client will query for a SRV at _nsreg._tcp.<zone> to find the >> daemon, which can be anywhere, in principle (the daemon will only speak >> TCP and limits initial registration to a list of configured subnets; I'm >> currently running mine on a separate server rather than on my router). > > Makes sense. The list of prefixes could be configured by HNCP. Yup. >> I punted somewhat on how to discover the zone; the client will currently >> take it as a command line parameter. But figure that can be distributed >> via DHCP/RA? > > Or put it in DNS under dot-home? Since the client already knows how to > speak DNS, this avoids yet another coupling between protocols. Ah yes, that makes sense; since we have a domain that always refers to the homenet, just define a name under that that will return PTRs to the zones available for registration. >> In principle, there's nothing preventing the daemon state from being >> replicated across the homenet routers, I suppose... > > I think it's more complicated and more fragile than having an > election. I'm not too keen on adding another flooding protocol to the > Homenet stack. I said it's possible in principle. I didn't say it was a good idea... ;) -Toke _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
