Hello Brian,
Example: if an Ethernet Join Proxy tries mDNS to discover a
Registrar, but the Registrar is only announced via the site DNS
infrastructure (unicast), then discovery would fail.
Isn't that entirely dependent on whether the name is in .local or not?
In any case it's an issue about what sort of resolver the pledge has,
surely? And isn't this something that DNS-SD is supposed to take care of?
Yes, DNS-SD is supposed to take care of that: the Join Proxy (JP) would
first use a unicast DNS-SD query to discover the list of browsing
domains. The returned list of domains is then used to do queries (PTR)
for services of type "Registrar" in each of these domains. The list of
domains can include "local." if that's configured by the DNS admin. That
would tell the device to also discover/browse in the "local." domain.
So initially a device wouldn't know which domain to use for browsing,
but that can be discovered (even multiple). And if browsing domain
discovery fails, it could always fall back to "local.".
For constrained devices the above is typically not how things work,
however. E.g. devices not related to BRSKI currently, Thread Border
Routers, will default to mDNS / *.local. discovery for peer services and
not bother to do the browsing domains discovery. I assumed something
similar could happen with Ethernet Join Proxy implementations unless
some specification clearly mandates they need to follow the above
procedure. Or vice versa, someone only implements unicast DNS-SD
discovery on a device and that doesn't even have an mDNS implementation
on board - which is a lot of extra code, it's a protocol in its own right.
So this is an issue about what sort of resolver(s) the Join Proxy has
implemented. (For a Pledge, I assume mDNS would be the default way
because a Pledge doesn't have a known+accessible DNS server to use.)
BTW, the reason that GRASP has its own discovery mechanism via
link-local IPv6 is to avoid any dependency on DNS or mDNS, so that it
can run on bare metal. Thus, GRASP runs on bare 802.3 if you want it
to; it doesn't really *need* an ACP except for security. I have no
idea whether it could run on Thread and 6TiSCH.
Agree, GRASP could work outside of an ACP - it could be run inside a
Thread network, which provides the security 'substrate' that the GRASP
RFC 8990 requires. But in the Thread case there's already unicast DNS-SD
(plus SRP for service registration as Stuart mentioned), so it would be
not necessary to also add GRASP. Unicast was selected for better
network performance (avoid query flooding etc). For (high-speed)
Ethernet this is less of a concern.
That said, I see a role for profiles.
Each "profile" would probably need to be a standard (defined outside
IETF) or an RFC.
I think they could be less formally defined than that, at least
initially.
Ok, maybe then just in an Appendix in the BRSKI-discovery draft? To get
an initial view of what we mean and what choices can be made to get
interoperable implementations.
thanks
Esko
Regards/Ngā mihi
Brian Carpenter
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
