Groupe de travail Réseau	D. McPherson, Arbor Networks	
Request for Comments : 5301	N. Shen, Cisco Systems	
Rend obsolète la RFC 2763	octobre 2008	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Mécanisme dynamique d'échange de nom d'hôte pour IS-IS

Statut de ce mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Résumé
La RFC 2763 définissait un mécanisme dynamique simple pour que les routeurs fonctionnant avec IS-IS apprennent les noms d'hôtes symboliques. La RFC 2763 définissait un nouveau TLV qui permet aux routeurs IS-IS d'arroser leurs informations de transposition de nom en identifiant de système à travers le réseau IS-IS.

Le présent document rend obsolète la RFC 2763. Le présent document déplace la capacité fournie par la RFC 2763 sur la voie de la normalisation.
Table des matières
1. Introduction	1
1.1 Spécification des exigences	2
2. Solutions possibles	2
3. TLV Nom d'hôte dynamique	2
4. Mise en œuvre	2
5. Considérations sur la sécurité	3
6. Remerciements	3
7. Considérations relatives à l'IANA	3
8. Références pour information	3
Adresse des auteurs	3
Déclaration complète de droits de reproduction	3

 	1.	Introduction

IS-IS utilise un identifiant de système de longueur variable de 1 à 8 octets (normalement 6 octets) pour représenter un nœud dans le réseau. Pour des raisons de gestion et de fonctionnement, les opérateurs de réseau ont besoin de vérifier le statut des adjacences IS-IS, des entrées dans le tableau d'acheminement, et le contenu de la base de données d'état de liaison IS-IS. Il est évident que, quand on cherche des informations de diagnostic, les représentations hexadécimales des identifiants de système et les identifiants d'unités de données de protocole d'état de liaison (LSP, Link State Protocol Data Unit) sont moins clairs que des noms symboliques.

Une façon de surmonter ce problème est de définir une transposition de nom en identifiant de système sur un routeur. Cette transposition peut être utilisée de façon bidirectionnelle, par exemple, pour trouver des noms symboliques pour les identifiants de système et pour trouver des identifiants de système pour les noms symboliques. Une façon de construire ce tableau de transpositions est par des définitions statiques. Parmi les administrateurs de réseau qui utilisent IS-IS comme IGP, il est de pratique courante de définir de telles transpositions statiques.

Donc, chaque routeur doit tenir un tableau configuré statiquement avec les transpositions entre noms de routeur et identifiants de système. Ces tableaux doivent contenir les noms et les identifiants de système de tous les routeurs du réseau, et doivent être modifiés chaque fois que se produit un ajout, une suppression, ou un changement.

Il y a plusieurs façons de construire un tel tableau. Une d'elles est via la configuration statique. Un autre schéma qui pourrait être mis en œuvre est via une recherche dans le DNS. Dans ce document, on donne une troisième solution, qui s'est révélée, dans des mises en œuvre et déploiements à grande échelle, être plus facile et gérable que la transposition statique ou le schéma avec le DNS.

 	1.1	Spécification des exigences
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	2.	Solutions possibles

L'inconvénient évident de la configuration statique des transpositions est la question de l'adaptabilité et de la maintenance. Les opérateurs de réseau ont à tenir les tableaux de noms. Ils doivent avoir une entrée dans le tableau pour chaque routeur du réseau, sur chaque routeur du réseau. L'effort de créer et maintenir ces tableaux statiques croît avec le nombre total de routeurs du réseau. Changer le nom ou l'identifiant de système d'un routeur, ou ajouter un nouveau routeur va affecter les configurations de tous les autres routeurs dans le réseau. Cela fait qu'il est très probable que ces tableaux statiques ne sont pas à jour.

Avoir un tableau qui puisse être mis à jour de façon centralisée serait utile. On pourrait imaginer d'utiliser le système du DNS pour cela. L'inconvénient est que quand le réseau a des problèmes, le temps de réponse des services DNS peut ne pas être satisfaisant ou les services du DNS peuvent même n'être pas disponibles. Un autre inconvénient possible pourrait être la complexité accrue du DNS. Aussi, certaines mises en œuvre du DNS pourraient ne pas prendre en charge les enregistrements A et PTR pour le service réseau sans connexion (CLNS, ConnectionLess Network Service) et les points d'accès de service réseau (NSAP, Network Service Access Point).

Une troisième façon de construire des transpositions dynamiques serait d'utiliser le mécanisme de transport du protocole d'acheminement lui-même pour annoncer les noms symboliques dans les PDU d'état de liaison IS-IS. Le présent document définit un nouveau TLV qui permet aux routeurs IS-IS d'inclure les données de transposition de nom en identifiant de système dans leurs LSP. Cela va permettre un transport simple et fiable des informations de transposition de nom à travers le réseau IS-IS.

 	3.	TLV Nom d'hôte dynamique

Le TLV Nom d'hôte dynamique est défini avec le type de TLV 137.

Longueur : la longueur totale du champ Valeur.

Valeur : chaîne de 1 à 255 octets.

Le TLV Nom d'hôte dynamique est facultatif. Ce TLV peut être présent dans tout fragment d'un LSP non pseudo nœud. Le champ Valeur identifie le nom symbolique du routeur d'origine du LSP. Ce nom symbolique peut être le FQDN pour le routeur, il peut être un sous ensemble du FQDN, ou il peut être toute chaîne que l'opérateur veut utiliser pour le routeur. L'utilisation du FQDN ou d'un sous ensemble de celui-ci est fortement recommandée. Le contenu de cette valeur est un nom de domaine, voir la [RFC2181]. La chaîne ne doit pas être terminée par un nul. L'identifiant de système de ce routeur peut être déduit de l'identifiant de LSP.

Si ce TLV est présent dans un LSP de pseudo nœud, il NE DEVRAIT PAS alors être interprété comme le nom d'hôte DNS du routeur.

Le champ Valeur est codé en 7 bits ASCII. Si une interface d'utilisateur pour configurer ou afficher ce champ permet des caractères Unicode, cette interface d'utilisateur est chargée d'appliquer les algorithmes ToASCII et/ou ToUnicode comme décrit dans la [RFC3490] pour réaliser le format correct pour la transmission ou l'affichage.

 	4.	Mise en œuvre

Le TLV Nom d'hôte dynamique est facultatif. Lorsque il génère un LSP, un routeur peut décider d'inclure ce TLV dans son LSP. À réception d'un LSP avec le TLV Nom d'hôte dynamique, un routeur peut décider d'ignorer ce TLV, ou d'installer le nom symbolique et l'identifiant de système dans son tableau de transpositions de nom d'hôte pour le réseau IS-IS.

Un routeur peut aussi facultativement insérer ce TLV dans son LSP pseudo nœud pour l'association d'un nom symbolique à un LAN local.

Si un système reçoit une transposition pour un nom ou identifiant de système qui est différent de la transposition de l'antémémoire locale, la mise en œuvre DEVRAIT remplacer la transposition existante par les dernières informations.

 	5.	Considérations sur la sécurité

Comme la transposition de nom en identifiant de système s'appuie sur les informations fournies par les routeurs eux-mêmes, un routeur mal configuré ou compromis peut injecter de fausses informations de transposition. Donc, ces informations doivent être traitées avec prudence quand, par exemple, on fait des diagnostics sur une suspicion d'incident de sécurité.

Le présent document ne soulève pas de nouvelle question de sécurité pour IS-IS ; pour les considérations générales de sécurité pour IS-IS, voir la [RFC5304].

 	6.	Remerciements

Les efforts originaux et les remerciements correspondants fournis dans la [RFC2763] ont permis ce travail. En particulier, nous tenons à reconnaître Henk Smit comme auteur de ce document.

 	7.	Considérations relatives à l'IANA

Le présent document spécifie le TLV 137, "Nom dynamique". Ce TLV a déjà été alloué et réservé [RFC2763]. À ce titre, aucune nouvelle action n'est requise de la part de l'IANA.

 	8.	Références pour information

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2181]	R. Elz et R. Bush, "Clarifications pour la spécification du DNS", juillet 1997. (P.S., MàJ par RFC4035, RFC2535, RFC4343, RFC4033, RFC4034, RFC5452, RFC8767)

[RFC2763]	N. Shen, H. Smit, "Mécanisme d'échange dynamique de nom d'hôte pour IS-IS", février 2000. (Obs, voir RFC5301) (Info.)

[RFC3490]	P. Faltstrom et autres, "Internationalisation des noms de domaine dans les applications (IDNA)", mars 2003. (Remplacée par les RFC5890 et 5891, P.S.)

[RFC5304]	T. Li et R. Atkinson, "Authentification cryptographique IS-IS", octobre 2008. (Remplace RFC3567, MàJ RFC1195) (PS)

 	Adresse des auteurs

Danny McPherson	Naiming Shen	
Arbor Networks, Inc.	Cisco Systems, Inc.	
mél : danny@arbor.net 	mél : naiming@cisco.com 	

 	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2008).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.
Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org .