On 2/21/2017 12:55 PM, Mark Andrews wrote: > In message <8bfcba26-22b6-4258-47dd-872a2d288169@xxxxxxx>, Joe Touch writes: >> ... >> IMO, an RFC that needs an API to pass the value "unspecified" should >> indicate just that. It would be far out of scope for an RFC to indicate >> the *value* passed in an API to indicate that parameter. >> >> Joe > Indeed. 0 is just overloaded in the BSD socket API. You need to > use raw sockets to send from port 0 when it shouldn't even be a > reserved source port as you are not expecting return traffic. FYI, that's required only for UDP traffic (and SCTP prohibits it as either source or dest). Others allow it. > We actually need a mechanism to allow 0 to be used as a source port. > setsockopts saying to assign source 0 or a bind0() system call would > be better than using a raw socket. But these are API issues. > > What's really annoying for developers is the when the IETF did > actually specfiy parts of the socket API for IPv6, POSIX only pulled > over half of it. If developers need to use the advanced half of > the API they need to do all sorts of different tricks per platform > to get them. > > Basic Socket Interface Extensions for IPv6 and Advanced Sockets API > for IPv6 are designed to be used together but POSIX has only pulled > in Basic Socket Interface Extensions for IPv6. That like only > taking the left shoe and throwing the right shoe in the bin when > you buy a pair of shoes. Yup. APIs are as difficult to get right as the "packet on the wire" or state machine parts of a protocol. Joe