[pim] Re: draft-ietf-pim-ipv6-zeroconf-assignment-07 early Dnsdir review

["Karstens, Nate" <[e-mail]>]

Geoff,

Thanks for your review, and sorry for the significant delay in my reply.

We posted version 08 of https://datatracker.ietf.org/doc/draft-ietf-pim-ipv6-zeroconf-assignment/ to address your concerns.

Please see below for individual responses to your feedback.

Thanks,

Nate

From: Geoff Huston via Datatracker <[e-mail]>
Sent: Wednesday, December 10, 2025 12:58
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: [pim] draft-ietf-pim-ipv6-zeroconf-assignment-07 early Dnsdir review

Document: draft-ietf-pim-ipv6-zeroconf-assignment Title: Zero-Configuration Assignment of IPv6 Multicast Addresses Reviewer: Geoff Huston Review result: Not Ready This is a review of a draft that is in its early stages so its unsurprising that


Document: draft-ietf-pim-ipv6-zeroconf-assignment

Title: Zero-Configuration Assignment of IPv6 Multicast Addresses

Reviewer: Geoff Huston

Review result: Not Ready



This is a review of a draft that is in its early stages so its unsurprising

that a number of items are called out in this review that will likely be

refined as the draft progresses. The larger issues as I see them are scope of

applicability (local? global? something else?) and explicitly noting the

reliance on mDNS to detect conflicts in self-assignment of multicasst addresses.



Issues:



- The document proposes the reservation of the eth-addr.arpa as a special-use

domain. RFC6761, section 4 is relevant here.As it stands I do not see these

"MUST" requirements being addressed in the draft, and the cursory  treatment of

this requirement in Section 4.1 is inadequate.



[NK] Good point. In looking at this further it became clear that the .arpa registry (https://www.iana.org/domains/arpa) and special-use domain name registry (https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml) have different purposes and requirements. So, we split this part of the IANA Considerations into two actions: 1) adding “eth-addr.arpa” to the .arpa registry and 2) adding “9.3.3.3.3.eth-addr.arpa” to the special-use domain registry. Entries in the special-use domain registry that are related to reverse-mapping narrow the scope down to the range of addresses that would be used for a given purpose; using “9.3.3.3.3.eth-addr.arpa” would follow this same pattern.



- The document proposes the use of mDNS probing algorithm described in

[RFC6762], RFC6762 appears to make some assumptions about the use of mDNS in

the context of a local scope. particularly in the area of the timers and repeat

count specified in the probing procesures. Are the same RFC6762 probe timers

when considering a multicast configuration of extended scope? Some text that

explains why algorithm would still be effective in a global context might be

useful.



[NK] We added a new section that provides additional information about use with multiple subnets. This also indicates that the protocol is unsuited for use on the global Internet and instead recommends using SSM.



- The document notest that records MUST be published using the IPv6 multicast

address for mDNS, but MAY also be published using the IPv4 multicast address

for mDNS. The use of IPv4 multicast in this context appears to be

counter-intuitive in this context. What purpose would publishing this using

IPv4 multicast serve?



[NK] Publishing on IPv4 is allowed because mDNS implementations do not always have a good way to limit transmission of a given record to IPv6. We added a note explaining that to the document.



-  The document notest that "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 (for any scope excluding global scope)." This text appear to assert

that this is not applicable for globally scoped  multicast, but is ambivalent

about the scenarios that extend beyond a local subnet (a link-layer multicast

scope). It seems to me to be an important consideration in terms of

applicability and perhaps should be explicitly called out in the introduction

and perhaps given its own section ("Scope pf Applicability"?)



[NK] Thanks for pointing this out! We added a new section that discusses using the protocol on multiple subnets. In considering this further we realized that the protocol would not work as-is because the IPv6 multicast address generated is for the local link only. This new section addresses that and specifies that the address must be a unicast-prefix based IPv6 multicast address.



- The document proposes that Veto records are published without probing. What

does "publish" entail in mDNS? Does it multicast this record? Or does it just

respond to mDNS queries?



[NK] There are several things that could be considered when determining if a new record should be multicast to the network. In this case, publishing the veto record would result in a multicast message due to the considerations in RFC 6762 section 6 (because “the responder determines than an unsolicited announcement is warranted”) and section 8.3, which discusses sending an unsolicited response with the new record.



- "Applications respond to the conflict the same as to a collision.  The

application retains its new group ID, so the same conflict is not repeated in

the future."" Previous text says that an application stops transmitting the

multicast stream and starts the process over using a different group ID, yet

this text says that the applications retains its new Group ID? This does not

make sense to me, and I guess more clarifying text would help a reader to

understand the protocol behaviour here.



[NK] The idea is that transmitters will collectively (and it a distributed manner) retain a successful configuration so that future iterations of the network would likely be able to skip conflict resolution (to be clear, you would still probe for the records to make sure they aren’t being used, but because everyone has saved off the successful configuration none of the records should conflict with each other). We added some text that will hopefully clarify the storage of the new group ID.



- The document notes that ""[I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps]

contains a list of criteria to evaluate potential solutions.  The protocol

described in this document satisfies all of the required criteria." It may be

useful the enumerate these crieria and explain how this protocol satisfies each

of these criteria.



[NK] Great idea! I think this added a lot to the document.



- The document notes that "it can take a signficant amount of time to detect a

record collision after a network partition is repaired." and "a greater concern

on networks where multicast streams may be established at any time.

Deployments on these networks may consider engaging a detection mechanism and

prompting hosts to send unsolicited mDNS response messages when the partition

is repaired." But I had the impression that this was exactly the scenario

envisaged here, and I read this text as saying "Well you need to rely on some

form of detection mechanisms mot described here. Seems to me that this is an

extremely important shortcoming in this document.



[NK] There are definitely trade-offs involved with using the protocol. One way to address this would be periodically transmitting certain messages, but this would come at the expense of increased bandwidth usage (mDNS is designed to be a fairly low-bandwidth protocol, see RFC 6762 section 7). The detection mechanism seemed like a way to address it without increasing bandwidth requirements. Either way, it’s probably fair to say that network partition resilience is more of a secondary feature, and if this is a significant concern for someone deploying the protocol then something like MADCAP or draft-ietf-pim-gaap may be more suited to their needs.



- "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. Which document enumerates the criteria

referred to here? What are these criteria? How are these criteria met? It may

be helpful to have this document show how tjhese criteria are satisfied.



[NK] Enumerating the individual requirements hopefully helped clarify this.



- "The "eth-addr.arpa." domain is effectively a reverse-mapping domain and so

has the same considerations as the reverse-mapping domains listed in [RFC6761],

Section 6.1." Multicast changes many things and I think this handwaving is

inadequate here.There are a set of questions in RFC6761 that MUST be answered

in this document before any name can be entered into the register of special

use domain names.



[NK] Thanks again for this suggestion, I think it resulted in a significant improvement to the document.



- "Special thanks to the National Marine Electronics Association for their

contributions in developing marine industry standards and their support for

this research." - What "research" is being referred to here?



[NK] There is another document that is more research-focused (draft-ietf-pim-zeroconf-mcast-addr-alloc-ps) but I think for this document “work” is a better word (and what we used in draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id).



_______________________________________________

pim mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

________________________________

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.