Original text:
scenarios, endpoints MUST follow the recommendations from BCP38 to prevent source address spoofing.  11. 11.1.

Reviewer comments:
Addressing the monitoring possibilities that connect request with ICMP scope has if sharing IP address as discussed in .
Over email, Mike Bishop mentioned: When looking into this I noticed that the section states the following about the IP Protocol field: But the section states: This is contradictory. I would recommend removing the recommendation in Error Signalling.
I don't think this is contradictory. The former text says "we will send you traffic whether you like it or not". The latter says "you should do something useful with it". Certainly it could be wordsmithed a bit, but I don't think an outright removal is a good idea as we should still give guidance to users that they are expected to do something if they're doing ipproto-based routing.
That doesn't match my understanding. To me, the former says "you don't need to send a route with ipproto=ICMP because it's always allowed" but the latter says "you SHOULD send a route with ipproto=ICMP"
I think those are compatible? The former is saying you don't have to, the latter is signaling you've acknowledged and will do something useful with it.
Isn't that just wasted bytes?
I could imagine a server doing something useful with this information. Maybe having different ratelimits for ICMP traffic for a well-behaved client that will process the messages. But this only applies in the cases where you're using ipproto scoping, so I am not too worried about the bytes-wasted
If we intend to have recipients act on this information, we should clearly define what it's meant to convey, otherwise we'll create interoperability issues.
That's fair. To be clear, I do not object to removing the text as you originally suggested. I just wanted to clarify that I didn't consider the current situation a contradiction.
I think we need to clarify this a bit as it actually exist three different interpretation depending on what was requested. So if the requester do a Connect request with ipproto=1 scope: I will get all ICMP message for this IP address would be my interpretation. This is fine to ask for, but I think we need a security consideration note on this. This should only be allowed if this external IP address that is assigned is only used by this requesting endpoint. Otherwise it will allow some possibility to overhead what the other endpoint attempt to do when ICMP messages are generated back towards this IP address. So if the connect request is for ipproto=6 (TCP): In this case we have two interpretations of what has been written. A) The IP proxy will send ICMP messages to the requesting endpoint to indicate issues. B) The IP proxy will match any incoming ICMP messages on the external IP address assgined and forward them to the requestor. So what I expect to happen is that A) will always happen, but it is unclear if B) will happen. I think we want to make clear that B) MAY/SHOULD/MUST be done. I will write a PR for the security consideration for requesting ICMP traffic for an assigned address.
Overall I totally agree with this change, but I think the wording needs some work. I've included a proposal.

Revised text:
scenarios, endpoints MUST follow the recommendations from BCP38 to prevent source address spoofing. <ins> Limiting request scope (see scope) allows two clients to share one of the proxy's external IP addresses if their requests are scoped to different IP protocol numbers.  If the proxy receives an ICMP packet destined for that external IP address, it has the option to forward it back to the clients.  However, some of these ICMP packets carry part of the original IP packet that triggered the ICMP response. Forwarding such packets can accidentally divulge information about one client's traffic to another client.  To avoid this, proxies that forward ICMP on shared external IP addresses MUST inspect the invoking packet included in the ICMP packet and only forward the ICMP packet to the client whose scoping matches the invoking packet. </ins> 11. 11.1.