Early Review of draft-ietf-pim-ipv6-zeroconf-assignment-07
review-ietf-pim-ipv6-zeroconf-assignment-07-rtgdir-early-eckert-2025-12-22-00

Document: draft-ietf-pim-ipv6-zeroconf-assignment
Title: Zero-Configuration Assignment of IPv6 Multicast Addresses                                 
Reviewer: Toerless Eckert for RTG DIR
Review result: Has Issues

This document is on the right path but has several issues that need to be worked out
and are discussed in the detailled review feedback below. In summary:

- The document forgets to call out its reason of existance, which is not simply
  IPv6 multicast group address collision but collision of the link-layer addresses
  as well.

- Unnecessary hand waiving: keep text focussed on deployments thats undestood to
  work - mDNS, link-local scope, ".local" domain. Move everything outside that
  scope outside the document or into an appendix.

- DNS RR PTR format unnecessarily complex, non-descriptive. Review suggests
  hopefully better/simpler encoding options.

- Incomplete and incorrect statements re this document meeting all of
  draft-ietf-pim-zeroconf-mcast-addr-alloc-ps requirements.

- Various nits.

The remainder of this email is output of idnets (with line numbers) interleaved
with review comments.

Thanks a lot for the work.

Toerless

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses
     in the document.  If these are example addresses, they should be changed.



2	Network Working Group                                        N. Karstens
3	Internet-Draft                                                    Garmin
4	Intended status: Standards Track                            D. Farinacci
5	Expires: 3 April 2026                                        lispers.net
6	                                                              M. McBride
7	                                                               Futurewei
8	                                                       30 September 2025

10	       Zero-Configuration Assignment of IPv6 Multicast Addresses
11	               draft-ietf-pim-ipv6-zeroconf-assignment-07

minor:

Given how this solution specifically relies on mDNS, i would strongly
recommend to include mDNS into the title of the document, e.g.:

     Zero-Configuration Assignment of IPv6 Multicast Addresses using mDNS
           draft-ietf-pim-ipv6-zeroconf-assignment-07

This also allows to easier distinguish this solution from others in case
others will evolve.


13	Abstract

15	   Describes a zero-configuration protocol for dynamically assigning
16	   IPv6 multicast addresses.  Applications randomly assign multicast
                                   ^

mayor:

... that are unique at link-layer.

17	   group IDs from a specified range and prevent collisions by using
18	   Multicast DNS (mDNS) to publish records in a new "eth-addr.arpa"
19	   special-use domain.  This protocol satisfies all of the criteria
20	   listed in draft-ietf-pim-zeroconf-mcast-addr-alloc-ps.
                                                                ^
nit:

suggest: ... "for IPv6 multicast addresses"

22	Status of This Memo

24	   This Internet-Draft is submitted in full conformance with the
25	   provisions of BCP 78 and BCP 79.

27	   Internet-Drafts are working documents of the Internet Engineering
28	   Task Force (IETF).  Note that other groups may also distribute
29	   working documents as Internet-Drafts.  The list of current Internet-
30	   Drafts is at https://datatracker.ietf.org/drafts/current/.

32	   Internet-Drafts are draft documents valid for a maximum of six months
33	   and may be updated, replaced, or obsoleted by other documents at any
34	   time.  It is inappropriate to use Internet-Drafts as reference
35	   material or to cite them other than as "work in progress."

37	   This Internet-Draft will expire on 3 April 2026.

39	Copyright Notice

41	   Copyright (c) 2025 IETF Trust and the persons identified as the
42	   document authors.  All rights reserved.

44	   This document is subject to BCP 78 and the IETF Trust's Legal
45	   Provisions Relating to IETF Documents (https://trustee.ietf.org/
46	   license-info) in effect on the date of publication of this document.
47	   Please review these documents carefully, as they describe your rights
48	   and restrictions with respect to this document.  Code Components
49	   extracted from this document must include Revised BSD License text as
50	   described in Section 4.e of the Trust Legal Provisions and are
51	   provided without warranty as described in the Revised BSD License.

53	Table of Contents

55	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
56	     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
57	   2.  Procedure . . . . . . . . . . . . . . . . . . . . . . . . . .   3
58	     2.1.  Veto Records  . . . . . . . . . . . . . . . . . . . . . .   4
59	   3.  Evaluation of Solution  . . . . . . . . . . . . . . . . . . .   4
60	   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
61	     4.1.  Domain Name Reservation Considerations  . . . . . . . . .   5
62	   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
63	   6.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   5
64	   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
65	     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
66	     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
67	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

69	1.  Introduction

71	   [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] includes a problem
72	   statement and requirements for a zero-configuration method for
73	   dynamically assigning multicast addresses.  This document describes a
                                                    ^

mayor:

add at "^":

that are not only unique themselves, but that also map to unique
link-layer addresses.

link-
74	   process that fulfills these requirements by having applications
                                                   ^
nit:

 "for IPv6 multicast addresses" 

75	   randomly assign IPv6 multicast group IDs from a specified range and
76	   using mDNS [RFC6762] to prevent collisions.

78	   Note that DNS-based Service Discovery (DNS-SD) [RFC6763] uses several
79	   different DNS record types, published using either Unicast or
80	   Multicast DNS, to facilitate service discovery.  This document uses a
81	   single DNS record type (PTR), published using Multicast DNS, to
82	   coordinate IPv6 multicast address assignment in a zero-configuration
83	   environment.  The DNS records in this protocol may be published

nit:

The correct term is "DNS resource record", so i would prefer if that term would
be used consistently instead of "DNS record". The IETF has been quite lenient
though. Seems to me as if all RFC written by DNS people use "DNS resource record",
and a larger number of RFCs that are written by "just users of DNS" just say
"DNS record"....

nit:

s/in a zero-configuration environment/without requiring any configuration/

Reason: I do not know what a "zero-configuration environment" is.
Badly defined term. Avoid...

84	   alongside records for other domain name services, such as DNS-SD, or
85	   they may be published alone. mDNS is used in favor of a new protocol
86	   with the expectation that functionality for address assignment can be
87	   achieved using existing mDNS implementations.

89	   This protocol is well-suited for networks that rely on IPv6 multicast
90	   and already deploy mDNS.

92	1.1.  Requirements Language

94	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
95	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
96	   "OPTIONAL" in this document are to be interpreted as described in BCP
97	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
98	   capitals, as shown here.

100	2.  Procedure

102	   When an application is preparing to transmit a multicast stream, it
103	   first generates a random group ID in the range 0x90000000-0x9FFFFFFF,
104	   which IANA is REQUESTED to assign from the "Dynamic Multicast Group

nit:

Start new sentence to avoid confusion about what IANA is requested to
assign (the range vs. the ID):
    ". IANA is requested to assign this range from ..."

105	   IDs" registry (see Section 4).  It combines this with the Interface
106	   Identifier (IID) of the intended source address for the multicast
107	   stream to generate a link-scoped IPv6 multicast address [RFC4489].
108	   The application then calculates the multicast Ethernet address that
109	   will be used to transmit the data ([RFC2464], Section 7) and uses
110	   that to construct a string like a reverse-mapping domain, using a new
111	   "eth-addr.arpa" special-use domain.

nit:

Any RFC reference for this special-use domain approach ? If so, please add.

nit:

That text is the normative description of the procedure, so you need to
formally describe how to construct the eth-addr.arpa string. You should
also include the specification of the format of the PTR RR you are introducing
here.

mayor:

I do not think it is necessary to use the complicated reverse representation
of a MAC address as proposed in this draft ("0.f.e.d.c.b.a.9.3.3.3.3"). That
format is only necessary when you need to support sub-tree delegation within
the name space.

For IP/IPv6 addresses delegation means that different sub-trees of the address space
are maintained by different administrative entities / DNS-servers. This
is a) not possible with mDNS, b) not possible with allocated MAC addresses.

If you do want to keep this format, then the document really needs to have
 good justification for doing so. And saying "we thought this is the same
problem as for ipv6.arpa, and hence the same solution" - is not a good
technical explanation.

I also don't think eth-addr.arpa is a good descriptive name. It is open
ended and suggests that different uses could re-use this domain, but in
reality such additional use could be conflicting in what they want to do
into the PTR RR.

So, i would suggest:

a) Simply use the lower-case representation of a MAC-address without any
filler characters, all zero written out to represent the MAC address.

b) Use a self descriptive name so anyone seeing such a domain name knows
   immediately what it means:

   33339abcdef0.rfcTHISRFC.arpa

You need to add some note like:

   [RFC-editor / IANA:  please replace THISRFC with the RFC number assigned
    to this document].

113	   For example, given a source address of fe80::a12:34ff:fe56:7890, the
114	   IPv6 multicast address may be ff32:00ff:a12:34ff:fe56:7890:9abc:def0,
115	   the group ID 9abc:def0, the multicast Ethernet address
116	   33:33:9A:BC:DE:F0, and the resulting string is
117	   "0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa".

nit:

This is too terse and does not follow the order in which it was explained in before,
so it is hard to match up against the explanation:

1. The node creates a unique IPv6 link local multicast group address according to
   [RFC4489] according to the following steps
1.1 The node creates a randomn group ID from the range 0x90000000-0x9FFFFFFF
    reserved for the procedures of this memo: 9abc:def0
1.2 The node retries the IID portion of the link-local unicast address of the
    link to use: fe81::a13:34ff:fe56:7890 -> a13:34ff:fe56:7890.
1.3 The node combines IID and random group ID to form the IPv6 link local
    group address: ff32:00ff:a12:34ff:fe56:7890:9abc:def0.
2.  The node knows that the MAC address used for this group address is
    33:33:<group-id>, and hence the DNS PTR RR to claim the MAC address is
    33339abcdef0.rfcTHISRFC.arpa

119	   The application then uses the mDNS probing algorithm described in
120	   [RFC6762], Section 8.1 to continuously query for a PTR record with
121	   the same name as the generated string.  If the probing algorithm
122	   completes without any conflict, then the application begins
123	   advertising its own unique PTR record using that name.  The PTRDNAME
124	   field consists of a unique application identifier, in the form of a
125	   DNS label, followed by the device's host name (for example,
126	   "application.example.local.").  Integrating a unique identifier in
127	   this manner allows for multiple applications to be on the same host.

mayor:

There needs to be more description about the PTR target FQDN and rules for it.

First of all, it seems prudent to require the PTR target FQDN to necessarily
be uniquely owned by the announcing host, through probing as of rfc6762, section 8.1.

Secondly, whether this is just some pre-existing or new hostname of this host,
such as example-host.local, or some new sub-domain name such as "application.example-host.local" -
that seems like outside the scope of this document because no procedures are defined
or pointed to.

128	   Note that A/AAAA records may also be published for this host name
129	   ("example.local."), though this is not a requirement for this design.

nit:

Again: this is just hand waving for something not specified. Better to remove or
move into an appendix so as not to cause confusion and followup questions.

131	   Because this protocol is focused specifically on allocating IPv6
132	   multicast addresses, records MUST be published using the IPv6
133	   multicast address for mDNS, but MAY also be published using the IPv4
134	   multicast address for mDNS.

minor:

KISS (Keep It Simple, Stupid): remove the MAY portion about IPv6 or else
explain in the tesxt when and where this is applicable.

136	   Once the PTR record is advertised, the host may then begin
137	   transmitting multicast data using the generated address.

139	   The application shall retain the group ID value and use it the next
140	   time the multicast stream is transmitted.  This allows the network to
141	   quickly settle on a configuration that will never have another
142	   collision as long as the network is unchanged.

144	   If a conflict is detected at any point, then the application stops
145	   transmitting that multicast stream and starts the process over using
146	   a different group ID.

148	   The host network stack may optionally monitor the network for traffic
149	   that uses the same destination multicast Ethernet address, but a
150	   different destination multicast IPv6 address.  If this is detected,
151	   then the application responds the same as a collision.
                               ^

nit: SHOULD

153	   While intended primarily for allocating IPv6 multicast addresses on
154	   the same subnet (link-local scope), the same technique could also
155	   apply to a larger network as long as mDNS traffic is routed between
156	   subnets (for any scope excluding global scope).

minor:

remove whole paragraph. Hand waiving. No supportive normative text what/if/how to do this.


158	2.1.  Veto Records

160	   [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] describes collisions
161	   occurring in the network infrastructure.

nit:

Add reference to section

161        When an infrastructure
162	   component detects a collision it cannot resolve, it triggers a
163	   conflict with the application by publishing a veto record.  A veto
164	   record is a unique PTR record using the string generated for the
165	   address as its name and the PTRDNAME field set to the string "veto",
166	   formatted as a DNS label.  The veto record is published without
167	   probing.

mayor:

I can not find somthing in [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] that
would point to the need for such a functionality. It would be good to have
a clearer specification for the condition in which this problem could occur.

I would suggest to use the special domain name "veto." (aka: global, not relative)
to indicate the specific purpose of anybody but the announcer to cease attempting
to claim the RR.

169	   Applications respond to the conflict the same as to a collision.  The
170	   application retains its new group ID, so the same conflict is not
171	   repeated in the future.

minor:

"retains its new group ID" ??? Maybe rephrase ? The application that looses
against a veto has to randomnly use a new group ID and try to re-claim the
DNS RR for it, right ?

173	3.  Evaluation of Solution

175	   [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] contains a list of
176	   criteria to evaluate potential solutions.  The protocol described in
177	   this document satisfies all of the required criteria.

mayor: 

Given how the multicast group address is derived from the IID according to RFC4489,
the address is tied to the node that owns this IID. When this node goes away, the
mechanism by which the address is "owned" - DAD and/or mDNS will no longer work.
Hence this mechanism does not seem to satisfy REQ-2.

minor:

To satisfy REQ-7: If multiple applications on the same host use the same IID according
to RFC4489, then they need to use a single cordinated instance of the allocation procedure
in this document so that they do not randomnly generate the same group-ID and
hence the same multicast address. Or else they might be able to determine from a
shared mDNS library/daemon if both would atempt to allocate the same mDNS RR. Otherwise
(e.g.: if mDNS is running independently from each other in each application,
the mDNS collision detection would have to work for looped-back packets, something
that may cause implementation challenges).

These type of issues around satisfying REQ-7 sould be described in the document.

mayor:

mDNS is typically supported today only across link-local scopes. Likewise, RFC4489
is only working for link-local addresses. Therefore i can not see how CONS-1
can be suppoted.

The document should describe that (and why) CONS-1 is not supported.

179	   However, because mDNS is designed to be a low-bandwidth protocol, it
180	   can take a signficant amount of time to detect a record collision
181	   after a network partition is repaired.  This is not a concern on
182	   networks where all multicast streams are established before any
183	   likely partition event because all group IDs will have been selected
184	   and stored for future use.

186	   It is a greater concern on networks where multicast streams may be
187	   established at any time.  Deployments on these networks may consider
188	   engaging a detection mechanism and prompting hosts to send
189	   unsolicited mDNS response messages when the partition is repaired.

191	   The protocol described in this document also satisfies the
192	   recommended criteria, to the extent that a deployment supports
193	   publishing mDNS-based DNS-SD records across multiple subnets (see
194	   [RFC8766]).

196	4.  IANA Considerations

198	   IANA should allocate a block of group IDs from the "Dynamic Multicast
199	   Group IDs" registry in the "IPv6 Multicast Address Space Registry"
200	   registry group that was created by
201	   [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id].  The range of this
202	   block should be 0x90000000-0x9FFFFFFF and the description should be
203	   the title of this document.

205	   The special-use domain "eth-addr.arpa" should be registered in the
206	   .arpa registry (https://www.iana.org/domains/arpa) and the "Special-
207	   Use Domain Names" registry (https://www.iana.org/assignments/special-
208	   use-domain-names).  This domain should not be delegated.

210	4.1.  Domain Name Reservation Considerations

212	   The "eth-addr.arpa." domain is effectively a reverse-mapping domain
213	   and so has the same considerations as the reverse-mapping domains
214	   listed in [RFC6761], Section 6.1.

216	5.  Security Considerations

218	   This algorithm only works in environments where all hosts are
219	   cooperating.  Malicious hosts could deny service by repeatedly
220	   triggering address conflicts.

nit:

Might point to the fact that this is not new for this memos functionality, but
for all of exclusive DNS RR when using mDNS.

222	6.  Acknowledgement

224	   Special thanks to the National Marine Electronics Association for
225	   their contributions in developing marine industry standards and their
226	   support for this research.

228	   Thanks also to the members of the PIM working group for their early
229	   brainstorming sessions and review of this draft, and to Esko Dijk for
230	   his review of the draft.

232	7.  References
233	7.1.  Normative References

235	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
236	              Requirement Levels", BCP 14, RFC 2119,
237	              DOI 10.17487/RFC2119, March 1997,
238	              <https://www.rfc-editor.org/info/rfc2119>.

240	   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
241	              Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
242	              <https://www.rfc-editor.org/info/rfc2464>.

244	   [RFC4489]  Park, J., Shin, M., and H. Kim, "A Method for Generating
245	              Link-Scoped IPv6 Multicast Addresses", RFC 4489,
246	              DOI 10.17487/RFC4489, April 2006,
247	              <https://www.rfc-editor.org/info/rfc4489>.

249	   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
250	              RFC 6761, DOI 10.17487/RFC6761, February 2013,
251	              <https://www.rfc-editor.org/info/rfc6761>.

253	   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
254	              DOI 10.17487/RFC6762, February 2013,
255	              <https://www.rfc-editor.org/info/rfc6762>.

257	   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
258	              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
259	              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

261	7.2.  Informative References

263	   [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id]
264	              Karstens, N., Farinacci, D., and M. McBride, "Updates to
265	              Dynamic IPv6 Multicast Address Group IDs", Work in
266	              Progress, Internet-Draft, draft-ietf-pim-updt-ipv6-dyn-
267	              mcast-addr-grp-id-07, 25 August 2025,
268	              <https://datatracker.ietf.org/doc/html/draft-ietf-pim-
269	              updt-ipv6-dyn-mcast-addr-grp-id-07>.

271	   [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps]
272	              Karstens, N., Farinacci, D., and M. McBride, "Zeroconf
273	              Multicast Address Allocation Problem Statement and
274	              Requirements", Work in Progress, Internet-Draft, draft-
275	              ietf-pim-zeroconf-mcast-addr-alloc-ps-07, 30 September
276	              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
277	              pim-zeroconf-mcast-addr-alloc-ps-07>.

279	   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
280	              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
281	              <https://www.rfc-editor.org/info/rfc6763>.

283	   [RFC8766]  Cheshire, S., "Discovery Proxy for Multicast DNS-Based
284	              Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June
285	              2020, <https://www.rfc-editor.org/info/rfc8766>.

287	Authors' Addresses

289	   Nate Karstens
290	   Garmin International, Inc.
291	   1200 E. 151st St.
292	   Olathe, KS 66062-3426
293	   United States of America
294	   Email: nate.karstens@gmail.com

296	   Dino Farinacci
297	   lispers.net
298	   San Jose, CA
299	   United States of America
300	   Email: farinacci@gmail.com

302	   Mike McBride
303	   Futurewei
304	   United States of America
305	   Email: michael.mcbride@futurewei.com

EOF