[ih] IPv8...

[John Day]

Thanks for the correction.

Not terribly precise, but I wouldn’t expect that.
I presume there then has to be some method for notifying stations and links that they should be willing? Seems to be an unnecessary complication. In most multicast proposals/implementations I have seen, an application requests to join a service that uses multicast, which would seem to make ‘willingness’ moot. 

(Applications shouldn’t have to specifically request multicast. The provider determines whether to simply send n copies or use multicast. It is the provide that benefits, not the application.)

Thanks again,
John

> On Apr 21, 2026, at 11:31, Craig Partridge <craig at tereschau.net> wrote:
> 
> 
> 
> On Tue, Apr 21, 2026 at 8:58 AM John Day via Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>> Let me try to provide some other definitions of multicast and anycast that will either help or confuse things.
>> 
>> First the definition of multicast in the Internet is patterned after multicast in Ethernet. That definition assumes that all stations see all packets, which implies flooding. This is what happens in Ethernet so it is quite natural and works well. However, it isn’t so useful for general networks, where one would like to avoid flooding. Perhaps a better more abstract definition would be:
>> (I hesitate to call it a multicast *address* even though it is taken from the IP address space because an address is location-dependent and route-independent. That doesn’t really apply to multicast in general.)
> 
> You clearly don't understand Deering's contribution to multicast.  He took the semantics of Ethernet multicast and generalized it to an Internet such that "all stations see all packets" but rather only those stations and links willing to receive/carry the multicast address (or, if you wish, a group of multicast addresses of which the target multicast address is one) see the packet.
> 
> This simplification also applies to anycast in an Internet context.
> 
> Craig
> 
> --
> *****
> Craig Partridge's email account for professional society activities and mailing lists.