On 7/16/2015 1:56 AM, Michael Tuexen wrote: >> > So, IMO, this is a great example of why studying these APIs as >> > abstractions is important and would have prevented this (IMO) oversight. > > Can you say specifically, what has been missed? > > My understanding is that SCTP and TCP are similar in respect to ICMP > processing > with the difference that > (a) SCTP ignore ICMP destination unreachable, port unreachable
When it MUST ignore those signals, that's fine. > (b) SCTP requires (MUST instead of SHOULD for TCP) the handling of an ICMP > destination unreachable, protocol unreachable similar to an SCTP ABORT. And this is the problem - when it acts on these signals, it never sends any information to the user. Further, ICMPs not otherwise defined are not required to be passed to the application, as is required for TCP. That's a HUGE problem for ICMP extensibility. > The reason is that there are no legacy SCTP stacks sending ICMP destination > unreachable, > port unreachable, so (a) is appropriate. (b) is for protecting hosts that > don't > support SCTP. > > The "handle like an ABORT" includes notifying the application. > > The handling of ICMP Destination unreachable (host or network unreachable) > is similar to the TCP case. If there is an SCTP state change, the user > will be notified if requested. That's not strictly required by the spec. Joe _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
