On 8-apr-04, at 20:37, Blaine Christian wrote:
However, this says a TTL of 254 will be accepted. Now the fact that I can talk to boxes running a slightly older IOS with a TTL of 0 without any problems suggests to me that emitting packets with a TTL of 255 on router A and accepting packets with a TTL of 254 on router B allows for the presence of a router C in the middle. That can't be good.
I suspect they set the limit to 254 because they expected to decrement the TTL on ingress (or that the box sending the packets would decrement on send).
But neither common sense nor observations support this expectation.
You have an interesting point WRT the TTL 0. Perhaps if you receive a packet with a TTL of 0 that is destined for yourself you should just accept it?
The interesting thing is that packets with a TTL of 0 wouldn't ordinarily be seen in the wild. A router won't forward a packet with a TTL of 1 (as this becomes 0 during the forwarding process) and a host that sends out packets with a TTL 0 can only expect to communicate on the local subnet. (So I guess doing all of this with TTL 0 rather than 255 would have been just as effective.)
It is not clear to me exactly when you "have" to throw away the packet (on ingress/themiddle/egress). I believe it is valid to accept a packet that is destined for yourself with a TTL of zero.
Agree. Yet another interesting aspect: a Cisco won't forward a packet with a TTL of 0: Minimum Time to Live [1]: 0 Maximum Time to Live [30]: 4 Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 23.16.3.14 0 23.16.3.19 8 msec 0 msec 4 msec 1 23.16.3.19) 4 msec 4 msec 4 msec 2 23.16.3.14) 12 msec * 16 msec So apparently a Cisco checks for TTL <= 1 on ingress when forwarding rather than TTL == 0 on egress. How hard do we have to look before we find a box that doesn't and accepts a packet with a TTL of 0 and then emits this packet with a TTL of 255?
Since I have observed that packets received from some types of routers have their TTL set to 255 (on upon reaching the receiving device route processor) I would have to assume that the TTL is not being decremented for route processor packets. Of course I was only playing with one router and it may be vendor dependant (the vendor was not Cisco).
In the (Free)BSD (4.9) code the TTL decrementing is done in the ip_forward() function. (That is, unless IPSTEALTH is defined, in which case the box doesn't bother.) Since many a router vendor borrowed code from BSD it is likely most do it like this.
I am not sure that 254 is a good maximum number. Perhaps someone "in the know" can enlighten all of us as to why they chose to stop at 254 instead of 255.
Yes, that would be helpful. Iljitsch