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

Thank you so much, Eric. All integrated into -08

inline!

On Tue, Jan 27, 2026 at 04:01:17PM -0800, Erik Nordmark via Datatracker wrote:
> Document: draft-ietf-pim-rfc1112bis
> Title: Host Extensions for IP Multicasting and "Any Source Multicasting" (ASM)
> IP service Reviewer: Erik Nordmark Review result: Ready with Issues
> 
> I have a question around Level 2L, which is new to me. In the past there has
> been an assumption that layer 2 devices (bridges, L2 switches) can perform
> IGMP/MLD snooping to determine what to filter based on Ethernet multicast
> addresses. Back in the day this possible except that the all-hosts (IPv4) and
> all-nodes (IPv6) would always need to be forwarded at L2. Has the industry
> moved away from IGMP/MLD snooping? And is the draft trying to say that an
> implementation is free to implement support for IGMP/MLD snooping but it is not
> part of the standard? (The intent of the different sections are not quite clear
> to me on this topic.)

I had tried to explain this in A.3, but your question made me revisit this
which wasn't all that easy because there are a couple of intertwined bits
and pieces. So this A.3 is now rewritten.

It has a paragraph explaining how link-local scope with IPv6 is very different
from IPv4 because it has enough addresses so applications can use it. In IPv4
it was just 224.0.0.0/24, so only used for few protocols. And this is also the
reason why MLD mandates to be used for link-local, whereas IGMP did not.

A.3 now also explicitly calls out the case of subnets without any hosts and
guaranteed no snooping switches, and on those IGMP/MLD can be quite redundant.
And L2 addresses on those subnets allows to forego IGMP/MLD - for just link-local.

And the example are radio subnets between RPL routers where the only multicast
that needs to be multicast to hosts are thre link-local routing protocol
packets such as from RPL. You don't want to implement a whole useless IGMP/MLD
stack on those constrained devices unless you have good reasons.

So there's an actual iotdir review brownie point here ;-)

Now, i haven't received actual confirmation from ROLL folks on this point
(you where Cc'edon my email), so i guess i have to try to hunt them down
at IETF125 or bring it up with Pascals review feedback - i by myself
am not 100% sure i am correct on this... Just 90% ;-))

I also added another A.4 explaining how this works for IP multicast gateways
(routers) because technically IP multicast routers also have jsut a host
stack, but tey can also optimize IGMP/MLD away. And the way how they can
then still be compliant with this spec is simply by stating that
a gateway host stack can superceed these (non-gateway)host stack
requirements - even though it can happily share the stack to the degree it
wants.

> Security considerations: have there been any discussion about the fact that
> applications should not assume that traffic sent to a link-local multicast
> address was sent by a host on the attached link? (various tunneling approaches
> can be used to have a router potentially send such a packet on a link.) Is this
> worth noting?

Remind me: How would the attack vector work with unicast ? When an IPv6
router decapsulates an inner packet with a link-local scope address, how would
it know, which subnet to send it out to ? Is there really some common behavior
that IPv6 hosts (or routers) would forward such a decapsulated packet to
e.g.: the same interface to which the outer IPv6 tunnel packet was addressed ?

In multicast, i am quite certain this attack vector does not exist. From having
worked with many different type of routers. There are simply no link-local scope
multicast forwarding entries. And forwarding is prohibited by this documents
section 8 - and that is based on pre-existing decade old BCP/standard IPv4/IPv6
specs as well.

So, the only way how this could exist in reality as an attack vector would
be if the problem exists for unicast, and the unicast code would handle an
encapsulated link-local-scope multicast destination address as if it was unicast
(but still set the right MAC-layer multicast destination).

So, quite sure this attack vector does not exist in reality... But happy
to warn about it, if i am wrong!

> Terminology nit:
> For better or worse, the IPv6 RFCs do not use the term "IPv6 host group", yet
> in this document that term appears three times. Some of those are odd - "IPv6
> host group address" should be replaced by "IPv6 multicast address". The one in
> section 4 might make sense to keep (but reword) to make the connection with the
> IPv4 terminology. Thus I'd suggest changing "IPv6 Host groups are identified by
> IPv6 addresses" to "In IPv6 the concept of host groups are identified by IPv6
> multicast addresses" or something along those lines.

The term "host group" (address) is applied a lot more in this
specification to IPv6 than just the cases you identified because they explicitly
called out "IPv6":

All cases of "IP host group" do equally apply to IPv4 and IPv6
because that's how "IP" is defined in this document. It implies both IPv4 and IPv6!!!

I have highlighted that sentence from the summary section to make it even
more obvious.

I have added a new section "10.14 Terminology" that dissuses if/when and
how one should use which term. I am explicitly referencing the case of rfc4291 and
rfc8200 in it (by example) and why the choice of terminology is fine in the case
of those documents. That should hopefully address your concern. This terminology 
stuff is a real pain to get right.

I have also reworked the text from section 6.4 to make the use of host group
more clear in there. 

In 7.2 i have corrected the term "IPv6 host groups" to "IPv6 host group
addresses" - brcause this was actually about the addresses, not the group
of receivers. In IPv6 there is the painful option that nobody has ever
used, that you could even have a Link-Local IPv6 SSM (FF32::/8), which is
why i wanted to be correct instead of just talking about IPv6 multicast
addresses. ANd not starting explain that there could be an FF32::/8.

I have also replaced all instances of "SSM channel address" with "SSM destination
address" as a result of now nailing down on the terminology (thats the official
term of rfc4607).

> Section 9.2:
> I'm having a hard time parsing this sentence "do or may include backward
> compatibility with IGMPv1" since it isn't clear what "do or may" means when
> referring to existing specifications. Is this intended to refer to
> implementations?

"do" was referring to existing specifications with backward compatibility with
IGMPv1. "may" refererred to future RFCs that may do the same.

I have reworded two paragraphs, separating the mentioning of existing specs
from future specs to hopefully make the wording clearer:

| Current versions of IGMP ({{IGMPv2}}, {{IGMPv3}}) and other protocols/mechanisms 
| including, but not limited to {{RFC5790}} or {{IGMPsnooping}} do include backward compatibility
| with IGMPv1.  This requires them to refer to {{RFC1112}} as the specification for IGMPv1.

| This document does not ask for any change to any current or future specifications or
| implementations that includes any form of support for IGMPv1 for backward compatibility 
| reasons. Backward compatibility is when a specification also includes support for any newer
| version of IGMP starting with {{IGMPv2}} and prefers it over IGMPv1.

| Any new or updated specification that wants to maintain such backward compatibility with
| IGMPv1 need to continue to reference {{RFC1112}} as the specification of IGMPv1.

> Section 10.8 typo: "MLS" should be "MLD".

Fixed.

> Section 12.2 says "keep an IP multicast address secret"
> That can easily be read as "secure" when "obscure" would be a better name for
> it. This is an observation about the pssibility to have randomly generated IPv6
> multicast addresses, and if such are used, it is hard (but not impossible) to
> find them by trial and error. But many IPv6 protocols use well-defined fixed
> multicast addresses.

Fixed to:

The larger address space of IPv6 multicast groups may make it harder for an IPv6  multicast address from being successfully discovered by undesired receivers, but many IPv6 multicast addresses are not random but well-defined.

Thanks a lot for the review!

Cheers
    Toerless

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