I'm trying to ping from Pc0 to Pc1 , i've specified a default gateway in Pc0 but i didn't in Pc1 . my question is why Pc1 is dropping the ICMP packet ? i know it's because i didn't give it a default gatway , but in a topology as simple as this why don't Pc1 just send the reply to the port which he received the frame from ? what could go wrong in this case? thanks .
topology
why Pc1 is dropping the ICMP packet ?
In most cases it's not dropping the packet; it's successfully receiving the packet but unable to respond to it (i.e. it's dropping the response that it generated but couldn't send). A lot of time, this distinction can be important.
why don't Pc1 just send the reply to the port which he received the frame from
Most IP stacks are deliberately mostly stateless. There's nothing that would mark the ICMP Echo Reply packet as a "reply" at IP level – it's a brand new IP packet with no relation to the packet that prompted it.
Note that remembering just the interface is not enough – Ethernet is not a point-to-point link, it has MAC-layer addressing, so the host would need to remember the MAC address to reply to as well.
Such methods have been used in the past. For example, Mikrotik SwitchOS (for its 'management' access) used to have no gateway configuration, and would indeed always reply via the same interface and to the same MAC address that it received packets from.
But while this makes sense for highly constrained firmware, it would probably add unnecessary complexity if the host's IP stack is already capable of "standard" IP routing – there's no point in adding a whole second mechanism just to avoid the need to have to set a default route.
Another similar method that was common in the past, one that allows the host to send any packet (not just responses) is to rely on "proxy ARP" – the host would send everything via its only interface, making ARP queries for every destination it wants to talk to (as if it were local), and the router would answer queries on behalf of remote destinations. But this has somewhat of a downside that instead of just a single "default gateway" routing-table entry that covers everything, the host would accumulate individual ARP-cache entries for each and every destination.
In the end, having a separate 'default gateway' setting is simpler and more efficient than the alternatives, and automatically distributing such information is already a solved problem with DHCP (and even BOOTP).
As Journeyman Geek points out, it's not strictly the default gateway that the host needs; it only needs a gateway specifically for the destination that it wants to respond to. So it would still be able to respond even if it only had a route for the PC0&lr;Router subnet, or just for PC0's address alone.
(Such information could also be distributed automatically using RIP or OSPF – it was not unheard of for hosts to listen to RIP broadcasts, for example, and in other network types like IPX or AppleTalk it even was the normal way of operations.)
