13. Basic Server Behavior (Comportement de base du serveur)

Cette section définit le comportement d'un serveur STUN de base et autonome. Un serveur STUN de base fournit aux clients des adresses de transport réfléchies par le serveur (server reflexive transport addresses) en recevant et en répondant aux requêtes STUN Binding.

Le serveur STUN doit (MUST) supporter la méthode Binding. Il ne devrait pas (SHOULD NOT) utiliser le mécanisme d'identification à court terme ou à long terme. C'est parce que le travail impliqué dans l'authentification de la requête est plus important que le travail consistant simplement à la traiter. Pour la même raison, il ne devrait pas (SHOULD NOT) utiliser le mécanisme ALTERNATE-SERVER. Il doit (MUST) supporter UDP et TCP. Il peut (MAY) supporter STUN sur TCP/TLS ; cependant, TLS fournit des avantages de sécurité minimaux dans ce mode de fonctionnement de base. Il peut (MAY) utiliser le mécanisme FINGERPRINT mais ne doit pas (MUST NOT) l'exiger. Étant donné que le serveur autonome exécute uniquement STUN, FINGERPRINT ne fournit aucun avantage. L'exiger briserait la compatibilité avec RFC 3489, et une telle compatibilité est souhaitable dans un serveur autonome. Un serveur STUN autonome devrait (SHOULD) supporter la compatibilité descendante avec les clients [RFC3489], comme décrit dans la Section 12.

Il est recommandé (RECOMMENDED) que les administrateurs des serveurs STUN fournissent des entrées DNS pour ces serveurs, comme décrit dans la Section 9.

Un serveur STUN de base n'est pas une solution en soi pour la traversée NAT. Il s'agit plutôt d'un outil qui peut être utilisé dans le cadre d'une solution par le biais d'une utilisation STUN. Ceci est discuté plus en détail dans la Section 14.