On Apr 21, 2004, at 4:43 PM, Mike Tancsa wrote: >> The default TTL gets decremented with every hop, which means that a >> packet coming in with a TTL of 255 had to be sent by a directly >> connected system. [ip_ttl is an octet, so it can't hold a larger TTL >> value.] A packet with a TTL of 64 could have been many hops away. > > Thanks, I realize that. My question is, what unintended consequences > might happen if the default is changed to 255 from 64. As one poster > said, if a packet generated by that host had a ttl of 255, it would > bounce around a lot more if it was trying to reach a host with a bad > route somewhere. Certainly true, but are we talking about changing the default TTL for FreeBSD, or only for routers running BGP where both sides agree to implement RFC-3682? I wouldn't expect a router to be initiating much traffic on it's own. > I am no IP expert, but I have been around long enough to know that > these default values get set only after long arduous debates and often > there are tradeoffs by raising or lowering a value. I guess I am > trying to find that original debate to see what I might be in for by > implementing this with my peers who request it. Changing the TTL to 255 means one should adjust the TCP MSL to ~4 minutes, rather than one minute. RFC-791 says: This field must be decreased at each point that the internet header is processed to reflect the time spent processing the datagram. Even if no local information is available on the time actually spent, the field must be decremented by 1. The time is measured in units of seconds (i.e. the value 1 means one second). Thus, the maximum time to live is 255 seconds or 4.25 minutes. Since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist. The intention is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime. Some higher level reliable connection protocols are based on assumptions that old duplicate datagrams will not arrive after a certain time elapses. The TTL is a way for such protocols to have an assurance that their assumption is met. RFC-793 says: To be sure that a TCP does not create a segment that carries a sequence number which may be duplicated by an old segment remaining in the network, the TCP must keep quiet for a maximum segment lifetime (MSL) before assigning any sequence numbers upon starting up or recovering from a crash in which memory of sequence numbers in use was lost. For this specification the MSL is taken to be 2 minutes. This is an engineering choice, and may be changed if experience indicates it is desirable to do so. Note that if a TCP is reinitialized in some sense, yet retains its memory of sequence numbers in use, then it need not wait at all; it must only be sure to use sequence numbers larger than those recently used. -- -Chuck _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"