-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-kuehlewind-system-ports-02.xml
237 lines (223 loc) · 16.5 KB
/
draft-kuehlewind-system-ports-02.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC6335 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6335.xml">
<!ENTITY RFC4844 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4844.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-kuehlewind-system-ports-02" ipr="trust200902">
<front>
<title abbrev="Reassignment of System Ports">Reassignment of System Ports to the IESG</title>
<author fullname="Mirja Kühlewind" initials="M." role="editor"
surname="Kühlewind">
<organization>ETH Zurich</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date year="2018" />
<abstract>
<t>In the IANA Service Name and Transport Protocol Port Number Registry
a large number of System Ports is currently assigned to individuals or
companies who have registered the port for the use with a certain
protocol before RFC6335 was published. For some of these ports, RFCs
exist that describe the respective protocol; for others, RFCs are under
development that define, re-define, or assign the protocol used for
the respective port, e.g. in case of so-far unused UDP ports that
have been registered together with the respective TCP port. In these
cases the IESG has the change control about the protocol used on the
port (as described in an RFC) but does not have the change control
about the port usage itself. Currently, to transfer the change
control to the IESG, the original assignee has to be contacted to
initialize this transfer. As it is not always possible to get
in touch with the original assignee, e.g. because of out-dated
contact information or more severe reasons, and the current practice
of case-by-case changes does not scale well, this document instructs
IANA to perform actions with the goal to reassigns all System Ports
to the IESG that have been assigned to individuals prior to the
publication of RFC6335.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>RFC 6335 <xref target="RFC6335"/> requires System Ports, also known as the Well Known Ports, in the range from 0 to 1023, to be assigned by the "IETF Review" or "IESG Approval" procedures <xref target="RFC5226"/>. Further, for assignments done through RFCs published via the "IETF Document Stream" <xref target="RFC4844"/>, the Assignee will be the IESG with the IETF Chair as the Contact. Therefore, all System Ports must be assigned to the IESG.</t>
<t>However, ports that were assigned before the publication of RFC 6335, are often assigned to individuals, even if they are part of the System Port range. Besides the fact that System Ports that are widely used by IETF protocols under IETF change control, this is especially problematic if the assignment is or should be changed. The Assignee, can change the assignment without confirmation of the IETF. However, if the IETF process requires a change, including de-assignment, this cannot be done without the agreement of the original Assignee. Furthermore, no procedure is defined to change the assignment in cases where the original Assignee is not reachable or for any other reason not available anymore, </t>
<t>This document instructs IANA to perform actions with the goal to re-assign all currently assigned System Ports in the range from 0 to 1023 to the IESG, with will also help to aligning existing entries in the "Service Name and Transport Protocol Port Number Registry" with the current procedures defined in RFC 6335.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA [will perform/has performed] action to re-assign all System Ports in the port range from 0 to 1023 that are currently assigned in the "Service Name and Transport Protocol Port Number Registry" (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) to the IESG <[email protected]> as Assignee and the IETF Chair <[email protected]> as Contact. The original Assignee and respective contact information should be preserved as a Assignment note "Originally assigned to $Assignee <$Contact>" where $Assignee is the current value in the Assignee column and $Contact is the current value in the Contact column.</t>
<t>To perform the assignment IANA is requested to contact the current Assignees by email with the registered email address to request the transfer. If the provided email address is not valid anymore, IANA is requested to report this to the IESG and the IESG is requested to perform actions, such as sending requests to the [email protected] mailing list to determine updated contact information. If these action do not show success within 4 weeks, the IESG is requested to make a decision about the re-assignment of the port in question.</t>
<t>IANA is requested to send the following request to each current Assignees:</t>
<t>"Dear $Assignee, you are the assignee for port $Port in the Service
Name and Transport Protocol Port Number Registry. This port is part
of the System Ports range which has a registration policy of "IETF
Review" or "IESG Approval" as defined in RFC6335 given the System
Ports range is already densely assigned. To enable future
documentation in the RFC series of the protocol in use for this port,
we would like to request you to confirm that you agree to de-assign
the port to enable a subsequent re-assignment to the IESG. We will
still note you as the original assignee with this contact information
in the registry, expect you prefer to not be noted anymore. Please
let us know if there is any reason to not perform this change, or if
the port is known to not be used (anymore) and can be reclassified as
reserved instead. Also if you have information about a publicly available
specification of the protocol in use on the respective port that is
not noted in the registry yet, we would be graceful to learn about
this and update the notes in the registry accordingly."</t>
<t>If the current Assignee does not agree to the re-assignment or does not reply within four weeks, IANA is requested to inform the IESG which then is requested to make a decision about the re-assignment of the port in question.</t>
<t>Before the start of this re-assignment process, IANA [will also update/has further updated] the Reference column with the following reference for the listed ports that have a corresponding published RFC that uses this port number, as well as the Assignment Notes column for historic RFCs:</t>
<texttable align="center">
<ttcol>Service Name</ttcol><ttcol>Port Number</ttcol><ttcol>Transport protocol</ttcol><ttcol>Reference</ttcol><ttcol>Assignment Notes</ttcol>
<c>systat</c><c>11</c><c>tcp</c><c>RFC866</c><c></c>
<c>systat</c><c>11</c><c>udp</c><c>RFC866</c><c></c>
<c>qotd</c><c>17</c><c>tcp</c><c>RFC865</c><c></c>
<c>qotd</c><c>17</c><c>upd</c><c>RFC865</c><c></c>
<c>msp</c><c>18</c><c>tcp</c><c>RFC1312</c><c></c>
<c>msp</c><c>18</c><c>udp</c><c>RFC1312</c><c></c>
<c>chargen</c><c>19</c><c>tcp</c><c>RFC864</c><c></c>
<c>chargen</c><c>19</c><c>udp</c><c>RFC864</c><c></c>
<c>smtp</c><c>25</c><c>tcp</c><c>RFC5321</c><c></c>
<c>smtp</c><c>25</c><c>udp</c><c>RFC5321</c><c></c>
<c>time</c><c>37</c><c>tcp</c><c>RFC868</c><c></c>
<c>time</c><c>37</c><c>udp</c><c>RFC868</c><c></c>
<c>rap</c><c>38</c><c>tcp</c><c>RFC1476</c><c></c>
<c>rap</c><c>38</c><c>udp</c><c>RFC1476</c><c></c>
<c>rlp</c><c>39</c><c>tcp</c><c>RFC887</c><c></c>
<c>rlp</c><c>39</c><c>udp</c><c>RFC887</c><c></c>
<c>nicname</c><c>43</c><c>tcp</c><c>RFC3912</c><c></c>
<c>nicname</c><c>43</c><c>udp</c><c>RFC3912</c><c></c>
<c>tacacs</c><c>49</c><c>tcp</c><c>RFC1492</c><c></c>
<c>tacacs</c><c>49</c><c>udp</c><c>RFC1492</c><c></c>
<c>domain</c><c>53</c><c>tcp</c><c>RFC1035</c><c></c>
<c>domain</c><c>53</c><c>udp</c><c>RFC1035</c><c></c>
<c>whoispp</c><c>63</c><c>tcp</c><c>RFC1913</c><c></c>
<c>whoispp</c><c>63</c><c>udp</c><c>RFC1913</c><c></c>
<c>bootps</c><c>67</c><c>tcp</c><c>RFC2131</c><c></c>
<c>bootps</c><c>67</c><c>udp</c><c>RFC2131</c><c></c>
<c>bootpc</c><c>68</c><c>tcp</c><c>RFC2131</c><c></c>
<c>bootpc</c><c>68</c><c>udp</c><c>RFC2131</c><c></c>
<c>tftp</c><c>69</c><c>tcp</c><c>RFC1350</c><c></c>
<c>tftp</c><c>69</c><c>udp</c><c>RFC1350</c><c></c>
<c>gopher</c><c>70</c><c>tcp</c><c>RFC1436</c><c></c>
<c>gopher</c><c>70</c><c>udp</c><c>RFC1436</c><c></c>
<c>finger</c><c>79</c><c>tcp</c><c>RFC1288</c><c></c>
<c>finger</c><c>79</c><c>udp</c><c>RFC1288</c><c></c>
<c>www-http</c><c>80</c><c>tcp</c><c>RFC7230, RFC7540</c><c></c>
<c>www-http</c><c>80</c><c>udp</c><c>RFC7230, RFC7540</c><c></c>
<c>kerberos</c><c>88</c><c>tcp</c><c>RFC4120</c><c></c>
<c>kerberos</c><c>88</c><c>udp</c><c>RFC4120</c><c></c>
<c>dixie</c><c>96</c><c>tcp</c><c>RFC1249</c><c></c>
<c>dixie</c><c>96</c><c>udp</c><c>RFC1249</c><c></c>
<c>hostname</c><c>101</c><c>tcp</c><c>RFC953</c><c>This RFC is historic.</c>
<c>hostname</c><c>101</c><c>udp</c><c>RFC953</c><c>This RFC is historic.</c>
<c>cso</c><c>105</c><c>tcp</c><c>RFC2378</c><c></c>
<c>cso</c><c>105</c><c>udp</c><c>RFC2378</c><c></c>
<c>rtelnet</c><c>107</c><c>tcp</c><c>RFC818</c><c>This RFC is historic.</c>
<c>rtelnet</c><c>107</c><c>udp</c><c>RFC818</c><c>This RFC is historic.</c>
<c>sunrpc</c><c>111</c><c>tcp</c><c>RFC1833</c><c></c>
<c>sunrpc</c><c>111</c><c>udp</c><c>RFC1833</c><c></c>
<c>auth</c><c>113</c><c>tcp</c><c>RFC1413</c><c></c>
<c>auth</c><c>113</c><c>udp</c><c>RFC1413</c><c></c>
<c>sftp</c><c>115</c><c>tcp</c><c>RFC913</c><c>This RFC is historic.</c>
<c>sftp</c><c>115</c><c>udp</c><c>RFC913</c><c>This RFC is historic.</c>
<c>cfdptkt</c><c>120</c><c>tcp</c><c>RFC1235</c><c></c>
<c>cfdptkt</c><c>120</c><c>udp</c><c>RFC1235</c><c></c>
<c>pwdgen</c><c>129</c><c>tcp</c><c>RFC972</c><c></c>
<c>pwdgen</c><c>129</c><c>udp</c><c>RFC972</c><c></c>
<c>imap</c><c>143</c><c>tcp</c><c>RFC3501</c><c></c>
<c>imap</c><c>143</c><c>udp</c><c>RFC3501</c><c></c>
<c>bftp</c><c>152</c><c>tcp</c><c>RFC1068</c><c></c>
<c>bftp</c><c>152</c><c>udp</c><c>RFC1068</c><c></c>
<c>sgmp</c><c>153</c><c>tcp</c><c>RFC1028</c><c>This RFC is historic.</c>
<c>sgmp</c><c>153</c><c>udp</c><c>RFC1028</c><c>This RFC is historic.</c>
<c>snmp</c><c>161</c><c>tcp</c><c>RFC3430</c><c></c>
<c>snmp</c><c>161</c><c>udp</c><c>RFC3417</c><c></c>
<c>snmptrap</c><c>162</c><c>tcp</c><c>RFC3430</c><c></c>
<c>snmptrap</c><c>162</c><c>udp</c><c>RFC3417</c><c></c>
<c>bgp</c><c>179</c><c>tcp</c><c>RFC4271</c><c></c>
<c>bgp</c><c>179</c><c>udp</c><c>RFC4271</c><c></c>
<c>irc</c><c>194</c><c>tcp</c><c>RFC1459</c><c></c><!-- This one is strange, because RFC 1459 defines IRC, but proposes no ports. -->
<c>irc</c><c>194</c><c>udp</c><c>RFC1459</c><c></c><!-- This one is strange, because RFC 1459 defines IRC, but proposes no ports. -->
<c>smux</c><c>199</c><c>tcp</c><c>RFC1227</c><c>This RFC is historic.</c>
<c>smux</c><c>199</c><c>udp</c><c>RFC1227</c><c>This RFC is historic.</c>
<c>ipx</c><c>213</c><c>tcp</c><c>RFC1234</c><c>This RFC is historic.</c>
<c>ipx</c><c>213</c><c>upd</c><c>RFC1234</c><c>This RFC is historic.</c>
<c>mpp</c><c>218</c><c>tcp</c><c>RFC1204</c><c></c>
<c>mpp</c><c>218</c><c>udp</c><c>RFC1204</c><c></c>
<c>bgmp</c><c>264</c><c>tcp</c><c>RFC3913</c><c>This RFC is historic.</c>
<c>bgmp</c><c>264</c><c>udp</c><c>RFC3913</c><c>This RFC is historic.</c>
<c>pt-tls</c><c>271</c><c>tcp</c><c>RFC6876</c><c></c>
<c>pt-tls</c><c>271</c><c>udp</c><c>RFC6876</c><c></c>
<c>rtsps</c><c>322</c><c>tcp</c><c>RFC7826</c><c></c>
<c>rtsps</c><c>322</c><c>udp</c><c>RFC7826</c><c></c>
<c>odmr</c><c>366</c><c>tcp</c><c>RFC2645</c><c></c>
<c>odmr</c><c>366</c><c>udp</c><c>RFC2645</c><c></c>
<c>aurp</c><c>387</c><c>tcp</c><c>RFC1504</c><c></c>
<c>aurp</c><c>387</c><c>udp</c><c>RFC1504</c><c></c>
<c>ldap</c><c>389</c><c>tcp</c><c>RFC4516</c><c></c>
<c>ldap</c><c>389</c><c>udp</c><c>RFC4516</c><c></c>
<c>svrloc</c><c>427</c><c>tcp</c><c>RFC2608</c><c></c>
<c>svrloc</c><c>427</c><c>udp</c><c>RFC2608</c><c></c>
<c>https</c><c>443</c><c>tcp</c><c>RFC7230, RFC7540</c><c></c>
<c>https</c><c>443</c><c>udp</c><c>RFC7230, RFC7540</c><c></c>
<c>kpasswd</c><c>464</c><c>tcp</c><c>RFC3244</c><c></c>
<c>kpasswd</c><c>464</c><c>udp</c><c>RFC3244</c><c></c>
<c>photuris</c><c>468</c><c>tcp</c><c>RFC2522</c><c></c>
<c>photuris</c><c>468</c><c>udp</c><c>RFC2522</c><c></c>
<c>isakmp</c><c>500</c><c>tcp</c><c>RFC7296</c><c></c>
<c>isakmp</c><c>500</c><c>udp</c><c>RFC7296</c><c></c>
<c>syslog</c><c>514</c><c>tcp</c><c>RFC5426</c><c></c>
<c>syslog</c><c>514</c><c>udp</c><c>RFC5426</c><c></c>
<c>printer</c><c>515</c><c>tcp</c><c>RFC1179</c><c></c>
<c>printer</c><c>515</c><c>udp</c><c>RFC1179</c><c></c>
<c>router</c><c>520</c><c>tcp</c><c>RFC2453</c><c></c>
<c>router</c><c>520</c><c>udp</c><c>RFC2453</c><c></c>
<c>ripng</c><c>521</c><c>tcp</c><c>RFC2080</c><c></c>
<c>ripng</c><c>521</c><c>udp</c><c>RFC2080</c><c></c>
<c>rtsp</c><c>554</c><c>tcp</c><c>RFC7826</c><c></c>
<c>rtsp</c><c>554</c><c>udp</c><c>RFC7826</c><c></c>
<c>vemmi</c><c>575</c><c>tcp</c><c>RFC2122</c><c></c>
<c>vemmi</c><c>575</c><c>udp</c><c>RFC2122</c><c></c>
<c>ipp</c><c>631</c><c>tcp</c><c>RFC8010</c><c></c>
<c>ipp</c><c>631</c><c>udp</c><c>RFC8010</c><c></c>
<c>msdp</c><c>639</c><c>tcp</c><c>RFC3618</c><c></c>
<c>msdp</c><c>639</c><c>udp</c><c>RFC3618</c><c></c>
<c>ldp</c><c>646</c><c>tcp</c><c>RFC3036</c><c></c>
<c>ldp</c><c>646</c><c>udp</c><c>RFC3036</c><c></c>
<c>rrp</c><c>648</c><c>tcp</c><c>RFC2832</c><c></c>
<c>rrp</c><c>648</c><c>udp</c><c>RFC2832</c><c></c>
<c>aodv</c><c>654</c><c>tcp</c><c>RFC3561</c><c></c>
<c>aodv</c><c>654</c><c>udp</c><c>RFC3561</c><c></c>
<c>acap</c><c>674</c><c>tcp</c><c>RFC2244</c><c></c>
<c>acap</c><c>674</c><c>udp</c><c>RFC2244</c><c></c>
<c>olsr</c><c>698</c><c>tcp</c><c>RFC3626</c><c></c>
<c>olsr</c><c>698</c><c>udp</c><c>RFC3626</c><c></c>
<c>agentx</c><c>705</c><c>tcp</c><c>RFC2741</c><c></c>
<c>agentx</c><c>705</c><c>udp</c><c>RFC2741</c><c></c>
</texttable>
<t>As part of this maintainance effort, IANA [will further add/has further added] the following entry in addition to the existing entry for port 441 with the IESG as Assignee and the IETF chair as Contact:</t>
<texttable align="center">
<ttcol>Service Name</ttcol><ttcol>Port Number</ttcol><ttcol>Transport protocol</ttcol><ttcol>Reference</ttcol><ttcol>Assignment Notes</ttcol>
<c>rmt</c><c>441</c><c>tcp</c><c>RFC1202</c><c>For historical reasons, multiple registrations exist for the same port number. Clients need to have prior knowledge of which service is provided by the server on that port in order to make use of it.</c>
</texttable>
</section>
<section anchor="Security" title="Security Considerations">
<t>This draft instructs IANA to perform actions on the Service Name and Transport Protocol Port Number Registry. It does not change the use of the ports or protocols running on them. Therefore
the security of these protocols in not impacted by these changes to the registry.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC6335;
</references>
<references title="Informative References">
&RFC4844;
&RFC5226;
</references>
</back>
</rfc>