[pim] Re: draft-ietf-pim-rfc1112bis-07 early Intdir review

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 ?
>
> 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
>


-- 
Pascal

_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]