In message <8bfcba26-22b6-4258-47dd-872a2d288169@xxxxxxx>, Joe Touch writes: > Hi James, > > > On 2/21/2017 12:05 PM, james woodyatt wrote: > > On Feb 20, 2017, at 08:10, Joe Touch <touch@xxxxxxx > > <mailto:touch@xxxxxxx>> wrote: > >> > >> There is no IANA registry for source ports, nor should there be. > >> Ports in the incoming first-contact are swapped, as indicated in RFCs > >> 768 and 793. Source ports indicate "who to call back", and "0" is > >> indicated in UDP (RFC768) as "nobody" and TCP (RFC793) > > > > p1. Port zero is currently Unassigned for the SCTP and DCCP standard > > transports and all the other non-standard transports listed in the > > Protocol Numbers registry. > > Per RFC6335, there is one registry for all transport port numbers. > "RESERVED" in that registry applies to all transports. > > > p2. Port zero is a System Port, so the process for assigning its IANA > > registration is RFC 6335, section 8.1.2, which says: > Agreed. > > > p3. Port zero is already reserved for SCTP by RFC 4960. IANA just > > needs to correct its registry to show that port zero is Assigned. > Per section 14.5, SCTP uses the existing transport port registry. It > lists a set of assignments starting at port 9, but does not request > assignment of 0. > > Section 3.1 prohibits the use of 0 as either source or destination port, > but that's not an assignment. That's a prohibition, and not indicated as > a reservation in the IANA Considerations (Sec 14). > > > p4. Port zero is not reserved for DCCP by RFC 4340, so port zero > > remains Unassigned there at this point. > > It remains RESERVED (as per the ports registry) but potentially > assignable to DCCP. > > > p5. Port zero is already reserved in their respective RFCs for a few > > of the non-standard transports listed in the Protocol Numbers > > registry, but being non-standard transports, thereâ??s no way to assign > > them for those protocols under the procedure in RFC 6335. > > "RESERVED" would involve IANA Considerations, and that act would have > resulted in their being recorded in the IANA registry. > > Prohibitions within the protocol do not result in IANA actions. > > > Iâ??m guessing the POSIX community could attempt to write an Internet > > Draft that expressly assigned port zero across all known and unknown > > transport protocols to the â??unspecified service numberâ?? semantic that > > it uses, > > 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. 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. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx