North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: BGP TTL check in 12.3(7)T

  • From: Iljitsch van Beijnum
  • Date: Thu Apr 08 16:04:44 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