Subject: Purpose of Port 0.

From: Danny Niu <[email-masked]>
Date: Mon, 20 Feb 2017 08:30:45 +0000

Hi, all. 

Recently on the POSIX mailing list, there's a discussion on the correct way to bind to (or listen on) an ephemeral port. While I referenced the "UNIX Network Programming", we're not quite satisfied because even though it's co-written by someone involved in IETF, it's still JUST a textbook. 

The canonical way to do this, according to some (from stackoverflow.com, and other places), is to bind to port 0, which I assume had been reserved for this purpose, but I haven't find anything to back this up yet. 

On the POSIX list, they suggested that IETF should, (or should have already) state(d) that port 0 be reserved for binding to ephemeral ports. So can we find any reference for this? Or should we draft an RFC? 

Thanks.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 20 Feb 2017 00:53:42 -0800

On 2/20/17 12:30 AM, Danny Niu wrote:
> Hi, all.
> 
> Recently on the POSIX mailing list, there's a discussion on the
> correct way to bind to (or listen on) an ephemeral port. While I
> referenced the "UNIX Network Programming", we're not quite satisfied
> because even though it's co-written by someone involved in IETF, it's
> still JUST a textbook.
> 
> The canonical way to do this, according to some (from
> stackoverflow.com, and other places), is to bind to port 0, which I
> assume had been reserved for this purpose, but I haven't find
> anything to back this up yet.
> 
> On the POSIX list, they suggested that IETF should, (or should have
> already) state(d) that port 0 be reserved for binding to ephemeral
> ports. So can we find any reference for this? Or should we draft an
> RFC?

The original convention is from berkeley sockets api, so it's been that
way since 1983 or so. it would predate therefore ieee 1003 by some
years. I would. suspect that Postel et al were well aware that it was
employed by that convention when it was noted as reserved in rfc 1340/1700.

---

From: Danny Niu <[email-masked]>
Date: Mon, 20 Feb 2017 09:05:29 +0000

Questions: 
Is "Berkerly Sockets API"  defined seperately from the BSD manpages? Or is it just sections of the BSD manpages? What happened to "Berkerly Sockets API"? 

Proposal: 
Folks at POSIX are a bit unwilling to dis-certify some allegedly existing systems, and think it'd be better IETF note the purpose of port 0, so that existing app/sys woudn't break. 
So is it too soon to start drafting? 

________________________________________
From: joel jaeggli <[email-masked]>
Sent: Monday, February 20, 2017 16:53
To: Danny Niu; [email-masked]
Subject: Re: Purpose of Port 0.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 20 Feb 2017 22:07:33 +1100

In message <[email-masked].
outlook.com>, Danny Niu writes:
> Questions:
> Is "Berkerly Sockets API"  defined seperately from the BSD manpages? Or
> is it just sections of the BSD manpages? What happened to "Berkerly
> Sockets API"?
>
> Proposal:
> Folks at POSIX are a bit unwilling to dis-certify some allegedly existing
> systems, and think it'd be better IETF note the purpose of port 0, so
> that existing app/sys woudn't break.

Well UDP source port 0 means don't reply (RFC 768).   It's for uni
directional streams.

As for 0 to select a ephemeral port that is a BSD sockets convention.
That isn't something the IETF should specify.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Mon, 20 Feb 2017 07:33:58 -0500

--On Monday, February 20, 2017 10:07 PM +1100 Mark Andrews
<[email-masked]> wrote:

> 
> In message
> <[email-masked]
> .prod. outlook.com>, Danny Niu writes:
>> Questions:
>> Is "Berkerly Sockets API"  defined seperately from the BSD
>> manpages? Or is it just sections of the BSD manpages? What
>> happened to "Berkerly Sockets API"?
>> 
>> Proposal:
>> Folks at POSIX are a bit unwilling to dis-certify some
>> allegedly existing systems, and think it'd be better IETF
>> note the purpose of port 0, so that existing app/sys woudn't
>> break.
> Well UDP source port 0 means don't reply (RFC 768).   It's for
> uni directional streams.
> 
> As for 0 to select a ephemeral port that is a BSD sockets
> convention. That isn't something the IETF should specify.

While _assignment_ of a por is an IETF matter and I mostly agree
with Mark, recognition of how one is being used is is a little
different.

It seems to me that this is rather more an IANA registry matter
than a standardization one and that, given practices today, it
would be reasonable to annotate the registry by adding "used
for" or "known to be used for" to "reserved".  

That should be mostly a housekeeping matter: could one of the
relevant ADs speak up and indicate whether they want an I-D, a
note (perhaps just this thread), a formal liaison request from
POSIX, or something else?

    john

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Feb 2017 12:40:48 +0000

Hi John,

> for" or "known to be used for" to "reserved".
Agreed.
> POSIX, or something else?
I will ask IESG.

---

From: Danny Niu <[email-masked]>
Date: Mon, 20 Feb 2017 12:46:25 +0000

That's what I'd expected, thanks. 

BTW, https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers did the same, 
except of the two references it cited, one is broken and one is not reliable enough. 

________________________________________
From: John C Klensin <[email-masked]>
Sent: Monday, February 20, 2017 20:33
To: Mark Andrews; Danny Niu
Cc: [email-masked]
Subject: Re: Purpose of Port 0.

    john

---

From: John C Klensin <[email-masked]>
Date: Mon, 20 Feb 2017 07:54:43 -0500

--On Monday, February 20, 2017 12:46 PM +0000 Danny Niu
<[email-masked]> wrote:

> BTW,
> https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
> did the same,  except of the two references it cited, one is
> broken and one is not reliable enough. 

Avoiding that sort of problem is part of what IANA registries
are supposed to be for.

Alexey, thanks,

   john

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Feb 2017 07:46:42 -0800

> Avoiding that sort of problem is part of what IANA registries
I would agree IF Wikipedia didn't insist on replicating the content of
the registry.

The best solution is to edit the Wikipedia page, but that's a Sisyphian
task.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Feb 2017 08:10:03 -0800

Hi, Danny (et al.),

On 2/20/2017 4:46 AM, Danny Niu wrote:
>> ell UDP source port 0 means don't reply (RFC 768).   It's for
>> uni directional streams.
>>
> While _assignment_ of a port is an IETF matter and I mostly agree
+1
> for" or "known to be used for" to "reserved".
The IANA port registries indicate default service interpretation for
ports used as a destination for first-contact (TCP SYN, UDP 'request'
messages intending a reply).

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)

As to the Berkeley socket convention, "0" has special meaning when used
in that API which follows mostly that already documented in RFC793. The
special meaning is for passive OPEN when indicating the foreign socket.
The other Berkeley conventions are specific to its API - if/when IANA
decided to assign 0 for active OPEN foreign sockets or other uses, then
presumably any API that could support that use would need a different
way to indicate "don't care" or "to be selected by the OS". There's no
*protocol* reason to exclude it, though, except that 793 makes it
difficult to do a passive OPEN to that port.

Finally, nearly all assigned ranges have RESERVED first and last values,
to allow for future changes. RFC820 (Jan 1983) is the first to list 0 as
RESERVED. The lists in RFC739 (Nov 1971) and 758 (Aug 1979)  starts at
1, though 0 not yet flagged as RESERVED, it is not assigned as early as
that. So, IMO, I would infer that the "not assignable" convention seems
to predate the Berkeley socket convention.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Feb 2017 08:34:50 +1300

On 21/02/2017 01:33, John C Klensin wrote:
> than a standardization one

Not quite though. Noting the RFC 768 usage as a source port, aren't
all these uses equivalent to saying 'Not valid on the wire as a
destination port'? That sounds like something the IETF should say,
as a protocol matter, and it leaves the value open for use by APIs
or other software.

This rings bells for me. Only yesterday I had to fix an unassigned
variable bug in my code for draft-ietf-anima-grasp by adding this:
    else:
        listen_port = 0

  Brian

> and that, given practices today, it
> .

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Feb 2017 14:49:30 -0800

Hi, Brian,

On 2/20/2017 11:34 AM, Brian E Carpenter wrote:
>> ...
> destination port'?

I don't think so.

768 says that if you receive 0 as source, do not reply.

That doesn't mean you can't *initiate* to port 0, if it is ever assigned.

Joe

---

From: james woodyatt <[email-masked]>
Date: Tue, 21 Feb 2017 12:05:19 -0800

On Feb 20, 2017, at 08:10, Joe Touch <[email-masked]> 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.

  <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml>>

p2. Port zero is a System Port, so the process for assigning its IANA registration is RFC 6335, section 8.1.2, which says:

>>   o  Ports in the System Ports range (0-1023) are also available for
>>       assignment through IANA.  Because the System Ports range is both
>>       the smallest and the most densely assigned, the requirements for
>>       new assignments are more strict than those for the User Ports
>>       range, and will only be granted under the "IETF Review" or "IESG
>>       Approval" procedures [RFC5226 <https://tools.ietf.org/html/rfc5226>].  A request for a System Port
>>       number MUST document *both* why using a port number from the
>>       Dynamic Ports range is unsuitable *and* why using a port number
>>       from the User Ports range is unsuitable for that application.

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.

p4. Port zero is not reserved for DCCP by RFC 4340, so port zero remains Unassigned there at this point.

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.

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, but my hunch is the need for that draft isn’t very strong (considering the intent declared in RFC 2553 to keep POSIX as the standard API for IPv6 applications) and that getting the language right would not be worth the hassle.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Feb 2017 12:25:20 -0800

Hi James,

On 2/21/2017 12:05 PM, james woodyatt wrote:
> On Feb 20, 2017, at 08:10, Joe Touch <[email-masked]
> <mailto:[email-masked]>> 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).

> 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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 22 Feb 2017 07:55:50 +1100

> the *value* passed in an API to indicate that parameter.

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Feb 2017 13:29:10 -0800

> 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.

> taking the left shoe and throwing the right shoe in the bin when
Yup. APIs are as difficult to get right as the "packet on the wire" or
state machine parts of a protocol.

Joe