Early Review of draft-ietf-pim-ipv6-zeroconf-assignment-07
review-ietf-pim-ipv6-zeroconf-assignment-07-intdir-early-box-2026-01-02-00

I am the assigned int-dir reviewer for this draft. For background on int-dir,
please see the [FAQ](https://wiki.ietf.org/en/group/intdir). Please resolve
these comments along with any other comments you may receive.

Comments regarding INT area hot topics (https://wiki.ietf.org/group/iesg/int)
--------------------------------------

Section 2 says "For example, given a source address of
fe80::a12:34ff:fe56:7890, the IPv6 multicast address may be
ff32:00ff:a12:34ff:fe56:7890:9abc:def0".

The hot topics asks that example addresses should be from a RFC6890 reserved
range. However 2001:db8:: isn't appropriate, as it's unicast. I have little
experience with multicast but as far as I can tell the IETF hasn't defined a
documentation prefix for multicast.

It's clear that the address should start with ffxx. The choice of ff32 implies
Source-Specific Multicast and link-local scope. SSM isn't referenced in this
document. Should it be? The requirements document only mentions it to say
"Cost-effective switches often do not support source-specific multicast (SSM)".
If SSM is intended, I suggest describing the connection. If it's not, let's
find an example that doesn't refer to it.

Also, whichever addresses are used should follow RFC5952 formatting, which
implies suppressing leading zeros.

Other comments from reading the draft
-------------------------------------

Section 2 says "The application … uses that to construct a string like a
reverse-mapping domain, using a new "eth-addr.arpa" special-use domain."

This standards-track document needs to clearly specify how that eth-addr.arpa
name is constructed, e.g. by reference to a section of an existing RFC.

Section 2 says "records MUST be published using the IPv6 multicast address for
mDNS, but MAY also be published using the IPv4 multicast address for mDNS."
Does the working group want to include a recommendation regarding this choice?

Section 2 "The application shall retain the group ID value and use it the next
time". Should this refer to persistent storage? I'm guessing that retention
only in RAM isn't your intention.

Section 2 "The host network stack may optionally monitor the network". Is this
recommended?

Section 2 "While intended primarily for allocating IPv6 multicast addresses on
the same subnet (link-local scope), the same technique could also apply to a
larger network as long as mDNS traffic is routed between subnets". Blindly
forwarding mDNS between subnets is problematic for a number of reasons, which
is why DNSSD is defining how mDNS and unicast DNS can work together across
multiple links. I suggest reframing the document to explicitly only define
link-local behaviour, and leave the question of how to handle multiple links to
a future document.

Section 2.1 "When an infrastructure component detects a collision it cannot
resolve, it triggers a conflict with the application by publishing a veto
record." What is this infrastructure component? It hasn't been defined. The
requirements draft discusses "infrastructure-free" environments.

Section 3 "Deployments on these networks may consider engaging a detection
mechanism and prompting hosts to send unsolicited mDNS response messages when
the partition is repaired." This informational paragraph feels out of place in
a standards track document, because it's not specifying the mechanism. This
could be resolved by deleting it, or by fully describing how to do this.

Section 3 "The protocol described in this document also satisfies the
recommended criteria, to the extent that a deployment supports publishing
mDNS-based DNS-SD records across multiple subnets (see [RFC8766])" I'm confused
by this. Do you mean to say that deployments needing multiple subnet
discoverability should send unicast queries to a Discovery Proxy so that remote
eth-addr.arpa names can be found?

Section 5 The security considerations section doesn't meet the requirements of
https://authors.ietf.org/required-content which says "The text of this section
must have a meaningful exploration of security issues raised by the proposal,
which should include both risks and a description of solutions or workarounds."

You could certainly flesh out the DoS risk. If a malicious device tries to deny
service by immediately vetoing every group ID that appears, will it cause all
the legitimate applications to remain in a probing state and be unable to offer
their services? If yes, is the working group happy that this risk is accepted?
Alternatively, should we have defined behaviour about how to detect and ignore
malicious vetos?

Editorial
---------

The first line of the abstract should be made into a complete sentence.

The phrase "mDNS is used in favor of a new protocol" perhaps ought to be
something like "mDNS is used rather than a new protocol".