Path: utzoo!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!nosc!ucsd!rutgers!caip.rutgers.edu!aramis.rutgers.edu!geneva.rutgers.edu!hedrick From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: connection between ARP and ICMP... Message-ID: Date: 6 Jan 89 05:01:52 GMT References: <8901052354.AA05731@beta.lanl.gov> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 28 To: mws%beta@LANL.GOV I think it's very wierd to say "host unreachable" because you don't have an ARP table entry. In my view unreachable should mean that you really can't get to the host, not that your internal cache needs refreshing. There's no question that it is a bug for hosts to break a connection when they get an unreachable while a connection is open. There may be a transient routing problem that will clear up shortly. The recommended approach is to save the error message but keep retrying. If you end up timing out, then you print the error based on the most recent unreachable. Thus the unreachable does accomplish something: it gives you some information about what is wrong, which is useful in generating an intelligent error message. But you sure don't want to break the connection the first time you get an unreachable. (Doing so is a common bug in TCP/IP implementations, however.) I've heard claims that when you are first setting up a connection, you should pay attention to unreachables. A user who is in the middle of a connection likely has time invested in his context and is willing to wait in hopes of continuing. But when you're first trying a connection, you don't, and it's silly to make people wait for a minute to time out of a connection attempt when you know that there's no route available to the destination. That sounds sort of plausible to me, but I think I might still wait for a timeout. I my opinion, both the gateway and the host are behaving suboptimally in your example. I'm not sure they are flatly wrong, but I'd try to get them changed. I think the host should ignore the unreachables, or use them only as a basis for error messages. And I think the gateway shouldn't issue them for a missing ARP table entry. (Indeed probably it shouldn't issue them at all, because of the number of buggy host implementations.)