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

Chris,

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

We’ve made a lot of changes in v08 and v09 of the document to respond to comments from other reviewers, and uploaded v10 in response to your comments.

Please see below for individual responses.

Cheers,

Nate

From: Chris Box via Datatracker <[email protected]>
Sent: Friday, January 2, 2026 09:36
To: [email protected]
Cc: [email protected]; [email protected]
Subject: [pim] draft-ietf-pim-ipv6-zeroconf-assignment-07 early Intdir review

Document: draft-ietf-pim-ipv6-zeroconf-assignment Title: Zero-Configuration Assignment of IPv6 Multicast Addresses Reviewer: Chris Box Review result: On the Right Track I am the assigned int-dir reviewer for this draft. For background on int-dir,


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

Title: Zero-Configuration Assignment of IPv6 Multicast Addresses

Reviewer: Chris Box

Review result: On the Right Track



I am the assigned int-dir reviewer for this draft. For background on int-dir,

please see the [FAQ](https://urldefense.com/v3/__https://wiki.ietf.org/en/group/intdir__;!!EJc4YC3iFmQ!Va_XsKBlTRQcfC75vQ1lBt36kldAsh1ayvAaCKkglFzIHUFZGVu-ifByhvN5TbYmKyLwgIri3N5Mc9_nRg$<https://urldefense.com/v3/__https:/wiki.ietf.org/en/group/intdir__;!!EJc4YC3iFmQ!Va_XsKBlTRQcfC75vQ1lBt36kldAsh1ayvAaCKkglFzIHUFZGVu-ifByhvN5TbYmKyLwgIri3N5Mc9_nRg$>). Please resolve

these comments along with any other comments you may receive.



Comments regarding INT area hot topics (https://urldefense.com/v3/__https://wiki.ietf.org/group/iesg/int__;!!EJc4YC3iFmQ!Va_XsKBlTRQcfC75vQ1lBt36kldAsh1ayvAaCKkglFzIHUFZGVu-ifByhvN5TbYmKyLwgIri3N6iAWq_UQ$<https://urldefense.com/v3/__https:/wiki.ietf.org/group/iesg/int__;!!EJc4YC3iFmQ!Va_XsKBlTRQcfC75vQ1lBt36kldAsh1ayvAaCKkglFzIHUFZGVu-ifByhvN5TbYmKyLwgIri3N6iAWq_UQ$>)

--------------------------------------



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.



[NK] I’m not aware of one either.



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.



[NK] This is a link-scoped IPv6 multicast address, defined in RFC 4489. It looks a lot like an SSM address, but it appears that the “plen” field is overloaded with 0xff to differentiate it.



Also, whichever addresses are used should follow RFC5952 formatting, which

implies suppressing leading zeros.



[NK] Thanks, looks like I missed one. It has been updated.



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.



[NK] We made some changes to the IANA Considerations section in v08 that provides some additional information about adding this to the .arpa and special-use domain registries. Please let me know if there is anything else you think we need to add.



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?



[NK] v08 added an explanation on why this is a MAY: not all mDNS implementations make it easy to only advertise over IPv6.



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.



[NK] That’s correct. Updated to clarify that this is meant to be persistent storage.



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

recommended?



[NK] It may be recommended in environments that are more prone to network partitions. It is probably not a problem in most networks.



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.



[NK] v08 added section 3, with additional information about how this would work across different subnets. It is left open-ended so that new approaches to multi-subnet mDNS can be used without having to update to this document. Here is an excerpt: “The protocol can be extended across multiple subnets if PTR records are distributed between subnets (for example, by using an mDNS reflector or the Discovery Proxy described in [RFC8766]).”



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.



[NK] v09 does a better job describing where this comes from (switch design, specifically the hash table with fixed buckets described in draft-ietf-pim-zeroconf-mcast-addr-alloc-ps). “Infrastructure-free” in this context is more tied to central servers – you would still need infrastructure like switches to distribute traffic.



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.



[NK] We removed some of the text and left it open as something that can be resolved by a future enhancement.



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?



[NK] Yes, that is one way to accomplish it. I found the mDNS reflector in Avahi a lot easier to work with, but as you mentioned earlier there are drawbacks to this approach and many environments will probably need the Discovery Proxy.



Section 5 The security considerations section doesn't meet the requirements of

https://urldefense.com/v3/__https://authors.ietf.org/required-content__;!!EJc4YC3iFmQ!Va_XsKBlTRQcfC75vQ1lBt36kldAsh1ayvAaCKkglFzIHUFZGVu-ifByhvN5TbYmKyLwgIri3N7XtfcAmA$<https://urldefense.com/v3/__https:/authors.ietf.org/required-content__;!!EJc4YC3iFmQ!Va_XsKBlTRQcfC75vQ1lBt36kldAsh1ayvAaCKkglFzIHUFZGVu-ifByhvN5TbYmKyLwgIri3N7XtfcAmA$> 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?



[NK] In v09 we added some text mentioning mDNS and in v10 some text to explain DoS using veto records. I’m not sure there is much that can be done to mitigate the risk because to a certain degree that risk is inherited from mDNS, which also assumes cooperating participants (RFC 7662 section 21).



Editorial

---------



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



[NK] Done!



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".



[NK] Done!



_______________________________________________

pim mailing list -- [email protected]<mailto:[email protected]>

To unsubscribe send an email to [email protected]<mailto:[email protected]>

________________________________

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.

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