]> Ericsson GmbH

ietf@kuehlewind.net

sabrina.tanamal@iana.org

In the IANA Service Name and Transport Protocol Port Number Registry, a large number of System Ports are 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, such as 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 the corresponding RFC) but change control for the port allocation iis designated to others. Under existing operational procedures, this means the original assignee needs to be involved in chnage to the port assignment. As it is not always possible to get in touch with the original assignee, particularly because of out-dated contact information, this current practice of handling historical allocation of System Ports does not scale well on a case-by-case basis. To address this, this document instructs IANA to perform actions with the goal to reassign System Ports to the IESG that were assigned to individuals prior to the publication of RFC6335, where appropriate.

RFC 6335 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 . For assignments done through RFCs published via the "IETF Document Stream" , the Assignee will be the IESG with the IETF Chair as the Contact. 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 and have a corresponding RFC. Besides the fact that System Ports are widely used by IETF protocols where the protocol specification is under IETF change control as defined in an RFC but the port itself may not, this situation is especially problematic if the assignment gets or needs to 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 not available anymore. This document mainly aims to clarify the change control for protocols that are maintained by the IETF; it further also intends an update of currently unused or not maintained ports. For this purpose this document instructs IANA to perform accumulative actions with the goal to re-assign currently assigned System Ports in the range from 0 to 1023 to the IESG, where appropriate, which will also help to align existing entries in the "Service Name and Transport Protocol Port Number Registry" with the current procedures defined in RFC 6335.

IANA [will perform/has performed] actions with the goal to re-assign 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 clarify the IESG's responisibility in managing those allocations. When the re-assignment is performd, the contact data for these assignments should be adjusted to refelct the IESG <iesg@ietf.org> as assignee and the IETF Chair <chair@ietf.org> as point of contact. The original assignee and respective contact information should be preserved as a note against the revised assignment data. To perform the re-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 actions do not show success within 4 weeks, the IESG is requested to make a decision about the re-assignment of the port in question. 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 NamePort NumberTransport protocolReferenceAssignment Notes systat11tcpRFC866 systat11udpRFC866 qotd17tcpRFC865 qotd17updRFC865 msp18tcpRFC1312 msp18udpRFC1312 chargen19tcpRFC864 chargen19udpRFC864 smtp25tcpRFC5321 smtp25udpRFC5321 time37tcpRFC868 time37udpRFC868 rap38tcpRFC1476 rap38udpRFC1476 rlp39tcpRFC887 rlp39udpRFC887 nicname43tcpRFC3912 nicname43udpRFC3912 tacacs49tcpRFC1492 tacacs49udpRFC1492 domain53tcpRFC1035 domain53udpRFC1035 whoispp63tcpRFC1913 whoispp63udpRFC1913 bootps67tcpRFC2131 bootps67udpRFC2131 bootpc68tcpRFC2131 bootpc68udpRFC2131 tftp69tcpRFC1350 tftp69udpRFC1350 gopher70tcpRFC1436 gopher70udpRFC1436 finger79tcpRFC1288 finger79udpRFC1288 www-http80tcpRFC7230, RFC7540 www-http80udpRFC7230, RFC7540 kerberos88tcpRFC4120 kerberos88udpRFC4120 dixie96tcpRFC1249 dixie96udpRFC1249 hostname101tcpRFC953This RFC is historic. hostname101udpRFC953This RFC is historic. cso105tcpRFC2378 cso105udpRFC2378 rtelnet107tcpRFC818This RFC is historic. rtelnet107udpRFC818This RFC is historic. pop2109tcpRFC937This RFC is historic. pop2109udpRFC937This RFC is historic. pop3110tcpRFC1939 pop3110udp sunrpc111tcpRFC1833 sunrpc111udpRFC1833 auth113tcpRFC1413 auth113udpRFC1413 sftp115tcpRFC913This RFC is historic. sftp115udpRFC913This RFC is historic. cfdptkt120tcpRFC1235 cfdptkt120udpRFC1235 pwdgen129tcpRFC972 pwdgen129udpRFC972 bftp152tcpRFC1068 bftp152udpRFC1068 sgmp153tcpRFC1028This RFC is historic. sgmp153udpRFC1028This RFC is historic. snmp161tcpRFC3430 snmp161udpRFC3417 snmptrap162tcpRFC3430 snmptrap162udpRFC3417 bgp179tcpRFC4271 bgp179udpRFC4271 irc194tcpRFC1459 irc194udpRFC1459 smux199tcpRFC1227This RFC is historic. smux199udpRFC1227This RFC is historic. ipx213tcpRFC1234This RFC is historic. ipx213updRFC1234This RFC is historic. mpp218tcpRFC1204 mpp218udpRFC1204 bgmp264tcpRFC3913This RFC is historic. bgmp264udpRFC3913This RFC is historic. pt-tls271tcpRFC6876 pt-tls271udpRFC6876 rtsps322tcpRFC7826 rtsps322udpRFC7826 odmr366tcpRFC2645 odmr366udpRFC2645 aurp387tcpRFC1504 aurp387udpRFC1504 ldap389tcpRFC4516 ldap389udpRFC4516 svrloc427tcpRFC2608 svrloc427udpRFC2608 https443tcpRFC7230, RFC7540 https443udpRFC7230, RFC7540 kpasswd464tcpRFC3244 kpasswd464udpRFC3244 photuris468tcpRFC2522 photuris468udpRFC2522 isakmp500tcpRFC7296 isakmp500udpRFC7296 syslog514tcpRFC5426 syslog514udpRFC5426 printer515tcpRFC1179 printer515udpRFC1179 router520tcpRFC2453 router520udpRFC2453 ripng521tcpRFC2080 ripng521udpRFC2080 rtsp554tcpRFC7826 rtsp554udpRFC7826 vemmi575tcpRFC2122 vemmi575udpRFC2122 ipp631tcpRFC8010 ipp631udpRFC8010 msdp639tcpRFC3618 msdp639udpRFC3618 ldp646tcpRFC3036 ldp646udpRFC3036 rrp648tcpRFC2832 rrp648udpRFC2832 aodv654tcpRFC3561 aodv654udpRFC3561 acap674tcpRFC2244 acap674udpRFC2244 olsr698tcpRFC3626 olsr698udpRFC3626 agentx705tcpRFC2741 agentx705udpRFC2741 As part of this maintenance 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 NamePort NumberTransport protocolReferenceAssignment Notes rmt441tcpRFC1202For 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.

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 is not impacted by these changes to the registry.

&RFC6335; &RFC4844; &RFC8126;