Network Working Group M. Kühlewind, Ed.
Internet-Draft ETH Zurich
Intended status: Standards Track March 5, 2018
Expires: September 6, 2018

Reassignment of System Ports to the IESG
draft-kuehlewind-system-ports-02

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 6, 2018.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

RFC 6335 [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 [RFC5226]. Further, for assignments done through RFCs published via the "IETF Document Stream" [RFC4844], the Assignee will be the IESG with the IETF Chair as the Contact. Therefore, all System Ports must be assigned to the IESG.

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,

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.

2. IANA Considerations

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 <iesg@ietf.org> as Assignee and the IETF Chair <chair@ietf.org> 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.

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 ietf@ietf.org 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.

IANA is requested to send the following request to each current Assignees:

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

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.

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:

Service Name Port Number Transport protocol Reference Assignment Notes
systat 11 tcp RFC866
systat 11 udp RFC866
qotd 17 tcp RFC865
qotd 17 upd RFC865
msp 18 tcp RFC1312
msp 18 udp RFC1312
chargen 19 tcp RFC864
chargen 19 udp RFC864
smtp 25 tcp RFC5321
smtp 25 udp RFC5321
time 37 tcp RFC868
time 37 udp RFC868
rap 38 tcp RFC1476
rap 38 udp RFC1476
rlp 39 tcp RFC887
rlp 39 udp RFC887
nicname 43 tcp RFC3912
nicname 43 udp RFC3912
tacacs 49 tcp RFC1492
tacacs 49 udp RFC1492
domain 53 tcp RFC1035
domain 53 udp RFC1035
whoispp 63 tcp RFC1913
whoispp 63 udp RFC1913
bootps 67 tcp RFC2131
bootps 67 udp RFC2131
bootpc 68 tcp RFC2131
bootpc 68 udp RFC2131
tftp 69 tcp RFC1350
tftp 69 udp RFC1350
gopher 70 tcp RFC1436
gopher 70 udp RFC1436
finger 79 tcp RFC1288
finger 79 udp RFC1288
www-http 80 tcp RFC7230, RFC7540
www-http 80 udp RFC7230, RFC7540
kerberos 88 tcp RFC4120
kerberos 88 udp RFC4120
dixie 96 tcp RFC1249
dixie 96 udp RFC1249
hostname 101 tcp RFC953 This RFC is historic.
hostname 101 udp RFC953 This RFC is historic.
cso 105 tcp RFC2378
cso 105 udp RFC2378
rtelnet 107 tcp RFC818 This RFC is historic.
rtelnet 107 udp RFC818 This RFC is historic.
sunrpc 111 tcp RFC1833
sunrpc 111 udp RFC1833
auth 113 tcp RFC1413
auth 113 udp RFC1413
sftp 115 tcp RFC913 This RFC is historic.
sftp 115 udp RFC913 This RFC is historic.
cfdptkt 120 tcp RFC1235
cfdptkt 120 udp RFC1235
pwdgen 129 tcp RFC972
pwdgen 129 udp RFC972
imap 143 tcp RFC3501
imap 143 udp RFC3501
bftp 152 tcp RFC1068
bftp 152 udp RFC1068
sgmp 153 tcp RFC1028 This RFC is historic.
sgmp 153 udp RFC1028 This RFC is historic.
snmp 161 tcp RFC3430
snmp 161 udp RFC3417
snmptrap 162 tcp RFC3430
snmptrap 162 udp RFC3417
bgp 179 tcp RFC4271
bgp 179 udp RFC4271
irc 194 tcp RFC1459
irc 194 udp RFC1459
smux 199 tcp RFC1227 This RFC is historic.
smux 199 udp RFC1227 This RFC is historic.
ipx 213 tcp RFC1234 This RFC is historic.
ipx 213 upd RFC1234 This RFC is historic.
mpp 218 tcp RFC1204
mpp 218 udp RFC1204
bgmp 264 tcp RFC3913 This RFC is historic.
bgmp 264 udp RFC3913 This RFC is historic.
pt-tls 271 tcp RFC6876
pt-tls 271 udp RFC6876
rtsps 322 tcp RFC7826
rtsps 322 udp RFC7826
odmr 366 tcp RFC2645
odmr 366 udp RFC2645
aurp 387 tcp RFC1504
aurp 387 udp RFC1504
ldap 389 tcp RFC4516
ldap 389 udp RFC4516
svrloc 427 tcp RFC2608
svrloc 427 udp RFC2608
https 443 tcp RFC7230, RFC7540
https 443 udp RFC7230, RFC7540
kpasswd 464 tcp RFC3244
kpasswd 464 udp RFC3244
photuris 468 tcp RFC2522
photuris 468 udp RFC2522
isakmp 500 tcp RFC7296
isakmp 500 udp RFC7296
syslog 514 tcp RFC5426
syslog 514 udp RFC5426
printer 515 tcp RFC1179
printer 515 udp RFC1179
router 520 tcp RFC2453
router 520 udp RFC2453
ripng 521 tcp RFC2080
ripng 521 udp RFC2080
rtsp 554 tcp RFC7826
rtsp 554 udp RFC7826
vemmi 575 tcp RFC2122
vemmi 575 udp RFC2122
ipp 631 tcp RFC8010
ipp 631 udp RFC8010
msdp 639 tcp RFC3618
msdp 639 udp RFC3618
ldp 646 tcp RFC3036
ldp 646 udp RFC3036
rrp 648 tcp RFC2832
rrp 648 udp RFC2832
aodv 654 tcp RFC3561
aodv 654 udp RFC3561
acap 674 tcp RFC2244
acap 674 udp RFC2244
olsr 698 tcp RFC3626
olsr 698 udp RFC3626
agentx 705 tcp RFC2741
agentx 705 udp RFC2741

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:

Service Name Port Number Transport protocol Reference Assignment Notes
rmt 441 tcp RFC1202 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.

3. Security Considerations

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.

4. References

4.1. Normative References

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M. and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011.

4.2. Informative References

[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, July 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008.

Author's Address

Mirja Kühlewind (editor) ETH Zurich EMail: ietf@kuehlewind.net

Table of Contents