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

Hi Nate

Please see comments inline.

On Wed, Sep 24, 2025 at 6:00 PM Karstens, Nate <[email protected]> wrote:
>
> 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.

Oh I see, I should have looked more carefully at 4489. I wasn't aware.

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

Right, just a little more text would be helpful.

> 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 should have read this more carefully. I get it now. But can you add
a sentence to this example and point out that the group ID is
9abc:def0?

   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 multicast Ethernet address 33:33:9A:BC:DE:F0, and the resulting
   string is "0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa".

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

I agree publishing a bunch is probably not a practical attack. It's a
much better attack to respond to the actual query being made.

Regards,
Stig

>
>
> 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]
>
> To unsubscribe send an email to [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]