Groupe de travail Réseau	B. Manning, ISI
Request for Comments : 1706 	R. Colella, NIST
RFC rendues obsolètes : 1637, 1348	octobre 1994
Catégorie : Information	Traduction Claude Brière de L'Isle

Enregistrements de ressource NSAP du DNS

Statut de ce mémoire
Le présent mémoire apporte des informations pour la communauté de l'Internet. Le présent mémoire ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Résumé
Les protocoles OSI de couche inférieure, comprenant le protocole réseau sans connexion (CLNP, connectionless network protocol) et les protocoles d'acheminement qui le prennent en charge, sont déployés dans certaines parties de l'Internet mondial. La maintenance et le débogage de la connexité CLNP est grandement aidée par la prise en charge dans le système des noms de domaines (DNS, Domain Name System) de la transposition entre les noms et les adresses de NSAP.

Le présent document définit le format d'un nouvel enregistrement de ressource (RR, Resource Record) du DNS pour la transposition de nom de domaine en NSAP. Le RR peut être utilisé avec tout format d'adresse de NSAP.

La traduction de NSAP en nom est accomplie par l'utilisation du RR PTR (voir dans le STD 13, [RFC1035] la description du RR PTR). Le présent document décrit comment les RR PTR sont utilisés pour prendre en charge cette traduction.

Le présent document rend obsolètes les RFC 1348 et RFC 1637.
Table des matières
1. Introduction	1
2. Fondements	2
3. Domaine d'application	2
4. Structure des NSAP	2
5. RR NSAP	3
6. Transposition de NSAP en nom en utilisant le RR PTR	4
7. Format de fichier maître	4
8. Considérations sur la sécurité	6
9. Adresse des auteurs	6
10. Références	6

 	1.	Introduction

Les protocoles OSI de couche inférieure, qui comprennent le protocole réseau sans connexion (CLNP, connectionless network protocol) [ISO8473] et les protocoles d'acheminement qui le prennent en charge, sont déployés dans certaines parties de l'Internet mondial. La maintenance et le débogage de la connexité CLNP est grandement aidée par la prise en charge par le système des noms de domaines (DNS, Domain Name System) [RFC1034], [RFC1035] de la transposition entre les noms et les adresses de point d'accès de service réseau (NSAP, network service access point) [ISO8348].
[Note : NSAP et adresse NSAP sont utilisés de façon interchangeable dans le présent mémoire].

Le présent document définit le format d'un nouvel enregistrement de ressource (RR) du DNS pour la transposition de noms de domaine en NSAP. Le RR peut être utilisé avec tout format d'adresse NSAP.

La traduction de NSAP en nom est accomplie par l'utilisation du RR PTR (voir dans la [RFC1035] la description du RR PTR. Le présent document décrit comment les RR PTR sont utilisés pour prendre en charge cette traduction.

Le présent mémoire suppose que le lecteur est familier du DNS. Une certaine familiarité avec les NSAP sera utile ; voir la [RFC1629] ou l'Annexe A de la norme [ISO8348] pour des informations supplémentaires.

 	2.	Fondements

La raison de la définition des transpositions des NSAP par le DNS est de prendre en charge le déploiement existant de CLNP dans l'Internet. Le débogage avec le ping et traceroute CLNP est devenu plus difficile avec seulement des NSAP numériques alors que l'échelle de déploiement a augmenté. Le débogage actuel est pris en charge en maintenant et échangeant un fichier de configuration avec des transpositions nom/NSAP similaires par leur fonction avec hosts.txt. Cela souffre du manque d'une coordination centrale pour ce fichier et aussi dans la perspective de l'adaptabilité. Le manque de coordination centrale est le plus sérieux des problèmes à court terme. L'adaptabilité d'une solution de type hosts.txt présente des déficiences bien connues à long terme.

 	3.	Domaine d'application

Les méthodes définies dans le présent document sont applicables à tous les formats de NSAP.

Comme point de référence, il y a une distinction entre l'enregistrement et la publication des adresses. Pour les adresses IP, l'IANA est l'autorité d'enregistrement racine et le DNS la méthode de publication. Pour les NSAP, l'Annexe A de la définition de service réseau, [ISO8348], décrit l'autorité d'enregistrement racine et le présent mémoire définit comment le DNS est utilisé comme méthode de publication.

 	4.	Structure des NSAP

Les NSAP ont une structure hiérarchique pour permettre une administration répartie et un acheminement efficace. L'administration répartie permet de sous déléguer l'autorité d'adressage, selon ce qui est permis par le délégataire, à d'autres structures de portions de l'espace de NSAP sous leur contrôle délégué. S'accommoder de cette autorité répartie exige qu'il y ait peu ou aucune connaissance a priori de la structure des NSAP dans les résolveurs et serveurs du DNS.

Pour les besoins du présent mémoire, les NSAP peuvent être vus comme une arborescence d'identifiants. La racine de l'arborescence est [ISO8348], et a comme ses subordonnés immédiats enregistrés les identifiants d'autorité et de format (AFI, Authority and Format Identifier) de un octet définis ici. La taille des champs définis ensuite dépend de la branche de l'arborescence suivie. La profondeur de l'arborescence varie selon l'autorité responsable de la définition des champs suivants.

Un exemple est l'autorité sous laquelle le U.S. GOSIP définit les NSAP [GOSIP]. Sous l'AFI 47, le NIST (National Institute of Standards and Technology) a obtenu une valeur de 0005 (l'AFI 47 définit le champ suivant comme ayant deux octets consistant en quatre chiffres BCD provenant de l'espace de désignation de code international [ISO6523]). Le NIST a défini les champs suivants dans [GOSIP], comme le montre la Figure 1. Le champ qui suit immédiatement 0005 est un identifiant de format pour le reste de la structure de NSAP de l'U.S. GOSIP, avec une valeur hexadécimale de 80. À la suite se trouve un champ de trois octets, dont les valeurs sont allouées aux opérateurs de réseaux ; l'autorité d'enregistrement pour ce champ est déléguée au GSA (General Services Administration).

Le dernier octet du NSAP est le sélecteur NSAP (NSel, NSAP selector). En pratique, le NSAP moins le NSel identifie la machine de protocole CLNP sur un certain système, et le NSel identifie l'utilisateur CLNP. Comme il peut y avoir plus d'un utilisateur CLNP (ce qui signifie plusieurs valeurs de NSel pour un certain NSAP de "base") la représentation du NSAP devrait être indépendante de l'utilisateur CLNP. Pour ce faire, une valeur de NSel de zéro devra être utilisée avec toutes les valeurs de NSAP mémorisées dans le DNS. Un NSAP avec NSel=0 identifie la couche réseau elle-même. Il appartient à l'application qui récupère le NSAP de déterminer la valeur appropriée à utiliser dans cette instance de communication.

Quand CLNP est utilisé pour prendre en charge des services TCP et UDP, la valeur de NSel utilisée est la valeur appropriée de PROTO IP enregistrée auprès de l'IANA. Pour l'OSI "standard", le choix des valeurs de NSel est laissée à la responsabilité de l'administration locale. Les administrateurs des systèmes qui prennent en charge le protocole de transport OSI [ISO8073] en plus de TCP/UDP doivent choisir des Nsel à utiliser avec le transport OSI qui ne soient pas en conflit avec les valeurs de PROTO IP

              |--------------|
              | <-- IDP -->  |
              |--------------|-------------------------------------|
              | AFI |  IDI   |            <-- DSP -->              |
              |-----|--------|-------------------------------------|
              | 47  |  0005  | DFI | AA |Rsvé | RD |Area | ID |Sel |
              |-----|--------|-----|----|-----|----|-----|----|----|
       octets |  1  |   2    |  1  | 3  |  2  | 2  |  2  | 6  | 1  |
              |-----|--------|-----|----|-----|----|-----|----|----|

IDP (Initial Domain Part) : partie initiale de domaine
AFI (Authority and Format Identifier) : identifiant d'autorité et de format 
IDI (Initial Domain Identifier) : identifiant initial de domaine
DSP (Domain Specific Part) : partie spécifique de domaine
DFI (DSP Format Identifier) : identifiant de format de partie spécifique de domaine
AA (Administrative Authority) : autorité administrative
Rsvé : réservé
RD (Routing Domain Identifier) : identifiant de domaine d'acheminement
Area (Area Identifier) : identifiant de zone
ID (System Identifier) : identifiant de système
SEL (NSAP Selector) : sélecteur de point d'accès de service réseau

Figure 1 : structure de NSAP GOSIP version 2

Dans les RR NSAP des fichiers maîtres et dans le texte imprimé du présent mémoire, les NSAP sont souvent représentés comme une chaîne de valeurs hexadécimales séparées par des points ".".

Les valeurs correspondent aux divisions pratiques du NSAP pour le rendre plus lisible. Par exemple, les champs séparés par des "." peuvent correspondre aux champs de NSAP définis par l'autorité appropriée (RARE, U.S. GOSIP, ANSI, etc.). L'utilisation de cette notation est uniquement pour la lisibilité. Les "." n'apparaissent pas dans les paquets DNS et les serveurs du DNS peuvent les ignorer quand ils lisent les fichiers maîtres. Par exemple, une représentation imprimable des quatre premiers champs d'un NSAP U.S. GOSIP pourrait ressembler à :

47.0005.80.005a00

et un NSAP U.S. GOSIP complet pourrait apparaître comme :

47.0005.80.005a00.0000.1000.0020.00800a123456.00.

D'autres formats de NSAP ont des longueurs différentes et des largeurs de champs définies administrativement différemment pour s'accommoder d'exigences différentes. Pour plus d'informations sur les formats de NSAP utilisés, voir la [RFC1629].

 	5.	RR NSAP

Le RR NSAP est défini avec des mnémoniques "NSAP" et le code TYPE 22 (en décimal) est utilisé pour transposer des noms de domaines en NSAP. La transposition de nom en NSAP dans le DNS en utilisant le RR NSAP opère de façon analogue à une recherche d'adresse IP. Une interrogation est générée par le résolveur qui demande un RR NSAP pour un nom de domaine fourni.

Les RR NSAP se conforment au format et à la sémantique de RR de niveau supérieur définis au paragraphe 3.2.1 de la [RFC1035].

                               1  1  1  1  1  1
 0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                                               |
/                                               /
/                        NAME                   /
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    TYPE = NSAP                |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    CLASS = IN                 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                        TTL                    |
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      RDLENGTH                 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/                       RDATA                   /
/                                               /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

où :

*  NAME : nom du propriétaire, c'est-à-dire, nom du nœud auquel appartient cet enregistrement de ressource.

*  TYPE : deux octets contenant le code de TYPE du RR NSAP de 22 (dé  »cimal).

*  CLASS : deux octets contenant le code de CLASS du RR IN de 1.

*  TTL : entier de 32 bits signé qui spécifie l'intervalle de temps en secondes pendant lequel l'enregistrement de ressource peut être mis en antémémoire avant que la source de l'information doive être consultée à nouveau. Les valeurs zéro sont interprétées comme signifiant que le RR peut seulement être utilisé pour la transaction en cours, et ne devrait pas être mis en antémémoire. Par exemple, les enregistrements SOA sont toujours distribués avec un TTL de zéro pour interdire la mise en antémémoire. Des valeurs de zéro peuvent aussi être utilisées pour des données extrêmement volatiles.

*  RDLENGTH : entier non signé de 16 bits qui spécifie la longueur en octets du champ RDATA.

*  RDATA : chaîne de longueur variable d'octets contenant le NSAP. La valeur est le codage binaire du NSAP comme il apparaîtrait dans le champ d'adresse de source ou destination CLNP. Un exemple typique d'un tel NSAP (en hexadécimal) est montré ci-dessous. Pour ce NSAP, RDLENGTH est 20 (en décimal) ; les "." ont été omits pour souligner qu'ils n'apparaissent pas dans les paquets DNS.

39840f80005a0000000001e13708002010726e00

Les RR NSAP ne causent pas de traitement de section supplémentaire.

 	6.	Transposition de NSAP en nom en utilisant le RR PTR

Le RR PTR est défini dans la [RFC1035]. Ce RR est normalement utilisé sous le domaine "IN-ADDR.ARPA" pour transposer les adresses IPv4 en noms de domaines.

De même, le RR PTR est utilisé pour transposer les NSAP en noms de domaines sous le domaine "NSAP.INT". Un nom de domaine est généré à partir du NSAP conformément aux règles décrites ci-dessous. Une interrogation est envoyée par le résolveur qui demande un RR PTR pour le nom de domaine fourni.

Un nom de domaine est généré à partir d'un NSAP en inversant les quartets hexadécimaux du NSAP, en traitant chaque quartet comme un sous domaine séparé, et en y ajoutant le nom de sous domaine de niveau supérieur "NSAP.INT". Par exemple, le nom de domaine utilisé dans la recherche inverse pour le NSAP

47.0005.80.005a00.0000.0001.e133.ffffff000162.00

apparaîtrait comme 

0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \ 0.8.5.0.0.0.7.4.NSAP.INT.

[Note de mise en œuvre : pour que cela fonctionne bien, les interfaces d'utilisateur devraient être conçues pour permettre aux utilisateurs d'entrer les NSAP en utilisant leur ordre naturel, c'est-à-dire, comme ils sont normalement écrits sur le papier. Aussi, des "." arbitraires devraient être permis (et ignorés) en entrée.]

 	7.	Format de fichier maître

Le format des RR NSAP (et des RR PTR relatifs aux NSAP) dans les fichiers maîtres se conforme à la Section 5, "Fichiers maîtres," de la [RFC1035]. On donne ci-dessous des exemples d'utilisation de ces RR dans des fichiers maîtres pour prendre en charge la transposition de nom en NSAP et de NSAP en nom.

Le RR NSAP introduit un nouveau format de chaîne hexadécimale pour le champ RDATA. Le format est "0x" (c'est-à-dire, un zéro suivi par un caractère 'x') suivi par une chaîne de longueur variable de caractères hexadécimaux (0 à 9, a à f). La chaîne hexadécimale est insensible à la casse. Les "." (points) peuvent être insérés dans la chaîne hexadécimale partout après le "0x" pour la lisibilité. Les "." n'ont pas de signification autre que la lisibilité et ne sont pas propagés dans le protocole (par exemple, dans les interrogations ou les transferts de zone).

;;;;;;
;;;;;; Fichier maître pour le domaine nsap.nist.gov.
;;;;;;

   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
                                     1994041800	; Série  - date
                                     1800 	; Rafraîchissement - 30 minutes
                                     300 	; Reessai   - 5 minutes
                                     604800	; Expiration  - 7 jours
                                     3600 ) 	; Minimum - 1 heure
          IN     NS     emu.ncsl.nist.gov.
          IN     NS     tuba.nsap.lanl.gov.
   ;
   ;
   $ORIGIN nsap.nist.gov.
   ;
   ;     hosts
   ;
   bsdi1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
            IN  A     129.6.224.161
            IN  HINFO PC_486    BSDi1.1
   ;
   bsdi2    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
            IN  A     129.6.224.162
            IN  HINFO PC_486    BSDi1.1
   ;
   cursive  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
            IN  A     129.6.224.171
            IN  HINFO PC_386    DOS_5.0/NCSA_Telnet(TUBA)
   ;
   infidel  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
            IN  A     129.6.55.164
            IN  HINFO PC/486    BSDi1.0(TUBA)
   ;
   ;     routeurs
   ;
   cisco1   IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
            IN  A     129.6.224.151
            IN  A     129.6.225.151
            IN  A     129.6.229.151
   ;
   3com1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
            IN  A     129.6.224.111
            IN  A     129.6.225.111
            IN  A     129.6.228.111

;;;;;;
;;;;;; Fichier maître pour transposition inverse des NSAP sous le préfixe NSAP 47.0005.80.005a00.0000.0001.e133
;;;;;;

   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
                                     1994041800	; Série  - date
                                     1800	; Rafraîchissement - 30 minutes
                                     300	; Réessai   - 5 minutes
                                     604800	; Expiration  - 7 jours
                                     3600 )	; Minimum - 1 heure
          IN     NS     emu.ncsl.nist.gov.
          IN     NS     tuba.nsap.lanl.gov.
   ;
   ;
   $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
   ;
   0.0.1.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi1.nsap.nist.gov.
   ;
   0.0.2.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi2.nsap.nist.gov.
   ;
   0.0.1.7.1.0.0.0.f.f.f.f.f.f  IN    PTR  cursive.nsap.nist.gov.
   ;
   0.0.4.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  infidel.nsap.nist.gov.
   ;
   0.0.1.5.1.0.0.0.a.a.a.a.a.a  IN    PTR  cisco1.nsap.nist.gov.
   ;
   0.0.1.1.1.0.0.0.a.a.a.a.a.a  IN    PTR  3com1.nsap.nist.gov.

 	8.	Considérations sur la sécurité

Les questions de sécurité ne sont pas discutées dans ce mémoire.

 	9.	Adresse des auteurs

Bill Manning	Richard Colella	
USC/Information Sciences Institute	National Institute of Standards and Technology	
4676 Admiralty Way	Technology/B217	
Marina del Rey, CA. 90292	Gaithersburg, MD 20899	
USA	USA	
téléphone : +1.310.822.1511	téléphone : +1 301-975-3627	
mél : bmanning@isi.edu 	mél : colella@nist.gov 	

 	10.	Références

[GOSIP]	GOSIP Advanced Requirements Group. "Government Open Systems Interconnection Profile (GOSIP) Version 2". Federal Information Processing Standard 146-1, U.S. Department of Commerce, National Institute of Standards and Technology, Gaithersburg, MD, avril 1991.

[ISO6523]	ISO/CEI JTC 1, Norme internationale 6523, "Échanges de donnés - structures pour l'identification des organisations". Genève, Confédération Helvétique, 1984.

[ISO8073]	ISO/CEI JTC 1, Norme internationale 8073, "Spécification de protocole de transport en mode connexion". Genève, Confédération Helvétique, 1986.

[ISO8473]	ISO/CEI JTC 1, Norme internationale 8473, "Protocole pour la fourniture du service réseau en mode sans connexion". Genève, Confédération Helvétique, 1986.

[ISO8348]	ISO/CEI JTC 1, Norme internationale 8348, "Systèmes de traitement de l'information – Communicationsde données – Définition du service réseau". Genève, Confédération Helvétique, 1993.

[RFC1034]	P. Mockapetris, "Noms de domaines - Concepts et facilités", STD 13, novembre 1987. (MàJ par RFC1101, 1183, 1348, 1876, 1982, 2065, 2181, 2308, 2535, 4033, 4034, 4035, 4343, 4035, 4592, 5936, 8020, 8482, 8767)

[RFC1035]	P. Mockapetris, "Noms de domaines – Mise en œuvre et spécification", STD 13, novembre 1987. (MàJ par RFC1101, 1183, 1348, 1876, 1982, 1995, 1996, 2065, 2136, 2181, 2137, 2308, 2535, 2673, 2845, 3425, 3658, 4033, 4034, 4035, 4343, 5936, 5966, 6604, 7766, 8482, 8767)

[RFC1629]	R. Colella et autres, "Lignes directrices pour allocations de NSAP OSI dans l'Internet", mai 1994. (D.S.)