A proper IPv4 implementation should also look at the intention of RFC 791:
The intention [of the TTL mechanism] is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime.
If a packet reaches its destination, we can say that it is deliverable (ergo, the packet is not undeliverable). If the packet is deliverable, then the TTL mechanism is not meant to be the cause for discarding the datagram.
Even though I cannot speak for every IPv4 implementation out there, I do not see the benefit of any end host to decrement the TTL of any datagram.
If I had to guess (or design it), the IPv4 processing software on S1 would:
- Only check if the datagram's destination IP address is equal to an IPv4 address on the S1
- If the datagram's IPv4 destination address is not present on S1, discard the datagram.
- If the datagram's IPv4 destination address is present on S1, look at the Protocol field of the IPv4 header and forward the datagram's payload to the appropriate process on S1.
- Not bother with the TTL. At all.
The above is only valid for a stub host that will never have to forward traffic. As soon as you enable routing on S1, you must perform very different IP processing.