[pim] Re: Erik Kline's Discuss on draft-ietf-pim-zeroconf- mcast-addr-alloc-ps-07: (with DISCUSS)

"Karstens, Nate" <[email protected]> Thu, 20 Nov 2025 22:25:22 +0000
Newsgroups gmane.ietf.pim
Message-ID <CH3PR04MB87948B6C8A536F99D5E715239CD4A@CH3PR04MB8794.namprd04.prod.outlook.com>
Erik,

That’s a great suggestion. We added the underlined to our -10 update to hopefully make this easier to understand:

An additional concern is that the group IDs used for this dynamic range overlap with the range used for Solicited-Node multicast addresses, a special type of multicast used by IPv6 for neighbor discovery (see Section 2.7.1 of RFC4291). This overlap increases the risk of unintentional conflicts with link-layer addresses.

Best Regards,

Nate

From: Erik Kline <[email protected]>
Sent: Thursday, November 20, 2025 09:40
To: Karstens, Nate <[email protected]>
Cc: The IESG <[email protected]>; [email protected]; [email protected]; [email protected]
Subject: Re: [pim] Erik Kline's Discuss on draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07: (with DISCUSS)

> Please provide an example of how multicast addresses with T=1 overlap with ff02: : 1: ffxx: xxxx addresses. Sure, I will base this example off of the example in RFC 4489 section 4. Let’s say that a device’s IPv6 link local address is fe80: : a12: 34ff: fe56: 7890. 


> Please provide an example of how multicast addresses with T=1 overlap with ff02::1:ffxx:xxxx addresses.

Sure, I will base this example off of the example in RFC 4489 section 4.

Let’s say that a device’s IPv6 link local address is fe80::a12:34ff:fe56:7890. It will use a Solicited-Node multicast address of ff02::1:ff56:7890. It uses RFC 4489 to calculate a link-scoped multicast prefix of ff32:00ff:a12:34ff:fe56:7890::/96. If it chooses 0xff567890 as its group ID (which is compliant with host allocation described in RFC 3307 section 4.3.2), then it will use the IPv6 multicast address ff32:00ff:a12:34ff:fe56:7890:ff56:7890. Both of these IPv6 multicast addresses use Ethernet multicast address 33:33:ff:56:78:90.

If you think this example would be useful to include in the document, how would you feel about updating draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id/__;!!EJc4YC3iFmQ!Q9ih46cUb4H0_ynEnS6hu6LbP0DYub-DPyS_FqbGAKwXIxZlUuxJ4d9xJFvsrO1C375rub4lixse0xcsvA$> to include it? That document is focused specifically on improving the IPv6 multicast address architecture to better accommodate multicast address allocation protocols.

Thank you; it's overall more clear that the "collision" that is concerned here is (effectively) the resulting MAC address.

I think in this case what triggered me was "this dynamic range overlaps", which confused me as the IPv6 prefixes do not overlap.  I think if you just clarify that the group ID/MAC address is the thing that overlaps (or collides) it would be helpfully more accurate.

Thanks for bearing with me,
-Erik

________________________________

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]