[pim] draft-ietf-pim-ipv6-zeroconf-assignment-07 early Rtgdir review

Toerless Eckert via Datatracker <[email protected]> Mon, 22 Dec 2025 10:15:00 -0800

Newsgroups	gmane.ietf.pim
Message-ID	<176642730018.648910.2685810667503585518@dt-datatracker-5656579b89-p6k4r>

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

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

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: [email protected]

296 Dino Farinacci
297 lispers.net
298 San Jose, CA
299 United States of America
300 Email: [email protected]

302 Mike McBride
303 Futurewei
304 United States of America
305 Email: [email protected]

EOF

_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]