Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!fernwood!asylum!romkey
From: romkey@asylum.SF.CA.US (John Romkey)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: ICMP_UNREACH_PORT
Message-ID: <1978@asylum.SF.CA.US>
Date: 3 May 89 22:50:25 GMT
References: <8905021609.AA00846@lear.ultra.com>
Reply-To: romkey@asylum.UUCP (John Romkey,The Asylum)
Organization: The Asylum; Belmont, CA
Lines: 29

In article <8905021609.AA00846@lear.ultra.com> wayne@ultra.UUCP (Wayne
Hathaway) writes about not understanding why he got some ICMP port
unreachables.

The system you tested against was behaving quite properly, both
according to the specs and according to the intentions.

The port unreachables aren't meant to go to some logging host, they're
meant to go back to the system that generated the packets that
couldn't be delivered. Port unreachable is an error indication
mechanism so that UDP-based applications can find out that no one was
home on the other side. Otherwise, there's no way for UDP to tell. You
could do this for TCP, too, but TCP explicitly uses the TCP reset
mechanism, instead.

IP doesn't and shouldn't send these messages. The layering works like
this: UDP gets a packet, checks if there's something listening on the
destination port. If there is, it delivers it, no problem. If there
isn't, it asks ICMP to generate a port unreachable message.

IP should send PROTOCOL unreachables. I don't have a copy of the IP
RFC handy, so I'm not going to double check on what the actual text
says.

Anyway, 4.3 is doing things correctly here.
-- 
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@xx.lcs.mit.edu
"We had some good machines/But they don't work no more" - Shriekback