It's the most clean solution. If you drop incoming traffic, the external peer will after a timeout try again. When you reject it, the external peer knows that, and won't try again.
No, he and you are both talking about ping from Internet.
Dropping packets.
It may cause some internet traffic management functionalities to stop working, by dropping packets.
Regarding your original question,
Especially with IPv6 there is more smartness in the routing path optimization in the background, e.g. path MTU discovery. It is better to respond according to the intended behaviour of the TCP/IP protocols.
The discussion about drop/reject surfaces every now and then, so you can find also earlier discussion on that.
I've been lurking to get a better understanding of routing and came upon a reply by psherman that said drop was the default (don't know what year that was). I had, already, changed it to drop because ShieldsUp suggested it.
So I just wondered why it used to be 'drop' by default and changed to reject.
thanks!
Tldr, no. Blindly dropping icmp makes things worse.
You can of course if you like to drop other stuff but more then often it's security Theater. If you fear someone will dos you by generation icmp packets based on reject, then simply rate limit.
Edit/ps: reject makes lives easier. You will not blindly debug any connectivity issues. If the other end sends icmp and or reject you know "ah cool I can reach". There are also various icmp types/codes. To state a reason why the packet hits rejected.
Reject has been the default for the wan input rule for a very long time. It is possible I was mistaken in a past post, but I do ageee with the others here who say that reject is the preferred rule.
Do you have a link to that old post of mine that you saw?