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