Telechat Review of draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10
review-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10-intdir-telechat-migault-2026-02-19-00

Hi,

I reviewed this document as part of the Internet Directorate's ongoing effort
to review all IETF documents being processed by the IESG.  These comments were
written primarily for the benefit of the Internet Area Directors. Document
authors, document editors, and WG chairs should treat these comments just like
any other IETF Last Call comments.

Disclaimer: I lack expertise in multicast; therefore, I kindly ask you to
consider my remarks with a grain of salt.

Yours,
Daniel

1.  Introduction

   For IPv6 multicast addresses, Section 2 of [RFC3307] defines the
   lower 32 bits of the IPv6 address, which are mapped directly to the
   link-layer, as the group ID, and then assigns ranges of group ID
   values based on how they are allocated.

I believe the sentence could be clearer, particularly for readers who are not
well-versed in the topic of multicast, which applies to my situation. Upon
briefly reviewing 3307, I do not observe a normative MUST that binds IPv6 to
the link-layer, leading me to question whether this is merely a convenience or
an obligation. I suspect that once the multicast destination IPv6 address is
constructed, the last four bytes identify the Group ID, which is then utilized
to form the 33-33-group ID multicast Ethernet destination address. Dividing the
text into multiple sentences aids in comprehension, as terms like 'mapping' can
be more confusing than 'copied', for instance.

My understanding is that multicast IP addresses are defined in 3306, featuring
a flag field composed of two bits (T and P). According to 2373, T=1 signifies a
permanent multicast IP address, while T=0 indicates that the multicast IP
address is not permanent. I perceive a distinction between the group ID and IP
addresses. I suspect that the P flag is intended to clarify the relationship
between the network prefix and the group ID. When the Group ID is associated
with the network prefix, which I understand cannot be used independently, P is
set to 1. Conversely, P=0 could imply a group ID that may be shared across
different network prefixes. At this juncture, I find it somewhat unclear what
the value of P would be for a private network concerning a specific group ID. I
would be interested in obtaining that information for my personal knowledge.

2.  Considerations for Source-Specific Multicast

   However, SSM is not universally supported ([RFC4607], Section 6 lists
   one example).  This document defines a range of dynamic IPv6
   multicast group IDs for use in environments that do support SSM.

I have the impression that the initial sentence may be omitted. It gives the
impression that we are defining a refinement of something that is not
universally utilized. I might be overlooking something, but if there is a
connection between the two sentences, I would recommend that it be explicitly
mentioned.

I believe it would be beneficial to outline the advantages or motivations for
partitioning the Group IDs.

This may be a naive question, but I am curious as to why the environment should
uniformly support MSS or not support it. More specifically, I am inquiring
whether we could have a mix of nodes that support SSM and those that do not. In
our situation, I am also contemplating the potential consequences of a host
supporting SSM according to the conventions defined in this document, alongside
hosts that support the previous version of SSM. This topic might be worth
discussing in the security considerations section as well.