Change:
I realise I'm late reviewing this, but this approach seems pretty cumbersome. Why do we need two connections, once send only and one receive only, rather than a single bidirectional connection? It also seems cumbersome to implement: both objects will be bound to the same port, and so will receive the multicast packets once the group has been joined. The send-only must then filter out those received packets?
In the multicast endpoint section, we should have explicit examples for patterns of ASM and SSM. Listen(multicast address, port, interface) Get a connection from a specific remote endpoint Initiate a connection back to talk to that endpoint, etc
We should mention the IGMP joining in Implementation, etc too
If we haven't done so, should note than one process may receive from the same address with SO_REUSEADDR so that every incoming multicast or broadcast UDP datagram destined to the shared port is delivered to all.
NAME I think the other bits about reuse address belong in implementation, filed
See my comment on – this approach seems cumbersome
For SSM, -> send only, -> receive only, makes sense. But for ASM, I'm increasingly thinking that we also want -> multicast peer that can both send and receive on a single local port: you want sender and receiver to be bound to the same local address/port pair.
I feel uncomfortable here. I have been persuaded we should add ASM Multicast. I suggest try a PR and see if this is simple and helpful?
Interim: waiting on NAME
CSP to propose a PR to see if this needs to be taken in a different direction.

Discussion:
be used to receive multicast messages.  The Remote Endpoint can be used to filter incoming multicast from specific senders.  Such a Preconnection will only support calling Listen(), not Initiate(). <del> The accepted Connections are receive-only. </del> <ins> Calling Listen() will cause the Transport Services system to register for receiving multicast, such as issuing an IGMP join RFC3376 or using MLDv2 for IPV6 RFC4604.  Any Connections that are accepted from this Listener are receive-only. </ins> Similarly, specifying a multicast group address on the Remote Endpoint will indicate that the resulting connection will be used to send multicast messages, and that the Preconnection will support <del> Initiate() but not Listen().  The Connection created this way is </del> <ins> Initiate() but not Listen().  Any Connections created this way are </ins> send-only. A Rendezvous() call on Preconnections containing group addresses results in an EstablishmentError as described in rendezvous. <ins> See multicast-examples for more examples. </ins> 6.1.2. An Endpoint can have an alternative definition when using different

Specify a Local Endpoint using a STUN server: <ins> 6.1.4. </ins> Specify a Local Endpoint using an Any-Source Multicast group to join on a named local interface: Source-Specific Multicast requires setting both a Local and Remote Endpoint: <ins> One common pattern for multicast is to both send and receive multicast.  For such cases, an application can set up both a Listener and a Connection.  The Listener is only used to accept Connections that receive inbound multicast.  The initiated Connection is only used to send multicast. </ins> 6.2. A Preconnection Object holds properties reflecting the application's