Groupe de travail Réseau	M. Stapp, Cisco Systems, Inc.
Request for Comments : 5460	février 2009
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Leasequery en vrac pour DHCPv6

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

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Résumé
Le protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6, Dynamic Host Configuration Protocol for IPv6) a été étendu avec la capacité Leasequery qui permet à un client de demander des informations sur les liens DHCPv6. Ce mécanisme se limite aux interrogations sur des liens individuels. Dans certaines situations, des interrogations de lien individuel peuvent n'être pas efficaces, ou même possibles. Le présent document étend le protocole Leasequery en ajoutant de nouveaux types d'interrogation et en permettant le transfert en vrac des données de lien DHCPv6 via TCP.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Vue d'ensemble du protocole	2
4. Interaction entre Leasequery UDP et Leasequery en vrac	3
5.  Définitions de message et d'option 	3
5.1 Tramage de message pour TCP	3
5.2 Messages	4
5.3 Types d'interrogations	4
5.4 Options	5
5.5 Codes d'état	5
5.6 Paramètres de connexion et de transmission	6
6. Comportement du demandeur	6
6.1 Connexion	6
6.2 Formation des interrogations	6
6.3 Traitement des réponses	6
6.4 Interrogation de plusieurs serveurs	7
6.5 Plusieurs interrogations à une seul serveur	7
6.6 Clôture de connexions	8
7. Comportement du serveur	8
7.1 Acceptation des connexions	8
7.2 Formation des réponses	8
7.3 Interrogations multiples ou parallèles	9
7.4  Clôture des connexions	9
8. Considérations sur la sécurité	9
9. Considérations relatives à l’IANA	9
10. Remerciements	10
11. Références	10
11.1 Références normatives	10
11.2 Références pour information	10
Adresse de l'auteur	10

 	1.	Introduction

Le protocole DHCPv6 [RFC3315] spécifie un mécanisme pour l'allocation d'adresse IPv6 et les informations de configuration aux nœuds IPv6. La délégation de préfixe (PD, Prefix Delegation) IPv6 pour DHCPv6 [RFC3633] spécifie un mécanisme pour la délégation DHCPv6 de préfixes IPv6 des données en rapport. Les serveurs DHCPv6 tiennent les informations d'autorité incluant les informations de lien pour les préfixes IPv6 délégués.

Le client d'un lien PD est normalement un routeur, qui annonce alors le préfixe délégué aux hôtes connectés localement. Le préfixe IPv6 délégué doit être acheminable afin d'être utile. Le client de PD DHCPv6 réel peut n'avoir pas la permission d'injecter des chemins dans le réseau qui délègue. Dans les réseaux de fournisseurs de service, par exemple, un routeur de bordure agit normalement comme un agent de relais DHCPv6, et ce routeur de bordure a souvent la responsabilité de maintenir les chemins au sein du réseau du fournisseur de service pour les liens de PD des clients.

Un relais DHCPv6 qui a cette responsabilité exige un moyen de récupérer les informations de lien auprès du ou des serveurs DHCPv6 d'autorité en cas de remplacement ou de réamorçage, afin de restaurer l'acheminement aux préfixes délégués. Le relais peut être un appareil du réseau sans la mémorisation locale adéquate pour maintenir les données nécessaires de lien à chemin. Un protocole DHCPv6 Leasequery [RFC5007] a été développé qui permet des interrogations sur les liens individuels de la part du ou des serveurs DHCPv6 d'autorité. Le mécanisme d'interrogation individuel est seulement utilisable quand le lien cible est connu du demandeur, comme à la réception de trafic. Dans le cas de la délégation de préfixe DHCPv6, les données de lien de PD peuvent devoir être connues avant que du trafic arrive du routeur client. Le routeur DHCPv6 relais peut n'être pas capable de former des interrogations individuelles dans ce cas.

Le présent document étend le protocole Leasequery DHCPv6 pour ajouter la prise en charge des interrogations qui répondent à ces exigences. Du côté SP, il peut y avoir des milliers de préfixes délégués par relais, de sorte qu'on spécifie l'utilisation de TCP [RFC4614] pour l'efficacité du transfert de données. On spécifie une nouvelle option DHCPv6, l'option Identifiant de relais, pour prendre en charge une récupération efficace de toutes les données associées à un agent de relais spécifique ; on ajoute aussi un type d'interrogation pour cela. On ajoute des types d'interrogation par segment de réseau et par valeur d'option Identifiant distant, pour aider un relais qui a besoin de récupérer un sous ensemble des liens de ses clients.

 	2.	Terminologie

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

La terminologie de DHCPv6 est définie dans la [RFC3315]. La terminologie de Leasequery DHCPv6 est définie dans la [RFC5007].

 	3.	Vue d'ensemble du protocole

Le mécanisme Leasequery en vrac est modélisé sur le protocole existant Leasequery individuel de la [RFC5007] ; la plupart des différences viennent de l'utilisation de TCP. Un client Leasequery en vrac ouvre une connexion TCP à un serveur DHCPv6, en utilisant l'accès DHCPv6 547. Noter que cela implique que le client Leasequery a des adresses de serveur IP disponibles via sa configuration ou quelque autre moyen, et qu'il a une accessibilité IP en envoi individuel au serveur. Aucun relais pour Leasequery en vrac n'est spécifié.

Après l'établissement d'une connexion, le client envoie un message LEASEQUERY contenant un type d'interrogation et des données sur les liens qui l'intéressent. Le serveur utilise le type d'interrogation et les données pour identifier tous les liens pertinents. Afin de prendre en charge des types d'interrogations, les serveurs peuvent devoir maintenir des structures de données supplémentaires ou être capables de localiser des liens sur la base de données d'option spécifiques. Le serveur répond avec un message LEASEQUERY-REPLY, qui indique le succès ou l'échec de l'interrogation. Si l'interrogation est réussie, le serveur inclut aussi les premières données de lien du client dans le message LEASEQUERY-REPLY. Si plus d'un lien du client a été retourné, le serveur transmet alors les liens de client supplémentaires dans une série de messages LEASEQUERY-DATA. Si le serveur a envoyé au moins un ligne de client, il envoie un message LEASEQUERY-DONE quand il a fini d'envoyer ses réponses. Le client peut réutiliser la connexion pour envoyer des interrogations supplémentaires. Chaque extrémité de la connexion TCP peut être close après que toutes les données ont été envoyées.

La présente spécification inclut une nouvelle option DHCPv6, l'option Relay-ID (identifiant de relais). L'option contient un identifiant DHCP unique (DUID, DHCP Unique Identifier) qui identifie un agent de relais DHCPv6. Les agents de relais peuvent inclure cette option dans les messages Relay-Forward qu'ils envoient. Les serveurs peuvent conserver le Relay-ID et l'associer aux liens faits au nom des clients du relais. Un relais peut alors récupérer les informations de lien sur les clients en aval en utilisant le Relay-ID dans un message LEASEQUERY. L'option Relay-ID est définie au paragraphe 5.4.1.

Leasequery en vrac prend en charge les interrogations par adresse IPv6 et par DUID de client comme spécifié dans la [RFC5007]. Le protocole Leasequery en vrac ajoute aussi plusieurs nouvelles interrogations. Les nouvelles interrogations introduites ici ne peuvent pas être utilisées effectivement avec le protocole Leasequery UDP. Les demandeurs NE DOIVENT PAS envoyer ces nouveaux types d'interrogations dans les messages d'interrogation de la [RFC5007].

Interrogation par identifiant de relais : cette interrogation demande à un serveur les liens associés à un relais spécifique ; le relais est identifié par un DUID porté dans une option Relay-ID.

Interrogation par adresse de lien : cette interrogation demande à un serveur les liens sur un segment de réseau particulier ; le lien est spécifié dans le champ link-address (adresse de liaison) de l'interrogation .

Interrogation par identifiant distant : cette interrogation demande à un serveur les liens associés à une valeur d'option Remote-ID (identifiant distant) [RFC4649] d'agent de relais.

 	4.	Interaction entre Leasequery UDP et Leasequery en vrac

Leasequery en vrac peut être vu comme une extension du protocole UDP Leasequery [RFC5007] existant. Cette section essaye de préciser les relations entre les deux protocoles.

Les types d'interrogations introduits dans le protocole UDP Leasequery peuvent être utilisés dans le protocole Leasequery en vrac. Un changement du comportement est introduit quand Leasequery en vrac est utilisé. La [RFC5007], dans les paragraphes 4.1.2.5 et 4.3.3, spécifie l'utilisation d'une option Liaison de client dans les messages LEASEQUERY-REPLY dans les cas où plusieurs liens sont trouvés. Quand Leasequery en vrac est utilisé, ce mécanisme n'est pas nécessaire : un serveur qui retourne plusieurs liens le fait simplement directement comme spécifié dans le présent document. L'option Lien de client NE DOIT PAS apparaître dans les réponses Leasequery en vrac.

Seuls les messages LEASEQUERY, LEASEQUERY-REPLY, LEASEQUERY-DATA, et LEASEQUERY-DONE sont permis sur la connexion Leasequery en vrac. Aucun autre message DHCPv6 n'est accepté. La connexion Leasequery en vrac n'est pas une option de remplacement de la communication DHCPv6 pour les clients qui recherchent un service DHCPv6.

Les nouvelles interrogations introduites dans la présente spécification ne peuvent pas être utilisées avec le protocole Leasequery UDP. Les serveurs qui mettent en œuvre la présente spécification et permettent aussi les interrogations UDP NE DOIVENT PAS accepter les types d'interrogation Leasequery en vrac dans les messages Leasequery UDP. Ces serveurs DOIVENT répondre par un code d'état d'erreur NotAllowed [RFC5007].

Les mises en œuvre devraient noter que le tramage de message TCP défini au paragraphe 5.1 n'est pas compatible avec le format de message UDP. Si une demande tramée en TCP est envoyée comme un message UDP, elle ne peut pas être valide, parce que les champs du protocole vont être décalés par le préfixe de taille de message.

 	5. 	Définitions de message et d'option 
 	5.1	Tramage de message pour TCP
L'utilisation de TCP pour le protocole Leasequery en vrac permet qu'un ou plusieurs messages DHCPv6 soient envoyés en même temps. Le receveur doit être capable de déterminer la taille de chaque message. Deux octets contenant la taille de message dans l'ordre des octets du réseau sont ajoutés devant chaque message DHCPv6 envoyé sur une connexion TCP de  Leasequery en vrac. Les deux octets de taille de message "trament" chaque message DHCPv6.

Message DHCPv6 tramé pour TCP :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Taille de message          | Type de msg   |               :
+---------------+---------------+---------------+---------------+
: Identifiant de transaction    |                               |
+---------------+---------------+                               |
|                                                               .
.                            options                            .
.                           (variable)                          .
|                                                               |
+---------------+---------------+---------------+---------------+

Taille de message :  nombre d'octets dans le message qui suit, comme entier de 16 bits dans l'ordre des octets du réseau.

Tous les autres champs sont comme spécifié dans DHCPv6 [RFC3315].

 	5.2	Messages
Les messages LEASEQUERY et LEASEQUERY-REPLY sont définis dans la [RFC5007]. Dans un échange Leasequery en vrac, un seul message LEASEQUERY-REPLY est utilisé pour indiquer le succès ou l'échec d'une interrogation, et pour porter les données qui ne changent pas dans le contexte d'une seule interrogation et réponse, comme les options de Server-ID et Client-ID. Si une interrogation est réussie, un seul message LEASEQUERY-REPLY DOIT apparaître. Si le serveur retourne des données de lien, le LEASEQUERY-REPLY contient aussi les premières données de lien du client dans une option OPTION_CLIENT_DATA.

 	5.2.1	LEASEQUERY-DATA
Le message LEASEQUERY-DATA porte des données sur un seul prêt de client DHCPv6 et/ou liens de PD sur une seule liaison. L'objet du message est de réduire la redondance des données quand il y a plusieurs liens à envoyer. Le message LEASEQUERY-DATA DOIT être précédé d'un message LEASEQUERY-REPLY. La LEASEQUERY-REPLY porte l'état de l'interrogation, les options Client-ID et Server-ID de Leasequery, et les premières données de lien du client si l'interrogation a réussi.

LEASEQUERY-DATA DOIT seulement être envoyé en réponse à une LEASEQUERY réussie, et seulement si plus d'une donnée de client est à envoyer. Le champ Identifiant de transaction du message LEASEQUERY-DATA DOIT correspondre à l'identifiant de transaction du message de demande LEASEQUERY. Les options Server-ID, Client-ID, et OPTION_STATUS_CODE NE DEVRAIENT PAS être incluses : ces données devraient être constantes pour toute réponse Leasequery en vrac, et devraient avoir été portées dans le message LEASEQUERY-REPLY.

 	5.2.2	LEASEQUERY-DONE
Le message LEASEQUERY-DONE indique la fin d'un groupe de réponses relatives à Leasequery. Le champ Identifiant de transaction du message LEASEQUERY-DONE DOIT correspondre à l'identifiant de transaction du message de demande LEASEQUERY. La présence du message lui-même signale la fin d'un flux de messages de réponse. Un seul LEASEQUERY-DONE DOIT être envoyé après toutes les réponses (une LEASEQUERY-REPLY réussie et zéro, un ou plusieurs messages LEASEQUERY-DATA) à une demande Leasequery en vrac réussie qui ont retourné au moins un lien.

Un serveur peut rencontrer une condition d'erreur après qu'il a envoyé la LEASEQUERY-REPLY initiale. Dans ce cas, il DEVRAIT tenter d'envoyer un LEASEQUERY-DONE avec une option OPTION_STATUS_CODE indiquant la condition d'erreur au demandeur. D'autres options DHCPv6 NE DEVRAIENT PAS être incluses dans le message LEASEQUERY-DONE.

 	5.3	Types d'interrogations
L'option OPTION_LQ_QUERY est définie dans la [RFC5007]. On introduit les nouveaux types d'interrogation suivants : QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, et QUERY_BY_REMOTE_ID. Ces interrogations sont destinées à aider les agents de relais à récupérer les données de lien dans des circonstances où des données de lien du relais, ou toutes ont été perdues.

 	5.3.1	QUERY_BY_RELAY_ID
Cette interrogation demande au serveur de retourner les liens associés au DUID de relais spécifié.

QUERY_BY_RELAY_ID : les options d'interrogation DOIVENT contenir une option OPTION_RELAY_ID. Si le champ d'adresse de lien est 0::0, l'interrogation demande tous les liens associés au relayDUID spécifié. Si l' adresse de lien est spécifiée, l'interrogation demande les liens sur cette liaison.

 	5.3.2	QUERY_BY_LINK_ADDRESS
L'interrogation QUERY_BY_LINK_ADDRESS demande au serveur de retourner les liens sur un segment de réseau identifié par la valeur d'une adresse de liaison provenant d'un message Relay-Forward d'un relais.

QUERY_BY_LINK_ADDRESS : l'adresse de liaison de l'interrogation contient une adresse qu'un relais peut avoir utilisé dans l'adresse de lien d'un message Relay-Forward. Le serveur tente de localiser les liens sur le même segment de réseau comme des adresses de lien.

 	5.3.3	QUERY_BY_REMOTE_ID
L'interrogation QUERY_BY_REMOTE_ID demande au serveur de retourner les liens associés à une valeur d'option d'identifiant distant provenant d'un message Relay-Forward d'un relais. Les options d'interrogation DOIVENT inclure une option Identifiant distant d'agent de relais [RFC4649].

Afin de prendre en charge cette interrogation, un serveur a besoin d'enregistrer la plus récente valeur d'option Identifiant distant vue dans un message Relay-Forward avec ses autres données de lien.

QUERY_BY_REMOTE_ID : les options d'interrogation DOIVENT inclure une option Identifiant distant d'agent de relais [RFC4649]. Si le serveur a enregistré des valeurs d'identifiant distant avec ses liens, il utilise la valeur de l'option pour identifier les liens à retourner.

 	5.4	Options
 	5.4.1	Option Relay-ID
L'option Relay-ID porte un DUID [RFC3315]. Un agent de relais PEUT inclure l'option dans les messages Relay-Forward qu'il envoie. Évidemment, il ne va pas être possible à un serveur de répondre aux interrogations QUERY_BY_RELAY_ID si l'agent de relais n'a pas inclus cette option. Un relais DEVRAIT être capable de générer un DUID à cette fin, et capturer le résultat dans une mémorisation stable. Un relais DEVRAIT aussi permettre que la valeur de DUID soit configurable : le faire permet à un administrateur de remplacer un agent de relais tout en conservant l'association entre le relais et les liens DHCPv6 existants.

Un serveur DHCPv6 PEUT associer les options Relay-ID provenant des messages Relay-Forward qu'il traite avec des délégations de préfixe et/ou les liens de prêt qui en résultent. Le faire lui permet de répondre aux Leasequeries QUERY_BY_RELAY_ID.
Le format de l'option Relay-ID est montré ci-dessous :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION_RELAY_ID         |      Longueur d'option        |
+---------------+---------------+---------------+---------------+
.                                                               .
.                              DUID                             .
.                        (longueur variable)                    .
.                                                               .
+---------------+---------------+---------------+---------------+

Code d'option : OPTION_RELAY_ID.

Longueur d'option : longueur du DUID en octets.

DUID : le DUID pour l'agent de relais.

 	5.5	Codes d'état
QueryTerminated : indique que le serveur est incapable d'effectuer une interrogation ou a prématurément terminé l'interrogation pour une raison quelconque (qui devrait être communiquée dans le texte du message). Ce peut être parce que le serveur est à court de ressources ou est en train de fermer. Le demandeur peut réessayer l'interrogation plus tard. Le demandeur devrait attendre au moins un court intervalle avant de réessayer. Noter qu'alors qu'un serveur peut simplement clore prématurément son extrémité de la connexion, il est préférable que le serveur envoie une LEASEQUERY-REPLY ou LEASEQUERY-DONE avec ce code d'état pour notifier la condition au demandeur.

 	5.6	Paramètres de connexion et de transmission
Les serveurs DHCPv6 qui prennent en charge Leasequery en vrac DEVRAIENT écouter les connexions TCP entrantes sur l'accès de serveur DHCPv6 547. Les mises en œuvre PEUVENT offrir de rendre configurable l'accès entrant, mais l'accès 547 DOIT être l'accès par défaut. Les mises en œuvre de client DEVRAIENT faire les connexions TCP sur l'accès 547, et PEUVENT offrir de rendre l'accès du serveur de destination configurable.

Ce paragraphe présente un tableau des valeurs utilisées pour contrôler le comportement de Leasequery en vrac, y compris les valeurs par défaut recommandées. Les mises en œuvre PEUVENT rendre ces valeurs configurables. Cependant, configurer de trop petites valeurs de temporisation peut conduire à un comportement dommageable pour l'application comme pour les autres trafics du réseau. Par suite, les valeurs de temporisation plus petites que les valeurs par défaut NE SONT PAS RECOMMANDÉES.

Paramètre	Valeur par défaut	Description
BULK_LQ_DATA_TIMEOUT	300 s	Temporisation des données de Leasequery en vrac
BULK_LQ_MAX_CONNS	10	Nombre maximum de connexions TCP Leasequery en vrac

 	6.	Comportement du demandeur
 	6.1	Connexion
Un demandeur tente d'établir une connexion TCP à un serveur DHCPv6 afin d'initier un échange Leasequery. Si la tentative échoue, le demandeur PEUT réessayer.

 	6.2	Formation des interrogations
Après l'établissement d'une connexion, le demandeur construit un message Leasequery, comme spécifié dans la [RFC5007]. L'interrogation peut avoir tout type d'interrogation défini, et inclure les options et données requises par le type d'interrogation choisi. Le demandeur envoie la taille du message puis envoie le message DHCPv6 réel, comme décrit au paragraphe 5.1.

Si la connexion TCP devient bloquée ou cesse d'être utilisable alors que le demandeur envoie son interrogation, le demandeur DEVRAIT être prêt à terminer la connexion après BULK_LQ_DATA_TIMEOUT. On fait cette recommandation pour permettre aux demandeurs de contrôler la période pendant laquelle il acceptent d'attendre avant d'abandonner une connexion, indépendamment des notifications provenant des mises en œuvre de TCP qu'ils peuvent utiliser.

 	6.3	Traitement des réponses
Le demandeur tente de lire un message LEASEQUERY-REPLY provenant de la connexion TCP. Si la connexion TCP cesse de livrer des données de réponse (si la connexion cesse d'être utilisable) le demandeur DEVRAIT être prêt à terminer la connexion après BULK_LQ_DATA_TIMEOUT, et PEUT commencer le traitement de réessai si il est configuré à le faire

Le demandeur examine le message LEASEQUERY-REPLY, et détermine comment procéder. Les règles de validation de message sont spécifiées dans Leasequery DHCPv6 [RFC5007]. Si la réponse contient un code d'état d'erreur (porté dans une option OPTION_STATUS_CODE) le demandeur suit les recommandations de la [RFC5007]. Une réponse de succès qui ne comporte pas d'option OPTION_CLIENT_DATA indique que le serveur cible n'a pas de liens qui correspondent à l'interrogation.

Note : le protocole Leasequery utilise l'option OPTION_CLIENT_LINK comme indicateur que plusieurs liens sont présents en réponse à une seule interrogation. Pour Leasequery en vrac, l'option OPTION_CLIENT_LINK n'est pas utilisée, et NE DOIT PAS être présente dans les réponses.

Une LEASEQUERY-REPLY de succès qui retourne des données de lien inclut une option OPTION_CLIENT_DATA et éventuellement des options supplémentaires. Si il n'y a pas de liens supplémentaires à retourner, elles vont être portées dans des messages LEASEQUERY-DATA. Chaque message LEASEQUERY-DATA contient une option OPTION_CLIENT_DATA, et éventuellement d'autres options. Un message LEASEQUERY-DATA qui ne contient pas une OPTION_CLIENT_DATA DOIT être éliminé.

Une seule interrogation en vrac peut résulter en un grand nombre de réponses. Par exemple, un seul agent de relais pourrait être responsable de chemins pour des milliers de préfixes délégués de clients. Le demandeur DOIT être prêt à recevoir plus d'une LEASEQUERY-DATA avec des identifiants de transaction correspondant à un seul message LEASEQUERY.

Le message LEASEQUERY-DONE termine une demande Leasequery en vrac réussie qui a retourné au moins un lien. Une LEASEQUERY-REPLY sans aucun lien NE DOIT PAS être suivie par un message LEASEQUERY-DONE pour le même identifiant de transaction. Après la réception d'un LEASEQUERY-DONE d'un serveur, le demandeur PEUT clore la connexion TCP à ce serveur. Si l'identifiant de transaction dans le LEASEQUERY-DONE ne correspond pas à un message LEASEQUERY en instance, le client DOIT clore la connexion TCP.

 	6.3.1	Achèvement de la réponse
La réponse à une demande Leasequery en vrac est complète (c'est-à-dire, aucun autre message pour cet identifiant de transaction de demande ne va être reçu) quand une des conditions suivantes est satisfaite :
1.	si le message LEASEQUERY-REPLY n'avait pas d'option OPTION_CLIENT_DATA, quand la LEASEQUERY-REPLY est reçue,
2.	autrement, si la LEASEQUERY-REPLY avait une OPTION_CLIENT_DATA, quand le message correspondant LEASEQUERY-DONE est reçu,
3.	autrement, quand la connexion est close.

 	6.4	Interrogation de plusieurs serveurs
Un client Leasequery en vrac PEUT être configuré à tenter de se connecter et interroger plusieurs serveurs DHCPv6 en parallèle. La spécification Leasequery DHCPv6 [RFC5007] inclut une discussion sur la réconciliation des données de lien reçues de plusieurs serveurs DHCPv6.

 	6.5	Plusieurs interrogations à une seul serveur
Les clients de Leasequery en vrac peuvent avoir besoin de faire plusieurs interrogations afin de récupérer les informations de lien. Un demandeur PEUT utiliser une seule connexion pour produire plusieurs interrogations. Chaque interrogation DOIT avoir un identifiant de transaction unique. Un serveur PEUT traiter plus d'une interrogation à la fois. Un serveur qui veut faire ainsi PEUT entrelacer les réponses aux multiples interrogations dans le flux des messages de réponse qu'il envoie. Les clients doivent savoir que les réponses pour plusieurs interrogations peuvent être entrelacées au sein du flux de messages de réponse. Les clients qui ne sont pas capables de traiter les réponses entrelacées (sur la base de l'identifiant de transaction) NE DOIVENT PAS envoyer plus d'une interrogation à la fois. Les demandeurs devraient savoir que les serveurs ne sont pas obligés de traiter les interrogations en parallèle, et que les serveurs vont probablement limiter le taux de traitement des interrogations provenant de tout demandeur.

 	6.5.1	Exemple
Cet exemple illustre ce à quoi pourait ressembler une série d'interrogations et de réponses. Ceci est seulement un exemple -- il n'y a pas d'exigence que cette séquence soit suivie, ou que les clients ou serveurs doivent prendre en charge des interrogations en parallèle.

Dans l'exemple de session, le client envoie quatre interrogations après avoir établi une connexion ; "xid" note un identifiant de transaction dans le diagramme. L'interrogation 1 résulte en un échec ; l'interrogation 2 réussit et le flux de réponses se conclut avant que le client produise de nouvelles interrogations. L'interrogation 3 et l'interrogation 4 se chevauchent, et le serveur entrelace ses réponses aux deux interrogations.

        Client	Serveur
        LEASEQUERY xid 1 ----->
                         <-----       LEASEQUERY-REPLY xid 1 (w/erreur)
        LEASEQUERY xid 2 ----->
                         <-----       LEASEQUERY-REPLY xid 2
                         <-----       LEASEQUERY-DATA xid 2
                         <-----       LEASEQUERY-DATA xid 2
                         <-----       LEASEQUERY-DONE xid 2
        LEASEQUERY xid 3 ----->
        LEASEQUERY xid 4 ----->
                         <-----       LEASEQUERY-REPLY xid 4
                         <-----       LEASEQUERY-DATA xid 4
                         <-----       LEASEQUERY-REPLY xid 3
                         <-----       LEASEQUERY-DATA xid 4
                         <-----       LEASEQUERY-DATA xid 3
                         <-----       LEASEQUERY-DONE xid 3
                         <-----       LEASEQUERY-DATA xid 4
                         <-----       LEASEQUERY-DONE xid 4

 	6.6	Clôture de connexions
Le demandeur PEUT clore son extrémité de la connexion TCP après l'envoi d'un message LEASEQUERY au serveur. Le demandeur PEUT choisir de conserver la connexion si il a l'intention de produire des interrogations supplémentaires. Noter que ce comportement de client ne garantit pas que la connexion va être disponible pour des interrogations supplémentaires : le serveur pourrait décider de clore la connexion sur la base de sa propre configuration.

 	7.	Comportement du serveur
 	7.1	Acceptation des connexions
Les serveurs qui mettent en œuvre Leasequery DHCPv6 en vrac écoutent les connexions TCP entrantes. Les numéros d'accès sont discutés au paragraphe 5.6. Les serveurs DOIVENT être capables de limiter le nombre de connexions actuellement acceptées et actives. La valeur BULK_LQ_MAX_CONNS DOIT être celle par défaut ; les mises en œuvre PEUVENT permettre que la valeur soit configurable.

Les serveurs PEUVENT restreindre les connexions Leasequery en vrac et les messages LEASEQUERY à certains clients. Les connexions qui ne sont pas de clients permis DEVRAIENT être closes immédiatement, pour éviter l'épuisement des ressources de connexion du serveur. Les serveurs PEUVENT restreindre certains clients à certains types d'interrogation. Les serveurs PEUVENT répondre aux interrogations qui ne sont pas permises avec le code d'état NotAllowed (Interdit) [RFC5007], et/ou clore la connexion.

Si la connexion TCP devient bloquée alors que le serveur accepte une connexion ou lit une interrogation, il DEVRAIT être prêt à terminer la connexion après BULK_LQ_DATA_TIMEOUT. On fait cette recommandation pour permettre aux serveurs de contrôler la durée d'attente qu'ils acceptent avant d'abandonner une connexion inactive, indépendamment des mises en œuvre TCP qu'ils peuvent être en train d'utiliser.

 	7.2	Formation des réponses
La spécification DHCPv6 Leasequery [RFC5007] décrit la construction initiale des messages LEASEQUERY-REPLY et le traitement de QUERY_BY_ADDRESS et QUERY_BY_CLIENTID. L'utilisation des messages LEASEQUERY-REPLY et LEASEQUERY-DATA pour porter plusieurs liens est décrite au paragraphe 5.2. La transmission et le tramage de message pour TCP est décrite au paragraphe 5.1. Si la connexion devient bloquée alors que le serveur tente d'envoyer des messages de réponse, le serveur DEVRAIT être prêt à terminer la connexion TCP après BULK_LQ_DATA_TIMEOUT.

Si le serveur rencontre une erreur durant le traitement initial de l'interrogation, avant qu'une réponse ait été envoyée, il DEVRAIT envoyer un LEASEQUERY-REPLY contenant un code d'erreur dans une option OPTION_STATUS_CODE. Cela signale au demandeur qu'aucune donnée ne va être retournée. Si le serveur rencontre une erreur alors qu'il traite une interrogation qui a déjà résulté en un ou plusieurs messages de réponse, le serveur DEVRAIT envoyer un message LEASEQUERY-DONE avec un état d'erreur. Le serveur DEVRAIT clore son extrémité de la connexion comme indication qu'il n'a pas été capable d'achever le traitement de l'interrogation.

Si le serveur ne trouve pas de liens qui satisfassent une interrogation, il DEVRAIT envoyer un LEASEQUERY-REPLY sans option OPTION_STATUS_CODE et sans option OPTION_CLIENT_DATA. Autrement, le serveur envoie chaque données de lien dans un message de réponse. Le premier message de réponse est une LEASEQUERY-REPLY. Les données de lien sont portées dans une option OPTION_CLIENT_DATA, comme spécifié dans la [RFC5007] et étendu ci-dessous. Le serveur retourne les liens suivants dans des messages LEASEQUERY-DATA, qui peuvent éviter des données redondantes (comme l'identifiant de client du demandeur).

Pour QUERY_BY_RELAY_ID, le serveur localise chaque lien associé à la valeur d'option Identifiant de relais de l'interrogation. Afin de donner une réponse significative à un QUERY_BY_RELAY_ID, le serveur doit être capable de conserver cette association dans ses données de lien DHCPv6. Si l'adresse de liaison de l'interrogation n'est pas réglée à 0::0, le serveur retourne seulement les liens sur les liaisons qui pourraient contenir cette adresse. Si l'adresse de lien n'est pas 0::0 et si le serveur ne peut pas trouver de liaisons correspondantes, le serveur DEVRAIT retourner l'état NotConfigured dans une LEASEQUERY-REPLY.

Pour QUERY_BY_LINK_ADDRESS, le serveur localise chaque lien associé au lien identifié par la valeur de l'adresse de lien de l'interrogation.

Pour QUERY_BY_REMOTE_ID, le serveur localise chaque lien associé à la valeur d'option Identifiant distant de relais de l'interrogation. Afin d'être capable de donner des réponses significatives à cette interrogation, le serveur doit être capable de conserver cette association dans sa base de données de liens. Si l'adresse de liaison du messge d'interrogation n'est pas réglée à 0::0, le serveur retourne seulement les liens sur les liaisons qui pourraient contenir cette adresse. Si l'adresse de lien n'est pas 0::0 et si le serveur ne peut pas trouver de liaisons correspondantes, le serveur DEVRAIT retourner l'état NotConfigured dans une LEASEQUERY-REPLY.

Le serveur envoie le message LEASEQUERY-DONE comme spécifié au paragraphe 5.2.

 	7.3	Interrogations multiples ou parallèles
Comme discuté au paragraphe 6.5, les demandeurs peuvent vouloir s'appuyer sur une connexion existante si ils ont besoin de faire plusieurs interrogations. Les serveurs PEUVENT prendre en charge de lire et traiter plusieurs interrogations provenant d'une seule connexion. Un serveur NE DOIT PAS lire plus de messages d'interrogation provenant d'une connexion que ce qu'il est prêt à traiter simultanément.

Ce PEUT être une caractéristique contrôlée administrativement. Les serveurs qui sont capables de traiter des interrogations en parallèle DEVRAIENT offrir une configuration qui limite le nombre d'interrogations simultanées permises à partir de tout demandeur, afin de contrôler l'utilisation des ressources si il y a plusieurs demandeurs qui recherchent le service.

 	7.4	 Clôture des connexions
Le serveur PEUT clore son extrémité de la connexion TCP après l'envoi de son dernier message (LEASEQUERY-REPLY ou LEASEQUERY-DONE) en réponse à une interrogation. Autrement, le serveur PEUT conserver la connexion et attendre des interrogations supplémentaires du client. Le serveur DEVRAIT être prêt à limiter le nombre de connexions qu'il maintient, et DEVRAIT être prêt à clore les connexions inactives pour appliquer la limite.

Le serveur DOIT clore son extrémité de la connexion TCP si il rencontre une erreur d'envoi de données sur la connexion. Le serveur DOIT clore son extrémité de la connexion TCP si il trouve qu'il doit interrompre une demande en cours de traitement. Un serveur qui interrompt une demande en cours de traitement PEUT tenter de le notifier à ses clients en utilisant le code d'état QueryTerminated (paragraphe 5.5). Si le serveur détecte que l'extrémité du client a été close, le serveur DOIT clore son extrémité de la connexion après qu'il a fini de traiter les demandes en instance de ce client.

 	8.	Considérations sur la sécurité

La section "Considérations sur la sécurité" de la [RFC3315] détaille les menaces générales pour DHCPv6. La spécification Leasequery DHCPv6 [RFC5007] décrit les recommandations pour le protocole Leasequery, en particulier à l'égard des messages LEASEQUERY relayés, de l'atténuation des attaques de déni de service par inondation de paquets, de la restriction aux clients de confiance, et de l'utilisation de IPsec [RFC4301].

L'utilisation de TCP introduit des problèmes supplémentaires. Les attaques qui tentent d'épuiser les ressources de connexion TCP disponibles pour le serveur DHCPv6, comme les attaques d'inondation de SYN, peuvent compromettre la capacité des clients légitimes à recevoir le service. Des clients malveillants qui réussissent à établir des connexions, mais qui envoient alors des interrogations invalides, des interrogations partielles, ou pas d'interrogation du tout, peuvent aussi épuiser le réservoir de connexions disponibles d'un serveur. On recommande que les serveurs offrent une configuration pour limiter les sources de connexions entrantes, qu'ils limitent le nombre de connexions acceptées et le nombre d'interrogations en cours provenant de toute connexion, et qu'ils limitent la durée pendant laquelle une connexion inactive va être laissée ouverte.

 	9.	Considérations relatives à l’IANA

L'IANA a alloué une nouvelle valeur dans le registre des codes d'option DHCPv6 :

53 : OPTION_RELAY_ID

L'IANA a alloué une nouvelle valeur dans le registre des codes d'état DHCPv6 :

11 : QueryTerminated

L'IANA a alloué les valeurs suivantes dans le registre des types de message DHCPv6 :

16 : LEASEQUERY-DONE
17 : LEASEQUERY-DATA

L'IANA a alloué les valeurs suivantes dans le registre des types d'interrogation pour l'option DHCPv6 OPTION_LQ_QUERY :

3 : QUERY_BY_RELAY_ID
4 : QUERY_BY_LINK_ADDRESS
5 : QUERY_BY_REMOTE_ID

Les registres sus-mentionnés sont disponibles à http://www.iana.org.

 	10.	Remerciements

Beaucoup des idées de ce document ont été proposées à l'origine par Kim Kinnear, Richard Johnson, Hemant Singh, Ole Troan, et Bernie Volz. D'autres suggestions et améliorations ont été faites par les participants au groupe de travail DHC, incluant John Brzozowski, Marcus Goller, Alfred Hoenes, Ted Lemon, Bud Millwood, et Thomas Narten.

 	11.	Références
 	11.1	Références normatives

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

[RFC3315]	R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins et M. Carney, "Protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6)", juillet 2003. (MàJ par RFC6422 et RFC6644, RFC7227 ; rendue obsolète par RFC8415)

[RFC3633]	O. Troan, R. Droms, "Options de préfixes IPv6 pour le protocole de configuration dynamique d'hôte (DHCP) version  6", décembre 2003. (P.S. ; MàJ par la RFC6603 ; Obsolète voir RFC8415)

[RFC4649]	B. Volz, "Option d'identifiant distant d'agent de relais du protocole de configuration dynamique d'hôte for IPv6 (DHCPv6)", août 2006. (P.S.)

[RFC5007]	J. Brzozowski et autres, "Leasequery dans DHCPv6", septembre 2007. (P.S.)

 	11.2	Références pour information

[RFC4301]	S. Kent et K. Seo, "Architecture de sécurité pour le protocole Internet", DOI 10.17487/RFC4301, décembre 2005. (P.S.) (Remplace la RFC2401)

[RFC4614]	M. Duke et autres, "Feuille de route pour les documents de spécification du protocole de contrôle de transmission (TCP)", septembre 2006. (Information)

 	Adresse de l'auteur

Mark Stapp
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA  01719
USA
téléphone : +1 978 936 0000
mél : mjs@cisco.com