[pim] Re: Comments on draft-ietf-pim-ipv6-zeroconf-assignmen t-06

Stig,

Thanks for your comments! Here are my thoughts:


  *   Regarding the example using prefix ff32, this is intentional because the algorithm generates a link scoped IPv6 multicast address. RFC 4489 section requires the flags to be 0011.
  *   One of the quirks of mDNS is that you can publish address records on both IPv4 and IPv6. That is, you can use the mDNS IPv6 multicast address (ff02::fb) to publish an A record for a device (which indicates its IPv4 address). Similarly, you can use the mDNS IPv4 multicast address (224.0.0.251) to publish a AAAA record for a device, which indicates its IPv6 address,. This requirement is basically saying that on a dual-stack host, it is only necessary to publish records / negotiate addresses using the IPv6 address for mDNS. We can provide a little more context to help the reader understand what this is referring to.
  *   I also work with CAN, where it is common to refer to the “bus”. Saying the host may “monitor the network” is more appropriate in this context, so I will change it.
  *   This monitoring functionality is probably best provided by the network stack because, as you point out, the application would have to request traffic to that address and port in order to receive those messages. Generally speaking, if a host is installed on a network that uses multicast snooping and is receiving traffic for an IPv6 multicast address it did not request, then it should alert the network administrator of the concern. With this draft, the host has the ability to resolve the issue on its own by publishing a veto record. I can make sure this concept is better understood by mentioning the network stack here.
  *   Regarding your question about scopes, it would not be necessary for the application to worry about which scope they are using because the address being negotiated is the Ethernet address. Any number of IPv6 multicast addresses of all different scopes would be transmitted using the same Ethernet address. These applications would attempt to publish the same eth-addr.arpa record in mDNS, which would trigger the address collision algorithm and result in a new Ethernet address.
  *   I’ve asked Dino and Mike about collision repair in GAAP and we will get back with you.
  *   Regarding the security considerations, I think the intended meaning was for publishing a bunch of addresses, as denial of service caused by traffic flooding is probably too obvious to spend much time on. I will clarify.

Cheers,

Nate

From: Stig Venaas <[email protected]>
Sent: Tuesday, September 23, 2025 17:19
To: [email protected]; [email protected]
Subject: [pim] Comments on draft-ietf-pim-ipv6-zeroconf-assignment-06

Hi I believe this draft is mostly ready for WGLC. If anyone else has thoughts on this, please chime in. I have a few review comments. The draft uses ff32: 00ff: a12: 34ff: fe56: 7890: 9abc: def0 as an example. But I don't think should set the bit for


Hi



I believe this draft is mostly ready for WGLC. If anyone else has

thoughts on this, please chime in.



I have a few review comments.



The draft uses ff32:00ff:a12:34ff:fe56:7890:9abc:def0 as an example.

But I don't think should set the bit for unicast-prefix based address

here. It's better to set the flags to just 1, using ff12.



In section 2:



   Because this protocol is focused specifically on allocating IPv6

   multicast addresses, mDNS records MUST be published using IPv6, but

   MAY also be published using IPv4.



What exactly does this mean? That MUST use IPv6 transport? Maybe this

can be clarified.



In section 2:



   The host may optionally monitor the bus for traffic that uses the

   same destination multicast Ethernet address, but a different

   destination multicast IPv6 address.  If this is detected, then the

   application responds the same as a collision.



It's unclear to me what "bus" means here. Should applications somehow

detect other packets for the same group? Internally in the host and/or

on the wire? This may be difficult unless the same port number is used

or application is able to use raw sockets.



In 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 (for any scope excluding global scope).



In order to avoid collisions where applications use different scope,

and also to avoid registering multiple records if using multiple

scopes, should the application always register in mDNS using scope 2,

even if it uses the same with higher scope addresses? Or do we want

the application to register for all scopes?



In section 3:



   It is 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.



Should GAAP be recommended for such applications?



In  section 5 Security Considerations



Although not an efficient attack, I guess malicious applications could

also register a bunch of addresses in mDNS.



Regards,

Stig



_______________________________________________

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]