To trace the tunnel hops and to be visible to the tunnel traffic, this would mean that ALL routers along the way need to support EoIP, unpack the packet inside, decrease its TTL, repack it and send it to the destination. To expect something like this is hilarious at best, and totally inefficient.
If you need to trace the tunnel hops, explore the endpoint IP by a regular trace, not the tunnel itself. EoIP is just a payload in an IP data flow and there is nothing you can do about it.
In Linux, this is possible on VPNs because there is an option to set the endpoint connection's TTL to be inherited from the tunnel interface's one. But this is a synthetic solution, and I really see no benefit since it would expect the tunneled traffic to need high TTL's without added benefits because the number of hops would not be perdictible like in the regular behavior.
Torturing CCR1009-7G-1C-1S+, RB450G, RB750GL, RB951G-2HnD, RB960PGS, RB260GSP, OmniTIK 5HnD and NetMetal 922UAGS-5HPacD + R11e-5HnD in my home network.