2. PROBLÈMES GÉNÉRAUX (GENERAL ISSUES)

Cette section discute de plusieurs sujets pertinents pour tous les protocoles d'application et de support.

2.1 Noms et numéros d'hôte (Host Names and Numbers)

Le système Internet a un système de noms d'hôte hiérarchique, le système de noms de domaine (Domain Name System, DNS). Chaque hôte Internet a une ou plusieurs adresses IP et peut avoir un ou plusieurs noms.

Un nom d'hôte se compose d'une séquence d'« étiquettes » séparées par des points. Par exemple : venera.isi.edu. L'étiquette la plus à droite est appelée le « domaine de premier niveau » (Top-Level Domain, TLD).

Exigences (Requirements)

• Un nom d'hôte ne DOIT PAS être composé de tous les labels numériques (MUST NOT).
• Le logiciel hôte DOIT gérer des noms d'hôte d'au moins 255 caractères de longueur (MUST).
• Le logiciel hôte ne DOIT PAS faire d'hypothèses sur le format ou le contenu des noms d'hôte, au-delà de celles de la spécification DNS (MUST NOT).

2.2 Utilisation du service de noms de domaine (Using Domain Name Service)

Le logiciel d'application DOIT être capable de gérer un nom d'hôte donné se résolvant en plusieurs adresses IP (MUST). Cette situation se présente dans plusieurs circonstances :

• Partage de charge (Load Sharing) : Plusieurs hôtes peuvent fournir le même service sous le même nom pour l'équilibrage de charge.
• Multihoming : Un seul hôte peut avoir plusieurs interfaces réseau avec différentes adresses IP.

Résolution de noms (Name Resolution)

Lorsqu'une application doit résoudre un nom d'hôte en une adresse IP, elle utilise typiquement le système de noms de domaine (DNS). L'application DEVRAIT (SHOULD) :

• Essayer plusieurs adresses si la première tentative de connexion échoue
• Mémoriser quelle adresse a réussi pour les connexions futures
• Implémenter des timeouts appropriés

Mise en cache (Caching)

Les applications PEUVENT mettre en cache les adresses résolues (MAY), mais elles DOIVENT honorer les valeurs de durée de vie (Time-To-Live, TTL) renvoyées par le DNS (MUST).

2.3 Applications sur hôtes multihomed (Applications on Multihomed Hosts)

Lorsqu'une application sur un hôte multihomed crée une connexion, l'adresse IP source DOIT être l'une des adresses IP de l'hôte (MUST).

Pour les hôtes multihomed avec plusieurs adresses IP :

• L'application PEUT permettre à l'utilisateur de sélectionner quelle adresse IP locale utiliser (MAY)
• Si aucune adresse spécifique n'est sélectionnée, la couche IP choisit l'adresse source en fonction du routage

2.4 Type de service (Type-of-Service)

Les protocoles d'application DEVRAIENT fournir un mécanisme pour que les applications spécifient le type de service IP (Type-of-Service, TOS) pour les connexions TCP ou les transmissions UDP (SHOULD).

Le champ TOS permet à une application de demander des caractéristiques de traitement spécifiques :

• Faible délai (Low delay) (minimiser le délai)
• Haut débit (High throughput) (maximiser le débit)
• Haute fiabilité (High reliability) (maximiser la fiabilité)
• Faible coût (Low cost) (minimiser le coût monétaire)

2.5 RÉSUMÉ DES EXIGENCES GÉNÉRALES DES APPLICATIONS (GENERAL APPLICATION REQUIREMENTS SUMMARY)

Fonctionnalité	Section	Must	Should	May	Not
Gérer les noms d'hôte >= 255 caractères	2.1	x
Nom d'hôte pas tous numériques	2.1	x
Supporter plusieurs adresses par nom	2.2	x
Essayer plusieurs adresses en cas d'échec	2.2		x
Honorer les valeurs TTL DNS	2.2	x
Permettre la spécification TOS	2.4		x

---