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., IPv6 Multicast Address Space Registry IANA > 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