Thursday July 27, 15:30-16:30 local time, 22:30-23:30 UTC
Meetecho Link
___
## Welcome {#welcome}
These two documents are scheduled for discussion on the 10th August IESG
telechat. Ted Lemon plans to update the documents prior to that
telechat.
Discussion about how to handle name conflicts.
Ted pointed out that hostnames with three or more labels, like
“one.two.local”, are generally resolved by sending a query to the
configured recursive resolver instead of using Multicast DNS, in
violation of RFC 6762 and the IANA Special-Use Domain Names registry.
Stuart explained that this is a historical workaround for enterprise
sites that used to use “.local” as an unregistered private internal
domain name. Possibly this workaround could be removed now.
Jonathan Hui pointed out that Matter devices (current significant users
of Advertising Proxy services, for devices outside the Thread mesh
discovering and communicating with devices on the Thread mesh) use fixed
names, and Matter device names are supposed to be guaranteed to be
unique via external means, so there should be no legitimate name
conflicts, and names should never need to be changed. Changing these
names will break Matter functionality.
Ted responded that if two Matter devices have the same name then those
Matter devices will not work correctly anyway, so this is a case that
should not ever happen in normal correct operation.
Abtin Keshavarzian suggested an architecture with one active primary
server and multiple backups on “hot standby” ready to take over if the
primary goes down.
Ted pointed out that this design does not take advantage of the ability
to do load balancing when there are multiple active SRP servers
available.
Thursday July 27, 17:00-18:00 local time, or in UTC Friday 00:00-01:30
Very short admin.
Stuart explained that the simultaneous probe logic was created for the
rare case where a bunch of factory-default devices are all powered on at
the same time and think they have the same name. The simultaneous probe
logic is designed to handle this efficiently and let all the devices
generate human-meaningful unique names.
The old first-come first-served logic was created for the case where
someone has a printer called “printer.local” and they buy a new printer.
The existing printer gets to keep its existing name, and the new printer
becomes “printer-2.local”, which is logical and makes sense to the
users. With our use of proxies, the precedence is effectively reversed.
Both proxies are acting on behalf of a single physical device, not two
independent devices as in the “printer” and “printer-2” example. The
existing data from one proxy is probably data that is old and out of
date, and the newly advertised data is actually new updated information
from the proxied device, that should replace the old stale data.
Jonathan Hui suggested using a monotonically increasing sequence number
from the client.
Ted pointed out that some client devices may not have enough flash
memory write-cycles to support recording a sequence number in stable
storage every time it changes.
Jonathan Hui: There are techniques to deal with this, for example, the
device can record the current sequence number after every 100
increments, and on reboot it skips ahead by 100 because it doesn’t know
where it was in the 100-increment window prior to the reboot. This
ensures that the first sequence number used after reboot is always ahead
of the last sequence number used before reboot.
Stuart mentioned that Section 8.1 of RFC 6762 does describe cases where
a Multicast DNS responder SHOULD skip probing, such as when records are
known by other means to be a priori unique (e.g., reverse address
mapping PTR records), or when proxying for records that have already
been determined to be unique on the local link.
Ted said he had tried this but something didn’t work right. It could be
related to sending too much Wi-Fi multicast traffic too rapidly.
Stuart pointed out that some Wi-Fi access points have features to block
excessive levels of Wi-Fi multicast traffic, but there is no
specification for what constitues “excessive multicast traffic”, so
software writers have no guidance for how their devices should behave to
be considered to be behaving reasonably and avoid having their multicast
traffic blocked.
Éric Vyncke suggested that if a client sees the IPv6-only DHCP option,
it should suppress all IPv4 Multicast DNS traffic.
This could help in the future, but today, most customers’ home networks
do still support IPv4 devices.
Remi Nguyenvan suggested that devices that are only reachable over IPv6
(e.g., Thread devices) could ignore all IPv4 traffic.
Stuart commented that interactions between IPv4 Multicast DNS and IPv6
Multicast DNS and IPv6 can be subtle. One example is that a network link
could have an IPv4-only device called “thing.local” and an IPv6-only
device called “thing.local”, and neither will see the other. When a
dual-stack device wants to connect to “thing.local” on its interface
“en0” it will need some way to indicate which one it means.
We have some limited deployment of Infrastructure DNSSD services in
specific envionments. For example, Thread Border Routers implement SRP,
Advertising Proxy, and Discovery proxy, to enable Wi-Fi devices
discovering devices on the Thread mesh, and vice versa. We do not yet
have broader use of Infrastructure DNSSD services in traditional
Ethernet and Wi-Fi networks.
Alexander Clouter asked about discovery in the cloud. Using DNSSD would
be better than many of the ad hoc solutions that are currently used.
Stuart supported exploring this more. Over the years the disparity
between Wi-Fi unicast and Wi-Fi multicast has got worse. Every year we
fail to fix this, it gets worse. CSA Matter depends on device discovery
working reliably, and work is going on there on a program to recommend
home gateways that support unicast discovery.
Jonathan Hui pointed out that many battery-powered Wi-Fi devices today
intentionally skip Wi-Fi beacons to save power, which makes Wi-Fi
multicast even less reliable.
Nathan Karstens asked if there is interest in solving this problem.
Stuart supported this work. This question has come up many times before,
and the solution may not be hard, but so far that solution has not yet
been written down. Thanks for starting this process.
Let’s update the draft and get feedback before IETF 118.