BGP TTL check in 12.3(7)T
Iljitsch van Beijnum
iljitsch at muada.com
Thu Apr 8 19:45:29 UTC 2004
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
More information about the NANOG
mailing list