Untitled Document

Protocole d'allocation dynamique d'adresse de client de diffusion groupée (MADCAP)

Le présent document définit le protocole d'allocation dynamique d'adresse de client de diffusion groupée (MADCAP, Multicast Address Dynamic Client Allocation Protocol) qui permet aux hôtes de demander des adresses de diffusion groupée à des serveurs d'allocation d'adresses de diffusion groupée.

Le protocole d'allocation dynamique d'adresse de client de diffusion groupée (MADCAP) permet aux hôtes de demander des services d'allocation d'adresse de diffusion groupée à des serveurs d'allocation d'adresse de diffusion groupée. Ce protocole fait partie de l'architecture d'allocation d'adresses de diffusion groupée qui est définie par le groupe de travail Allocation d'adresse de diffusion groupée de l'IETF. Il peut cependant être utilisé séparément du reste de cette architecture en tant que de besoin.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la RFC 2119 [9].

Les constantes utilisées par ce protocole apparaissent comme [NOM-DE-CONSTANTE] et sont résumées à l'Appendice B.

La présente spécification utilise un certain nombre de termes qui ne sont peut être pas familiers au lecteur. La présente section définit certains d'entre eux et se réfère aux autres documents pour la définition des autres.

C'est un hôte qui demande des services d'allocation d'adresse de diffusion groupée via MADCAP.

C'est un hôte qui fournit des services d'allocation d'adresses de diffusion groupée via MADCAP.

C'est la diffusion groupée sur IP, telle que définie dans [11] et modifiée dans [12].

C'est une adresse de diffusion groupée IP ou groupe d'adresses, telle que définie dans [11] et [13]. C'est un identifiant pour un groupe de nœuds.

C'est une gamme d'adresses de diffusion groupée configurée de telle sorte que le trafic envoyé à ces adresses soit limité à un sous-ensemble de l'Internet. Voir [3] et [13].

C'est l'adresse de plus faible numéro dans une portée de diffusion groupée. Cette définition ne s'applique qu'au sein du présent document.

Une portée de diffusion groupée peut avoir plusieurs instances, qui sont appelées zones de portée ou zones tout court. Par exemple, une organisation peut avoir plusieurs sites. Chaque site peut avoir sa propre zone de portée de site locale, chacune d'elles serait une instance de la portée locale de site. Cependant, une interface donnée sur une hôte donné ne sera jamais que dans une seule instance d'une portée donnée. Les messages envoyés par un hôte dans des zones de portée de site local à une adresse dans la portée de site local seront limitées à la zone de site local qui contient l'hôte.

C'est un nom lisible par l'homme pour une zone de portée, une chaîne de caractères ISO 10646 avec une étiquette de langue de la RFC 1766 [6]. Une zone peut avoir plusieurs noms, chacun dans une langue différente. Par exemple, une zone à utiliser dans les localisations d'IBM en Suisse pourrait avoir les noms "IBM Suisse", "IBM Switzerland", "IBM Schweiz", et "IBM Svizzera" avec les étiquettes de langage "fr", "en", "de", et "it".

C'est une liste des zones de portée de diffusion groupée. Comme il peut être difficile de déterminer quelles zones de portée de diffusion groupée sont en vigueur, les clients MADCAP peuvent demander aux serveurs MADCAP de fournir une liste de portées de diffusion groupée récapitulant toutes les zones disponibles pour le client. Pour chaque zone de portée, la liste comporte la gamme d'adresses de diffusion groupée pour cette portée, un TTL maximum ou un compte de bonds à utiliser pour cette portée, et un ou plusieurs noms de zone pour cette zone de portée.

Pour que les applications de diffusion groupée soient déployées partout, il est nécessaire de définir un protocole que tout hôte puisse utiliser pour allouer les adresses de diffusion groupée. Voici les exigences pour un tel protocole.

Rapidité de réponse : L'hôte devrait être capable d'allouer une adresse de diffusion groupée et de commencer à l'utiliser rapidement.

Faible charge réseau : Les hôtes qui n'allouent ni ne désallouent d'adresses de diffusion groupée à présent ne devraient pas avoir besoin d'envoyer ou recevoir aucun trafic réseau.

Prise en charge de système à connexion intermittente ou gérés par le réseau électrique : Les hôtes devraient être capables d'être déconnectés du réseau, débranchés, ou rendus autrement inaccessibles sauf durant les brèves périodes durant lesquelles ils allouent une adresse de diffusion groupée.

Portée d'adresse de diffusion groupée : Le protocole doit être capable d'allouer aussi bien les adresses de diffusion groupée à portée limitée administrativement que les adresses de diffusion groupée à portée mondiale.

Utilisation efficace de l'espace d'adresse : L'espace d'adresse de diffusion groupée est très petit. Le protocole devrait faire une utilisation efficace de cette ressource rare.

Authentification : À cause de la rareté des adresses de diffusion groupée, il est important de se protéger contre l'accaparement de ces adresses. On peut le faire en authentifiant les clients. C'est aussi une condition préalable clé pour l'établissement des politiques.

Politiquement neutre : Les politiques d'allocation (comme qui peut allouer les adresses) ne devraient pas être dictées par le protocole.

Prise en charge des applications de conférence : Lorsque on alloue une adresse à utiliser dans un environnement de conférence, les membres de la conférence devraient être capables de modifier une adresse de diffusion groupée prêtée pour la conférence.

MADCAP était à l'origine fondé sur DHCP. Il y a toujours quelques similitudes et il est possible que les mises en œuvre de DHCP et de MADCAP aient du code en commun. Cependant, MADCAP est complètement distinct de DHCP ; il n'y a aucune dépendance entre les deux et il y a de nombreuses différences significatives.

MADCAP est construit sur un modèle client-serveur, dans lequel les hôtes demandent des services d'allocation d'adresse aux serveurs d'allocation d'adresse. Lorsque un client MADCAP souhaite demander un service, il envoie un message en envoi individuel ou en diffusion groupée à un ou plusieurs serveurs MADCAP, dont chacun répond facultativement par un message en envoi individuel au client.

Tous les messages sont des datagrammes UDP. Les données UDP contiennent un en-tête de longueur fixe et un champ d'options de longueur variable. Les options sont codées dans un format type-longueur-valeur avec des champs de type et de valeur de deux octets. Les champs fixes sont ceux de version, msgtype (type de message), addrfamily (famille d'adresse), et xid (identifiant de transaction).

La retransmission est traitée par le client. Si un client envoie un message et ne reçoit pas de réponse, il peut retransmettre sa demande un petit nombre de fois en utilisant un recul exponentiel. Pour éviter d'exécuter deux fois la même demande du client lorsque est reçue une demande retransmise, les serveurs mettent les réponses en antémémoire pendant un court instant et renvoient les réponses mises en antémémoire à réception des demandes retransmises.

Chaque demande contient un msgtype, un xid, et une option d'identifiant de prêt (Lease Identifier). Les clients doivent s'assurer que ce triplet est vraisemblablement unique sur tous les messages MADCAP reçus par un serveur MADCAP sur une période de [XID-REUSE-INTERVAL] (10 minutes). Cela permet au serveur MADCAP d'utiliser ce triplet comme clé dans son antémémoire de réponse.

Les messages envoyés par les serveurs comportent le xid inclus dans la demande d'origine de sorte que les clients puissent faire correspondre les réponses aux demandes.

Le champ msgtype est d'un seul octet et définit le "type" d'un message MADCAP. Les types de message actuellement définis sont énumérés au Tableau 2. Ce sont : DISCOVER, OFFER, REQUEST, RENEW, ACK, NAK, RELEASE et GETINFO. Les messages DISCOVER, REQUEST, RENEW, RELEASE et GETINFO ne sont envoyés que par un client. Les messages OFFER, ACK et NAK ne sont envoyés que par un serveur.

Les messages REQUEST, RENEW et RELEASE sont utilisés pour demander, renouveler, ou libérer un prêt sur une ou plusieurs adresses de diffusion groupée. Un client fait un envoi individuel de l'un de ces messages à un serveur et le serveur répond par un ACK ou un NAK.

Le message GETINFO est utilisé pour demander des informations, telles que la liste des portées de diffusion groupée, ou pour trouver des serveurs MADCAP. Un client peut faire un envoi individuel du message GETINFO à un serveur MADCAP. Cependant, il peut ne connaître l'adresse IP d'aucun serveur MADCAP. Dans ce cas, il va faire une diffusion groupée d'un message GETINFO à une adresse de diffusion groupée de serveur MADCAP et tous les serveurs qui souhaitent répondre vont renvoyer un ACK ou NAK au client.

Chaque portée de diffusion groupée a une adresse de diffusion groupée de serveur MADCAP associée. Cette adresse a été réservée par l'IANA comme l'adresse d'un décalage relatif de -1 par rapport à la dernière adresse d'une portée de diffusion groupée. Les clients MADCAP utilisent cette adresse pour trouver les serveurs MADCAP.

Le message DISCOVER est un message utilisé pour découvrir les serveurs MADCAP qui peuvent probablement satisfaire une demande. Les messages DISCOVER sont toujours en diffusion groupée. Les serveurs qui peuvent probablement satisfaire une demande correspondant aux paramètres fournis dans le message DISCOVER réservent temporairement les adresses nécessaires et renvoient une offre en envoi individuel au client. Le client choisit un serveur avec lequel poursuivre et envoie une demande en diffusion groupée comportant l'identifiant de serveur du serveur à la même adresse de diffusion groupée qu'utilisée pour le message DISCOVER. Le serveur choisi répond par un ACK ou un NAK et les autres serveurs arrêtent de réserver les adresses qu'ils conservaient temporairement.

Pour des descriptions détaillées des échanges de protocole typiques, consulter l'Appendice A.

MADCAP est un mécanisme plutôt qu'une politique. MADCAP permet aux administrateurs de système local d'exercer un contrôle sur les paramètres de configuration lorsque ils le désirent. Par exemple, les serveurs MADCAP peuvent être configurés de façon à limiter le nombre d'adresses de diffusion groupée allouées à un seul client. La mise en application appropriée d'une telle limite requiert une sécurité cryptographique, telle que décrite à la Section Considération sur la sécurité.

Les demandes MADCAP provenant d'un seul hôte peuvent être envoyées au nom de différentes applications ayant des besoins et exigences différentes. Les serveurs MADCAP NE DOIVENT PAS supposer que parce qu'une demande provenant d'un client MADCAP prend en charge une caractéristique facultative particulière (comme Retry After), les demandes futures provenant de ce client vont aussi prendre en charge ces caractéristiques facultatives.

Le protocole MADCAP est un protocole client-serveur. En général, le client fait un message en envoi individuel ou en diffusion groupée à un ou plusieurs serveurs, qui répondent facultativement par des messages en envoi individuel au client.

Un numéro d'accès réservé dédié à MADCAP est utilisé sur le serveur (numéro d'accès 2535, alloué par l'IANA). Tout numéro d'accès peut être utilisé sur les machines clientes. Lorsque un serveur MADCAP envoie un message à un client MADCAP, il DOIT utiliser un numéro d'accès de destination qui correspond au numéro d'accès de source fourni par le client dans le message qui est cause que le serveur a envoyé ce message.

Les paragraphes qui suivent décrivent le format de message MADCAP et les types de message. Une liste complète des options MADCAP figure à la Section 3.

La Figure 1 donne le format d'un message MADCAP et le Tableau 1 décrit chacun des champs dans le message MADCAP. Les numéros entre parenthèses indiquent la taille de chaque champ en octets. Les noms des champs donnés dans la figure seront utilisés tout au long de ce document pour se référer aux champs des messages MADCAP.

Toutes les quantités de plusieurs octets sont dans l'ordre des octets du réseau.

Tout message dont les données UDP sont trop courtes pour tenir ce format (au moins 12 octets) DOIVENT être ignorées.

Champ	Octets	Description
version	1	Numéro de version du protocole (zéro pou cette spécification)
sgtype	1	Type de message (DISCOVER, GETINFO, etc.)
addrfamily	2	Famille d'adresses (IPv4, IPv6, etc.)
xid	4	Identifiant de transaction
options	variable	Champs d'options

2.1.1 Champ version

Le champ version doit toujours être zéro pour la présente version du protocole. Tout message qui comporte une autre valeur dans ce champ DOIT être ignorée.

2.1.2 Champ msgtype

2.1.3 Champ addrfamily

Le champ addrfamily définit la famille d'adresses par défaut (IPv4 ou IPv6) pour ce message MADCAP, en utilisant les numéros de famille d'adresse définis par l'IANA (y compris ceux définis en [10]). Sauf mention contraire, toutes les adresses incluses dans le message appartiendront à cette famille.

2.1.4 Champ xid

Le champ xid est un identifiant de transaction. Ce numéro DOIT être choisi par le client de telle sorte que la combinaison de xid, msgtype et de l'identifiant de prêt soit unique sur tous les messages MADCAP reçus par un serveur MADCAP sur une période de [XID-REUSE-INTERVAL] (10 minutes).

Le champ xid est utilisé par le client et le serveur pour associer messages et réponses entre un client et un serveur. Avant qu'un client n'envoie un message, il choisit un nombre à utiliser comme xid. La technique utilisée pour choisir un xid est à la discrétion de la mise en œuvre, mais quelle que soit la technique utilisée, elle DOIT rendre improbable que la même combinaison de xid, msgtype et d'identifiant de prêt soit utilisée pour deux messages différents dans l'intervalle [XID-REUSE-INTERVAL] (même sur plusieurs clients qui ne communiquent pas entre eux). Cela donne assez de temps pour que le message soit éliminé de toutes les antémémoires de réponse des serveurs (comme décrit dans les paragraphes qui suivent) et qu'on s'accommode de tous les retards du réseau.

La technique RECOMMANDÉE pour choisir un xid est de choisir un nombre aléatoire de quatre octets comme premier xid d'une session et d'incrémenter cette valeur chaque fois qu'un nouvel xid est nécessaire. Le nombre aléatoire choisi n'a pas besoin d'être cryptographiquement aléatoire. Le nombre aléatoire peut être choisi via toute technique convenable, telle que celle décrite au paragraphe A.6 de la RFC 1889 [14].

Lorsque un serveur répond au message d'un client, il DOIT utiliser la même valeur de xid dans la réponse que celle que le client a utilisé dans la demande. Cela permet au client d'associer les réponses au message auquel elles répondent.

Lors de la retransmission de messages (comme décrit au paragraphe 2.3) le client DOIT les retransmettre sans les changer, en utilisant donc les mêmes xid et identifiant de prêt.

Si un serveur reçoit un message avec les mêmes xid, msgtype et identifiant de prêt qu'un reçu dans l'intervalle [RESPONSE-CACHE-INTERVAL], il DOIT traiter ce message comme une retransmission de celui reçu précédemment et retransmettre la réponse, s'il en est. Après [RESPONSE-CACHE-INTERVAL], le serveur peut oublier le message précédemment reçu et traiter toutes retransmissions de ce message comme si elles étaient de nouveaux messages. Bien sûr, un serveur n'a pas besoin de mettre un message en antémémoire si il finit par ignorer ce message. Cependant, des gains de performances peuvent être obtenus en faisant ainsi.

Cela évite que des retransmissions causent plusieurs allocations, dans la mesure où les demandes ne sont pas équipotentes. Une valeur appropriée pour [RESPONSE-CACHE-INTERVAL] serait de soixante secondes, mais elle peut avoir toute valeur entre zéro et 300 secondes (cinq minutes) et peut être ajustée de façon dynamique selon les contraintes de ressource du serveur. Cependant, utiliser une valeur inférieure à soixante secondes N'EST PAS RECOMMANDÉ parce que c'est la période normale de retransmission du client.

2.1.5 Champ options

Le champ options comporte une liste de paramètres étiquetés qui sont appelés "options". Toutes les options consistent en un code d'option de deux octets et en une longueur d'option de deux octets, suivie par le nombre d'octets spécifiés par la longueur d'option. Dans le cas de certaines options, le champ longueur est une constante mais elle doit encore être spécifiée.

Le champ option DOIT contenir une séquence d'options dont la dernière est l'option Fin (code d'option 0). Tout message dont le champ options ne se conforme pas à cette syntaxe DOIT être ignoré.

Tout client ou serveur MADCAP qui envoie un message MADCAP PEUT inclure toute option figurant sur la liste de la section 3, sous réserve des restrictions du Tableau 5 et ailleurs dans ce document. Il PEUT aussi inclure d'autres options MADCAP qui seront définies à l'avenir. Un client ou serveur MADCAP NE DOIT PAS inclure plus d'une option du même type d'option dans un message MADCAP.

Tous les clients et serveurs MADCAP DOIVENT reconnaître toutes les options énumérées dans le présent document et se comporter conformément à ce document lors de la réception et lors du traitement de toute option. Toute option non reconnue DOIT être ignorée et le reste du message traité comme si les options inconnues n'étaient pas présentes. Si un serveur MADCAP reçoit un message qui ne se conforme pas aux exigences de ce document (par exemple, ne pas inclure toutes les options requises), une erreur Demande invalide DOIT être générée et traitée de la façon décrite au paragraphe 2.6. Si un client MADCAP reçoit un message qui ne se conforme pas aux exigences de ce document, il DOIT ignorer le message.

L'ordre des options au sein d'un message n'a pas de signification et tout ordre DOIT être pris en charge d'une manière équivalente, à l'exception de l'option Fin qui doit survenir une fois par message, comme dernière option dans le champ options.

De nouveaux codes d'option MADCAP peuvent seulement être définis par consensus de l'IETF, comme décrit à la Section 5.

Le champ msgtype définit le "type" d'un message MADCAP. Les valeurs légales pour ce champ sont :

Valeur	Type de message
1	DISCOVER
2	OFFER
3	REQUEST
4	RENEW
5	ACK
6	NAK
7	RELEASE
8	GETINFO

Tout au long de ce document, les messages MADCAP seront désignés par le type du message ; par exemple, un message MADCAP avec un type de message de 8 sera désigné comme un message GETINFO.

Ci après figurent les descriptions des types de message MADCAP. Le Tableau 5, qui apparaît au début de la section 3, récapitule les options qui sont permises avec chaque type de message.

Les clients et serveurs MADCAP DOIVENT traiter tous les types de message MADCAP définis dans le présent document de façon cohérente avec ce document.

Si un serveur MADCAP reçoit un message dont il ne reconnaît pas le type, il DOIT générer une erreur Demande invalide et traiter le message de la façon décrite au paragraphe 2.6. Si un client MADCAP reçoit un message dont le type n'est pas reconnu, il DOIT ignorer le message.

Noter, cependant, que dans certaines circonstances, le présent document requiert ou suggère que les clients ou serveurs ignorent les messages avec certains types de message même si ils peuvent être reconnus. Par exemple, les clients qui n'envoient pas de messages DISCOVER DEVRAIENT ignorer les messages OFFER. Aussi, les serveurs sécurisés DEVRAIENT ignorer les messages DISCOVER et tous les serveurs DEVRAIENT ignorer les messages DISCOVER qu'ils ne peuvent satisfaire.

De nouveaux types de message MADCAP ne peuvent être définis que par consensus de l'IETF, comme décrit à la Section 5.

2.2.1 GETINFO

Le message GETINFO est utilisé par un client MADCAP qui veut acquérir des paramètres de configuration, en particulier une liste de portée de diffusion groupée. Ce message permet aussi à un client de déterminer quels serveurs vont vraisemblablement être capables de traiter les futures demandes.

Le client MADCAP lance un message GETINFO. Le message peut être en envoi individuel à un serveur MADCAP particulier ou en diffusion groupée à une adresse de diffusion groupée de serveur MADCAP. Pour des précisions sur l'adresse de diffusion groupée de serveur MADCAP, voir au paragraphe 2.10.

Si un serveur reçoit un message GETINFO et si il peut bien traiter la demande, il DOIT lancer un message ACK en envoi individuel au client. Tous les messages GETINFO DOIVENT comporter une option Liste de demande d'option. Le serveur DEVRAIT essayer d'inclure les options spécifiées dans sa réponse, mais il n'est pas obligé de le faire (en particulier si il ne les reconnaît pas).

Si un serveur reçoit un message GETINFO et si il ne réussit pas à traiter la demande, il DOIT générer et traiter une erreur de la façon décrite au paragraphe 2.6.

Si un client envoie un message GETINFO et ne reçoit pas de messages ACK en réponse, il DEVRAIT renvoyer son message GETINFO, comme décrit au paragraphe 2.3.

Lorsque un client MADCAP envoie un message GETINFO, il PEUT inclure l'option Langage requis, qui spécifie quels langages le client préfèrerait pour les noms de zone dans la liste des portées de diffusion groupée. La bonne façon de traiter cette étiquette par rapport aux noms de zone est exposée dans la définition de l'option Liste des portées de diffusion groupée.

2.2.2 DISCOVER

Le message DISCOVER est envoyé en diffusion groupée par un client MADCAP qui veut découvrir les serveurs MADCAP qui peuvent probablement satisfaire une demande.

Les clients MADCAP ne sont pas obligés d'utiliser le message DISCOVER. Ils PEUVENT employer d'autres méthodes pour trouver des serveurs MADCAP, comme d'envoyer un message GETINFO en diffusion groupée, en mettant en antémémoire une adresse IP qui a fonctionné dans le passé ou en étant configuré avec une adresse IP. Utiliser le message DISCOVER présente l'avantage particulier de permettre aux clients de recevoir des réponses de tous les serveurs qui peuvent satisfaire la demande.

Le client MADCAP commence par envoyer un message DISCOVER en diffusion groupée à une adresse de diffusion groupée de serveur MADCAP. Tous les serveurs qui souhaitent assister le client répondent en envoyant un message OFFER en envoi individuel au client. Si un serveur ne peut traiter la demande qu'avec un temps de prêt plus court ou une heure de début plus tardive que ce que demande le client, il DEVRAIT envoyer un message OFFER avec le temps de prêt ou l'heure de début qu'il peut offrir. Cependant, il NE DOIT PAS offrir un temps de prêt plus court que le temps de prêt minimum spécifié par le client ou une heure de début plus tardive que l'heure de début maximum spécifiée par le client.

Pour des précisions sur l'adresse de diffusion groupée de serveur MADCAP, voir au paragraphe 2.10.

Si un client envoie un message DISCOVER et ne reçoit aucun message OFFER en réponse, le client DEVRAIT reémettre son message DISCOVER, comme décrit au paragraphe 2.3.

Si un client envoie un message DISCOVER et reçoit un ou plusieurs messages OFFER en réponse, il DEVRAIT choisir le serveur qu'il veut utiliser (s'il en est) et envoyer un message REQUEST identifiant ce serveur au sein de [DISCOVER-DELAY] après avoir reçu le premier message OFFER. Voir au paragraphe 2.2.4 des informations complémentaires sur le message REQUEST.

Le mécanisme utilisé par le client pour choisir le serveur qu'il veut utiliser est à la discrétion de la mise en œuvre. Le client PEUT choisir la première réponse acceptable ou il PEUT attendre un certain temps (pas plus que [DISCOVER-DELAY]) et choisir la meilleure réponse reçue dans cette période (si la première réponse a une plus petite durée de prêt que celle qu'il a demandé par exemple).

La valeur de [DISCOVER-DELAY] dépend elle aussi de la mise en œuvre, mais la valeur RECOMMANDÉE est celle du temporisateur de retransmission en cours, comme spécifié au paragraphe 2.3. Attendre trop longtemps (approcher [OFFER-HOLD]) peut être cause que les serveurs abandonnent les adresses qu'ils avaient réservées.

Lorsque un client MADCAP envoie un message DISCOVER, il PEUT inclure les options Durée de prêt, Durée minimum de prêt, Heure de début, Heure de début maximum, Nombre d'adresses demandé, et Liste des gammes d'adresses, décrivant les adresses qu'il veut recevoir. Cependant, il n'a besoin d'inclure aucune de ces options. Si une de ces options n'est pas incluse, le serveur fournira l'option par défaut appropriée (maximum disponible pour Durée de prêt, pas de minimum pour Durée minimum de prêt, aussitôt que possible pour Heure de début, pas de maximum pour Heure de début maximum, une pour Nombre d'adresses demandé, et toutes les adresses disponibles pour Liste des gammes d'adresses). L'option Portée de diffusion groupée DOIT être incluse dans le message DISCOVER afin que le serveur sache quelle portée devrait être utilisée. L'option Heure en cours DOIT être incluse si les options Heure de début ou Heure de début maximum sont incluses. L'option Identifiant de prêt DOIT toujours être incluse.

2.2.3 OFFER

Le message OFFER est un message en envoi individuel envoyé par un serveur MADCAP en réponse à un message DISCOVER qu'il peut probablement satisfaire.

Un serveur MADCAP n'est jamais obligé d'envoyer un message OFFER en réponse à un message DISCOVER. Par exemple, il peut n'être pas capable de satisfaire la demande du client ou il peut avoir été configuré pour ne répondre qu'à certains types de messages DISCOVER ou ne pas répondre du tout aux messages DISCOVER.

Si un serveur MADCAP décide d'envoyer un message OFFER, il DOIT inclure les options Durée de prêt et Portée de diffusion groupée, décrivant les adresses qu'il veut fournir. Cependant, il n'a pas besoin d'inclure l'option Liste des gammes d'adresses. Si l'option Liste des gammes d'adresses allouées n'est pas incluse, on suppose que le serveur est d'accord pour fournir le nombre d'adresses que le client demandait. Si l'option Heure de début n'est pas incluse, on suppose que le serveur est d'accord pour fournir à l'heure de début demandée par le client (s'il en est une). L'option Heure en cours DOIT être incluse si l'option Heure de début est incluse.

Si un serveur peut traiter la demande avec une durée de prêt plus courte ou une heure de début plus tardive que ce que le client demandait, il DEVRAIT envoyer un message OFFER avec la durée de prêt ou l'heure de début qu'il peut offrir. Cependant, il NE DOIT PAS offrir une durée de prêt plus courte que la durée de prêt minimum spécifiée par le client ou une heure de début plus tardive que l'heure de début maximum spécifiée par le client.

Si le serveur envoie un message OFFER, il DEVRAIT essayer de détenir suffisamment d'adresses pour achever la transaction. Si il reçoit un message REQUEST en diffusion groupée avec la même option Identifiant de prêt que le message DISCOVER pour lequel il détient ces adresses et une option Identifiant de serveur qui ne correspond pas au sien, il DEVRAIT arrêter de réserver les adresses. Le serveur DEVRAIT aussi arrêter de réserver les adresses après un délai approprié de [OFFER-HOLD] si la transaction n'est pas achevée. La valeur de ce délai est spécifique de la mise en œuvre, mais une valeur d'au moins 60 secondes est RECOMMANDÉE.

Comme avec tous les messages envoyés par le serveur, le champ xid DOIT correspondre au champ xid inclus dans la demande du client auquel ce message répond. L'option Identifiant de prêt DOIT être incluse, avec la valeur correspondant à celle incluse dans la demande du client. L'option Identifiant de serveur DOIT être incluse, avec comme valeur l'adresse IP du serveur. Et le paquet NE DOIT PAS être retransmis.

2.2.4 REQUEST

Le message REQUEST est utilisé par un client MADCAP qui veut allouer une ou plusieurs adresses de diffusion groupée. Il n'est pas utilisé pour renouveler un prêt existant. Le message RENEW est utilisé pour cela.

Si un message REQUEST achève une transaction initiée par un message DISCOVER, la procédure suivante DOIT être suivie afin que tous les serveurs MADCAP sachent quel serveur a été choisi. Le client DOIT lancer un message REQUEST en diffusion groupée à la même adresse de diffusion groupée de serveur MADCAP que celle où le message DISCOVER a été envoyé. L'Identifiant de prêt utilisé dans le message DISCOVER DOIT être utilisé dans le message REQUEST. Et aussi, l'option Identifiant de serveur DOIT être incluse, en utilisant l'Identifiant de serveur du serveur choisi.

Si un message REQUEST n'achève pas une transaction initiée par un message DISCOVER, le message REQUEST DOIT être en envoi individuel au serveur MADCAP que le client veut utiliser. Dans ce cas, l'option Identifiant de serveur PEUT être incluse, mais pas nécessairement.

Si le serveur choisi peut réussir à traiter la demande, il DEVRAIT envoyer un message ACK en envoi individuel au client. Autrement, il DEVRAIT générer et traiter une erreur de la façon décrite au paragraphe 2.6. Si un serveur peut traiter la demande avec un temps de prêt plus court ou une heure de début plus tardive que ce que demande le client, il DEVRAIT envoyer un message ACK avec la durée de prêt ou l'heure de début qu'il peut offrir. Cependant, il NE DOIT PAS offrir une durée de prêt plus courte que la durée de prêt minimum spécifiée par le client ou une heure de début plus tardive que l'heure de début maximum spécifiée par le client.

Lorsque un client MADCAP envoie un message REQUEST, il PEUT inclure les options Durée de garde (Lease Time), Durée de garde minimum (Minimum Lease Time), Heure de début (Start Time), Heure de début maximum (Maximum Start Time), Nombre d'adresses demandées (Number of Addresses Requested), et Liste des gammes d'adresse (List of Address Ranges), qui décrivent les adresses qu'il veut recevoir. Cependant, il n'a pas besoin d'inclure une de ces options. Si une de ces options n'est pas incluse, le serveur va fournir la valeur d'option par défaut appropriée (le maximum disponible pour la durée de prêt, pas de minimum pour la durée de prêt minimum, aussitôt que possible pour l'heure de début, pas de maximum pour l'heure de début maximum, une pour le nombre d'adresses demandées, et toutes adresses disponibles pour la gamme d'adresses). L'option Portée de diffusion groupée DOIT être incluse dans le message REQUEST afin que le serveur sache quelle portée devrait être utilisée. L'option Heure en cours DOIT être incluse si les options Heure de début ou Heure de début maximum sont incluses.

Si un client envoie un message REQUEST et ne reçoit pas de message ACK ou NAK en réponse, le client DEVRAIT renvoyer son message REQUEST, comme décrit au paragraphe 2.3.

Si le serveur répond par un NAK ou échoue à répondre dans un délai (qui dépend de la mise en œuvre) raisonnable [NO-RESPONSE-DELAY], le client PEUT essayer de trouver un autre serveur en envoyant un message DISCOVER avec un autre xid ou en envoyant un message REQUEST avec un autre xid à un autre serveur. La valeur RECOMMANDÉE pour [NO-RESPONSE-DELAY] est de 60 secondes.

2.2.5 ACK

Le message ACK est utilisé par un serveur MADCAP pour répondre affirmativement à un message GETINFO, REQUEST, ou RELEASE. Le serveur envoie individuellement le message ACK au client duquel il a reçu le message auquel il répond.

L'ensemble des options incluses dans un message ACK diffère, selon la sorte de message auquel il répond.

Si le message ACK répond à un message GETINFO, il DEVRAIT inclure toutes les options demandées par le client en utilisant l'option Liste des options demandées.

Si le message ACK répond à un message REQUEST, il DOIT inclure les options Durée de prêt, Portée de diffusion groupée et Liste des gammes d'adresse. Il PEUT inclure une option Heure de début. Si une option Heure de début est incluse, une option Heure en cours DOIT aussi être incluse. Si aucune option Heure de début n'est incluse, le prêt est supposé commencer immédiatement.

Si le message ACK répond à un message RENEW, il DOIT inclure les options Durée de prêt, Portée de diffusion groupée et Liste des gammes d'adresse. Il PEUT inclure une option Heure de début. Si une option Heure de début est incluse, Une option Heure en cours DOIT aussi être incluse. Si aucune option Heure de début n'est incluse, le prêt est supposé commencer immédiatement.

Si le message ACK répond à un message RELEASE, il DOIT seulement inclure les options Identifiant de serveur et Identifiant de prêt.

Comme avec tous les messages envoyés par le serveur, le champ xid DOIT correspondre au champ xid inclus dans la demande du client à laquelle répond ce message. L'option Identifiant de prêt DOIT être incluse, avec la valeur correspondante à celle incluse dans la demande du client. L'option Identifiant de serveur DOIT être incluse, sa valeur étant celle de l'adresse IP du serveur. Et le paquet NE DOIT PAS être retransmis.

2.2.6 NAK

Le message NAK est utilisé par un serveur MADCAP pour répondre négativement à un message. Le serveur envoie individuellement le message NAK au client duquel il a reçu le message auquel il répond.

Comme avec tous les messages envoyés par le serveur, le champ xid DOIT correspondre au champ xid inclus dans la demande du client à laquelle ce message répond. L'option Identifiant de prêt DOIT être incluse, avec la valeur correspondante à celle incluse dans la demande du client. L'option Identifiant de serveur DOIT être incluse, avec la valeur de l'adresse IP du serveur. L'option Erreur DOIT être incluse avec un code d'erreur indiquant ce qui n'allait pas. Et le paquet NE DOIT PAS être retransmis.

2.2.7 RENEW

Le message RENEW est utilisé par un client MADCAP qui veut renouveler un prêt d'adresse de diffusion groupée, en changeant la durée de prêt ou l'heure de début.

Le client envoie le message RENEW en individuel à un serveur MADCAP. Si le serveur peut réussir à traiter la demande, il DEVRAIT faire un envoi individuel de message ACK au client. Autrement, il DOIT générer et traiter une erreur de la manière décrite au paragraphe 2.6.

Le prêt à renouveler est celui qui a été alloué avec une option Identifiant de prêt correspondant à celle fournie dans le message RENEW.

Lorsque un client MADCAP envoie un message RENEW, il PEUT inclure les options Durée de prêt, Durée de prêt minimum, Heure de début, et Heure de début maximum, décrivant le nouveau prêt qu'il veut recevoir. Cependant, il n'a pas besoin d'inclure ces options. Si une de ces options n'est pas incluse, le serveur fournira les valeurs par défaut appropriées (maximum disponible pour la durée de prêt, pas de minimum pour la durée de prêt minimum, aussitôt que possible pour l'heure de début et pas de maximum pour l'heure de début maximum). L'option Heure en cours DOIT être incluse si les options Heure de début ou Heure de début maximum sont incluses.

Si un client envoie un message RENEW et ne reçoit pas de message ACK ou NAK en réponse, il DEVRAIT renvoyer son message RENEW, comme décrit au paragraphe 2.3.

Si le serveur répond par un NAK ou échoue à répondre dans un délai raisonnable (qui dépend de la mise en œuvre) [NO-RESPONSE-DELAY], le client PEUT envoyer un message RENEW avec un autre xid à un autre serveur, pourvu que la caractéristique Mobilité du serveur ait été utilisée dans le message REQUEST d'origine et que cette caractéristique soit exigée pour le message RENEW ultérieur envoyé à un autre serveur. Pour des informations complémentaires sur la caractéristique de mobilité du serveur, voir au paragraphe 2.13.1. La valeur RECOMMANDÉE pour [NO-RESPONSE-DELAY] est 60 secondes.

2.2.8 RELEASE

Le message RELEASE est utilisé par un client MADCAP qui veut renoncer à l'allocation d'une ou plusieurs adresses de diffusion groupée avant l'arrivée à expiration de leur durée de prêt.

Le client envoie en individuel le message RELEASE au serveur MADCAP duquel il a obtenu l'allocation des adresses. Si le serveur choisi peut réussir à traiter la demande, il DOIT envoyer un message ACK en individuel au client. Autrement, il DOIT générer et traiter une erreur de la façon décrite au paragraphe 2.6.

Le prêt à libérer est celui qui a été alloué avec une option Identifiant de prêt qui correspond à celle fournie dans le message RELEASE. Il n'est pas possible de libérer seulement une partie des adresses dans un seul prêt.

Si un client envoie un message RELEASE et ne reçoit pas de messages ACK ou NAK en réponse, le client DEVRAIT renvoyer son message RELEASE, comme décrit au paragraphe 2.3.

Si le serveur répond par un NAK ou échoue à répondre dans un délai raisonnable (qui dépend de la mise en œuvre) [NO-RESPONSE-DELAY], le client PEUT envoyer un message RELEASE avec un autre xid à un autre serveur, pourvu que la caractéristique Mobilité du serveur ait été utilisée dans le message REQUEST d'origine et que cette caractéristique soit exigée pour le message RELEASE suivant envoyé à un autre serveur. Pour des informations complémentaires sur la caractéristique de mobilité du serveur, voir au paragraphe 2.13.1. La valeur RECOMMANDÉE pour [NO-RESPONSE-DELAY] est de 60 secondes.

Les clients MADCAP sont chargés de toutes les retransmissions de messages. Le client DOIT adopter une stratégie de retransmission qui incorpore un algorithme de retard exponentiel pour déterminer le délai entre les retransmissions. Le délai entre les retransmissions DEVRAIT être choisi de façon à permettre un temps suffisant pour que les réponses provenant du serveur soient délivrées sur la base des caractéristiques de l'inter réseau entre le client et le serveur.

L'algorithme RECOMMANDÉ est d'utiliser un délai de 4 secondes avant la première retransmission et de doubler ce délai pour chaque retransmission suivante, avec un délai maximum de 16 secondes et un maximum de trois retransmissions. Si une transmission initiale a été envoyée à l'instant t (en secondes) et qu'aucune réponse n'a été reçue, les transmissions suivantes seraient à t+4, t+12, et t+28. Si aucune réponse n'a été reçue à t+60, le client va arrêter les retransmissions et suivre d'autres voies d'action (comme d'inscrire une erreur ou d'envoyer un message à une autre adresse.

Le client PEUT fournir une indication des tentatives de retransmission à l'utilisateur comme indication des progrès du processus. Le client PEUT arrêter les retransmissions à tout moment.

L'option Identifiant de prêt est incluse dans chaque message MADCAP. Sa valeur est utilisée pour identifier un prêt et DOIT être unique parmi tous les prêts demandés par tous les clients dans un domaine d'allocation d'adresse de diffusion groupée.

Le premier octet de l'identifiant de prêt est le type d'identifiant de prêt. Le Tableau 3 fait la liste des types d'identifiant de prêt définis pour l'instant et les paragraphes 2.4.1 et 2.4.2 décrivent ces types d'identifiant de prêt.

De nouveaux types d'identifiant de prêt MADCAP ne pourrant être définis que par consensus de l'IETF, comme décrit à la section 5.

Le serveur MADCAP n'a pas besoin d'analyser l'identifiant de prêt. Il DEVRAIT n'utiliser l'identifiant de prêt que comme un identifiant opaque, qui doit être unique pour chaque prêt. L'objet de la définition de types d'identifiants de prêt différents est de permettre aux clients MADCAP qui ont déjà une adresse unique au monde d'éviter la possibilité de collisions d'identifiants de prêt en utilisant cette adresse avec un identifiant spécifique du client. Les clients MADCAP qui n'ont pas une adresse unique au monde DEVRAIENT utiliser le type 0 d'identifiant de prêt.

En plus d'associer les messages de client et de serveur (avec les champs msgtype et xid, comme décrit au paragraphe suivant) l'identifiant de prêt est utilisé pour déterminer à quel prêt se réfère une demande RENEW ou RELEASE. Les serveurs MADCAP DEVRAIENT faire correspondre l'identifiant de prêt inclus dans un message RENEW ou RELEASE à l'identifiant de prêt utilisé dans un message REQUEST initial. Si l'identifiant de prêt ne correspond pas, un serveur MADCAP DOIT générer et traiter une erreur Identifiant de prêt non reconnu de la façon décrite au paragraphe 2.6.

Pour les applications de conférence, il peut être souhaitable de permettre aux participants à la conférence de modifier un prêt utilisé pour la conférence. Le code de caractéristique Identifiant de prêt partagé est utilisé pour prendre en charge cette exigence. Si ce code de caractéristique est demandé par le client et mis en œuvre par le serveur lors de l'allocation du prêt, le serveur DEVRAIT désactiver toutes les exigences d'authentification et permettre à tout client qui connaît l'identifiant de prêt de modifier le prêt.

Comme décrit à la Section Considérations sur la sécurité, la sécurité MADCAP n'est pas extrêmement utile sans un contrôle d'admission dans l'infrastructure d'acheminement de diffusion groupée. Cependant, si la sécurité MADCAP est souhaité lors de l'utilisation de la caractéristique d'identifiant de prêt partagé, la confidentialité de l'identifiant de prêt DOIT être conservée par le chiffrement de tous les messages qui le contiennent. Un identifiant de prêt qui comporte un long nombre aléatoire (d'au moins huit octets) DOIT être utilisé dans ces circonstance afin qu'il ne soit pas facile de deviner l'identifiant de prêt.

2.4.1 Identifiant de prêt aléatoire

Le premier octet d'un identifiant de prêt aléatoire est le type 0 d'identifiant de prêt (0 pour indique l'identifiant de prêt aléatoire). Après cela vient une séquence d'octets, qui DEVRAIT représenter un long nombre aléatoire (d'au moins 16 octets) provenant d'un générateur de nombres aléatoires décent.

Un identifiant de prêt aléatoire ne comporte aucune indication de sa longueur. On suppose que cela peut être déterminé par des moyens externes, comme un champ de longueur précédant l'identifiant de prêt.

2.4.2 Identifiant de prêt spécifique de l'adresse

Le premier octet d'un identifiant de prêt spécifique de l'adresse est le type d'identifiant de prêt (1 pour indiquer l'identifiant de prêt spécifique de l'adresse). Après lui vient un numéro de famille d'adresse de deux octets défini par l'IANA (incluant ceux définis dans [10]), une adresse dans la famille d'adresses spécifiée, et un identifiant spécifique du client (comme un numéro de séquence ou l'heure actuelle).

Un identifiant de prêt spécifique de l'adresse ne comporte aucune indication de sa longueur. On suppose que cela peut être déterminé par des moyens externes, comme un champ de longueur précédant l'identifiant de prêt.

Les messages entre clients et serveurs sont associés les uns aux autres en utilisant l'identifiant de prêt et le champ xid. Comme décrit au paragraphe 2.1.4, le client DOIT choisir un xid de telle sorte qu'il soit improbable que la même combinaison de xid, msgtype, et identifiant de prêt soit utilisée pour deux messages différents au sein de [XID-REUSE-INTERVAL] (même sur plusieurs clients qui ne communiquent pas entre eux). L'option Identifiant de prêt, le msgtype, et le champ xid DOIVENT être inclus dans chaque message envoyé par le client ou le serveur.

Le client DOIT vérifier l'option Identifiant de prêt et le champ xid dans chaque message entrant pour s'assurer qu'ils correspondent à l'identifiant de prêt et au xid pour une transaction en cours. Sinon, le message DOIT être ignoré. Le serveur DOIT vérifier l'option Identifiant de prêt et le champ xid dans chaque message entrant pour établir le contexte appropriée pour le message. Si un serveur ne peut pas traiter un message parce qu'il est invalide pour son contexte, le serveur DOIT générer et traiter une erreur Demande invalide, comme décrit au paragraphe 2.6. Une transaction peut être une tentative d'allocation d'une adresse de diffusion groupée (consistant en messages DISCOVER, OFFER, REQUEST, ACK et NAK) une tentative de renouveler un prêt (consistant en messages RENEW, ACK et NAK) une tentative de libérer une adresse de diffusion groupée précédemment allouée (consistant en messages RELEASE, ACK et NAK) ou une tentative pour acquérir des paramètres de configuration (consistant en messages GETINFO, ACK et NAK).

Si un serveur MADCAP rencontre une erreur lors du traitement d'un message, il peut traiter cette erreur de deux façons différentes. Si il est clair que le message n'est pas un NAK, le serveur DEVRAIT répondre par un NAK contenant l'option Erreur appropriée. Cependant, le serveur PEUT décider d'ignorer complètement un transgresseur chronique. Si le message est un NAK ou si il n'apparaît pas clairement que le message est un NAK (par exemple, le message est altéré ou a un numéro de version incorrect), le serveur DEVRAIT ignorer le message. Cela évite les NAK en boucles.

Si un client MADCAP rencontre une erreur lors du traitement d'un message, il DOIT ignorer le message.

La RFC 2365 [3] traite de la division de l'espace d'adresse de diffusion groupée en un certain nombre de portées administratives. Les routeurs devraient être configurés de telle sorte que chaque portée corresponde à une partition particulière du réseau en régions disjointes. Les messages envoyés à une adresse de diffusion groupée qui rentrent dans une certaine portée administrative ne devraient être délivrés qu'aux hôtes qui se sont joints à ce groupe de diffusion groupée *et* entrent dans la même région que l'envoyeur. Par exemple, les paquets envoyés à une adresse dans la portée locale d'une organisation ne devraient être livrés qu'aux hôtes qui se sont joints à ce groupe et entrent dans la même organisation que l'envoyeur.

Différents ensembles de portées peuvent être actifs en différents endroits du réseau et à des moments différents. Avant de tenter d'allouer une adresse d'une portée administrative (autre que la portée mondiale ou de niveau liaison, qui sont toujours actives), un client MADCAP DEVRAIT déterminer que la portée est active sur sa localisation à cet instant. Plusieurs techniques que peut utiliser un client MADCAP pour déterminer l'ensemble des portées administratives (la liste des portées) sont la configuration manuelle ou la configuration via MADCAP (en utilisant l'option Liste de portée de diffusion groupée).

Si un client MADCAP est incapable de déterminer sa liste de portées en utilisant une de ces techniques, il PEUT temporairement supposer une liste de portées consistant en une seule portée. Si il utilise IPv4, il DEVRAIT utiliser la portée locale IPv4 (239.255.0.0/16), avec un TTL maximum de 16. Si il utilise IPv6, il DEVRAIT utiliser SCOP 3, avec un compte de bonds maximum de 16. En utilisant cette liste temporaire de portées, il PEUT essayer de contacter un serveur MADCAP qui pourra lui fournir une liste de portées.

Lorsque un client MADCAP demande une adresse avec un message DISCOVER ou REQUEST, il DOIT spécifier la portée administrative dans laquelle cette adresse devrait être allouée. Cette portée est indiquée avec l'option Portée de diffusion groupée. De même, le serveur DOIT inclure l'option Portée de diffusion groupée dans tous les messages OFFER et tous les messages ACK envoyées en réponse aux messages REQUEST.

Une autre façon de limiter la propagation des messages en diffusion groupée est d'utiliser la portée du TTL. Cette technique a plusieurs inconvénients par rapport à la limitation administrative de portée d'adresses de diffusion groupée (comme décrite en [3]), mais elle est actuellement d'un usage largement répandu.

Avec la portée de TTL, des zones du réseau sont désignées comme des portées. Les routeurs sur les bordures de ces zones sont configurés avec des seuils de TTL de telle sorte que les paquets en diffusion groupée ne sont pas transmis si leur TTL restant ne dépasse pas ce seuil. Un paquet qui devrait se restreindre à une portée de TTL donné devrait avoir un TTL initial inférieur au seuil de TTL de cette portée. Des techniques similaires peuvent être utilisée avec IPv6, en utilisant le champ de Compte de bonds à la place du champ de TTL.

MADCAP peut être utilisé dans un environnement où la limitation administrative de portée n'est pas utilisée et où la portée de TTL l'est. Dans ces circonstances, un serveur MADCAP PEUT retourner une liste de portées qui inclue des portées avec des TTL inférieurs à 255. Le client MADCAP PEUT alors allouer des adresses à partir de ces portées, mais il NE DOIT PAS établir le champ TTL d'un paquet envoyé à une telle adresse à une valeur supérieure au TTL maximum indiqué dans la liste de portées. Dans un tel environnement, il est recommandé que les adresses de diffusion groupée de serveur MADCAP associées à la portée locale IPv4 (ou à SCOP 3 pour IPv6) soient configurées en utilisant les seuils de TTL de sorte que les paquets envoyés à ces adresses avec un TTL de 16 ne soient pas envoyés au delà d'une limite appropriée. Cela permettra aux clients MADCAP d'utiliser leur comportement par défaut pour trouver les serveurs MADCAP.

Dans un environnement où est utilisé la limitation administrative de portée, les TTL maximum dans la liste des portées DEVRAIENT être à 255. Les routeurs frontière de zone de portée administrative vont empêcher les fuites de paquets MADCAP au delà des limites appropriées.

Un client MADCAP peut localiser un serveur MADCAP de plusieurs façons. Par exemple, le client peut être configuré avec une adresse IP.

La technique RECOMMANDÉE est que le client envoie un message GETINFO à une adresse de diffusion groupée de serveur MADCAP et attende des réponses ACK. Cette technique est décrite plus en détail au paragraphe suivant.

Chaque portée de diffusion groupée a une adresse de diffusion groupée de serveur MADCAP associée. Cette adresse a été réservée par l'IANA comme l'adresse qui a un décalage relatif de -1 par rapport à la dernière adresse d'une portée de diffusion groupée.

Un client MADCAP qui cherche des serveurs qui puissent fournir des services d'allocation de diffusion groupée PEUT envoyer un message GETINFO à une adresse de diffusion groupée de serveur MADCAP. Tous les serveurs MADCAP qui écoutent à cette adresse DEVRAIENT répondre par un message ACK en envoi individuel à ce client si ils souhaitent offrir une réponse.

L'adresse de diffusion groupée de serveur MADCAP utilisée par un client PEUT être établie par configuration. Si un client n'a pas une telle configuration, il DEVRAIT utiliser l'adresse de diffusion groupée de serveur MADCAP associée à la portée locale IPv4 (ou à SCOP 3 pour IPv6) avec un TTL maximum de 16, sauf si il est configuré autrement.

Si un client ne reçoit pas de réponse à un message envoyé à une adresse de diffusion groupée de serveur MADCAP (après retransmission), il PEUT envoyer le message à une portée plus grande et répéter ce processus autant que nécessaire. Cependant, le client NE DOIT PAS envoyer un message MADCAP à l'adresse de diffusion groupée de serveur MADCAP associée à la portée mondiale.

Cette technique permet aux serveurs MADCAP de fournir des services pour les portées dans lesquelles ils ne résident pas. Cependant, c'est une technique dangereuse et compliquée et elle N'EST PAS RECOMMANDÉE pour l'instant. Donc, les clients MADCAP DEVRAIENT seulement envoyer des messages en diffusion groupée à l'adresse de diffusion groupée de serveur MADCAP correspondant à la portée locale IPv4 (ou au SCOP 3, si on utilise IPv6), sauf si ils sont configurés autrement.

Les serveurs MADCAP qui souhaitent fournir des services pour les portées dans lesquelles ils ne résident pas DOIVENT faire des efforts particuliers pour s'assurer que leurs services satisfont les besoins en allocation des clients surtout sans conflit et des informations de liste de portée précises. En particulier, la coordination avec d'autres serveurs qui fournissent des services pour cette portée peut être difficile. Et aussi, établir dans quelle portée se trouve ce client peut être difficile. Si un serveur MADCAP n'est pas prêt à fournir des services pour des portées dans lesquelles il ne réside pas, il DEVRAIT ignorer les messages DISCOVER et les messages REQUEST dont la portée ne correspond pas ou englobe la portée de l'adresse de diffusion groupée de serveur MADCAP sur laquelle la demande a été reçue. Il DEVRAIT aussi ignorer les messages GETINFO qui ne sont pas reçus sur l'adresse de diffusion groupée de serveur MADCAP pour la portée locale IPv4.

L'option Heure en cours est utilisée pour détecter et traiter le biais d'horloge entre les clients et serveurs MADCAP. Cette option DOIT être incluse dans tout message MADCAP qui comporte une heure absolue (comme l'option Heure de début). Elle PEUT être incluse dans tout message DISCOVER, OFFER, REQUEST, RENEW, ou ACK.

Le biais d'horloge est une situation dans laquelle deux systèmes ont des horloges qui ne sont pas synchronisées. De nombreux protocoles (tels que DHCP) ignorent le biais d'horloge en utilisant des heures relatives. MADCAP pourrait utiliser une technique similaire, mais cela conduit à des situations désagréables à cause de la façon dont sont utilisées les adresses de diffusion groupée.

Par exemple, supposons qu'à 13 h UTC un client dont l'horloge est en avance d'une heure demande un prêt pour une heure commençant dans une heure. Si on utilise des heures relatives pour MADCAP, le serveur, dont l'horloge est réglée correctement, va réserver une adresse de diffusion groupée de 14 à 15 h UTC et accordera la demande. Si le client est le seul à utiliser le prêt, tout ira bien. Le client va commencer à utiliser le prêt dans une heure et va continuer pendant une heure. Cela va coïncider avec l'heure que le serveur avait réservé (bien que le client pense que c'était de 15 à 16 h UTC).

Cependant, les adresses de diffusion groupée sont normalement utilisées par plusieurs parties à la fois. Le client va probablement utiliser SAP (ou quelque autre mécanisme pour convoyer SDP) pour annoncer une session utilisant l'adresse de diffusion groupée qui vient d'être prêtée. SDP utilise des heures absolues, car elles peuvent être envoyées via la messagerie électronique, la Toile, ou d'autre mécanismes de livraison différée. Ainsi le client va annoncer la session comme fonctionnant de 15 à 16 h UTC. Tous les clients dont l'horloge est réglée correctement vont utiliser l'adresse durant cet intervalle. Comme le serveur n'a réservé l'adresse que de 14 à 15 h UTC, cela peut être cause que l'adresse soit utilisée pour plusieurs sessions simultanément.

MADCAP ne peut pas résoudre tous les problèmes de biais d'horloge. C'est le domaine de NTP [4]. Cependant, il essaye de détecter les biais d'horloge substantiels entre clients et serveurs MADCAP afin que ce biais d'horloge ne cause pas de collisions massives ultérieurement dans l'utilisation des adresses de diffusion groupée.

L'option Heure en cours contient l'opinion de l'envoyeur sur l'heure actuelle en UTC au moment où le message a été assemblé. À cause des retards de transmission et du traitement, cette valeur va rarement correspondre à l'opinion du receveur sur l'heure en cours au moment où l'option est traitée par le receveur. Cependant, des différences supérieures à une minute ou deux indiquent probablement un biais d'horloge entre l'envoyeur et le receveur.

Les serveurs MADCAP DEVRAIENT s'attendre à un faible biais d'horloge avec leurs clients et le tolérer, en s'assurant que les adresses de diffusion groupée sont allouées pour une période de temps supplémentaire [EXTRA-ALLOCATION-TIME] des deux côtés du prêt indiqué par le client. Cependant, des biais d'horloge de grande ampleur exigent un traitement particulier. La valeur de [EXTRA- ALLOCATION-TIME] DOIT être un paramètre configurable, car les circonstances locales peuvent varier. La valeur RECOMMANDÉE par défaut est une heure.

Cependant, les biais d'horloge de grande ampleur vont causer des problèmes plus tard lors de l'annonce des sessions. Si un serveur MADCAP détecte un biais d'horloge supérieur à [CLOCK-SKEW-ALLOWANCE], il DOIT générer et traiter une erreur Biais d'horloge excessif, comme décrit au paragraphe 2.6. Le serveur PEUT aussi enregistrer un message. La valeur de [CLOCK-SKEW-ALLOWANCE] DOIT être un paramètre configurable, car les circonstances locales peuvent varier. La valeur RECOMMANDÉE par défaut est 30 minutes.

Chaque client ou serveur MADCAP PEUT mettre en œuvre une ou plusieurs caractéristiques facultatives. Les caractéristiques facultatives de MADCAP sont identifiées par un code de caractéristique de deux octets.

Un client MADCAP PEUT demander, exiger ou indiquer la prise en charge d'une caractéristique facultative en incluant une option Liste de caractéristiques dans un message. Pour des informations complémentaires sur les caractéristiques facultatives, voir la description de l'option Liste de caractéristiques.

Le Tableau 4 fait la liste des codes de caractéristiques définis pour l'instant et les paragraphes 2.13.1 à 2.13.3 décrivent comment fonctionnent ces caractéristiques.

De nouveaux codes de caractéristique MADCAP ne peuvent être définis que par consensus de l'IETF, comme décrit à la section 5.

2.13.1 Mobilité du serveur

La caractéristique Mobilité du serveur (Server Mobility) permet qu'une adresse allouée par un serveur MADCAP soit renouvelée ou libérée sur un serveur MADCAP différent. Cela exige une communication et de la coordination entre les serveurs MADCAP. Le principal bénéfice en est l'immunité aux défaillances d'un seul serveur MADCAP et peut-être de meilleures performances par l'équilibrage des charges.

Afin de tirer parti de la caractéristique Mobilité du serveur, un client MADCAP doit s'assurer que la caractéristique est mise en œuvre par les deux serveurs qui sont utilisés pour l'allocation d'origine et le serveur qui est utilisé pour le renouvellement ou la libération. La meilleure façon de s'assurer de cela est d'inclure la caractéristique de mobilité du serveur dans la liste exigée d'une option Liste de caractéristiques dans le message REQUEST utilisé pour allouer l'adresse (et dans le message DISCOVER, si il en est utilisé un). Lorsque vient le moment de renouveler ou libérer l'adresse, le client DEVRAIT envoyer un message RENEW ou RELEASE en envoi individuel au serveur duquel l'adresse a été allouée. Cependant, si ce serveur est indisponible, le client PEUT envoyer le message RENEW ou RELEASE à tout autre serveur qui a inclus la caractéristique Mobilité du serveur dans sa liste des caractéristiques prises en charge. Le client peut trouver un tel serveur en (par exemple) envoyant un message GETINFO avec une option Liste de demande d'options qui comporte le code d'option de liste de caractéristiques.

Si le client MADCAP ne veut pas demander cette caractéristique lors de l'allocation des adresses, il peut inclure la caractéristique dans la liste demandée d'une option Liste de caractéristiques et voir si le serveur inclut la caractéristique dans la liste demandée d'option Liste de caractéristique dans le message ACK.

Même si la caractéristique Mobilité du serveur est utilisée, il n'est pas garanti qu'un serveur sera disponible pour effectuer le renouvellement ou la libération ou que le renouvellement ou libération va réussir. La connexité des serveurs peut subir une défaillance, par exemple.

2.13.2 Recommencer après

La caractéristique Recommencer après (Retry After) permet à un serveur MADCAP de demander à un client MADCAP de réessayer sa demande ultérieurement, autant qu'il peut être nécessaire lors de l'allocation d'un grand nombre d'adresses ou de l'allocation d'adresses pour une longue durée.

Par exemple, si un client MADCAP demande 1000 adresses, une approbation administrative peut être exigée, ou l'allocation de plus d'adresses de la part d'un autre domaine MASC peut être nécessaire. Cela peut prendre plusieurs heures ou plusieurs jours. Si le client et le serveur MADCAP prennent tous deux en charge la caractéristique Recommencer après, le serveur MADCAP peut envoyer un message ACK avec une option Heure de réessai qui indique quand les adresses peuvent être prêtes. Le client peut recommencer sa demande après l'heure de réessai pour avoir les adresses.

Si un client MADCAP inclut la caractéristique Recommencer après dans la liste des options prises en charge d'une option Liste de caractéristiques dans un message REQUEST, un serveur MADCAP qui prend en charge la caractéristique Recommencer après PEUT décider de commencer un processus d'allocation long. Dans ce cas, le serveur MADCAP va inclure une option Liste de gammes d'adresses vide dans son message ACK, une option Liste de caractéristiques qui inclut la caractéristique Recommencer après dans la liste des exigés, et une option Heure de réessai avec l'heure après laquelle le client devrait réessayer la demande.

Le client NE DOIT PAS inclure la caractéristique Recommencer après dans la liste des demandés ou des exigés d'une option Liste des caractéristiques, car la décision de vouloir Recommencer après devrait appartenir au serveur MADCAP.

Après un certain délai (de préférence après l'heure indiquée dans l'option Recommencer après) le client DEVRAIT envoyer un message REQUEST avec toutes les options du message REQUEST d'origine (en particulier l'option Identifiant de prêt) mais avec une nouvelle valeur xid. Le serveur PEUT retourner un message ACK normal ou un message NAK à ce moment, ou il PEUT continuer à reporter la transaction à un moment ultérieur en incluant une option Liste de gammes d'adresses vide dans son message ACK, une option Liste de caractéristiques qui inclut la caractéristique Recommencer après dans la liste des exigés, et une option Heure de réessai avec une heure après laquelle le client devrait réessayer la demande.

À tout moment après la réception du message ACK initial avec l'option Heure de réessai, le client PEUT terminer le processus d'allocation et tout prêt l'accompagnant par l'envoi au serveur qui effectue l'allocation (ou à un autre serveur si la caractéristique Mobilité du serveur est aussi activée) d'un message LIBÉRER avec l'Identifiant de prêt inclus dans le message REQUEST d'origine.

La caractéristique Recommencer après peut aussi être utilisés lors du renouvellement d'un prêt. Dans ce cas, la description ci-dessus s'applique avec l'exception que le client envoie un message RENEW au lieu d'un message REQUEST.

Si un client envoie un message RENEW avec un Identifiant de prêt qui correspond à un prêt qui est actuellement en cours d'allocation avec la caractéristique Recommencer après en réponse à un message REQUEST, le serveur DOIT générer et traiter une erreur Demande invalide de la façon décrite au paragraphe 2.6. Aussi, si un client envoie un message RENEW avec un identifiant de prêt qui correspond à un prêt qui est actuellement en cours d'allocation avec la caractéristique Recommencer après en réponse à un message RENEW, mais si les options fournies dans les deux messages RENEW ne correspondent pas, le serveur DOIT générer et traiter une erreur Demande invalide de la façon décrite au paragraphe 2.6.

Noter que la caractéristique Recommencer après peut compliquer l'API d'application. Pour cette raison, un client MADCAP peut demander la caractéristique Recommander après pour certains messages et non pour d'autres. Cela ne devrait pas causer de problèmes pour un serveur MADCAP robuste. En général, les serveurs ne devraient pas s'attendre à un comportement cohérent de la part des clients excepté autant qu'exigé par la présente spécification. Cela s'applique aussi aux attentes des clients.

2.13.3 Identifiant de prêt partagé

Pour les applications de conférence, il peut être souhaitable de permettre aux participants à une conférence de modifier un prêt utilisé pour la conférence. Le code de caractéristique Identifiant de prêt partagé est utilisé pour prendre en charge cette exigence.

Si ce code de caractéristique était demandé par le client et mis en œuvre par le serveur lorsque le prêt a été alloué, le serveur DEVRAIT désactiver toute exigence d'authentification relevant de ce prêt, en permettant à tout client qui connaît l'identifiant de prêt de modifier le prêt.

Un client MADCAP qui souhaite utiliser la caractéristique Identifiant de prêt partagé devrait inclure cette caractéristique dans la liste des demandés ou des exigés de l'option Liste de caractéristiques d'un message REQUEST lors de la première allocation du prêt. Si la caractéristique était exigée, le serveur DEVRAIT essayer de mettre en œuvre cette demande et inclure la caractéristique dans la liste des exigés de la réponse. Si le serveur ne peut pas mettre en œuvre la caractéristique pour cette demande, il DOIT générer et traiter une erreur Caractéristique exigée non prise en charge de la façon décrite au paragraphe 2.6. Si la caractéristique était demandée, le serveur DEVRAIT essayer de mettre en œuvre la caractéristique et l'inclure dans la liste des demandés de la réponse. Cependant, si le serveur ne peut pas mettre en œuvre la caractéristique, il peut simplement la sauter.

Les demandes ultérieures qui relèvent d'un prêt pour lequel la caractéristique Identifiant de prêt partagé a été mise en œuvre à l'heure d'allocation PEUVENT inclure la caractéristique Identifiant de prêt partagé dans la liste des demandés ou des exigés de l'option Liste de caractéristiques. Dans ce cas, le serveur DEVRAIT essayer de mettre en œuvre la caractéristique en désactivant toute exigence d'authentification relevant de ce prêt, permettant à tout client qui connaît l'identifiant de prêt de modifier le prêt, et en incluant la caractéristique dans la liste des exigés de la réponse. Si le serveur ne peut pas mettre en œuvre la caractéristique, il DEVRAIT la sauter si la caractéristique était demandée. Mais si la caractéristique était exigée et si le serveur ne peut pas la mettre en œuvre, le serveur DOIT générer et traiter une erreur Caractéristique exigée non prise en charge de la façon décrite au paragraphe 2.6.

Comme on l'a décrit plus haut, chaque message MADCAP comporte un champ d'options consistant en une liste de paramètres étiquetés appelés "options". Toutes les options consistent en un code d'option de deux octets et d'une longueur d'option de deux octets, suivie par le nombre des octets spécifiés par la longueur d'option.

La présente section définit un ensemble de codes d'option à utiliser dans les messages MADCAP. De nouvelles options peuvent être définies en utilisant le processus défini à la section 5. La liste des options est donnée dans l'ordre numérique.

Option	GETINFO	ACK (en réponse à GETINFO)
Heure du prêt	NE DOIT PAS	NE DOIT PAS
Identifiant de serveur	NE DOIT PAS	DOIT
Identifiant de prêt	DOIT	DOIT
Portée de diffusion groupée	NE DOIT PAS	NE DOIT PAS
Liste des options demandées	DOIT	NE DOIT PAS
Heure de début	NE DOIT PAS	NE DOIT PAS
Nombre d'adresses demandées	NE DOIT PAS	NE DOIT PAS
Langue demandée	PEUT	NE DOIT PAS
Liste des portées de diffusion groupée	NE DOIT PAS	PEUT
Liste des gammes d'adresse	NE DOIT PAS	NE DOIT PAS
Heure en cours	NE DOIT PAS	PEUT
Liste des caractéristiques	PEUT	PEUT
Heure de réessai	NE DOIT PAS	NE DOIT PAS
Heure minimum du prêt	NE DOIT PAS	NE DOIT PAS
Heure maximum de début	NE DOIT PAS	NE DOIT PAS
Erreur	NE DOIT PAS	NE DOIT PAS

Option	DISCOVER	OFFER
Heure du prêt	PEUT	DOIT
Identifiant de serveur	NE DOIT PAS	DOIT
Identifiant de prêt	DOIT	DOIT
Portée de diffusion groupée	DOIT	DOIT
Liste des options demandées	NE DOIT PAS	NE DOIT PAS
Heure de début	PEUT	PEUT
Nombre d'adresses demandées	PEUT	NE DOIT PAS
Langue demandée	NE DOIT PAS	NE DOIT PAS
Liste des portées de diffusion groupée	NE DOIT PAS	NE DOIT PAS
Liste des gammes d'adresse	PEUT	PEUT
Heure en cours	PEUT	PEUT
Liste des caractéristiques	PEUT	PEUT
Heure de réessai	NE DOIT PAS	NE DOIT PAS
Heure minimum du prêt	PEUT	NE DOIT PAS
Heure maximum de début	PEUT	NE DOIT PAS
Erreur	NE DOIT PAS	NE DOIT PAS

Option	REQUEST	ACK (en réponse à REQUEST)
Heure du prêt	PEUT	DOIT
Identifiant de serveur	DOIT (si diff. groupée)	DOIT
Identifiant de prêt	DOIT	DOIT
Portée de diffusion groupée	DOIT	DOIT
Liste des options demandées	NE DOIT PAS	NE DOIT PAS
Heure de début	PEUT	PEUT
Nombre d'adresses demandées	PEUT	NE DOIT PAS
Langue demandée	NE DOIT PAS	NE DOIT PAS
Liste des portées de diffusion groupée	NE DOIT PAS	NE DOIT PAS
Liste des gammes d'adresse	PEUT	DOIT
Heure en cours	PEUT	PEUT
Liste des caractéristiques	PEUT	PEUT
Heure de réessai	NE DOIT PAS	PEUT
Heure minimum du prêt	PEUT	NE DOIT PAS
Heure maximum de début	PEUT	NE DOIT PAS
Erreur	NE DOIT PAS	NE DOIT PAS

Option	RENEW	ACK (en réponse à RENEW)
Heure du prêt	PEUT	DOIT
Identifiant de serveur	NE DOIT PAS	DOIT
Identifiant de prêt	DOIT	DOIT
Portée de diffusion groupée	NE DOIT PAS	DOIT
Liste des options demandées	NE DOIT PAS	NE DOIT PAS
Heure de début	PEUT	PEUT
Nombre d'adresses demandées	NE DOIT PAS	NE DOIT PAS
Langue demandée	NE DOIT PAS	NE DOIT PAS
Liste des portées de diffusion groupée	NE DOIT PAS	NE DOIT PAS
Liste des gammes d'adresse	NE DOIT PAS	DOIT
Heure en cours	PEUT	PEUT
Liste des caractéristiques	PEUT	PEUT
Heure de réessai	NE DOIT PAS	PEUT
Heure minimum du prêt	PEUT	NE DOIT PAS
Heure maximum de début	PEUT	NE DOIT PAS
Erreur	NE DOIT PAS	NE DOIT PAS

Option	RELEASE	ACK (en réponse à RELEASE)
Heure du prêt	NE DOIT PAS	NE DOIT PAS
Identifiant de serveur	NE DOIT PAS	DOIT
Identifiant de prêt	DOIT	DOIT
Portée de diffusion groupée	NE DOIT PAS	NE DOIT PAS
Liste des options demandées	NE DOIT PAS	NE DOIT PAS
Heure de début	NE DOIT PAS	NE DOIT PAS
Nombre d'adresses demandées	NE DOIT PAS	NE DOIT PAS
Langue demandée	NE DOIT PAS	NE DOIT PAS
Liste des portées de diffusion groupée	NE DOIT PAS	NE DOIT PAS
Liste des gammes d'adresse	NE DOIT PAS	NE DOIT PAS
Heure en cours	NE DOIT PAS	NE DOIT PAS
Liste des caractéristiques	PEUT	PEUT
Heure de réessai	NE DOIT PAS	NE DOIT PAS
Heure minimum du prêt	NE DOIT PAS	NE DOIT PAS
Heure maximum de début	NE DOIT PAS	NE DOIT PAS
Erreur	NE DOIT PAS	NE DOIT PAS

Option	NAK
Heure du prêt	NE DOIT PAS
Identifiant de serveur	DOIT
Identifiant de prêt	DOIT
Portée de diffusion groupée	NE DOIT PAS
Liste des options demandées	NE DOIT PAS
Heure de début	NE DOIT PAS
Nombre d'adresses demandées	NE DOIT PAS
Langue demandée	NE DOIT PAS
Liste des portées de diffusion groupée	NE DOIT PAS
Liste des gammes d'adresse	NE DOIT PAS
Heure en cours	NE DOIT PAS
Liste des caractéristiques	PEUT
Heure de réessai	NE DOIT PAS
Heure minimum du prêt	NE DOIT PAS
Heure maximum de début	NE DOIT PAS
Erreur	DOIT

L'option Fin marque la fin des informations valides dans le champ d'options. Cette option DOIT être incluse à la fin du champ d'options dans chaque message MADCAP.

Cette option est utilisée dans une demande de client (DISCOVER, REQUEST, ou RENEW) pour autoriser le client à demander une heure de prêt pour l'adresse de diffusion groupée. Dans une réponse de serveur (OFFER ou ACK), un serveur MADCAP utilise cette option pour spécifier l'heure de prêt qu'il veut offrir.

L'heure est en secondes, et est spécifiée par un entier non signé de 32 bits.

Cette option contient l'adresse IP d'un serveur MADCAP. Un numéro de famille d'adresse de deux octets (comme défini par l'IANA, y compris ceux définis en [10]) est mémorisé d'abord, suivi par l'adresse. La famille d'adresses pour cette adresse n'est pas déterminée par le champ addrfamily dans l'en-tête fixe de sorte que les adresses d'une famille peuvent être allouées tout en communicant avec un serveur via des adresses d'une autre famille.

Tous les messages envoyés par un serveur MADCAP DOIVENT comporter une option Identifiant de serveur avec l'adresse IP du serveur qui envoie le message.

Les clients MADCAP DOIVENT inclure une option Identifiant de serveur dans les messages REQUEST en diffusion groupée afin d'indiquer quel message OFFER a été accepté.

Cette option est utilisée par les clients MADCAP pour spécifier un identifiant de prêt univoque. Pour plus d'informations sur cette option et la façon dont elle est utilisée, voir au paragraphe 2.4.

L'option Portée de diffusion groupée est utilisée par le client pour indiquer la portée de diffusion groupée demandée dans un message DISCOVER ou REQUEST. Elle est aussi utilisée par le serveur MADCAP pour indiquer la portée d'une adresse allouée.

Le client peut obtenir la liste des portées par une option Liste des portées de diffusion groupée ou en utilisant d'autres moyens. L'identifiant de portée est la première adresse de diffusion groupée dans la portée. La famille d'adresse de l'identifiant de portée est déterminée par le champ addrfamily dans l'en-tête fixe.

Cette option est utilisée par un client MADCAP dans un message GETINFO pour demander que certaines options soient incluses dans la réponse ACK du serveur. Le serveur DEVRAIT essayer d'inclure les options spécifiées dans sa réponse, mais il n'est pas obligé de le faire.

L'option Heure de début spécifie l'heure de début d'un prêt d'adresse de diffusion groupée.

Un client peut inclure cette option dans un message DISCOVER, RENEW, ou REQUEST pour demander une adresse de diffusion groupée à utiliser à l'avenir. Un serveur peut inclure cette option dans un message OFFER ou dans un ACK en réponse à un message REQUEST ou RENEW pour indiquer qu'un prêt a été accordé et qu'il va commencer dans le futur.

Si l'option Heure de début est présente, l'option Heure du prêt d'adresse IP spécifie la durée du prêt qui commence à la valeur de l'option Heure de début.

Si l'option Heure de début est présente, l'option Heure en cours DOIT aussi être présente, comme décrit au paragraphe 2.12.

La valeur de l'heure est un entier non signé de 32 bits dans l'ordre des octets du réseau qui donne le nombre de secondes depuis 00:00 UTC, le 1 er janvier 1970. Cela peut être converti en un horodatage NTP en ajoutant 2 208 988 800 en décimal. Ce format d'heure ne reviendra pas à zéro avant l'année 2106.

Cette option spécifie le nombre minimum et le nombre désiré d'adresses demandées par le client. Elle n'est utilisée que dans les messages DISCOVER et REQUEST et est seulement envoyée par le client.

Le nombre minimum et le nombre désiré d'adresses demandées sont des entiers non signés de 16 bits dans l'ordre des octets du réseau. Le minimum DOIT être inférieur ou égal au nombre désiré. Si ce n'est pas le cas dans un message reçu, le serveur MADCAP DOIT générer et traiter une erreur Demande invalide de la façon décrite au paragraphe 2.6.

Le client PEUT obtenir plus d'une adresse soit en répétant le protocole pour chaque adresse soit en demandant plusieurs adresses en même temps via cette option. Lorsque le client demande seulement une adresse, cette option NE DEVRAIT PAS être incluse. Un serveur MADCAP qui reçoit un paquet DISCOVER ou REQUEST qui comporte cette option DOIT inclure entre le minimum et le nombre désiré d'adresses dans toute réponse OFFER ou ACK.

Cette option spécifie la langue dans laquelle le client MADCAP voudrait que les chaînes telles que les noms de zone soient retournées. Elle n'est incluse que dans un message GETINFO envoyé par le client. C'est une étiquette de langue de la RFC 1766 [6]. La façon appropriée de traiter cette étiquette par rapport aux noms de zone est exposée plus en détails dans la définition de l'option Liste des portées de diffusion groupée.

Cette option est envoyée par le serveur dans un message ACK en réponse à un message GETINFO envoyé par le client.

Si le client n'a pas inclus d'option Langue demandée dans son message GETINFO, le serveur MADCAP DEVRAIT retourner tous les noms de zone pour chaque zone. Si le client a inclus une option Langue demandée dans son message GETINFO, le serveur MADCAP DOIT retourner pas plus d'un nom de zone pour chaque zone. Pour chaque zone, le serveur MADCAP DEVRAIT d'abord chercher un nom de zone qui corresponde à l'étiquette de langue demandée (en utilisant une comparaison ASCII insensible à la casse). Si des noms correspondent, l'un d'eux devrait être retourné. Autrement, le serveur MADCAP DEVRAIT choisir un autre nom de zone à retourner (s'il en est de défini). Il DEVRAIT donner la préférence aux noms de zone qui sont marqués à utiliser si aucun nom n'est disponible dans une langue désirée.

La liste des portées est une liste de m tuplets, où chaque tuplet est de la forme :

où l'ID de portée est la première adresse de diffusion groupée dans la portée, Dernière adresse est la dernière adresse de diffusion groupée dans la portée, TTL est la valeur du TTL de la diffusion groupée pour les adresses de diffusion groupée de la portée, et Compte de noms est le nombre de nom codés pour cette zone (qui peut être zéro). La famille d'adresses de l'identifiant de portée et la dernière adresse sont déterminées par le champ addrfamily dans l'en-tête fixe. Noter qu'un serveur MADCAP particulier peut allouer des adresses à partir d'un sous-ensemble de la portée. Par exemple, les adresses dans la portée peuvent être réparties d'une certaine manière entre plusieurs serveurs.

où Fanions de nom est un champ de fanions avec des fanions qui sont définis ci-dessous, Longueur de langue est la longueur de l'étiquette de langue en octets (qui NE DOIT PAS être zéro), Étiquettes de langue indique la langue du nom de zone (comme décrit en [6]), Longueur de nom est la longueur du nom en octets (qui NE DOIT PAS être zéro), et Noms est une chaîne codée en UTF-8 [5] qui indique le nom donné à la zone de portée.

Le bit de poids fort du champ Fanions de nom est mis (à 1) si le nom qui suit devrait être utilisé si aucun nom n'est disponible dans une langue désirée. Autrement, ce bit est à zéro. Tous les bits restants dans l'octet DEVRAIENT être mis à zéro et DOIVENT être ignorés.

Les entrées d'identifiants de portée dans la liste DOIVENT être univoques et les portées DEVRAIENT être énumérées de la plus petite (topologiquement parlant) à la plus grande. Cela facilite l'affichage d'une interface d'utilisateur plus cohérente, avec les portées qui gardent habituellement le même ordre. Cependant, les portées peuvent n'être pas strictement incorporées. Dans ces circonstances, il n'y a pas d'ordre strict de la plus petite à la plus grande et le serveur doit utiliser une autre technique pour ordonner la liste des portées.

Il y a deux portées qui sont prises en charge par les serveur d'allocation d'adresses de diffusion groupée : à l'intérieur de abcd.com avec les adresses 239.192.0.0 à 239.195.255.255, et mondiale avec les adresses 224.0.1.0 à 238.255.255.255. Cette option sera alors donnée par :

Cette option est utilisée par le serveur pour fournir la liste de toutes les gammes d'adresse allouées au client.

Cette option est aussi utilisée par le client lorsque il demande un prêt pour un ensemble spécifique d'adresses. Cette caractéristique ne devrait être que rarement nécessaire, comme lorsque on a par accident permis l'arrivée à expiration d'un prêt et qu'il faut le réallouer.

Cette option est utilisée pour exprimer ce que l'envoyeur pense qu'est l'heure en cours. C'est utile pour détecter le biais d'horloge. Cette option DOIT être incluse si les options Heure de début ou Heure maximum de début sont utilisées, comme décrit au paragraphe 2.12.

La valeur de l'heure est un entier non signé de 32 bits dans l'ordre des octets du réseau qui donne le nombre de secondes depuis 00:00 UTC, au 1 er janvier 1970. Cela peut être converti en horodatage NTP [4] en ajoutant 2 208 988 800 en décimal. Ce format horaire ne reviendra pas à zéro avant l'année 2106.

Cette option fait la liste des caractéristiques MADCAP facultatives prises en charge, demandées, ou exigées, par l'envoyeur. Cette option PEUT être incluse dans tout message envoyé par un serveur ou client MADCAP.

Les caractéristiques facultatives de MADCAP sont identifiées par un code de caractéristique de deux octets. De nouveaux codes de caractéristique MADCAP ne peuvent être définis que par consensus de l'IETF, comme décrit à la Section 5.

L'option Liste de caractéristiques consiste en trois listes distinctes : caractéristiques prises en charge, caractéristiques demandées, et caractéristiques exigées. Chaque liste consiste en une liste sans ordre de codes de caractéristiques. La liste de celles prises en charge est utilisée par les clients ou serveurs MADCAP pour indiquer les caractéristiques que l'envoyeur accepte. Les listes des demandées et des exigées sont utilisées par les clients MADCAP pour indiquer quelles caractéristiques sont demandées ou exigées d'un serveur MADCAP. La liste des exigées est utilisée par les serveurs MADCAP pour indiquer quelles caractéristiques sont mises en œuvre par le serveur MADCAP dans le traitement de ce message. Les messages envoyés par les serveurs MADCAP NE DOIVENT PAS inclure de code de caractéristique dans la liste des demandées.

Si un client MADCAP inclut l'option Liste de caractéristiques dans un message, il PEUT inclure des caractéristiques dans toutes les listes, prises en charge, demandées, et exigées. Si un serveur MADCAP reçoit un message contenant l'option Liste de caractéristiques et qu'il ne prend pas en charge toutes les caractéristiques de la liste des exigées, il DOIT générer et traiter une erreur Caractéristique exigée non prise en charge de la façon décrite au paragraphe 2.6. Si le serveur prend en charge toutes les caractéristiques de la liste des exigées, il DOIT les mettre en œuvre de la façon appropriée pour ce message. Il DEVRAIT essayer de mettre en œuvre les caractéristiques de la liste des demandées et il PEUT mettre en œuvre les caractéristiques de la liste des prises en charge. Si une caractéristiques facultative (comme Recommencer après) ne figure dans aucune partie de l'option Liste de caractéristiques incluse dans le message du client (ou si le client n'a pas inclus d'option Liste de caractéristiques dans son message) le serveur NE DOIT PAS utiliser cette caractéristique dans sa réponse.

Si un serveur MADCAP ne répond pas au message d'un client qui comporte une option Liste de caractéristiques, le serveur DOIT inclure une option Liste de caractéristiques avec une liste des caractéristiques prises en charge qui énumère les caractéristiques qu'il accepte, une liste des caractéristiques exigées qui énumère les caractéristiques qu'il met en œuvre en répondant à ce message (qui doivent être incluses dans la liste des caractéristiques prises en charge de l'option Liste de caractéristiques du client) et une liste vide des caractéristiques demandées.

L'option Heure de réessai spécifie l'heure à laquelle un client devrait réessayer un message REQUEST ou RENEW lorsque il utilise la caractéristique Recommencer après.

Cette option ne devrait être envoyée par un serveur MADCAP que dans un ACK en répondant à un message REQUEST ou RENEW qui comporte une caractéristique Recommencer après dans la liste des acceptées, demandées ou exigées. Pour un exposé plus complet sur Recommencer après, voir au paragraphe 2.13.2.

Si l'option Heure de réessai est présente, l'option Heure en cours DOIT aussi être présente.

La valeur de l'heure est un entier non signé de 32 bits dans l'ordre des octets du réseau qui donne le nombre de secondes depuis 00:00 UTC, le 1 er janvier 1970. Cela peut être converti en horodatage NTP en ajoutant 2 208 988 800 en décimal. Ce format d'heure ne reviendra pas à zéro avant l'année 2106.

Cette option est utilisée dans une demande de client (DISCOVER, REQUEST, ou RENEW) pour permettre au client de spécifier une durée minimum de prêt pour l'adresse de diffusion groupée. Si un serveur ne peut pas satisfaire à cette durée de prêt minimum, il DOIT générer et traiter une erreur Demande valide ne peut être satisfaite de la façon décrite au paragraphe 2.6.

L'heure est en unités de secondes, et est spécifiée par un entier non signé de 32 bits.

L'option Heure maximum de début spécifie l'heure de début la plus tardive que le client veut accepter pour le prêt d'une adresse de diffusion groupée.

Un client peut inclure cette option dans un message DISCOVER, RENEW, ou REQUEST pour spécifier qu'il ne veut pas recevoir un prêt avec une heure de début plus tardive que la valeur spécifiée. Si un serveur ne peut pas satisfaire à cette heure de début maximum, il DOIT générer et traiter une erreur Demande valide ne peut être satisfaite de la façon décrite au paragraphe 2.6.

Si l'option Heure maximum de début est présente, l'option Heure en cours DOIT aussi être présente, comme décrit au paragraphe 2.12.

La valeur de l'heure est un entier non signé de 32 bits dans l'ordre des octets du réseau qui donne le nombre de secondes depuis 00:00 UTC, le 1 er janvier 1970. Cela peut être converti en horodatage NTP en ajoutant 2 208 988 800 en décimal. Ce format de temps ne reviendra pas à zéro avant l'année 2106.

Un serveur MADCAP inclut cette option dans un message NAK pour indiquer la raison de l'échec de la demande. Un serveur MADCAP DOIT inclure une option ERREUR dans chaque message NAK.

Les deux premiers octets d'une option ERREUR contiennent un code d'erreur MADCAP. Plusieurs codes d'erreur MADCAP sont définis plus loin dans cette section. De nouveaux codes d'erreur MADCAP ne peuvent être définis que par consensus de l'IETF, comme décrit à la section 5.

Tous les octets restants dans l'option ERREUR contiennent des données supplémentaires sur l'erreur. Le format de ces données dépend du code d'erreur. La définition d'un code d'erreur MADCAP doit inclure une définition des données supplémentaires à inclure avec ce code d'erreur.

Un client qui reçoit un message NAK contenant une option ERREUR PEUT enregistrer ou afficher un message qui indique le code d'erreur et les données supplémentaires reçues. Le client NE DOIT PAS retransmettre un message une fois qu'une réponse NAK à ce message a été reçue. Le client PEUT ajuster le message pour corriger l'erreur et envoyer le message corrigé ou envoyer le message à un serveur différent.

3.17.1 Demande valide n'a pu être satisfaite

Le code d'erreur MADCAP 0 indique que la demande était valide, mais n'a pu être menée à son terme avec les adresses disponibles et la configuration actuelle. Les données supplémentaires sont un code d'option de deux octets qui indique quelle option a causé le problème. Une valeur de 0xFFFF indique que le problème n'est pas celui d'une option spécifique.

3.17.2 Demande invalide

Le code d'erreur MADCAP 1 indique que la demande était mal formée ou invalide d'une façon ou d'une autre. Les données supplémentaires sont un code d'option de deux octets qui indique quelle option a causé le problème. Une valeur de 0xFFFF indique que le problème n'était pas celui d'une option spécifique.

3.17.3 Biais d'horloge excessif

Le code d'erreur MADCAP 2 indique un biais d'horloge excessif (voir le paragraphe 2.12). Les données supplémentaires consistent en une valeur d'heure de quatre octets qui représente l'idée qu'a le serveur de l'heure actuelle, un entier non signé de 32 bits dans l'ordre des octets du réseau qui donne le nombre de secondes depuis 00:00 UTC, le 1 er janvier 1970. Cela peut être converti en un horodatage NTP en ajoutant 2 208 988 800 en décimal. Ce format d'heure ne reviendra pas à zéro avant l'année 2106.

3.17.4 Identifiant de prêt non reconnu

Le code d'erreur MADCAP 3 indique que l'identifiant de prêt n'a pas été reconnu (normalement en réponse à un message RENEW ou RELEASE). Il n'y a pas de données supplémentaires.

3.17.5 Caractéristique exigée non prise en charge

Le code d'erreur MADCAP 4 indique qu'au moins une caractéristique incluse dans la liste exigée de l'option Liste de caractéristiques n'est pas acceptée. Les données supplémentaires contiennent une liste des codes de caractéristiques de la liste des exigées qui ne sont pas prises en charge.

3.17.6 Utilisation expérimentale

Les codes d'erreur MADCAP de 1024 à 2047 sont réservés pour une utilisation expérimentale. Le format des données supplémentaires incluses avec ces codes d'erreur n'est pas défini.

MADCAP a des exigences de sécurité relativement basiques. À présent, il n'y a pas de moyen de mettre en application d'utilisation autorisée des adresses de diffusion groupée dans les protocoles d'acheminement/gestion de diffusion groupée. Il n'est donc pas possible d'identifier d'utilisation non autorisée d'adresse de diffusion groupée par un adversaire. De plus, une adresse de diffusion groupée allouée par un usager/système peut être utilisée par d'autres systèmes sans violer les termes de l'allocation de l'adresse de diffusion groupée. Par exemple, un système peut réserver une adresse à utiliser par une session de groupe de travail où chacun des membres du groupe de travail est autorisé à transmettre des paquets en utilisant l'adresse de groupe allouée. Autrement dit, le protocole d'allocation d'adresse de diffusion groupée n'impose pas la façon dont l'adresse devrait être utilisée, il impose seulement la période pendant laquelle elle peut être utilisée et qui doit la libérer ou la renouveler. Lorsque une adresse est allouée à un système/usager, cela veut fondamentalement dire qu'aucun autre utilisateur/système ne se verra (très vraisemblablement) allouer cette adresse pendant cette période, sans aucune restriction sur son utilisation.

Pour protéger contre les serveurs MADCAP vicieux (serveurs mal configurés et mal intentionnés), les clients dans certaines situations aimeraient authentifier le serveur. De même, à des fins de vérification ou de comptabilité, le serveur peut vouloir authentifier les clients. De plus, dans certains cas, le serveur peut avoir des politiques pour restreindre le nombre d'adresses allouées à un système ou un utilisateur. Ce dispositif est très précieux lorsqu'un utilisateur ou client qui se comporte bien mais est un peu inexpérimenté demande un grand nombre d'adresses, et impacte ainsi involontairement d'autres utilisateurs ou systèmes. Donc, un administrateur peut vouloir exercer un contrôle limité fondé sur l'identification du client. L'identification du client pourrait se fonder sur l'identité du système ou de l'utilisateur. Dans la plupart des situations pratiques, l'identification du système va suffire, cependant, en particulier dans le cas de systèmes multi utilisateurs, l'identification de l'utilisateur va parfois jouer un rôle important. Donc, des capacités d'authentification fondées sur l'identification de l'utilisateur peuvent être souhaitables. Comme toujours, l'intégrité des données est une exigence forte qui, si elle n'est pas protégée, peut conduire à de nombreux problèmes y compris d'attaques de déni de service.

Dans le cas de MADCAP, la confidentialité n'est pas une exigence forte. Dans la plupart des cas, au moins lorsque une adresse de diffusion groupée est utilisée, un adversaire peut être capable de déterminer des informations qui étaient contenues dans les messages MADCAP. Dans certains cas, les utilisateurs/systèmes peuvent vouloir protéger les informations des messages MADCAP de telle sorte qu'un adversaire ne soit pas capable de déterminer à l'avance les informations pertinentes, et donc planifier à l'avance une attaque. Par exemple, si un adversaire connaît à l'avance (sur la base des messages MADCAP) qu'un utilisateur particulier a demandé un grand nombre d'adresses pour une certaine période et une certaine portée, il peut être capable de deviner l'objet de ces demandes et cibler une attaque. Lorsque la caractéristique Identifiant de prêt partagé est utilisée, préserver la confidentialité des messages MADCAP devient plus important. Aussi, il pourra y avoir des caractéristiques qui seront ajoutées au protocole à l'avenir qui auraient des exigences de confidentialité plus fortes.

Le protocole IPSEC [8] satisfait aux exigences d'identification et de protection d'intégrité de client/serveur établies ci-dessus, il n'exige aucune modification au protocole MADCAP, et c'est l'aboutissement d'importants travaux à l'IETF et dans l'industrie. Donc, lorsque la sécurité est une exigence forte, IPSEC DEVRAIT être utilisé pour protéger tous les messages en envoi individuel du protocole MADCAP. Lorsque la sécurité fondée sur IPSEC est utilisée, tous les paquets de diffusion groupée excepté GETINFO DOIVENT être abandonnés par le serveur MADCAP. La plupart des mises en œuvre existantes de IPSEC prennent en charge l'identification de client sous la forme d'une identification de système et ne prennent pas en charge l'identification de l'utilisateur. Cependant, lorsque on le désire, IPSEC avec l'API appropriée peut être nécessaire pour prendre en charge l'identification de l'utilisateur.

Le présent document définit plusieurs espaces de numéros (options MADCAP, types de message MADCAP, types MADCAP d'identifiant de prêts, caractéristiques MADCAP, et codes d'erreur MADCAP). Pour tous ces espaces de numéros, certaines valeurs sont définies dans cette spécification. De nouvelles valeurs ne peuvent être définies que par consensus de l'IETF, comme décrit en [7]. En fait, cela signifie qu'elles sont définies par des RFC approuvées par l'IESG.

Les auteurs tiennent à remercier Rajeev Byrisetty, Steve Deering, Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning, Dave Thaler, Ramesh Vyaghrapuri et les participants à l'IETF pour l'assistance qu'ils ont apporté à ce protocole.

Beaucoup de ce document se fonde sur [1] et [2]. Les auteurs de ce document tiennent à exprimer leur gratitude à l'égard des auteurs de ces travaux antérieurs. Toutes les erreurs du présent document ne sont à imputer qu'aux auteurs de ce document.

[1] R. Droms, "Protocole de configuration dynamique d'hôte", RFC 2131, mars 1997. (M. à j. par les RFC 3396 et 4361).

[2] S. Alexander et R. Droms, "Options DHCP et Extensions de fabricant BOOTP", RFC 2132, mars 1997.

[3] D. Meyer, "Diffusion groupée sur IP limitée administrativement", RFC 2365, juillet 1998. (BCP0023).

[4] D. Mills, "Protocole de l'heure du réseau, version 3, spécification, mise en œuvre et analyse", RFC 1305, STD 12, mars 1992.

[5] F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", RFC 2279, janvier 1998. (Obsolète, voirRFC3629) (D.S.).

[6] H. Alvestrand, "Étiquettes pour l'identification des langues", RFC 1766, mars 1995. (Obsolète, voirRFC3066, RFC3282) (P.S.)

[7] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", RFC 2434, BCP 26, octobre, 1998. (Rendue obsolète par la RFC 5226)

[8] S. Kent et R. Atkinson, "Architecture de sécurité pour le protocole Internet", RFC 2401, novembre 1998.

[9] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", RFC 2119, BCP 14, mars 1997.

[10] J. Reynolds et J. Postel, "Numéros alloués", RFC 1700, STD 2, octobre 1994. (Historique)

[11] S. Deering, "Extensions d'hôte pour diffusion groupée sur IP", RFC 1112, STD 5, août 1989.

[12] S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6)", RFC 2460, décembre 1998. (MàJ par 5095, D.S)

[13] R. Hinden, S. Deering, "Architecture d'adressage IP version 6", RFC 2373, juillet 1998. (Obsolète, voirRFC3513) (P.S.)

[14] H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : protocole de transport pour applications en temps réel", RFC 1889, janvier 1996. (Obsolète, voirRFC3550 STD64)

Appendice A Exemples

Le présent appendice comporte plusieurs exemples d'échanges typique de protocole MADCAP.

Dans cet exemple, un client MADCAP veut déterminer la liste des portées effectives. Le client utilise IPv4, aussi commence t-il par envoyer un paquet GETINFO en diffusion groupée à l'adresse de diffusion groupée de serveur MADCAP correspondant à la portée locale IPv4. Ce paquet comporte l'option Identifiant de prêt, une liste des options demandées incluant le code d'option Liste des portées de diffusion groupée, et une option Langue demandée contenant la chaîne "en", car le client est configuré pour préférer la langue anglaise.

Deux serveurs MADCAP répondent en envoyant des messages ACK. Ces messages ACK comportent l'option Identifiant de prêt et le xid fourni par le client, l'identifiant de serveur du serveur, et la liste des portées de diffusion groupée avec un nom par portée (celui qui correspond de plus près à l'étiquette de langue "en").

Figure 2 : Diagramme temporel des messages échangés dans l'exemple
de découverte de liste de portées de diffusion groupée

Dans cet exemple, le client MADCAP veut allouer une adresse de diffusion groupée de la portée mondiale à utiliser dans les deux prochaines heures.

Le client commence par envoyer un paquet DISCOVER en diffusion groupée à l'adresse de diffusion groupée de serveur MADCAP associée à la portée locale IPv4. Ce paquet comporte les options Heure du prêt, Identifiant de prêt, et Portée de diffusion groupée.

Tous serveur qui reçoit le paquet DISCOVER et qui peut satisfaire cette demande réserve temporairement une adresse pour le client et envoie un paquet OFFER en envoi individuel au client. Ces paquets contiennent les options Heure du prêt, Identifiant de serveur, Identifiant de prêt, et Portée de diffusion groupée.

Après un délai approprié, le client envoie un paquet REQUEST en diffusion groupée à l'adresse de diffusion groupée de serveur MADCAP. Ce paquet contient toutes les options incluses dans le paquet DISCOVER, mais comporte aussi l'option Identifiant de serveur, qui indique quel serveur il a choisi pour la demande.

Le serveur dont l'identifiant de serveur correspond à celui spécifié par le client répond par un paquet ACK contenant les options incluses dans le paquet OFFER, ainsi qu'une option Liste des gammes d'adresse qui fait la liste des adresses allouées. Tous les autres serveurs qui avaient envoyé des paquets OFFER arrêtent de réserver une adresse pour le client et oublient tout l'échange.

Le client a maintenant un "prêt" de deux heures de l'adresse de diffusion groupée.

Si le client ne reçoit pas un ACK de la part du serveur, il retransmet son paquet REQUEST pendant un moment. Si il ne reçoit toujours pas de réponse, il va recommencer avec un nouveau message DISCOVER.

Figure 3 : Diagramme temporel des messages échangés dans l'exemple d'allocation d'adresse de diffusion groupée

Voici une continuation de l'exemple précédent. Le client a déjà reçu une allocation d'adresse de diffusion groupée de la portée mondiale à utiliser pour les deux prochaines heures. Alors que la moitié de cette période de deux heures s'est écoulée, il décide qu'il veut étendre son prêt d'une autre heure.

Le client envoie un paquet RENEW en envoi individuel au serveur qui lui a alloué l'adresse. Ce paquet comporte les options Heure du prêt et Identifiant de prêt. L'identifiant de prêt correspond à celui utilisé pour l'allocation d'origine. La durée incluse dans Heure du prêt est deux heures, car le client veut que le prêt expire dans deux heures à partir de maintenant.

Le serveur répond par un paquet ACK qui indique que l'extension du prêt a été accordée. Ce paquet comporte les options Heure du prêt, Identifiant de serveur, Identifiant de prêt, Portée de diffusion groupée, et Liste des gammes d'adresse.

Si le serveur ne veut pas accorder l'extension de prêt demandée, il faudra qu'il réponde par un paquet NAK avec l'option Identifiant de prêt.

Figure 4 : Diagramme temporel des messages échangés dans l'exemple d'extension de prêt

C'est la continuation de l'exemple précédent. Le client a déjà reçu l'allocation d'une adresse de diffusion groupée et a étendu son prêt pour encore deux heures. Une demi-heure plus tard, le client a fini d'utiliser l'adresse de diffusion groupée et veut la libérer afin qu'elle puisse être réutilisée.

Le client envoie un paquet RELEASE en envoi individuel au serveur qui lui a alloué l'adresse. Ce paquet comporte l'option Identifiant de prêt. L'identifiant de prêt correspond à celui utilisé pour l'allocation d'origine. Lorsque le serveur reçoit ce paquet, il annule le prêt du client sur l'adresse et envoie un paquet ACK au client, indiquant que le prêt a été libéré. Ce paquet comporte les options Identifiant de serveur et Identifiant de prêt.

Figure 5 : Diagramme temporel de l'échange de messages dans l'exemple de libération d'adresse

C'est la continuation de l'exemple précédent. Quelques temps plus tard, le client décide d'allouer une autre adresse de diffusion groupée. Comme il a récemment travaillé avec un serveur, il décide d'essayer d'envoyer une demande REQUEST en envoi individuel à ce serveur. Si cela ne fonctionne pas, il peut toujours essayer un DISCOVER en diffusion groupée, comme illustré dans l'exemple 2.

Le client fait un envoi individuel du paquet REQUEST au serveur duquel il veut obtenir l'allocation de l'adresse. Ce paquet comporte les options Heure du prêt, Identifiant de prêt, et Portée de diffusion groupée.

Le serveur répond par un paquet ACK contenant les options Heure du prêt, Identifiant de prêt, et Portée de diffusion groupée tirées du paquet REQUEST, ainsi que l'option Identifiant de serveur et l'option Liste des gammes d'adresse qui donne la liste des adresses allouées.

Si le client n'a pas reçu un ACK de la part du serveur, il va retransmettre son paquet REQUEST pendant un certain temps. Si il ne reçoit toujours pas de réponse, il va recommencer avec un message DISCOVER en diffusion groupée.

Figure 6 : Diagramme temporel de l'échange de messages dans l'exemple d'allocation d'adresse en envoi individuel

Appendice B Valeurs de constantes recommandées

Le Tableau 6 fait la liste des valeurs recommandées pour les constantes définies dans cette spécification.

Nom de la constante	Valeur recommandée
[CLOCK-SKEW-ALLOWANCE]	30 minutes
[DISCOVER-DELAY]	délais de retransmission actuel
[EXTRA-ALLOCATION-TIME]	1 heure
[NO-RESPONSE-DELAY]	60 secondes
[OFFER-HOLD]	au moins 60 secondes
[RESPONSE-CACHE-INTERVAL]	au moins 60 secondes (5 minutes maximum)
[XID-REUSE-INTERVAL]	10 minutes (exigé)

Le présent document et les informations y 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.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.

Groupe de travail Réseau	S. Hanna, Sun Microsystems, Inc.
Requests for Comments : 2730	B. Patel, Intel Corp.
Catégorie : En cours de normalisation	M. Shah, Microsoft Corp.
Traduction Claude Brière de L'Isle	décembre 1999

Stephen R. Hanna	Baiju V. Patel	Munil Shah
Sun Microsystems, Inc.	Intel Corp.	Microsoft Corporation
One Network Drive	Mail Stop: AG2-201	One Microsoft Way
Burlington, MA 01803	5200 NE Elam Young Parkway	Redmond, WA 98052
USA	Hillsboro, OR 97124	USA
téléphone : +1.781.442.0166	téléphone : 503 696 8192	téléphone : 425 703 3924
mél : steve.hanna@sun.com	mél : baiju.v.patel@intel.com	mél : munils@microsoft.com

Type d'identifiant de prêt	Nom
0	Identifiant de prêt aléatoire
1	Identifiant de prêt spécifique de l'adresse

Code de caractéristique	Nom de caractéristique
0	Mobilité du serveur
1	Recommencer après
2	Identifiant de prêt partagé