Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ultra.UUCP!wayne From: wayne@ultra.UUCP (Wayne Hathaway) Newsgroups: comp.protocols.tcp-ip Subject: ICMP_UNREACH_PORT Message-ID: <8905021609.AA00846@lear.ultra.com> Date: 2 May 89 16:09:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 63 Whilst doing some load-testing of our in-house net, I noticed some surprising behavior; I'd be interested in some expert comments. First the configuration: Several Sun 3's running SunOS 4.0.1, connected by an UltraNet (our product, but basically irrelevant to the question). Next the situation: We seemed to be having some troubles with the checksum hardware on one of our cards (in a diskless Sun 3/140, to be specific), resulting in excessive discarding of datagrams. To test it, I started up a process on another Sun which sent a steady stream of 8K UDP datagrams to a random port on the 3/140. Since I was interested in datagrams tossed by the card rather than the SunOS kernel, I did not bother having anybody do a "recvfrom" on the 3/140 (in other words, the datagrams would be tossed by the 3/140's UDP). [By the way, the UltraNet MTU is larger than 8K, so these datagrams are legal.] Okay, the strangeness: Looking at counters, I noticed that not only did the 3/140 receive (say) 854 datagrams, it also SENT exactly 854 datagrams. It didn't take too much detective work to figure out what the outgoing datagrams were -- they were ICMP messages with Type 3, Code 3: "Destination Port Unreachable". My question is "Why?" I realize this behavior is perfectly LEGAL (since the ICMP spec [RFC 792] says "If ... the IP module cannot deliver the datagram because the ... process port is not active, the destination host may send a destination unreachable message to the source host."), it just seemed strange to see 4.3 BSD actually doing it. First of all, I'm a great believer in the idea of "if something weird happens, build a datagram describing it and launch it towards some logging host, then forget it." But if that host's logging program isn't up, this is going to result in DOUBLE the network traffic (at least in number of datagrams). No great "overload" problem, of course, but it does seem silly, particularly since (for UDP datagrams, at least) the original sending host isn't really going to be able to DO anything with the information. And second, what is IP doing talking about ports anyway??? I mean, ports are upper layer artifacts, no? According to my trusty grep, the word "port" does not even APPEAR in the IP spec (RFC 791)! But then, the ICMP spec DOES say "If ... the IP module cannot deliver the datagram because the ... process PORT is not active" so SOMEBODY sure expects IP to be in the port business! (The spec also mentions ports in a couple of other places, but they don't seem to be particularly relevant.) Actually, what is happening in 4.3 BSD is that UDP is turning around and causing its ICMP to send the ICMP_UNREACH_PORT message. Nothing illegal about this, of course, but it does get us back to the previous question: why bother? (The UDP action is in udp_usrreq.c and is prefaced by the comment "don't send ICMP response for broadcast packet" -- I would ask why EVER send it?! Also I note that TCP does not seem to ever send an ICMP_UNREACH_PORT.) Anyway, any thoughts from all the IP/ICMP/BSD gurus out there? Wayne Hathaway Ultra Network Technologies domain: wayne@Ultra.COM 101 Daggett Drive Internet: ultra!wayne@Ames.ARC.NASA.GOV San Jose, CA 95134 uucp: ...!ames!ultra!wayne 408-922-0100