Early Review of draft-ietf-pim-rfc1112bis-07
review-ietf-pim-rfc1112bis-07-intdir-early-thubert-2026-02-09-00

Dear all

I am the assigned int-dir reviewer for this draft. For background on int-dir,
please see the [FAQ](https://wiki.ietf.org/en/group/intdir). Please resolve
these comments along with any other comments you may receive.

We note well:
"

   INTDIR: This document would locally belong to INT as it extends the
   IPv4/IPv6 host stack for IP Multicast (and references to SSM).  It
   simply evolved as a PIM document due to PIM-WG ongoing ownership of
   all of IP multicast below application layer.  IPv6 is added mostly
   "by-reference", because in the absence of an earlier attempt to add
   IPv6 support into an rfc1112bis, all normatively necessary aspects of
   IPv6 multicast where added to a scattered set of RFCs, which are now
   comprehensively referenced in this memo.
"

I believe that the document is ready with nits to be fixed.
Please see below:

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

2.2.  Overview

"
   There are three levels of conformance to this specification.  They
   apply independently for IPv4 and IPv6.
"

> adding 2L seems to introduce a fourth level

3.1.  Level 0: no support for IP multicasting.

 "  IPv6 addresses for
   IP multicasting are described in [RFC4291] and [RFC7371]."

 > indicating section 2.7 in [RFC4291] would be a plus since the IPv6
 architecture has all types of addresses.

4.  HOST GROUP ADDRESSES

"The IPv4 Link-Local addresses 224.0.0.0 is"

> addresses -> address

 " The IPv6 Link-Local all-hosts group
   address is FF02::1.
"
>
Please use canonical form (see RFC 5952), that is ff02::1.
The address name is really all nodes (or all-nodes), not all-hosts
(https://www.rfc-editor.org/rfc/rfc4291#section-2.7.1). Please fix all multiple
instances. >

"  The addresses of other groups are currently
   published via the IANA "IPv6 Multicast Address Space Registry".
"
>
  A reference to the IANA registry would be a plus, e.g.,
           <reference anchor="IANA.MASR">
                <front>
                        <title>IPv6 Multicast Address Space Registry</title>
                        <author>
                                <organization>
                                        IANA
                                </organization>
                        </author>
                        <date year=""></date>
                </front>
                <seriesInfo name="IANA,"
                value="https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml"></seriesInfo>
           </reference>

>

5.  MODEL OF A HOST IP IMPLEMENTATION

"       __________________________________________________________
      |                            |                             |
      |           Local            | IP-to-local address mapping |
      |          Network           |         (e.g., ARP/ND)      |
      |          Modules           |_____________________________|
      |      (e.g., Ethernet)                                    |
      |                                                          |
"

>

Arguably ND is a L3 service over multicast, not the other way around.
Like, the mapping happens at L3 and the MAC address is an opaque that is
manipulated up there.

>

6.  SENDING MULTICAST IP DATAGRAMS

6.4.  Extensions to an Ethernet Local Network Module

"
   Mapping of IPv6 host group addresses to Ethernet is defined in
   [RFC2464] and [RFC6085].
"

>
It should be mentioned how IPv6 multicast addresses such as solicited-node
multicast addresses are translated into the 33-33-00-00-00-00 to
33-33-FF-FF-FF-FF range, and IANA assignments, referencing section 2.3.1 of
RFC9542 and/or
https://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml#IANA%20MAC%20ADDRESS%20BLOCK
>

7.2.  Extensions to the IP Module

"
   An incoming datagram is not rejected for having an IPv4 time-to-live
   of 1 or IPv6 Hop Limit of 1.  This field MUST not automatically be
"
>
I expect  "An incoming datagram" is still to be understood as "an incoming
multicast IP datagram" >

"
   This does also apply for the IPv6 Link-Local all-hosts
   group FF02::1, but not to other Link-Local IPv6 host groups.  See
   Section 10.7 and Appendix A.3.

   Level 2/2L hosts and gateways SHOULD permanently join to the Link-
   Local all-hosts group for the version of IP they implement.  See
   Section 10.11.

"
> There's more to it in IPv6, and joining all-nodes is a MUST for ND, see RFC
4862:

5.4.2.  Sending Neighbor Solicitation Messages

   Before sending a Neighbor Solicitation, an interface MUST join the
   all-nodes multicast address and the solicited-node multicast address
   of the tentative address.  The former ensures that the node receives
   Neighbor Advertisements from other nodes already using the address;
   the latter ensures that two nodes attempting to use the same address
   simultaneously should detect each other's presence.
>

10.8.  RFC4291 and Level 2L

 "

    Supporting only Level 2L is also
   the only option in which an IPv6 host will not send MLD messages for
   Link-Local groups because MLD (unlike IGMP) choose to mandate the
   sending of MLD messages even for Link-Local host groups.

"
> sorry I fail to parse that.

"
   This was done specifically to ensure that MLD snooping switches could
   constrain also Link-Local host groups, considering also the potential
   for local networks with IPv6 to potentially have many more hosts on
   them than with IPv4 because of the larger IPv6 addressing space.
   Implementing only Level 2L for IPv6 is thus undesirable if MLS
   snooping may be encountered in deployments of the node.  However,
   there are easily also node types that will never see this need, such
   as radio-link only nodes.  Hence the option to only support Level 2L
   for IPv6.
"
> this is also a difficult read. Note that snooping MLD for link local is
rarely implemented to my best knowledge.

10.12.  IGMP/MLD messages for Link-Local IPv4 host group addresses

> self-contradicting title, MLD and IPv4

"
   Referring to that explanation, a new MAY requirement in Section 7.2
   allowing (but not recommending) this behavior makes existing
   specifications and deployments compatible with this documents
   specifications.  It is only a MAY even though it is common in IPv4,
   because the experience with IPv6 shows that it does work (of course)
   equally well if this is not done, and can then support better MLD
   snooping than IGMP snooping.
"
> I guess joining implicitly is still joining...

A.3.  Link-local IP multicast and IGMP/MLD

   "On networks, where IP multicast packets are broadcast, such as (non-"

   > extra comma

A.4.  Application Socket Security Considerations

 "
   In result, early host stacks for IPv4 multicast did indeed have the
   problem that two UDP sockets joining to different IPv4 multicast
   addresses but the same UDP port would receive traffic destined to
"
> is that " joining two different IPv4 multicast"?

Many thanks for the hard work and great appendix A