In message <8bfcba26-22b6-4258-47dd-872a2d288169(_at_)isi(_dot_)edu>, 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(_at_)isi(_dot_)edu
<mailto:touch(_at_)isi(_dot_)edu>> 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(_at_)isc(_dot_)org