Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!earth.cray.com!droid
From: droid@earth.cray.com (Andy Nicholson)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  ICMP_UNREACH_PORT
Message-ID: <8905031531.AA14991@galf.cray.com>
Date: 3 May 89 15:31:05 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 57

> 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?"

The answer probably is "Because the protocol spec makes it available and
it is probably a good thing to do."  Note that this is more of a
rationalization.  Nowhere that I can think of does the spec say it has
to be done this way.  I would tend to agree that it is probably a good thing
to do.

I find it easy to conceive of an IP implementation on a more advanced operating
system where the IP could receive the ICMP message, make a determination of
the process sending the offending datagram, and asynchronously notify that
process (via a mechanism like signals, and using a signal like SIGPIPE) that
the destination port was not there.  Or the IP could keep a list of
unavailable ports and return a write error to UDP (but only for a short period
of time, as a port may appear later).  There are probably lots of things that
could be done with the message.  It is probably there because it seemed like
"the right thing" to the implementor.

> 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.)

I see you are naive regarding layering of TCP/IP.  They are, but only sometimes.
TCP and UDP protocols make a lot of assumptions about how IP works in order
to gain some performance improvements, like sticking in a partially filled
IP header at the front of the TCP or UDP packet that is passed on to IP.
The fact of the matter is that layering is great from a conceptual view,
but it nukes performance.  Finally, the IP concept of an upper level protocol
port is not the same as the UDP or IP port.  The IP protocol merely makes
the assumption that upper level protocols will have some demultiplexing
mechanism (which they may or may not) and call this the port.  They could
have called this something like endpoint id or demux, or whatever, but port
gets the point across just fine.  Again, although the protocols are layered,
it was pretty much assumed that there was a great likelyhood of finding
TCP and UDP above IP.

> 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.)

TCP does not send an unreachable port message because it sends a reset segment
instead, as the TCP protocol spec says to.  That is why telnet returns
immediately with "connection refused" if you telnet to a machine that is up
but does not have its telnet server running.

Andy Nicholson			droid@earth.cray.com