[Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes)

[Michael Richardson <[e-mail]>]

peter van der Stok <[e-mail]> wrote:
    > We just did our own mDNS (students did years ago) and have no
    > experience with
    > existing code.
    > What was the precise question?

It's a good question. What *IS* the question :-)

We have had the discussion about use of GRASP M_FLOOD vs mDNS for discovery
of the Join Proxy by the pledge.   We have had some indirect feedback
("heresay") from implementers to the effect thta the M_FLOOD stuff
"is IETF ivory tower nonsense, and we should stop inventing new vanity
protocols."

(paraphrased, and unattributed.  Sorry Brian: not my words, and I'm relaying
them third or fourth-hand, and I sure wish that said people would communicate
directly, but I think corporate reporting structures get in the way of some
of that)

There are some esthetic reasons to prefer use of M_FLOOD. This has to do with
ANIMA being a self-contained system.

There is also a claim that mDNS is already present in many small
devices. RFC6763 even says that some ethernet chips can autonomously answer
mDNS queries when the device in question is in low-power mode!

But there are some real technical claims about why mDNS does not suit:

The specific claim is that we can't do unsolicited announcements using
mDNS.  https://tools.ietf.org/html/rfc6762#section-8, section 8.2 says:

   A Multicast DNS responder MUST NOT send announcements in the absence
   of information that its network connectivity may have changed in some
   relevant way.  In particular, a Multicast DNS responder MUST NOT send
   regular periodic announcements as a matter of course.

The rfc6763 DNS-SD process makes it pretty clear that discovery involves a
query and a reply, and that responses may be multicast such that they are
easily cached.  6762 says a lot about TTL and how often things are cached.

I myself do not quite understand the entire interaction.  I observe that
on networks I am part of that, my mDNS daemon (avahi), always has a list of
seldom (even never!) used services in it's cache.

For instance:
knothole-[~](2.1.5) mcr 10002 %avahi-browse -vat | wc -l
174

knothole-[~](2.1.5) mcr 10003 %avahi-browse -vat | grep -i Mumble
+ credil IPv6 lapeche                      Mumble Server local
+ credil IPv4 lapeche                      Mumble Server local

I'm sure that NOBODY has ever asked the network if there was a Mumble
server around.  Clearly, when it first started, it had a reason to announce
itself, but that value should have a TTL that after the several hundred days
of uptime for the "lapeche" machine must have expired.  So I'm unclear how
reconcile what I read in the specifications ("MUST NOT send regular priodic
announcements") with what I see in practice.


It might be that in the end we don't care about the anonimity of the pledge.
If the pledge can ask the network about Join Proxy, then there is nothing
to stop us from using mDNS here.

On the other hand, M_FLOOD is as certainly useable, and is rather simple.
I had very little problem implementing it myself.  I also think that every
Join Proxy is also an ACP node, and so it will want to M_FLOOD about it's
ACPness, and so I see little downside here.

I do not have horse in this race:  I just don't want to be ignored by
developers... who granted, have not come to this conversation.

(I hear lots of anti-IETF rhetoric from Linux kernel developers, most of whom
have never posted any question to an IETF list, ever!)


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-