Re: TTL Uses ???
Steve Deering <email@example.com> Fri, 14 January 1994 19:01 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10993;
14 Jan 94 14:01 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10987; 14 Jan 94 14:01 EST
Received: from world.std.com by CNRI.Reston.VA.US id aa16787; 14 Jan 94 14:01 EST
Received: by world.std.com (5.65c/Spike-2.0) id AA02339; Fri, 14 Jan 1994 12:36:56 -0500
Received: from alpha.Xerox.COM by world.std.com (5.65c/Spike-2.0) id AA02322; Fri, 14 Jan 1994 12:36:53 -0500
Received: from skylark.parc.xerox.com ([220.127.116.11]) by alpha.xerox.com with SMTP id <14779(2)>; Fri, 14 Jan 1994 09:36:28 PST
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 14 Jan 1994 09:36:20 -0800
Cc: firstname.lastname@example.org, email@example.com
Subject: Re: TTL Uses ???
In-Reply-To: bound's message of Fri, 14 Jan 94 07:52:35 -0800. <9401141552.AA18732@xirtlu.zk3.dec.com>
Date: Fri, 14 Jan 1994 09:36:14 PST
From: Steve Deering <firstname.lastname@example.org>
> Can anyone list the internet apps that depend on TTL or actually look at > from the IP datagram? > > Here are some purely guesses: > > traceroute > tcpdump > netstat Jim, IP multicast applications use the TTL field to limit the transmission distance of multicast packets. Combined with "TTL thresholds" in the multicast routers on the boundaries of administrative domains, this provides a very useful scoping function for multicasts. Note, however, that this is third function overloaded onto TTL (along with loop-breaking and maximum-lifetime enforcement), and it is an ugly hack. The right way to accomplish the scoping function, in my opinion, is through the multicast addressing, and therefore SIPP multicast addresses have an explicit scope subfield. We did not do that for IP because the 28-bits of address space available for IP multicast addresses is too small to afford the wastage of substructuring. Even with scoped multicast addresses, applications might still want to use the TTL for fine-grain limiting of multicast propagation distance, for example, for performing an "expanding ring search" (e.g.., initiate a search for a resource by sending a multicast with TTL 1, then 2, 4, ... until an answer is received or a miximum search diameter is exceeded). > I am still wondering also if TCP connects are only depending on the fact > that ICMP time exceeded/datagram dropped or watching the TTL timer? > > In all this theory it just dawned on me to check how much pain re > porting apps will be caused by this??? Don't worry about it. Almost all current IP routers treat the TTL field simply as a hop count, and not very many people are losing sleep over that. If it should become a serious concern, the right place to fix it is in TCP, as Robert said. TCP doesn't trust IP to deliver its packets in order, unduplicated, or undamaged; why whould it trust it to limit their lifetimes? The problem is easy to fix in TCP with bigger sequence numbers or timestamps, but impossible to solve in IP (because IP can run over arbitrary subnetworks and it cannot always know, learn or limit the length of time it takes a packet to traverse one of those subnetworks). Anyway, the IPng Directorate should be delighted to see that CATNIP, SIPP, and TUBA have all converged on an 8-bit hop-limit field. :-) Steve