Protocole de localisation de ressource (RLP)

La présente note décrit un protocole de localisation de ressources à utiliser dans l'ARPA Internet. Il est très utile sur les réseaux qui emploient des technologies qui prennent en charge une méthode d'adressage en diffusion, mais il peut aussi être utilisé sur d'autres types de réseaux. Pour en tirer un bénéfice maximum, tous les hôtes qui fournissent des ressources ou services significatifs à d'autres hôtes sur l'Internet devraient mettre en œuvre ce protocole. Les hôtes qui ne réussissent pas à mettre en œuvre le protocole de localisation de ressource risquent d'être ignorés par les autres hôtes qui essayent de localiser des ressources sur l'Internet. La présente RFC spécifie un projet de norme pour la communauté ARPA Internet.

Le protocole de localisation de ressource (RLP) utilise le protocole de datagramme d'utilisateur (UDP) [1] qui à son tour invoque le protocole Internet (IP) [3] pour livrer ses datagrammes. Voir à l'Appendice A et en [6] les allocations appropriées d'accès et de numéro de protocole.

Sauf indication contraire, toutes les quantités numériques du présent document sont des nombres décimaux.

1.   Introduction

De temps en temps, les hôtes de l'Internet sont confrontés au problème de la détermination de l'endroit de l'Internet où sont fournis certains services ou ressources réseau particuliers. Par exemple, cette situation va survenir lorsqu'un hôte a besoin d'envoyer un paquet destiné à un réseau externe à un routeur du réseau auquel il est directement connecté et ne connaît aucun des routeurs. Dans un autre cas, un hôte peut avoir besoin de traduire un nom de domaine en une adresse Internet et ne pas connaître de noms des serveurs auxquels il pourrait demander d'effectuer la traduction. Dans ces situations, un hôte peut utiliser le protocole de localisation de ressource pour déterminer ces informations.

Dans presque tous les cas, le problème de la localisation de ressources est simplement la question de trouver l'adresse IP d'un hôte (habituellement, n'importe lequel) soit sur le réseau directement connecté, soit ailleurs sur l'Internet, qui comprenne un protocole donné. Le plus souvent, l'hôte qui interroge comprend lui-même le protocole en question. Normalement (comme c'est le cas de la localisation d'un serveur de noms), l'hôte qui interroge entend ultérieurement utiliser ce protocole pour communiquer avec l'hôte localisé une fois que son adresse sera connue (par exemple, pour demander des traductions de noms en adresse). Moins souvent, l'hôte qui interroge ne comprend pas nécessairement lui-même le protocole en question. Au lieu de cela (comme dans le cas de la localisation d'un routeur), il essaye simplement de trouver quelque autre hôte qui le fasse (par exemple pour déterminer un endroit approprié pour livrer un paquet qui ne peut pas être livré localement).

2.   Dénomination de ressource

Bien que le problème de la localisation de ressource puisse, dans la plupart des cas, se réduire au problème de trouver un hôte qui mette en œuvre un protocole donné fondé sur Internet, la localisation d'un protocole Internet particulier du plus bas niveau (c'est-à-dire un auquel est alloué un numéro de protocole pour le transport en utilisant IP) n'est pas complètement suffisant. De nombreux services et ressources réseau significatifs sont fournis par des protocoles de niveau supérieur qui utilisent simplement les divers protocoles de niveau inférieur pour leurs propres besoins de transport (par exemple, le protocole FTP [2] emploie le protocole TCP [4] pour son transport de niveau inférieur). Conceptuellement, cette incorporation de protocole peut même être transposée sur des niveaux arbitraires.

Par conséquent, le protocole de localisation de ressource nomme une ressource par le numéro de protocole alloué à son protocole de transport Internet de plus bas niveau et par un identifiant spécifique de protocole/ressource de longueur variable. Par exemple, le protocole d'écho fondé sur UDP peut être désigné par son numéro alloué de protocole (17) et son numéro d'accès "bien connu" à 16 bits (7). Autrement, le protocole de message de contrôle Internet [5] (en l'absence de tout protocole client de niveau supérieur) serait désigné simplement par son numéro de protocole alloué (1) et un identifiant spécifique de protocole vide. D'un autre côté, certain protocole de ressource encore indéfini (fourni via, disons TCP) pourrait être désigné par le numéro de protocole alloué (6), son numéro d'accès TCP "bien connu" à 16 bits, et puis un identifiant supplémentaire de longueur fixe ou variable spécifique de cet accès TCP.

En général, les composants de l'identifiant spécifique de protocole/ressource sont définis comme étant des quantités "naturelles" utilisées pour démultiplexer successivement le protocole à chaque niveau supérieur suivant de protocole. Voir à la section 5 des échantillons d'allocations.

3.   Résumé du protocole

Le protocole de localisation de ressource est une simple procédure de demande/réponse. L'hôte qui interroge construit une liste des ressources qu'il voudrait localiser et envoie un message de demande sur le réseau. Un message de demande peut être envoyé soit à une adresse IP et un hôte particulier soit, sur les réseau qui fournissent une capacité d'adresse de diffusion, à l'adresse IP qui se réfère à tous les hôtes de ce réseau (voir en [7]). Par exemple, un hôte qui essaye de localiser un serveur de noms de domaines pourrait construire une demande contenant le nom de la ressource [17, 53] (se référant au protocole de serveur de noms de domaines fourni à l'accès UDP "bien connu" 53) puis diffuser ensuite cette demande sur son réseau local.

Chaque hôte receveur examine la liste des ressources désignées dans le paquet de demande, détermine lesquelles de ces ressources il détient, et retourne en confirmation un message de réponse à l'hôte demandeur. L'hôte receveur détermine si il fournit ou non une ressource par des décompositions successives du nom de la ressource jusqu'à ce que soit le nom soit épuisé, soit qu'il rencontre un composant qui n'est pas pris en charge. Dans l'exemple précédent, chaque hôte sur le réseau qui reçoit la demande diffusée va examiner le nom de la ressource en consultant d'abord ses tableaux pour déterminer si il fournit le service UDP. Si cela réussit, il va ensuite examiner le composant d'accès UDP du nom et consulter son tableau UDP pour déterminer si il fournit le service sur l'accès UDP 53. À ce point, le nom sera épuisé et si les deux vérifications ont été réussies, l'hôte va retourner un message de réponse à l'hôte qui interroge pour lui indiquer la prise en charge de la ressource.

3.1   Messages de demande

RLP fournit deux types de base de messages de demande qui peuvent être transmis par un hôte qui interroge. Le premier type exige qui tout hôte qui reçoit le message de demande ne retourne un message de réponse que si il fournit au moins une des ressources désignées dans la liste de demande. Le second type exige que tout hôte qui reçoit le message retourne toujours un message de réponse même si il ne fournit aucune des ressources désignées dans la liste de demande.

Ces deux types de messages de demande sont :

<Who-Provides?> (qui fournit ?)

Ce type exige que tout hôte qui reçoit le message retourne un message de réponse approprié qui désigne toutes les ressources figurant sur la liste de demande fournie. Si l'hôte receveur ne fournit aucune des ressources désignées, il peut ne pas retourner de réponse.

<Do-You-Provide?> (est-ce que vous fournissez ?)

Ce type est identique au message <Who-Provides?> mais avec l'exigence supplémentaire qu'une réponse doit toujours être retournée. Lorsque un hôte receveur ne fournit aucune des ressources demandées, il retourne simplement une liste de réponse vide. Cette liste de réponse vide permet à l'hôte demandeur de détecter immédiatement que l'hôte qui confirme ne fournit aucune des ressources désignées sans avoir à attendre la fin de la temporisation après avoir retransmis la demande de façon répétée.

Le message de demande <Who-Provides?> est typiquement utilisé lors de la diffusion de demandes à un réseau IP entier. Le message de demande <Do-You-Provide?> est, de son côté, typiquement utilisé lors de la confirmation qu'un hôte particulier fournit bien ou ne fournit pas une ou plusieurs ressources spécifiques. Il peut n'être pas en diffusion (car une telle demande inonderait l'hôte qui interroge de messages de réponse provenant de tous les hôtes du réseau).

En plus des deux types de base de messages de demande, deux variantes supplémentaires de types de messages de demande peuvent aussi être transmises par un hôte qui interroge. Ces types de message fournissent une capacité de localisation de ressource de "tiers". Ils diffèrent des types de message de base en fournissant un espace pour un qualificatif supplémentaire avec chaque ressource de la liste pour identifier les hôtes "tiers" dont l'hôte qui confirme estime qu'il peuvent fournir la ressource. Comme ci-dessus, le premier type exige que tout hôte qui reçoit le message de demande ne retourne un message de réponse que si il connaît un hôte qui fournit au moins une des ressources désignées dans la liste de demande. Le second type exige que tout hôte qui reçoit le message retourne toujours un message de réponse même si il n'a connaissance d'aucun hôte qui fournirait une des ressources désignées dans la liste des demandes.

Ces deux autres types de message de demande sont :

<Who-Anywhere-Provides?> (est-ce que quelqu'un, n'importe où, fournit ?)

Ce message fait le parallèle du message <Who-Provides?> avec la variante "tiers" décrite ci-dessus. L'hôte qui confirme est obligé de retourner au moins sa propre adresse IP (si il fournit la ressource désignée) ainsi que les adresses IP de tout autre hôte dont il pense qu'il peut fournir la ressource désignée. L'hôte qui confirme peut cependant ne jamais retourner une adresse IP pour une ressource qui est la même qu'une adresse IP figurant sur la liste avec le nom de la ressource dans le message de demande. Dans ce cas, il doit traiter la ressource comme si elle n'était pas prise en charge à cette adresse IP et l'omettre de toute liste de réponse.

<Does-Anyone-Provide?> (est-ce que quelqu'un fournit ?)

Ce message fait le parallèle du message <Do-You-Provide?> avec encore une fois la variante "tiers" décrite ci-dessus. Comme précédemment, l'hôte qui confirme est obligé de retourner sa propre adresse IP ainsi que les adresses IP de tout les autres hôtes dont il pense qu'ils peuvent fournir la ressource désignée et il est interdit de retourner la même adresse IP dans la spécification de ressource en réponse que celle qui figurait dans la liste spécifiée dans la demande de ressources. Comme dans le cas <Do-You-Provide?> et pour les mêmes raison, ce message peut aussi n'être pas en diffusion.

Ces variantes de messages de demande permettent aux hôtes "intelligents" de fournir des informations de localisation de ressource pour les réseaux sans capacité de diffusion (pourvu que tous les hôtes du réseau sachent toujours l'adresse d'un ou plusieurs de ces hôtes "intelligents"). Elles permettent aussi que des informations de localisation de ressource pour les services qui ne sont fournis nulle part sur un réseau directement connecté soient fournies par des routeurs "intelligents" qui ont peut-être interrogé d'autres réseaux auxquels ils sont rattachés ou bien ont acquis l'information d'une autre façon.

La restriction sur le retour dans une réponse de la même adresse IP que celle qui était spécifiée dans la demande fournit un mécanisme primitif pour exclure la prise en considération de certaines adresses connues dans une réponse (voir l'exemple 3 de la section 5). Elle peut aussi être utilisée pour outrepasser la préférence de l'hôte receveur pour sa propre adresse IP dans les réponses de "tiers" lorsque ceci est exigé.

3.2.   Messages de réponse

Chacun des types de message de demande a un type associé de message de réponse. Le type de base de message de réponse est retourné en réponse aux deux messages de demande <Who-Provides?> et <Do-You-Provide?> et fournit les informations sur les ressources fournies par l'hôte qui confirme. L'autre type de message de réponse est la variante "tiers" retournée en réponse aux deux messages de demande <Who-Anywhere-Provides?> et <Does-Anyone-Provide?> et fournit les informations sur les ressources fournies par les hôtes connus de l'hôte qui confirme.

Ces deus types de message de réponse sont :

<I-Provide> (je fournis)

Ce message de réponse contient une liste exacte des ressources provenant de la liste de demande que fournit l'hôte qui confirme. Ces ressources doivent figurer dans la liste de réponse précisément dans le même ordre que celui de la liste du message de demande.

<They-Provide> (ils fournissent)

Ce message de réponse contient de façon similaire une liste exacte des ressources provenant de la liste de demande (qualifiées de façon appropriée avec les adresses IP) que fournit l'hôte qui confirme ou dont il pense qu'un autre hôte les fournit. Encore une fois, ces ressources doivent figurer dans la liste de réponse précisément dans le même ordre que celui dans lequel elles figuraient dans le message de demande.

Ces deux types de message de réponse peuvent n'être pas en diffusion.

Un hôte demandeur qui reçoit un message <They-Provide> en réponse de la part d'un hôte qui confirme au nom d'un hôte tiers n'est pas obligé de s'appuyer inconditionnellement sur les informations indirectes fournies. Ces informations devraient normalement être considérées comme une simple indication. Dans la plupart des cas, l'hôte qui interroge devrait transmettre une demande <Do-You-Provide?> spécifique à l'hôte tiers et confirmer que la ressource est bien fournie à cette adresse IP avant de poursuivre.

4.   Formats de message

Les messages RLP sont encapsulés dans les paquets UDP pour tirer parti de la capacité de multiplexage fournie par les accès de source et destination RLP et de la fiabilité supplémentaire fournie par la somme de contrôle UDP. Les messages de demande sont envoyés à partir d'un accès de source pratique sur l'hôte qui interroge à l'accès RLP de destination d'un hôte receveur. Les messages de réponse sont retourné de l'accès RLP de source alloué à l'hôte qui confirme à l'accès de destination approprié de l'hôte qui interroge, comme déterminé par l'accès de source dans le message de demande.

Le format des divers messages RLP est décrit dans les diagrammes suivants. Toutes les quantités numériques qui occupent plus d'un octet sont mémorisées dans les messages de l'octet de poids fort à l'octet de moindre poids, selon la norme usuelle du protocole Internet. Tous les diagrammes de paquet indiquent les octets du message de gauche à droite et ensuite du haut vers le bas comme ils surviennent dans la portion de données du paquet UDP encapsulant.

Chaque paquet RLP a le format général suivant :

+--------+--------+--------+--------+

|        |        |        |

| Type   | Flags  | Message-ID      |

|        |        |        |

+--------+--------+--------+--------+

| -

|          Resource-List -

| -

+--------+--------+--------+---\\---+

- +

-            Resource-List |

- |

+--------+--------+--------+---\\---+

où

<Type>

est un seul octet qui identifie le type de message. Les types actuellement définis sont :

0   <Who-Provides?>

1   <Do-You-Provide?>

2   <Who-Anywhere-Provides?>

3   <Does-Anyone-Provide?>

4   <I-Provide>

5   <They-Provide>

6-255   réservé.

<Flags> (fanions)

est un seul octet qui spécifie les possibles modifications à l'interprétation standard de <Type>. Les bits dans ce champ sont numérotés de gauche à droite (du plus fort poids vers le moindre poids) en commençant par le bit 1. Les bits fanions actuellement définis sont :

Bit 1   <Local-Only> (seulement en local). Exige que tout message de réponse généré en réponse à un message de demande avec ce bit de fanion mis (à 1) ne puisse nommer que les adresses IP qui sont sur le même réseau IP que l'envoyeur du message de demande. Ce fanion exige aussi que les hôtes multi-rattachement qui répondent aux diffusions de demandes <Who-Provides?> utilisent l'adresse source de réseau IP local appropriée dans la réponse retournée. Ce bit doit être à zéro dans les messages de réponse.

Bits 2-8   Réservés. Doivent être à zéro.

<Message-ID>

est une valeur de deux octet (16 bits) qui identifie le message de demande. Il est utilisé simplement pour aider à faire correspondre les demandes et les réponses. L'hôte envoyeur devrait initialiser ce champ à une valeur pratique lorsqu'il construit un message de demande. L'hôte receveur doit retourner cette même valeur dans le champ <Message-ID> de tout message de réponse généré en réponse à cette demande.

<Resource-List>

est la liste des ressources demandées ou pour lesquelles des informations de localisation sont fournies. Cette liste est une séquence d'octets commençant à l'octet qui suit le <Message-ID> et s'étend jusqu'à la fin du paquet UDP. Le format de ce champ est expliqué plus en détail au paragraphe suivant. La taille de cette liste est implicitement spécifiée par la longueur du datagramme UDP encapsulant.

4.1   Listes de ressources

Une <Resource-List> consiste en zéro, un ou plusieurs spécificateurs de ressource. Chaque spécificateur de ressource est simplement une séquence d'octets. Tous les spécificateurs de ressource ont un format initial de nom de ressource commun

+--------+--------+--------+---\\---+

|        |        |        |

|Protocol|IDLength| Resource-ID     |

|        |        |        |

+--------+--------+--------+---\\---+

où

<Protocol>

est le numéro de protocole alloué au protocole Internet de plus bas niveau utilisé pour accéder à la ressource.

<IDLength>

est la longueur de l'identifiant de ressource associé à ce <Protocol>. Cette longueur peut avoir une valeur fixée ou une valeur variable selon la ressource en question. Il est inclus de telle sorte que les spécificateurs qui se réfèrent aux ressources qu'un hôte ne peut pas fournir puissent être sautés sans qu'on ait besoin de connaître la structure spécifique de l'identifiant de la ressource en question. Si le <Protocol> n'a pas d'identifiant naturel associé, cette longueur est 0.

<Resource-ID>

est l'identifiant qualificatif utilisé pour préciser un peu plus la ressource demandée. Si le champ <IDLength> était 0, ce champ est alors vide et n'occupe pas d'espace dans le spécificateur de ressource.

De plus, les spécificateurs de ressource dans tous les messages <Who-Anywhere-Provides?>, <Does-Anyone-Provide?> et <They-Provide> contiennent aussi un qualificatif supplémentaire qui suit le <Protocol-ID>. Ce qualificatif a le format :

+--------+--------+--------+--------+---//---+

|        |        |

|IPLength| IP-Address-List |

|        |        |

+--------+--------+--------+--------+---//---+

où

<IPLength>

est le nombre d'adresses IP contenues dans le <IP-Address-List> suivant (le champ <IP-Address-List> occupe donc les quatre derniers octets 4*<IPLength> dans son spécificateur de ressource). Dans les messages de demande, c'est le nombre maximum d'adresses qualificatives qui peuvent être incluses dans le spécificateur de ressource de la réponse correspondante. Bien que ce ne soit pas particulièrement utile, il peut être à 0 et dans ce cas ne donne pas d'espace pour qualifier le nom de la ressource avec des adresses IP dans le spécificateur retourné. Dans les messages de réponse, c'est le nombre d'adresses qualificatives connues pour fournir la ressource. Il peut ne pas dépasser le nombre spécifié dans le spécificateur de la demande correspondante. Ce champ ne peut pas être 0 dans un message de réponse, sauf si il a été fourni à 0 dans le message de demande et que l'hôte qui confirme a retourné une ou plusieurs adresses IP si de l'espace avait été fourni.

<IP-Address-List>

est une liste d'adresses IP de quatre octets utilisée pour qualifier le spécificateur de ressource par rapport à ces adresses particulières. Dans les messages de réponse, ce sont les adresses IP de l'hôte qui confirme (le cas échéant) et les adresses de tous les autres hôtes connus pour fournir cette ressource (sous réserve des limitations de longueur de la liste). Dans les messages de demande, ce sont les adresses IP des hôtes pour lesquels les informations de ressource ne peuvent pas être retournées. Dans de tels messages, ces adresses devraient normalement être initialisées à une valeur "neutre" (comme l'adresse de l'hôte qui fait la demande) sauf si il est prévu d'exclure spécifiquement les adresses fournies de toute prise en considération dans les messages de réponse.

L'hôte receveur détermine si il fournit une des ressources désignées dans la liste de demande en décomposant successivement chaque nom de ressource. Le premier niveau de décomposition est le numéro de protocole Internet qui peut vraisemblablement être recherché dans un tableau pour déterminer si ce protocole est pris en charge par l'hôte. Les décompositions suivantes sont fondées sur les composants précédents jusqu'à ce qu'un des trois événements suivants survienne :

1.   le composant actuel identifie un aspect des composants précédents que l'hôte ne prend pas encharge,

2.   le nom de ressource tiré de la liste de demande est épuisé, ou

3.   le nom de ressource tiré de la liste de demande n'est pas épuisé mais l'hôte n'attend plus d'autre composant dans le nom donné dans les composants précédents.

Dans le cas 1, l'hôte receveur a déterminé qu'il ne fournit pas la ressource désignée. Le spécificateur de ressource peut n'être pas inclus dans un message de réponse retourné.

Dans le cas 2, l'hôte receveur a déterminé qu'il fournit bien la ressource désignée (note : cela peut arriver même si l'hôte receveur aurait attendu que le nom de ressource contienne plus de composants que ceux qui sont réellement présents). Le spécificateur de ressource doit être inclus (sauf prohibitions d'adresse IP) dans tout message de réponse retourné.

Dans le cas 3, l'hôte receveur a déterminé qu'il ne fournit pas complètement la ressource désignée car il reste des composants de nom qu'il ne comprend pas (cela peut arriver avec des spécialisations ou des extensions d'un protocole connu qui ne sont pas reconnues universellement). Le spécificateur de ressource peut n'être pas inclus dans un message de réponse retourné.

5.   Exemples d'utilisation

Les scénarios suivants illustrent des utilisations typiques de RLP. Dans tous les cas, les messages indiqués sont encapsulés dans un datagramme UDP avec les numéros d'accès de source et de destination appropriés, la longueur du message, et la somme de contrôle. Ce datagramme est ensuite encapsulé dans un datagramme IP avec l'adresse de source appropriée de l'hôte envoyeur et l'adresse de destination (individuelle ou en diffusion) pour l'hôte receveur.

Tous les exemples numériques de protocole sont comme spécifié dans les documents appropriés de description de protocole dont la liste figure dans les références.

1.   Supposons un hôte H fraîchement réamorcé qui souhaite trouver un routeur sur le réseau où il est directement connecté, auquel il puisse envoyer son premier paquet externe. Il va alors diffuser la demande

<Who-Provides?> <Flags>=<Local-Only> <Message-ID>=12345 <Resource-List>={[GGP], [EGP]}

codé dans le message de 8 octets

+---+-----+-------+---+---+---+---+-----+

| 0 | 128 | 12345 | 3 | 0 | 8 | 0 |

+---+-----+-------+---+---+---+---+-----+

sur son réseau local.

-   Le routeur G1 (qui comprend EGP) reçoit la demande et retourne comme réponse :

<I-Provide> <Flags>=none <Message-ID>=12345 <Resource-List>={[EGP]}

codé dans le message de 6 octets

+---+---+-------+---+---+-----+

| 4 | 0 | 12345 | 8 | 0 |

+---+---+-------+---+---+-----+

à l'hôte H qui se souvient alors que ce routeur G1 peut être utilisé pour acheminer du trafic au reste de l'Internet.

-   Au même moment, le routeur G2 (qui comprend à la fois GGP et EGP) peu aussi recevoir la demande et retourner la réponse

<I-Provide> <Flags>=none <Message-ID>=12345 <Resource-List>={[GGP], [EGP]}

codé dans le message de 8 octets

+---+---+-------+---+---+---+---+-----+

| 4 | 0 | 12345 | 3 | 0 | 8 | 0 |

+---+---+-------+---+---+---+---+-----+

à l'hôte H qui peut alors aussi ajouter le routeur G2 à sa liste si c'est son choix.

2.   Supposons maintenant que l'hôte H est un système autonome qui a simplement rencontré quelque erreur logicielle fatale et souhaite localiser un serveur de vidage de la mémoire en cas de panne pour sauvegarder son état avant de réamorcer. Supposons que le protocole de vidage de la mémoire en cas de panne sur le réseau local de l'hôte soit mis en œuvre en utilisant le protocole trivial de transfert de fichier (TFTP, Trivial File Transfer Protocol) [8]. De plus, supposons que le nom de fichier particulier "CRASH-DUMP" soit utilisé pour indiquer le traitement de vidage de la mémoire en cas de panne (par exemple, le serveur peut générer localement un nom unique de fichier pour détenir chaque dépôt qu'il reçoit d'un hôte). L'hôte H peut alors diffuser la demande

<Who-Provides?> <Flags>=none <Message-ID>=54321 <Resource-List>={[UDP, TFTP, WRQ, "CRASH-DUMP"]}

codé dans le message de 21 octets

+---+---+-------+----+----+----+-----+-----+

| 0 | 0 | 54321 | 17 | 15 | 69 |

+---+---+-------+----+----+----+-----+-----+

| 2 | 'C' 'R' 'A' 'S' 'H' '-' |

+---+---+-------+----+----+----+-----+-----+

| 'D' 'U'   'M'   'P'  0  |

+---+---+-------+----+----+

à son réseau local (noter que le composant de nom de fichier est explicitement terminé par un octet nul de façon à ne pas exclure une future spécialisation plus poussée du protocole de vidage de la mémoire en cas de panne).

-   L'hôte C (qui accepte cette spécialisation du protocole TFTP) reçoit la demande et retourne la réponse

<I-Provide> <Flags>=none <Message-ID>=54321 <Resource-List>={[UDP, TFTP, WRQ, "CRASH-DUMP"]}

codé dans le message de 21 octets

+-----+------+-------+-----+-----+-----+-----+-----+

|     | 0    | 54321 |  17 |  15 |  69 |

+-----+------+-------+-----+-----+-----+-----+-----+

|  2  | 'C'     'R'    'A'   'S'   'H'   '-' |

+-----+------+-------+-----+-----+-----+-----+-----+

|  'D'  'U'     'M'    'P'     0 |

+-----+------+-------+-----+-----+

à l'hôte H qui peut alors procéder à l'envoi de sa mémoire à l'hôte C et réamorcer.

-   Cependant l'hôte D (qui fournit le service TFTP mais pas la spécialisation de vidage de mémoire en cas de panne) peut recevoir la demande et déterminer qu'il ne fournit pas la prise en charge de la ressource (car le nom de la ressource contient des composants qu'il ne comprend pas à la suite du numéro d'accès UDP). Il va donc ne pas retourner de réponse à l'hôte H.

3.   Finalement, supposons que l'hôte M souhaite localiser un serveur de traduction de noms de domaine (fondé sur UDP ou sur TCP) n'importe où sur l'Internet. De plus, supposons que l'hôte M est sur un réseau IP qui ne fournit pas de capacités d'adresse en diffusion et que l'hôte R est un serveur de localisation de ressource "connu" pour ce réseau.

D'abord, dans la mesure où l'hôte M préfère trouver un serveur de noms de domaine si possible sur son propre réseau de connexion local, il envoie la demande

<Does-Anyone-Provide?> <Flags>=<Local-Only> <Message-ID>=12321 <Resource-List>=

{[TCP, <DOMAIN-NAME-SERVER-PORT>] {M},

[UDP, <DOMAIN-NAME-SERVER-PORT>] {M}}

codé dans le message de 22 octets

+-----+-----+-------+-----+

|   3 | 128 | 12321 |

+-----+-----+-------+-----+-----+-----+-----+-----+-----+

|   6 |   2 |    53 |   1 |   M |

+-----+-----+-------+-----+-----+-----+-----+-----+-----+

|  17 |   2 |    53 |   1 |   M |

+-----+-----+-------+-----+-----+-----+-----+-----+-----+

à l'hôte R.

L'hôte R reçoit la demande et consulte ses tables à la recherche des hôtes connus pour prendre en charge toutes les variétés de service de noms de domaine. Il trouve des entrées indiquant que les deux hôtes S et T fournissent des services de noms de domaine fondés sur UDP mais ni l'un ni l'autre ne sont sur le même réseau IP que l'hôte H. Il doit alors envoyer la réponse de confirmation négative

<They-Provide> <Flags>=none <Message-ID>=12321 <Resource-List>={}

codé dans le message de 4 octets

+-----+-----+-------+-----+

|   5 |   0 | 12321 |

+-----+-----+-------+-----+

en réponse à l'hôte M.

L'hôte M, en recevant cette réponse, pourrait maintenant abandonner tout espoir de trouver un serveur sur son propre réseau et reformater sa demande pour permettre toutes les adresses d'hôte, et renvoyer

<Does-Anyone-Provide?> <Flags>=none <Message-ID>=12322 <Resource-List>=

{[TCP, <DOMAIN-NAME-SERVER-PORT>] {M},

[UDP, <DOMAIN-NAME-SERVER-PORT>] {M}}

codé dans le message de 22 octets

+-----+-----+-------+-----+

|   3 |   0 | 12322 |

+-----+-----+-------+-----+-----+-----+-----+-----+-----+

|   6 |   2 |    53 |   1 |   M |

+-----+-----+-------+-----+-----+-----+-----+-----+-----+

|  17 |   2 |    53 |   1 |   M |

+-----+-----+-------+-----+-----+-----+-----+-----+-----+

à nouveau à l'hôte R.

L'hôte R reçoit cette nouvelle demande et n'est plus contraint de ne retourner que des adresses locales. Cependant, comme n'a été fourni que l'espace pour une seule adresse IP qualificative dans chaque spécificateur de demande de ressource, il peut ne pas retourner immédiatement les deux adresses. Au lieu de cela, il est forcé de ne retourner que la première adresse et répond

<They-Provide> <Flags>=none <Message-ID>=12322 <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>] {S}}

codé dans le message de 13 octets

+-----+-----+-------+-----+-----+-----+-----+-----+

|   5 |   0 | 12322 |  17 |   2 |  53 |

+-----+-----+-------+-----+-----+-----+-----+-----+

|   1 |   S |

+-----+-----+-------+-----+-----+

à l'hôte M.

L'hôte M reçoit la réponse et (étant soupçonneux par nature) décide de la confirmer avec l'hôte S. Il envoie alors

<Do-You-Provide?> <Flags>=none <Message-ID>=12323 <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>]}

codé dans le message de 8 octets

+-----+-----+-------+-----+-----+-----+-----+-----+

|   1 |   0 | 12323 |  17 |   2 |  53 |

+-----+-----+-------+-----+-----+-----+-----+-----+

à l'hôte S, et il reçoit en retour de l'hôte S la réponse

<I-Provide> <Flags>=none <Message-ID>=12323 <Resource-List>={}

codée dans le message de 4 octets

+-----+-----+-------+-----+

|   4 |   0 | 12323 |

+-----+-----+-------+-----+

niant toute prise en charge de service de noms de domaine fondé sur UDP.

En désespoir de cause l'hôte M interroge à nouveau l'hôte R, en excluant cette fois l'hôte S du champ de recherche, et envoie la demande

<Does-Anyone-Provide?> <Flags>=none <Message-ID>=12324 <Resource-List>=

{[TCP, <DOMAIN-NAME-SERVER-PORT>] {S},

[UDP, <DOMAIN-NAME-SERVER-PORT>] {S}}

codé dans le message de 22 octets

+-----+-----+-------+-----+

|   3 |   0 | 12324 |

+-----+-----+-------+-----+-----+-----+-----+-----+-----+

|   6 |   2 |    53 |   1 |   S |

+-----+-----+-------+-----+-----+-----+-----+-----+-----+

|  17 |   2 |    53 |   1 |   S |

+-----+-----+-------+-----+-----+-----+-----+-----+-----+

et reçoit cette fois la réponse

<They-Provide> <Flags>=none <Message-ID>=12324 <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>] {T}}

codée dans le message de 13 octets

+-----+-----+-------+-----+-----+-----+-----+-----+

|   5 |   0 | 12324 |  17 |   2 |  53 |

+-----+-----+-------+-----+-----+-----+-----+-----+

|   1 |   T |

+-----+-----+-------+-----+-----+

de l'hôte R, que bien sûr l'hôte M insiste à nouveau pour confirmer en envoyant la demande

<Do-You-Provide?> <Flags>=none <Message-ID>=12325 <Resource-List>= {[UDP, <DOMAIN-NAME-SERVER-PORT>]}

codée dans le message de 8 octets

+-----+-----+-------+-----+-----+-----+-----+-----+

|   1 |   0 | 12325 |  17 |   2 |  53 |

+-----+-----+-------+-----+-----+-----+-----+-----+

à l'hôte T, et il reçoit finalement confirmation de l'hôte T avec cette réponse :

<I-Provide> <Flags>=none <Message-ID>=12325 <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>]}

codée dans le message de 8 octets

+-----+-----+-------+-----+-----+-----+-----+-----+

|   4 |   0 | 12325 |  17 |   2 |  53 |

+-----+-----+-------+-----+-----+-----+-----+-----+

qu'il fournit bien le service de traduction des noms de domaine à l'accès UDP 53.

Appendice A   Numéros alloués

Le numéro d'accès UDP "bien connu" pour le protocole de localisation de ressource est 39 (47 en octal).

Références

[1]   J. Postel, "Format structuré pour la transmission de documents multimédia", août 1980.

[2]   J. Postel, "Protocole de transfert de fichiers", juin 1980.

[3]   J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet DARPA", STD 5, septembre 1981.

[4]   J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", (STD 7), septembre 1981.

[5]   J. Postel, "Protocole du message de contrôle Internet – Spécification du protocole du programme Internet DARPA", STD 5, septembre 1981.

[6]   J. Reynolds et J. Postel. "Numéros alloués" RFC 870, USC/Information Sciences Institute, octobre 1983. (Obsolète, voir le sitewww.iana.org)

[7]   Gurwitz, R.,et R. Hinden, "IP – problèmes d'adressage de réseau de zone locale" IEN 212, Bolt Beranek and Newman, septembre 1982.

[8]   K. Sollins, "Protocole TFTP (révision 2)", juin 1981. (rendue obsolète par la RFC1350)