>-----Original Message----- >From: Taps [mailto:[email protected]] On Behalf Of Michael Tuexen >Sent: Thursday, June 04, 2015 9:20 PM >To: Joe Touch >Cc: Pal Martinsen (palmarti); [email protected] >Subject: Re: [Taps] TAPS Transports and ICMP > >> On 04 Jun 2015, at 20:27, Joe Touch <[email protected]> wrote: >> >> >> >> On 6/4/2015 11:15 AM, Pal Martinsen (palmarti) wrote: >>> >>>> On 04 Jun 2015, at 17:43, Joe Touch <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>> On 6/4/2015 3:48 AM, Pal Martinsen (palmarti) wrote: >>>> ... >>>>> Does it make sense for the TAPS transports draft to add ICMP? >>>> >>>> ICMP is not a transport protocol. >>> >>> Sure. And I agree. But it has the potential to influence how the various >>> transport protocols behave. That interaction might be nice to have >>> described in the transports draft. >> >> Abstract APIs need to be described. These are part of that description. >> >>>> The ways in which transport protocols either terminate or pass-through >>>> ICMP messages is part of the transport protocol abstract API. >>>> >>>> E.g., for UDP and TCP see RFC1122. >>>> >>>> UDP passes all ICMP messages to the app. >>>> >>> No. Not unless the application specifically listens for it. >> >> UDP passes all ICMP messages to the app. If the app doesn't listen for >> it, that's the app's decision. >> >>> Unfortunately how to do this varies from OS to OS: >>> See https://tools.ietf.org/html/draft-martinsen-tram-stuntrace- >01#appendix-A.2 for >>> examples. >> >> You are confusing the OS and language-dependent implementation of the >> API with the abstract API. >> >> RFC1122 requires that UDP implementations make the ICMP signals >> available to the application. It does not indicate by what mechanism. >> >>> Listening for port unreachable can be nice to avoid spamming a host or >>> application that recently crashed. Detecting fragmentation or max MTU is >>> also a nice feature especially VoIP applications sending video can >>> utilise to optimise their packet sizes. >> >> UDP is required to pass ALL ICMP messages to the app layer, as per RFC >1122. >> >>>> TCP passes only dest unreachable types 0, 1, and 5, time exceeded and >>>> parameter problem. All others it interprets or ignores internally and >>>> it’s not clear it should pass up to the app. >>> >>> That is exactly that kind of information I would find useful in the >>> transports draft. >> >> Well, yes - IMO, that's because it's part of the abstract API. >> >>> Any pitfalls with ICMP when doing SCTP? >> >> In many ways, SCTP subsumes similar requirements as TCP, but that's >> probably buried in the SCTP docs. >It is. See >https://tools.ietf.org/html/rfc4960#appendix-C >
[Karen ] In this context then it is noteworthy to observe that SCTP defacto API (spec or implementations, I know) does not prescribe for that the SCTP transport passes information of received ICMP messages (any kind/type/code) up to SCTP User. Here SCTP is significantly different from UDP and TCP defacto APIs. For security reasons SCTP demands for hard reaction to receipt of protocol unreachable, but that is a protocol feature not an api issue. BR, Karen >Best regards >Michael >> >> Joe >> >> _______________________________________________ >> Taps mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps > >_______________________________________________ >Taps mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
