Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!GATEWAY.MITRE.ORG!barns
From: barns@GATEWAY.MITRE.ORG (Bill Barns)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  ICMP_UNREACH_PORT
Message-ID: <8905031759.AA07566@gateway.mitre.org>
Date: 3 May 89 17:59:29 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 24

I hold that there is an inherent layering wart in dealing with error
reporting of nonexistent layer-specific address selectors.  You get to
choose the form and location of your wart(s) when you design a protocol
suite, but there will be one somewhere, in some form, if you try to
implement such a function.  The justification for this argument gets
pretty involved; send mail if you want to hear it.  ICMP's approach is
arguably "best" because it provides an optional layer 3 wart which you
may use if you believe it belongs in layer 3, but (since it's optional)
you can implement a layer 4 wart when you design a layer 4 protocol if
you're so inclined, or you can ignore the whole problem by never
reporting such errors.

As for the utility of sending these errors, certainly there is no
knowing in advance whether the recipient will do anything worthwhile
with them, but the forthcoming Host Requirements RFC is attempting to
clarify the issue of service interfaces in such a way that in any
conformant implementation, there will at least be the potential for the
error report to actually be put to use.  For the case of UDP it is
required that the ICMP error be passed back to the application whose
datagram inspired it.  Whether the application makes any intelligent
use of it is an application layer issue.  See sections 3.4 and 4.1.3.3
of the HR RFC draft.  Latest edition of this draft is dated April 17, 1989.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org