[pim] Re: draft-ietf-pim-rfc1112bis-07 early Intdir review
Toerless Eckert <[email protected]> Fri, 27 Feb 2026 03:42:33 +0100
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <[email protected]> |
Thanks a lot, Pascal. Great stuff. Replies inline. All integrated into -08 Let me front-end one question resulting from text i addd due to other reviews where you are the expert. I also posted as Q to [email protected] Can you confirm or reject the claim/possibility of the following: - RPL nodes (normal nodes, not leightweight leafs or so) - (constrained) radio interface/subnet attachments (802.15.*or the like) - interface/subnet also only connecting to normal nodes (not leaves) - Not supporting IP multicast routing (not running MPL or the like). Do all node implementations you know use MLD to announce membership for ff02::1a ? I am asking because the "Level 2L" of rfc1112bis would allow nodes such as these RPL nodes to NOT have to use/implement MLD in cases like this where MLD does not really do anything useful - so it would be great to have evidence that that is actually already done in the industry. more inline On Mon, Feb 09, 2026 at 07:01:43AM -0800, Pascal Thubert via Datatracker wrote: > Document: draft-ietf-pim-rfc1112bis > Title: Host Extensions for IP Multicasting and "Any Source Multicasting" (ASM) > IP service Reviewer: Pascal Thubert Review result: Ready with Nits > > 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 Ack. Already fixed from Erics review. > 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. fixed. > > 4. HOST GROUP ADDRESSES > > "The IPv4 Link-Local addresses 224.0.0.0 is" > > > addresses -> address fixed. > " The IPv6 Link-Local all-hosts group > address is FF02::1. > " > > > Please use canonical form (see RFC 5952), that is ff02::1. Darn. I should have been long enough around Brian Carpenter to know better. Shame ;-) fixed. > 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. > fixed. > " 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> Done. > 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. Added following explanatory text: Note that as described in {{level2}}, ND ({{RFC4861}}) itself operates on top of the IPv6 Service Interface as extended by this document because it relies on sending/receiving IPv6 multicast packets. However, it is shown as part of the Local Network Module because that is the component in this host stack model that relies on ND to perform its operation. > 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 I've added sentence: Note that {{RFC9542}} establishes an "IANA OUI Ethernet Numbers" registry covering the IPv4 and IPv6 multicast MAC address ranges. This actually also made me catch the fact that that registry had listed rfc1112 as reference for the IPv4 MAC address range, so i added an IANA request to updated that range. The 33-33 range is not really part of the registry, it's just part of the explanation and only points to RFC9542, whereas it should actually point to RFC2464 and RFC6085... Wonder if i should add an IANA ask for that. > > > > 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" > That's actual rfc1112 text, so i'll be more defensive with it as it has served well for 40 years (and has surprisingly well stood the test of time). A datagram with an IP multicast destination address is not necessarily an IP multicast datagram. It could as well be invalid. And those cases are discussed further down in the same section. So i imagine i could even be getting confused if the text would say multicast IP datagram, because i would wonder if that applies then also to those invalid packets. > 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. > > 224.0.0.1/FF02::1 are unique in that the host stack is expected to join to them even when there is no "application" socket open at all that needs them. For 224.0.0.1, rfc1112 had some weird explanation from Steve that this would make implementations easier, i never figured out why. But IPv6 with MLD did inherited this wisdom, so it's just kept as legacy truth. ND with neighbor solicitation address is a "normal" link-local multicast group. It is joined (only) whenever ND is run. And ND isn't mandatory on alls subnets, as described by RFC4861, the excerpt also cited in RFC8504, section 5.4 (referenced in the rfc1112bis "Level 2" spec part). > 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 is effectively about my top-posted question. I rephrased the wording Choosing to support only Level 2L is also the only option in which an IPv6 host or gateway will not need to send MLD messages for Link-Local groups because the {{MLDv2}} specification (unlike IGMP) choose to mandate the sending of MLD messages even for Link-Local host groups. > " > 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. I have removed that paragraph and now point to the new, more detailled appendix A.3 that covers this better i hope. > Note that snooping MLD for link local is rarely implemented to my best knowledge. No idea,. wht data do you have ? Point still is that MLDv2 requirement to support it is a good rule to support what IPv6 can do better. Just those cases where it would be problematic need to be better worried about (IMHO). > 10.12. IGMP/MLD messages for Link-Local IPv4 host group addresses > > > self-contradicting title, MLD and IPv4 Thanks, typo. Should be just "IP". Fixed. > " > 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... There is no definition what "implicit joining" should be. If "implicit joining" to you means to not send IGMP/MLD membership reports, then that's exactly the option that is being added through a couple of added text in this doc vs. rfc1112 to allow for all known well-working implementations to be compliant: not sending IGMP membership for link-local in IPv4, and not doing so when you're ONLY ever going to use link-local groups in IPv6 (Level 2L). > A.3. Link-local IP multicast and IGMP/MLD > > "On networks, where IP multicast packets are broadcast, such as (non-" > > > extra comma Replaced text. > 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"? fixed to: In result, early host stacks for IPv4 multicast did indeed have the problem that two UDP sockets each joining to a different IPv4 multicast address but the same UDP port would receive traffic destined to either IPv4 multicast addresses. > Many thanks for the hard work and great appendix A Thanks! And thanks for all the feedback. Cheers Toerless _______________________________________________ pim mailing list -- [email protected] To unsubscribe send an email to [email protected]