1. Introduction (Introduzione)
1. Introduction (Introduzione)
Per molti anni, l'assegnazione di nuovi nomi di servizio e valori di numero di porta da utilizzare con il protocollo di controllo della trasmissione (Transmission Control Protocol, TCP) [RFC0793] e il protocollo di datagramma utente (User Datagram Protocol, UDP) [RFC0768] ha avuto linee guida poco chiare. Sono stati aggiunti nuovi protocolli di trasporto —— il protocollo di trasmissione a controllo di flusso (Stream Control Transmission Protocol, SCTP) [RFC4960] e il protocollo di controllo della congestione dei datagrammi (Datagram Congestion Control Protocol, DCCP) [RFC4342] —— e sono stati sviluppati nuovi meccanismi come i record DNS SRV [RFC2782], ciascuno con registri separati e linee guida separate. La comunità ha anche riconosciuto la necessità di procedure aggiuntive oltre alla semplice assegnazione, in particolare modifica, revoca e rilascio.
Un elemento chiave della razionalizzazione procedurale specificata in questo documento è stabilire procedure di assegnazione identiche per tutti i protocolli di trasporto IETF. Questo documento allinea le procedure IANA per TCP e UDP con quelle per SCTP e DCCP, risultando in un processo unico che i richiedenti e l'IANA seguono per tutte le richieste per tutti i protocolli di trasporto, compresi i protocolli futuri non ancora definiti.
Oltre a dettagliare le procedure IANA per l'assegnazione iniziale di nomi di servizio e numeri di porta, questo documento specifica anche procedure post-assegnazione che finora sono state gestite in modo ad hoc. Queste includono procedure per disassegnare un numero di porta che non è più in uso, per prendere un numero di porta assegnato a un servizio che non è più in uso e riutilizzarlo per un altro servizio, e la procedura mediante la quale l'IANA può revocare unilateralmente un'assegnazione di numero di porta precedente. La sezione 8 discute i dettagli di queste procedure e processi che i richiedenti e l'IANA seguono per tutte le richieste per tutti i protocolli di trasporto attuali e futuri.
L'IANA è l'autorità per l'assegnazione di nomi di servizio e numeri di porta. I registri creati per memorizzare queste assegnazioni sono mantenuti dall'IANA. Per i protocolli sviluppati dai gruppi di lavoro IETF, l'IANA ora offre anche un metodo per l'"assegnazione anticipata" (early assignment) [RFC4020] di nomi di servizio e numeri di porta, come descritto nella sezione 8.1.
Questo documento aggiorna le procedure IANA per i numeri di porta UDP e TCP rendendo obsolete le sezioni 8 e 9.1 delle linee guida di allocazione IANA [RFC2780]. (Si noti che altre sezioni delle linee guida di allocazione IANA, relative ai valori del campo protocollo negli header IPv4, sono state anche aggiornate nel febbraio 2008 [RFC5237].) Questo documento aggiorna anche le procedure di assegnazione IANA per DCCP [RFC4340] [RFC5595] e SCTP [RFC4960].
Il protocollo di datagramma utente leggero (Lightweight User Datagram Protocol, UDP-Lite) condivide lo spazio delle porte con UDP. La specifica UDP-Lite [RFC3828] afferma: "UDP-Lite utilizza lo stesso insieme di valori di numero di porta assegnati dall'IANA per l'uso da parte di UDP". Un aggiornamento delle procedure UDP comporta quindi anche un aggiornamento corrispondente delle procedure UDP-Lite.
Questo documento chiarisce anche cos'è un nome di servizio e come viene assegnato. Ciò avrà un impatto sulla specifica DNS SRV [RFC2782], poiché tale specifica fa solo una breve menzione che i nomi simbolici dei servizi sono definiti in "Assigned Numbers" [RFC1700], senza indicare a quale sezione si riferisce all'interno di quel documento di 230 pagine. La specifica DNS SRV potrebbe essersi riferita all'elenco delle assegnazioni di porte (noto come /etc/services su Unix), o alla sezione "Protocol And Service Names", o a entrambi, o a qualche altra sezione. Inoltre, "Assigned Numbers" [RFC1700] è stato reso obsoleto [RFC3232] ed è stato sostituito da registri online [PORTREG] [PROTSERVREG].
Lo sviluppo di nuovi protocolli di trasporto è uno sforzo importante che l'IETF non intraprende molto spesso. Se un nuovo protocollo di trasporto viene standardizzato in futuro, ci si aspetta che segua il più possibile queste linee guida e pratiche relative all'uso di nomi di servizio e numeri di porta, per coerenza.
Al momento della stesura di questo documento, le procedure interne dei team di "Expert Review" (revisione da parte di esperti), compreso quello del team di revisione delle porte dell'IANA, non sono documentate in alcun RFC e questo documento non cambia ciò.