[pim] Re: rfc1112bis and 224.0.0.1

[Toerless Eckert <[e-mail]>]

On Fri, Jun 13, 2025 at 02:19:30PM -0700, Stig Venaas wrote:
> Hi Toerless and wg
> 
> We should try to wrap up this draft soon

Thanks a lot!

Check out draft-ietf-pim-rfc1112bis-04.

Answers below.

> and I have a few things I
> would like to discuss first. One thing is regarding the all-hosts
> group 224.0.0.1.

Sigh... So, every time someone raises what looks like a small issue, i stumble
across a big heap of historic manure.

Did you know that the current requirements to support IP multicast are as follows:

  - SHOULD support IPv4 multicast send/receive as in RFC1112,
    BUT WITHOUT IGMP, only MAY implement IGMP (specified in RFC1122 - no requirement in RFC1112!)
  - No requirement whatsoever to support IPv6 multicast, just
    dependency ("if host needs it") (RFC8504).

So, i tried to make sense out of this heap, this cost a bit of new text,
but given how we had a (crappy) requirement for IPv4 hosts to support
IPv4 multicast from RFC1122, the benefit is that now rfc1112bis (rev  4) does now
include a "all Internet hosts SHOULD support IP multicast (send/receive) for IPv4 and IPv6".

Felt this was significant enough to still do it. Otherwise we'd be
left with still RFC1122 being the unchallenged normative requirement for Internet hosts.

And what rfc1122 says is actually the reason for a lot of this link-local without
IGMP that we see in old code. Alas, i had to add a definition of that mode
of IP multicast (Level 2L), because rfc1122 doesn't even explain how it's supposed
to work.

Anyhow. This is what i stumbled across when trying to figure out 224.0.0.1
usage as you wanted to discuss (and grep found me rfc1122 ;-).

So, back to topic:

> Toerless, you concluded that this can be left to the individual igmp protocol,
>
> but to me this seems like a generic multicast host stack issue.
>
> I imagine there might be protocols relying on hosts responding to 224.0.0.1.
>
> And also that it might be used by management tools or
> manual testing to verify that a host is present.

So: There is no technical necessity for the IP multicast host stack to permanently
join 224.0.0.1/FF02::1. Any protocol or management tool can simply do a JoinHostGroup(224.0.0.1)
to ensure it will be received. Whether or not IGMP/MLD are used. It just needs
triggering of the MAC filter. 

I primarily feld it was nasty that IGMP/MLD simply inherited a requirement from
RFC1112 without us saying so much in RFC1112bis.

When i grep'ed through all RFCs, i could find the following ones using RFC224.0.0.1

RFC1256 - (IRDP) - pretty much deprecated IMHO
RFC2004 - IP Mobility support
RFC6281 - Apple's Back to My Mac (BTMM) Service
RFC6886 - NAT port mapping
RFC6887 - PCP

I think they're all fairly obsolete.

However: I also read through the linux kernel today, and it still has this 224.0.0.1
exception in it. And so i think do all other implementations. And there is no
good reason for causing unnecessary churn.

So, in result, i have written the permanent join requirement as a SHOULD
and written the explanations into section 10.10.

The only example i could come up for Steve Deerings "it's simpler" is actually
a use of 224.0.0.1: ICMP echo Had to dig a while before it would work
again for me (security of course having it disable don all my modern machines,
but i remembered it from back in the past).

Hope this resolves your point.

> In IPv6 the all-nodes address is a key part of the architecture and
> not part of MLD.

I have not seen FF02::1 being mentioned in any IPv6 arch/addressing spec.

It is simply used by the neighbor discovery protocol. Yes, those RA
messages also seem to be processed directly by the kernel, so the simplicity
argument would equally apply (or not apply ;-) as for ICMP echo.

Should i add that RA example to 10.10 so we have one for IPv6 ?

Thanks a lot!
    Toerless

> 
> Anyone else have any thoughts on this?
> 
> Thanks,
> Stig
> 

-- 
---
[e-mail]