Path: utzoo!attcan!uunet!lll-winken!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!rutgers!mcnc!rti!dg-rtp!bigben!bigben!philip From: philip@beeblebrox.dle.dg.com (Philip Gladstone) Newsgroups: comp.protocols.tcp-ip Subject: Re: Death on ICMP unreachable also harmful Message-ID: Date: 18 Nov 90 21:32:37 GMT References: <1990Nov16.164448.9918@bwdls61.bnr.ca> <9011170344.AA20268@gaak.LCS.MIT.EDU> <1990Nov17.164522.9996@ugle.unit.no> Sender: usenet@dle.dg.com (Net News) Organization: Data General, Development Lab Europe Lines: 25 In-Reply-To: he@spurv.runit.sintef.no's message of 17 Nov 90 16:45:22 GMT Havard Eidnes writes: > The Host Requirements state > that a host implementation of TCP MUST NOT do this (specifically: the ICMPs > net unreachable, host unreachable or source route failed should be > considered temporary failures and not permanent conditions). Some gateways > have the ability to turn off the sending of ICMP net unreachables, but this > is just a workaround for "broken" host implementations. I have found that most implementations of TCP/IP do not return net/host unreachable messages even when they know that the path to the net/host is not available. Is this due to the existence of the 'broken' implementations as mentioned above? For example, on a lan which uses ARP, the host 'knows' that the remote machine is not present when the ARP request times out. At this point, it tends to drop the datagram. I would prefer to get back 'net unreachable' messages rather than the ubiquitous 'timeout' message. -- Philip Gladstone Development Lab Europe Data General, Cambridge England. +44 223-67600