[pim] Re: draft-ietf-pim-rfc1112bis-07 early Intdir review
Pascal Thubert <[email protected]> Fri, 27 Feb 2026 18:01:01 +0100
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <CADPqcJ+vU8J00W3E5iB7khz_K348HEKCxDbWb+Tn4NQcuUfVKQ@mail.gmail.com> |
Hello Toerless > > good to hear from you. Please see below: > > > > Le ven. 27 févr. 2026 à 03:42, Toerless Eckert <[email protected]> a écrit : > >> 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 ? >> > IoT nodes I'm aware of do not use MLD at all. When multicast is needed (e.g., WiSUN) then RFC 9685 is used. Quoting it: "The 6LN MUST also subscribe all the IPv6 multicast addresses that it listens to, and it MUST set the P-Field to 1 in the EARO for those addresses. The one exception is the all-nodes link scope multicast address ff02::1 , which is implicitly registered by all nodes, meaning that all nodes are expected to accept messages sent to ff02::1 but are not expected to register it. " > >> 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. >> >> Yes, that is fine. note that 6LoWPAN ND does not use SNMA and associated use of MLD, as opposed to traditional IPv6 ND. > 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. >> >> >> Cool > > 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. >> >> ok > > 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). > > ok > >> > 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. >> > ok > >> >> > " >> > 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. >> >> perfect > > Note that snooping MLD for link local is rarely implemented to my best >> knowledge. >> >> No idea,. wht data do you have ? >> > I thought you'd know better. I remember trying to find it in IOS and finding that you could turn MLD for FF02:: on only in one version (was that nexus?) and that was all. I looked it up out of curiosity and did not dig much so please do not trust that result too much. > 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. >> > ok > >> > " >> > 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. >> > per RFC 9685, at least for IoT nodes. > >> 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). >> > good that's consistent with the above > >> > 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. >> > Pleasure, see you soon! Pascal > >> Cheers >> Toerless >> > > > -- > Pascal > -- Pascal _______________________________________________ pim mailing list -- [email protected] To unsubscribe send an email to [email protected]