<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-netconf-port-numbers-07" number="9900" category="std" updates="" obsoletes="" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.30.1 -->version="3" xml:lang="en"> <front> <title abbrev="NETCONF Transport Port Numbers">Updates to NETCONF Transport Port Numbers</title> <seriesInfoname="Internet-Draft" value="draft-ietf-netconf-port-numbers-07"/>name="RFC" value="9900"/> <author fullname="Mohamed Boucadair"> <organization>Orange</organization> <address> <email>mohamed.boucadair@orange.com</email> </address> </author> <date year="2025"month="September" day="16"/> <area>Operations and Management</area> <workgroup>Network Configuration</workgroup>month="December"/> <area>OPS</area> <workgroup>netconf</workgroup> <keyword>de-assign</keyword> <keyword>deallocate</keyword> <keyword>release</keyword><abstract> <?line 33?> <t>This<!--[rfced] May we update the abstract as follows or otherwise so that NETCONF is expanded? Original: This document releases NETCONF-related port number IANA assignments for services that have not been in use in productionnetworks.</t> </abstract> <note removeInRFC="true"> <name>Discussion Venues</name> <t>Discussion of thisnetworks. Perhaps: This documenttakes place onreleases IANA-assigned port numbers for services related to the Network ConfigurationWorking Group mailing list (netconf@ietf.org), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/netconf/"/>.</t> <t>SourceProtocol (NETCONF) that have not been in use in production networks. --> <abstract> <t>This document releases NETCONF-related port number IANA assignments forthis draft and an issue tracker can be found at <eref target="https://github.com/boucadair/netconf-port-numbers"/>.</t> </note>services that have not been in use in production networks.</t> </abstract> </front> <middle><?line 37?><section anchor="introduction"> <name>Introduction</name> <t>The "Service Name and Transport Protocol PortNumber" registryNumber Registry" <xref target="IANA-SERVICE"/> records several NETCONF-related port and service name assignments such as 830 for NETCONF over Secure Shell (SSH) <xref target="RFC6242"/>, 831 for NETCONF over the Blocks Extensible Exchange Protocol (BEEP) <xref target="RFC4744"/>, 832 for NETCONF over the Simple Object Access Protocol (SOAP) <xref target="RFC4743"/>, 4334 for NETCONF Call Home <xref target="RFC8071"/>, and 6513 for NETCONF over Transport Layer Security (TLS) <xref target="RFC7589"/><xref target="I-D.ietf-netconf-over-tls13"/>.</t> <t>However, three of these assignments (831, 832, and 833) are for protocols that are notdeployeddeployed, andwere tagged as Historicthe relevant RFCs (<xref target="RFC4743"/> and <xreftarget="RFC4744"/>).target="RFC4744"/>) have been marked Historic. All these assignments are thus no longer required to support these services.</t> <t>This document de-assigns these unused port numbers.</t> <t>Consistent with <xref section="8.2" sectionFormat="of" target="RFC6335"/>, this document does not de-assign service names; only port numbers are de-assigned for better usage of available scarce resources.</t> </section> <section anchor="operational-considerations"> <name>Operational Considerations</name> <t>There are no known implementations and deployments of protocols that rely upon the port numbers released back by this document.</t> <t>Existing configurations (if any) that associate the released port numbers with the service names "netconf-beep" and "netconfsoaphttp" need to be reassessed and updated according to the actions in <xref target="sec-IANA"/>.</t> <t>Other than that, there are no new operations or manageability requirements introduced by this document.</t> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>This document does not describe any protocol. As such, this document does not introduce any new security vulnerability.</t> </section> <section anchor="sec-IANA"> <name>IANA Considerations</name><t>This document requests<t>Per this document, IANAto updatehas updated the "Service Name and Transport Protocol Port Number Registry"registry<xref target="IANA-SERVICE"/> as specified in the following subsections.</t> <t>De-assigned allocations are marked per <xref section="8.2" sectionFormat="of" target="RFC6335"/>. These actions are not repeated here.</t><ul empty="true"> <li> <t>Note to the RFC Editor: Please replace "THIS_DOCUMENT" with the RFC number to be assigned to this document.</t> </li> </ul><section anchor="netconf-over-beep-service"> <name>NETCONF over BEEP Service</name> <t>OLD:</t> <table> <thead> <tr> <th align="left">Service Name</th> <th align="center">Port Number</th> <th align="center">Transport Protocol</th> <th align="left">Description</th> <th align="center">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">netconf-beep</td> <td align="center">831</td> <td align="center">tcp</td> <td align="left">NETCONF over BEEP</td> <td align="center"> <xref target="RFC4744"/></td> </tr> <tr> <td align="left">netconf-beep</td> <td align="center">831</td> <td align="center">udp</td> <td align="left">NETCONF over BEEP</td> <td align="center"> <xref target="RFC4744"/></td> </tr> </tbody> </table> <t>NEW:</t> <table> <thead> <tr> <th align="left">Service Name</th> <th align="center">Port Number</th> <th align="center">Transport Protocol</th> <th align="left">Description</th> <th align="center">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">netconf-beep</td> <tdalign="center"> </td>align="center"> </td> <tdalign="center"> </td>align="center"> </td> <td align="left">NETCONF over BEEP</td> <td align="center"> <xref target="RFC4744"/>THIS_DOCUMENT</td>RFC 9900</td> </tr> </tbody> </table> <t>A notecan behas been added to 831 to indicate that the port number used to be assigned to NETCONF over BEEP but was released byTHIS_DOCUMENT.</t>RFC 9900.</t> </section> <section anchor="netconf-over-soap-service"> <name>NETCONF over SOAP Service</name> <t>OLD:</t> <table> <thead> <tr> <th align="left">Service Name</th> <th align="center">Port Number</th> <th align="center">Transport Protocol</th> <th align="left">Description</th> <th align="center">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">netconfsoaphttp</td> <td align="center">832</td> <td align="center">tcp</td> <td align="left">NETCONF for SOAP over HTTPS</td> <td align="center"> <xref target="RFC4743"/></td> </tr> <tr> <td align="left">netconfsoaphttp</td> <td align="center">832</td> <td align="center">udp</td> <td align="left">NETCONF for SOAP over HTTPS</td> <td align="center"> <xref target="RFC4743"/></td> </tr> <tr> <td align="left">netconfsoapbeep</td> <td align="center">833</td> <td align="center">tcp</td> <td align="left">NETCONF for SOAP over BEEP</td> <td align="center"> <xref target="RFC4743"/></td> </tr> <tr> <td align="left">netconfsoapbeep</td> <td align="center">833</td> <td align="center">udp</td> <td align="left">NETCONF for SOAP over BEEP</td> <td align="center"> <xref target="RFC4743"/></td> </tr> </tbody> </table> <t>NEW:</t> <table> <thead> <tr> <th align="left">Service Name</th> <th align="center">Port Number</th> <th align="center">Transport Protocol</th> <th align="left">Description</th> <th align="center">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">netconfsoaphttp</td> <tdalign="center"> </td>align="center"> </td> <tdalign="center"> </td>align="center"> </td> <td align="left">NETCONF for SOAP over HTTPS</td> <td align="center"> <xref target="RFC4743"/>THIS_DOCUMENT</td>RFC 9900</td> </tr> <tr> <td align="left">netconfsoapbeep</td> <tdalign="center"> </td>align="center"> </td> <tdalign="center"> </td>align="center"> </td> <td align="left">NETCONF for SOAP over BEEP</td> <td align="center"> <xref target="RFC4743"/>THIS_DOCUMENT</td>RFC 9900</td> </tr> </tbody> </table> <t>A notecan behas been added to832/833832 and 833 to indicate that the port numbers used to be assigned to NETCONF over SOAP but were released byTHIS_DOCUMENT.</t>RFC 9900.</t> </section> </section> </middle> <back> <displayreference target="I-D.ietf-netconf-over-tls13" to="NETCONF-over-TLS"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC6335"> <front> <title>Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry</title> <author fullname="M. Cotton" initials="M." surname="Cotton"/> <author fullname="L. Eggert" initials="L." surname="Eggert"/> <author fullname="J. Touch" initials="J." surname="Touch"/> <author fullname="M. Westerlund" initials="M." surname="Westerlund"/> <author fullname="S. Cheshire" initials="S." surname="Cheshire"/> <date month="August" year="2011"/> <abstract> <t>This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.</t> <t>This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice.</t> </abstract> </front> <seriesInfo name="BCP" value="165"/> <seriesInfo name="RFC" value="6335"/> <seriesInfo name="DOI" value="10.17487/RFC6335"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6335.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <reference anchor="IANA-SERVICE"target="https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml">target="https://www.iana.org/assignments/service-names-port-numbers"> <front> <title>Service Name and Transport Protocol Port Number Registry</title> <author><organization/><organization>IANA</organization> </author><date>n.d.</date> </front> </reference> <reference anchor="RFC6242"> <front> <title>Using the NETCONF Protocol over Secure Shell (SSH)</title> <author fullname="M. Wasserman" initials="M." surname="Wasserman"/> <date month="June" year="2011"/> <abstract> <t>This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6242"/> <seriesInfo name="DOI" value="10.17487/RFC6242"/> </reference> <reference anchor="RFC4744"> <front> <title>Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)</title> <author fullname="E. Lear" initials="E." surname="Lear"/> <author fullname="K. Crozier" initials="K." surname="Crozier"/> <date month="December" year="2006"/> <abstract> <t>This document specifies an application protocol mapping for the Network Configuration Protocol (NETCONF) over the Blocks Extensible Exchange Protocol (BEEP). [STANDARDS-TRACK]</t> </abstract></front><seriesInfo name="RFC" value="4744"/> <seriesInfo name="DOI" value="10.17487/RFC4744"/></reference><reference anchor="RFC4743"> <front> <title>Using NETCONF over the Simple Object Access Protocol (SOAP)</title> <author fullname="T. Goddard" initials="T." surname="Goddard"/> <date month="December" year="2006"/> <abstract> <t>The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. Web Services is one such environment and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4744.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4743.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8071.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7589.xml"/> <!-- draft-ietf-netconf-over-tls13-04 inthis environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange Extensible Protocol (BEEP) bindings for NETCONF. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4743"/> <seriesInfo name="DOI" value="10.17487/RFC4743"/> </reference> <reference anchor="RFC8071"> <front> <title>NETCONF Call Home and RESTCONF Call Home</title> <author fullname="K. Watsen" initials="K." surname="Watsen"/> <date month="February" year="2017"/> <abstract> <t>This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client, respectively.</t> </abstract> </front> <seriesInfo name="RFC" value="8071"/> <seriesInfo name="DOI" value="10.17487/RFC8071"/> </reference> <reference anchor="RFC7589"> <front> <title>Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication</title> <author fullname="M. Badra" initials="M." surname="Badra"/> <author fullname="A. Luchuk" initials="A." surname="Luchuk"/> <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder"/> <date month="June" year="2015"/> <abstract> <t>The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange of NETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539.</t> </abstract> </front> <seriesInfo name="RFC" value="7589"/> <seriesInfo name="DOI" value="10.17487/RFC7589"/> </reference> <reference anchor="I-D.ietf-netconf-over-tls13"> <front> <title>Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication</title> <author fullname="Sean Turner" initials="S." surname="Turner"> <organization>sn3rd</organization> </author> <author fullname="Russ Housley" initials="R." surname="Housley"> <organization>Vigil Security, LLC</organization> </author> <date day="18" month="January" year="2024"/> <abstract> <t> RFC 7589 defines how to protect NETCONF messages with TLS 1.2. This document updatesRFC7589 to update support requirements for TLS 1.2 and add TLS 1.3 support requirements, including restrictions on the useEd Queue in EDIT*R as ofTLS 1.3's early data. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-netconf-over-tls13-04"/> </reference>12/3/25 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-over-tls13.xml"/> </references> </references><?line 112?><section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>Thanks toAmanda Baber and Zahed Sarker<contact fullname="Amanda Baber"/> and <contact fullname="Zahed Sarker"/> for the guidance. Thanks toTom Petch<contact fullname="Tom Petch"/> for the comments.</t> <t>Thanks toKent Watsen<contact fullname="Kent Watsen"/> for the Shepherd review,Mahesh Jethanandani<contact fullname="Mahesh Jethanandani"/> for the AD review,Bernie Volz<contact fullname="Bernie Volz"/> for the INTDIR review,Roni Even<contact fullname="Roni Even"/> forgenartGen-ART review,Barry Leiba<contact fullname="Barry Leiba"/> for ARTART review,Dhruv Dhody<contact fullname="Dhruv Dhody"/> for the OPSDIR review,Michael Tüxen<contact fullname="Michael Tüxen"/> for TSVART review, andJoe Touch<contact fullname="Joe Touch"/> for the port review.</t> <t>Thanks toGorry Fairhurst<contact fullname="Gorry Fairhurst"/> for the IESG review.</t> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA9VYzXLbRhK+4yl6qYtcZVC2KMdabO0mlEhHSixKJTJO1V62 BsCQmBU4g8wMSDOi3iy3vNh2zwAgIMpSXHsy7TIJYPrv669/4DAMAytsziPo /VKkzHIDVsFkPDu/nnyAmWbSFEpbuKF/JuUy5tr0AhbHmq9Q5qWDCWpcKL2J wNg0CFKVSLZEY6lmcxsKbueh5DZRch6SdCi9YPjmfWDKeCmMEUraTYEil+PZ h8A/jwLyNApQznBpShOB1SUP0KNBwDRn6Nl1wTWzKG2AyRSumGQLvuTS9oK1 0ncLrcqCAuCWLuEcXRCL0ov0gju+wdtpFEAIKQ8Z+rGQ/oLluaKw6ErznDPD gyBgpc2UpvMB4Gde5rmP9Epl+J3CmSoTljKh3XOlF0yK3521CK4RvQV3D/iS iTyCpZfqx7XUD8qd6SdqGQRS6SWKrhCCQMj57grgcjgZhtPx7afL83HkNEKV 3ynXK5FwmKBiB0krZ1pZlai8nTy45QthrN5USphecBtBZm1hoqOj9XrdF4hp HyM58vAQuObIeDMhRW86SX3mUf9zZpd5EIRhCCxGqyyxQTDLhAGkTEmaa6xN Tc4Qb2AaUnAheEUufGi5AwgOVHaR2RmzkLEVB6ksxJxLEBJKw+mr0CotE0oI SE8K0/ceLUWa5pjkA7iUtjlF/nHofSWsPYyjwvX+vp2shwd8kiDnDPq7Qu7m TwdKJqqAQDqbu2ixZpIMb8Dp4I2LvC5PhQqRAEmpOUwznudwOJ1evIL7++9v P5x/d3xy/PDwGqXe7ktZDPIMGX9nYPzZYrWJOOf4M8mIj7sYD8/G45ta48n7 kxPUGJwOjp/WOBXLAtVcx//liYVhgtkxLV3T62Fb14C8OxkMTjrKzrES4UIh BP7g6Zv3b8koIfTdu7eDfcu71HxkmxoRYTdwOPs4re29f3f694cH/H0Zjvqd DkU6Qpubt+gPUuNCrSlRrzEgzTmoOUVmOgmBQ8SUgD1+7RJ3Ohi8AmxQzrWi CrfiJd0mWqa8yNUG000Ca453LVss6NrABTJHaZHAYRsbd7IN/Ks+DBGbfXfI hs1Kg4YgV5g/jaT7rRQa1WPbN2Xh0PGCddn0H1di0xBNdbKUWEOdQiQhbKkG /SWJtbAZeoh4u/o67R8TXH8j7g0G7yi7tmtBcVOBUZnqcN78A5TMNx2DLrbm OHpDEMfcWoyxNNj7ySJbYXdlRGCTMI3aNDeq1D7IA2hmBhaf8z6tZ4grdjTg kwR3Uq2xdxCHyd/WnPHZ82ijwUc5xkreQFkgBFQEHfer9pZCzJI7iDddRNC9 8WcEU8gFJO1RhRQTGJfcvKpYZIxKBLYLZ6FR2jHlskGPO5hCr+Y5Nsai56Kp bxnFCur8PWyNnioxKUdjWLcVVUu3PuDvhLoYOYrHyApLvKPYY+/vDU9Canuu gq7xMfUDJp3zxIIWyJKvQe2mOKZz6YY4i0VORVsx12Mtqs5MAO5jd7Ar9f28 foF4JtEippa+abKIZYXdGXvsF/nauOHkKAJTG16VuUSz3nnnkxtWXX/g/qBB aH8A/lZyg7E6OQTXI+4w/tox1Ez3XlDPI9ibR9hwTMETMReIqvCcnStcf9aU XdzPjK9nKp5Rq/KqDcnXBOZyyfQdcRDNPtMD+jDz/SrZSRKkmhfcEYu4gZb+ BRNFUXtyoTiMU4FdMYIbR3YSyBlC0ZtdXE7/M7o+/+VqPJn1drQnmWpf8Exu PHdKH1HnoDtDaMzVuxQy+OMId7BtB/0t1J824HT7iZy40yNHtsLhQjdu+Rxj lagQtsE2bH+2UecyjDo3omcOR6iqXeFbHE1bmxRobz9A/9l2pgo8paBMn1RQ YfBIPJiMf/1m4do2jv5FuDr0o+iHxGcOCbY7Il2aesbR2oVfQqYi8fXM7OP5 AG7A7rN135W4tK1Zsul68QSfadX61vlcj6faT2TmcUXtTsJoJXDxusgvZrOb 6bZD00GH5U+q9YT/f9USo1pqBy97u6uqF9TWakhry9ln1O6xd/AtV+te1tyf r8zW49r9Yu6eVe7AfVn5lxvD8RFm8cXmYP5Sd3BuvdQd3PsubaC0nwwT2nNz ni782+V95O3x9J+9OcsN77kdhck7959GQ1zPUgZnjBhBK8i/WYZWpjT9tUOG /F6UImWYfRr3teRMLeEGAc6aU4laOpv9toGfaQv6lVmD7+31QXybLXAxSDGq leDr13CFRk0GP3FaK8khKZrDw1F9LDjjWgoOn1T+e/P4cjIbXd42mm4Vio5X lbEFl0zb5uEZ07gyfeQiZu7x8HaGfxv1o0yXKxhlKt006q9vpm31VwJfoXkO sz//+FzZmE0/tZQ4DH9SHOEpW9C4xPsjHXR+VOTRByZ0Vmpjd1GNpz825/8H bXUSj/ATAAA=[rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>