1. Introduction
1. Introduction
Pendant de nombreuses années, l'attribution de nouveaux noms de service et de valeurs de numéro de port pour une utilisation avec le protocole de contrôle de transmission (Transmission Control Protocol, TCP) [RFC0793] et le protocole de datagramme utilisateur (User Datagram Protocol, UDP) [RFC0768] a eu des directives peu claires. De nouveaux protocoles de transport ont été ajoutés —— le protocole de transmission à contrôle de flux (Stream Control Transmission Protocol, SCTP) [RFC4960] et le protocole de contrôle de congestion de datagrammes (Datagram Congestion Control Protocol, DCCP) [RFC4342] —— et de nouveaux mécanismes comme les enregistrements DNS SRV [RFC2782] ont été développés, chacun avec des registres séparés et des directives séparées. La communauté a également reconnu le besoin de procédures supplémentaires au-delà de la simple attribution, notamment la modification, la révocation et la libération.
Un élément clé de la rationalisation procédurale spécifiée dans ce document est d'établir des procédures d'attribution identiques pour tous les protocoles de transport IETF. Ce document aligne les procédures IANA pour TCP et UDP avec celles pour SCTP et DCCP, ce qui donne un processus unique que les demandeurs et l'IANA suivent pour toutes les demandes pour tous les protocoles de transport, y compris les futurs protocoles non encore définis.
En plus de détailler les procédures IANA pour l'attribution initiale de noms de service et de numéros de port, ce document spécifie également des procédures post-attribution qui jusqu'à présent ont été traitées de manière ad hoc. Celles-ci incluent des procédures pour désattribuer un numéro de port qui n'est plus utilisé, pour prendre un numéro de port attribué à un service qui n'est plus utilisé et le réutiliser pour un autre service, et la procédure par laquelle l'IANA peut révoquer unilatéralement une attribution de numéro de port antérieure. La section 8 discute les détails de ces procédures et processus que les demandeurs et l'IANA suivent pour toutes les demandes pour tous les protocoles de transport actuels et futurs.
L'IANA est l'autorité pour attribuer les noms de service et les numéros de port. Les registres créés pour stocker ces attributions sont maintenus par l'IANA. Pour les protocoles développés par les groupes de travail IETF, l'IANA offre maintenant également une méthode pour l'"attribution anticipée" (early assignment) [RFC4020] de noms de service et de numéros de port, comme décrit dans la section 8.1.
Ce document met à jour les procédures de l'IANA pour les numéros de port UDP et TCP en rendant obsolètes les sections 8 et 9.1 des directives d'allocation de l'IANA [RFC2780]. (Notez que d'autres sections des directives d'allocation de l'IANA, relatives aux valeurs de champ de protocole dans les en-têtes IPv4, ont également été mises à jour en février 2008 [RFC5237].) Ce document met également à jour les procédures d'attribution de l'IANA pour DCCP [RFC4340] [RFC5595] et SCTP [RFC4960].
Le protocole léger de datagramme utilisateur (Lightweight User Datagram Protocol, UDP-Lite) partage l'espace de port avec UDP. La spécification UDP-Lite [RFC3828] dit: "UDP-Lite utilise le même ensemble de valeurs de numéro de port attribuées par l'IANA pour une utilisation par UDP". Une mise à jour des procédures UDP entraîne donc également une mise à jour correspondante des procédures UDP-Lite.
Ce document clarifie également ce qu'est un nom de service et comment il est attribué. Cela aura un impact sur la spécification DNS SRV [RFC2782], car cette spécification ne fait qu'une brève mention que les noms symboliques des services sont définis dans "Assigned Numbers" [RFC1700], sans préciser à quelle section il se réfère dans ce document de 230 pages. La spécification DNS SRV peut avoir fait référence à la liste des attributions de port (connue sous le nom de /etc/services sur Unix), ou à la section "Protocol And Service Names", ou aux deux, ou à une autre section. De plus, "Assigned Numbers" [RFC1700] a été rendu obsolète [RFC3232] et a été remplacé par des registres en ligne [PORTREG] [PROTSERVREG].
Le développement de nouveaux protocoles de transport est un effort majeur que l'IETF n'entreprend pas très souvent. Si un nouveau protocole de transport est normalisé à l'avenir, il devrait suivre autant que possible ces directives et pratiques concernant l'utilisation des noms de service et des numéros de port, pour des raisons de cohérence.
Au moment de la rédaction de ce document, les procédures internes des équipes d'"Expert Review" (examen par des experts), y compris celle de l'équipe d'examen des ports de l'IANA, ne sont documentées dans aucun RFC et ce document ne change pas cela.