Network Working Group S

Sous option Authentification pour l'option
d'agent de relais du protocole de configuration dynamique d'hôte (DHCP)

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

L'option Informations d'agent de relais du protocole de configuration dynamique d'hôte (DHCP, Dynamic Host Configuration Protocol) [RFC3046] convoie les informations entre l'agent de relais DHCP et un serveur DHCP. La présente spécification définit une sous option d'authentification pour cette option, contenant un hachage chiffré dans sa charge utile. La sous option prend en charge la protection de l'intégrité des données et contre la répétition pour les messages DHCP relayés.

Table des Matières

1. Introduction

2. Terminologie des exigences

3. Terminologie DHCP

4. Format de sous option

5. Détection de répétition

6. Champ Identifiant de relais

7. Calcul des informations d'authentification

7.1 Algorithme HMAC-SHA1

8. Procédures d'envoi des messages

8.1 Détection de répétition

8.2 Préparation de paquet

8.3 Calcul de somme de contrôle

8.4 Envoi du message

9. Procédures de traitement des messages entrants

9.1 Examen initial

9.2 Vérification de détection des répétitions

9.3 Vérification de la somme de contrôle

10. Comportement de l'agent de relais

10.1 Réception de messages d'autres agents de relais

10.2 Envoi des messages aux serveurs

10.3 Réception des messages des serveurs

11. Comportement du serveur DHCP

11.1 Réception des messages des agents de relais

11.2 Envoi des messages de réponse aux agents de relais

12. Considérations relatives à l'IANA

13. Considérations sur la sécurité

13.1 Champ Identifiant de clé

13.2 Vulnérabilités du protocole

14. Remerciements

15. Références

15.1 Références normatives

15.2 Références pour information

Adresse des auteurs

Déclaration des droits de reproduction

DHCP [RFC2131] fournit des adresses IP et des informations de configuration pour les clients IPv4. Il inclut une capacité d'agent de relais [RFC0951], [RFC1542] dans laquelle des processus au sein de l'infrastructure réseau reçoivent des messages en diffusion provenant des clients et les transmettent aux serveurs comme messages en envoi individuel. Dans des environnements de réseau tels que les données sur câble DOCSIS et xDSL, par exemple, il s'est révélé utile pour l'agent de relais d'ajouter des informations au message DHCP avant de le transmettre, en utilisant l'option d'informations d'agent de relais [RFC3046]. La sorte d'informations qu'ajoutent les relais est souvent utilisée dans la prise de décision du serveur sur les adresses et les paramètres de configuration que le client devrait recevoir. La façon dont les données d'agent de relais sont utilisées dans la prise de décision du serveur tend à rendre ces données très importantes, et elle souligne l'importance des relations de confiance entre l'agent de relais et le serveur.

La spécification d'authentification DHCP existante [RFC3118] couvre seulement la communication entre le client et le serveur DHCP. Parce que des informations d'agent de relais sont ajoutées après que le client a envoyé son message, la spécification de l'authentification DHCP exclut explicitement les données d'agent de relais de cette authentification.

Le but de la présente spécification est de définir les méthodes qu'un agent de relais peut utiliser pour

Pour atteindre ces objectifs, on spécifie une nouvelle sous option d'agent de relais, la sous option d'authentification. Le format de cette sous option est très similaire à celui de l'option Authentification DHCP, et la spécification de ses méthodes de chiffrement et de calcul de hachage est aussi similaire.

La sous option d'authentification est incluse par les agents de relais qui cherchent à s'assurer de l'intégrité des données qu'ils incluent dans l'option Agent de relais. Ces agents de relais sont configurés avec les paramètres nécessaires pour générer des sommes de contrôle cryptographiques des données dans les messages DHCP qu'ils transmettent aux serveurs DHCP. Un serveur DHCP configuré pour traiter la sous option d'authentification utilise les informations de la sous option pour vérifier la somme de contrôle dans la sous option et ne continue le traitement de l'option d'informations d'agent de relais que si la somme de contrôle est valide. Si le serveur DHCP envoie une réponse, il inclut une sous option d'authentification dans son message de réponse. Les agents de relais vérifient les sommes de contrôle dans les réponses de serveur DHCP pour décider si ils transmettent les réponses.

Dans le présent document, les mots clés 'DOIT', 'NE DOIT PAS', 'EXIGE', 'DEVRA', 'NE DEVRA PAS', 'DEVRAIT', 'NE DEVRAIT PAS', 'RECOMMANDE', 'PEUT', et 'FACULTATIF' sont à interpréter comme décrit dans la [RFC2119] et indiquent les niveaux d'exigence pour les mises en œuvre SIP conformes.

Le présent document utilise les termes "serveur DHCP" (ou "serveur") et "client DHCP" (ou "client") comme défini dans la [RFC2131]. Le terme "agent de relais DHCP" se réfère à un " agent de relais BOOTP" comme défini dans la RFC 2131.

Le code pour la sous option est 8. Le champ Longueur inclut les longueurs des champs Algorithme, RDM, et tous les champs suivants de sous option en octets.

Le champ Algorithme définit l'algorithme utilisé pour générer les informations d'authentification.

Les quatre bits du champ MBZ sont réservés pour une utilisation future. Ces bits DEVRAIENT être réglés à zéro et NE DOIVENT PAS être utilisés lors du traitement de la sous option.

Le champ RDM (Replay Detection Method, méthode de détection des répétitions) définit la méthode utilisée pour générer les données de détection de répétition.

Le champ Détection de répétition contient une valeur utilisée pour détecter les messages répétés, qui sont interprétés conformément à la méthode de détection de répétition (RDM).

Le champ Identifiant de relais est utilisé par les agents de relais qui n'établissent pas giaddr, comme décrit au paragraphe 2.1 de la [RFC3046].

Le champ Informations d'authentification contient les données requises pour communiquer les paramètres spécifiques de l'algorithme, ainsi que la somme de contrôle. La somme de contrôle est généralement un résumé des données du paquet DHCP calculé en utilisant la méthode spécifiée par le champ Algorithme.

Le mécanisme de détection de répétition se fonde sur la notion qu'un receveur peut déterminer si un message a une valeur de jeton de répétition valide. La RDM par défaut, de valeur 1, spécifie que le champ Détection de répétition contient une valeur de compteur croissante. Le receveur associe un compteur de répétition à chaque envoyeur et rejette tout message contenant une sous option Authentification avec une valeur de compteur de détection de répétition inférieure ou égale à la dernière valeur valide. Les serveurs DHCP PEUVENT identifier les agents de relais par la valeur de "giaddr" ou par d'autres données dans le message (par exemple, des données dans d'autres sous options d'agent de relais). Les agents de relais identifient les serveurs DHCP par l'adresse IP de source. Si la valeur de détection de répétition du message et la somme de contrôle sont valides, le receveur met à jour sa notion de dernière valeur de compteur de répétition valide associée à l'envoyeur.

Toutes les mises en œuvre DOIVENT prendre en charge la RDM par défaut. Des méthodes supplémentaires peuvent être définies à l'avenir, suivant le procès décrit à la Section 12.

Les receveurs DEVRAIENT effectuer la vérification de détection de répétition avant de vérifier la somme de contrôle. Le calcul du hachage chiffré sera vraisemblablement beaucoup plus coûteux que la vérification de la valeur de la détection de répétition.

Note : cela fait peser sur le receveur la charge de conserver l'état de démarrage (la plus récente valeur valide du compteur) pour chaque envoyeur, mais le nombre de membres dans un système agent-serveur DHCP ne sera jamais d'une taille ingérable.

La spécification de l'option Informations d'agent de relais [RFC3046] permet à un agent de relais d'ajouter une option d'agent de relais aux messages relayés sans établir le champ giaddr. Dans ce cas, le receveur final du message a besoin d'un identifiant stable afin d'associer un état par envoyeur comme l'identifiant de clé et les compteurs de détection de répétition.

Un agent de relais qui ajoute une option Informations d'agent de relais et établit giaddr NE DOIT PAS établir le champ Identifiant de relais. Un agent de relais qui n'établit pas giaddr PEUT être configuré à placer une valeur dans le champ Identifiant de relais. Si l'agent de relais est configuré à utiliser le champ Identifiant de relais, il PEUT être configuré avec une valeur à utiliser, ou il PEUT être configuré à générer une valeur fondée sur d'autres données, comme son adresse MAC ou IP. Si un relais génère une valeur d'identifiant de relais, il DEVRAIT choisir une valeur qu'il puisse régénérer de façon fiable; par exemple, à travers les réamorçages.

Les serveurs qui traitent une sous option Authentification DEVRAIENT utiliser la valeur giaddr pour identifier l'envoyeur si le champ giaddr est établi. Les serveurs PEUVENT être configurés à utiliser d'autres données dans le message pour identifier l'envoyeur. Si giaddr n'est pas établi, le serveur DEVRAIT utiliser le champ Identifiant de relais si il n'est pas à zéro. Si ni le champ giaddr ni le champ Identifiant de relais ne sont établis, le serveur PEUT être configuré à utiliser d'autres données dans le message, ou il PEUT incrémenter un compteur d'erreurs.

Le champ Informations d'authentification contient un hachage chiffré généré par l'envoyeur. Tous les algorithmes sont définis pour traiter de la même façon les données dans les messages DHCP. L'envoyeur et le receveur calculent un hachage sur une mémoire tampon contenant tous les octets du message DHCP, incluant l'en-tête fixe de message DHCP, les options DHCP, et les sous options d'agent de relais, avec les exceptions suivantes. La valeur du champ "hops" DOIT être réglée à zéro pour le calcul parce que sa valeur peut être changée dans la transmission. La valeur du champ 'giaddr' DOIT aussi être réglée à zéro pour le calcul parce que elle peut être modifiée dans les réseaux où un agent de relais ajoute l'option d'agent de relais mais un autre agent de relais établit "giaddr" (voir le paragraphe 2.1 de la [RFC3046]). De plus, comme l'option d'agent de relais est elle-même incluse dans le calcul, le champ Informations d'authentification dans la sous option d'authentification est réglé tout à zéro. La longueur d'option d'agent de relais, la longueur de la sous option d'authentification et les autres champs de sous option d'authentification sont tous inclus dans le calcul.

Toutes les mises en œuvre DOIVENT prendre en charge l'algorithme 1, l'algorithme HMAC-SHA1. Des algorithmes supplémentaires pourront être définis à l'avenir, suivant le processus décrit à la Section 12.

Le numéro d'algorithme 1 est alloué au protocole HMAC [RFC2104] en utilisant la fonction de hachage SHA-1 [RFC3174]. Cet algorithme exige qu'une clé secrète partagée soit configurée chez l'agent de relais et chez le serveur DHCP. Un identifiant de clé de 32 bits est associé à chaque clé partagée, et cet identifiant est porté dans les quatre premiers octets du champ Informations d'authentification de la sous option d'authentification. Le calcul HMAC-SHA1 génère une valeur de hachage de 20 octets , qui est placée dans le champ Informations d'authentification après l'identifiant de clé.

Lorsque l'algorithme 1 est utilisé, le format de la sous option d'authentification est le suivant :

La longueur de sous option est 38. Les champs RDM et Détection de répétition sont comme spécifié à la Section 5. Le champ Identifiant de relais est réglé comme spécifié Section 6. L'identifiant de clé est réglé par l'envoyeur à l'identifiant de la clé utilisée pour calculer la somme de contrôle, comme une valeur d'entier dans l'ordre des octets du réseau. Le résultat de HMAC suit l'identifiant de clé.

L'identifiant de clé n'existe que pour permettre à l'envoyeur et au receveur de spécifier un secret partagé dans les cas où plus d'un secret est en usage parmi les relais et serveurs DHCP d'un réseau. Les valeurs d'identifiant de clé sont entièrement l'affaire de la configuration locale ; leur unicité est seulement locale. La présente spécification ne définit aucune sémantique ni n'impose aucune exigence sur les valeurs d'identifiant de clé de cet algorithme.

L'envoyeur obtient une valeur de compteur de détection de répétition à utiliser sur la base de la RDM qu'il utilise. Si l'envoyeur utilise RDM 1, la RDM par défaut, la valeur DOIT être supérieure à toute valeur envoyée précédemment.

L'envoyeur règle les champs "giaddr" et "hops" tout à zéro. Il ajoute l'option Informations d'agent de relais au paquet du client, incluant la sous option d'authentification. L'envoyeur choisit une valeur appropriée de détection de répétition. Il place son identifiant dans le champ Identifiant de relais, si nécessaire, ou règle ce champ tout à zéro. Il règle la longueur de sous option, place la valeur de détection de répétition dans le champ Détection de répétition de la sous option, et règle le champ Algorithme au numéro d'algorithme qu'il utilise. Si l'envoyeur utilise HMAC-SHA1, il règle le champ Identifiant de clé à la valeur appropriée. L'envoyeur règle le champ qui va contenir la somme de contrôle tout à zéro. D'autres algorithmes peuvent spécifier des étapes de préparation supplémentaires.

L'envoyeur calcule la somme de contrôle sur le message DHCP entier, en utilisant l'algorithme qu'il a choisi. Il place le résultat du calcul dans le champ Informations d'authentification de la sous option d'authentification.

L'envoyeur restaure les valeurs des champs "hops" et "giaddr" et envoie le message.

Le receveur examine le message à la recherche du champ "giaddr" et détermine si le paquet comporte l'option Informations d'agent de relais. Il utilise sa configuration pour déterminer si il devrait attendre une sous option d'authentification. Le receveur DOIT prendre en charge une configuration qui lui permet d'éliminer les messages entrants qui ne contiennent pas une option Informations d'agent de relais valide et la sous option d'authentification.

Si le receveur détermine que la sous option d'authentification est présente et qu'il devrait traiter la sous option, il utilise les données du message pour déterminer quels algorithmes, clés, et RDM utiliser pour valider le message. Si le receveur ne peut pas déterminer quel algorithme, clé, et RDM utiliser, ou si il ne prend pas en charge la valeur indiquée dans le message, il DEVRAIT éliminer le message. Comme cette situation pourrait indiquer une mauvaise configuration qui pourrait dénier le service aux clients, les receveurs PEUVENT tenter de le notifier à leurs administrateurs ou d'enregistrer un message d'erreur.

Le receveur examine le champ RDM. Les receveurs DOIVENT éliminer les messages contenant des valeurs de RDM qu'ils ne prennent pas en charge. Parce que cela peut indiquer une mauvaise configuration chez l'envoyeur, une tentative DEVRAIT être faite pour indiquer cette condition à l'administrateur en incrémentant un compteur d'erreurs ou en écrivant un message dans un journal d'événements. Si le receveur prend en charges la RDM, il examine la valeur du champ Détection de répétition en utilisant les procédures de la RDM et de la Section 5. Si la valeur n'est pas valide, le receveur DOIT éliminer le message.

Note qu'à ce moment, le receveur NE DOIT PAS mettre à jour sa notion de la dernière valeur valide de détection de répétition pour l'envoyeur. Tant que la somme de contrôle n'a pas été vérifiée, le champ Détection de répétition ne peut pas être de confiance. Si le receveur se fie à la valeur de Détection de répétition sans vérifier la somme de contrôle, un hôte malveillant pourrait envoyer un message répété avec une valeur de détection de répétition qui serait très élevée, amenant le receveur à rejeter les valeurs légitimes provenant de l'envoyeur.

Le receveur prépare le paquet afin de vérifier la somme de contrôle en réglant les champs "giaddr" et "hops" à zéro, et en réglant le champ Informations d'authentification de la sous option tout à zéro. En utilisant l'algorithme et la clé associés à l'envoyeur, le receveur calcule un hachage du message. Il compare le résultat de son calcul à la valeur envoyée. Si les sommes de contrôle ne correspondent pas, le receveur DOIT éliminer le message. Autrement, le receveur met à jour sa notion de dernière valeur valide de détection de répétition associée à l'envoyeur et traite le message.

Les agents de relais DHCP sont normalement configurés avec les adresses d'un ou plusieurs serveurs DHCP. Un agent de relais qui met en œuvre cette sous option requiert un numéro d'algorithme pour chaque serveur, ainsi que des accréditifs appropriés (c'est-à-dire, des clés). Les mises en œuvre de relais DEVRAIENT prendre en charge une configuration qui indique que tous les messages relayés devraient inclure la sous option d'authentification. L'utilisation de la sous option d'authentification DEVRAIT être désactivée par défaut. Les agents de relais PEUVENT prendre en charge une configuration qui indique que certains serveurs de destination prennent en charge la sous option d'authentification et que d'autres serveurs ne le font pas. Les agents de relais PEUVENT prendre en charge la configuration d'un seul numéro d'algorithme et d'une seule clé à utiliser avec tous les serveurs DHCP, ou ils PEUVENT prendre en charge la configuration de différents algorithmes et clés pour chaque serveur.

Il y a des configurations de réseau dans lesquelles un agent de relais ajoute l'option d'agent de relais et ensuite transmet le message DHCP à un autre agent de relais. Par exemple, un commutateur de couche 2 peut être directement connecté à un client, et il peut transmettre des messages à un routeur d'agrégation, qui règle giaddr et transmet ensuite le message à un serveur DHCP. Lorsque un relais DHCP qui met en œuvre la sous option d'authentification reçoit un message, il PEUT utiliser les procédures de la Section 9 pour vérifier la source du message avant de le transmettre.

Lorsque l'agent de relais reçoit un paquet en diffusion provenant d'un client, il détermine quels serveurs DHCP (ou autres agents de relais) devraient recevoir des copies du message. Si l'agent de relais est configuré à inclure la sous option d'authentification, il détermine quels algorithmes et RDM utiliser, et ensuite il effectue les étapes de la Section 8.

Lorsque l'agent de relais reçoit un message, il détermine à partir de sa configuration si il s'attend à ce que le message contienne une option Informations d'agent de relais et une sous option Authentification. L'agent de relais PEUT être configuré à abandonner les messages de réponse qui ne contiennent pas la sous option d'authentification. L'agent de relais suit alors les procédures de la Section 9.

Les serveurs DHCP peuvent interagir avec plusieurs agents de relais. Les mises en œuvre de serveur PEUVENT prendre en charge une configuration qui associe le même algorithme et clé avec tous les agents de relais. Les serveurs PEUVENT prendre en charge une configuration qui spécifie l'algorithme et la clé à utiliser individuellement avec chaque agent de relais.

Lorsque un serveur DHCP qui met en œuvre la sous option d'authentification reçoit un message, il effectue les étapes de la Section 9.

Lorsque le serveur a préparé un message de réponse, il utilise le message de demande entrant et sa configuration pour déterminer si il devrait inclure une option Information d'agent de relais et une sous option Authentification. Si le serveur est configuré à inclure la sous option d'authentification, il détermine quel algorithme et RDM utiliser puis effectue les étapes de la Section 8.

Note : ce comportement de serveur représente un légère différence avec le paragraphe 2.2 de la [RFC3046]. Il n'est pas fait écho à la sous option d'authentification du serveur au relais ; le serveur génère sa propre sous option.

La Section 4 définit une nouvelle sous option de l'option d'agent de relais DHCP appelée sous option d'authentification. L'IANA a alloué un nouveau code de sous option dans l'espace de numéros de sous option de l'option Agent de relais.

La présente spécification introduit deux nouveaux espaces de numéros pour les champs "Algorithme" et "Méthode de détection de répétition" de la sous option d'authentification. Ces espaces de numéros ont été créés et seront tenus par l'IANA.

L'identifiant d'algorithme est une valeur d'un octet. La valeur d'algorithme 0 est réservée. La valeur d'algorithme 1 est allouée au hachage chiffré HMAC-SHA1, comme défini au paragraphe 7.1. Des valeurs d'algorithme supplémentaires seront allouées et affectées par consensus de l'IETF, comme défini dans la [RFC2434].

L'identifiant de RDM est une valeur de quatre bits. La valeur de RDM 0 est réservée. La valeur de RDM 1 est affectée à l'utilisation d'une valeur de compteur à croissance monotone, comme défini à la Section 5. Des valeurs de RDM supplémentaires seront allouées et affectées par consensus de l'IETF, comme défini dans la [RFC2434].

La présente spécification décrit un protocole qui ajoute la protection de l'authentification de la source et de l'intégrité du message aux messages entre agents de relais et serveurs DHCP.

L'utilisation de ce protocole impose une nouvelle charge de calcul aux agents de relais et serveurs, parce qu'ils doivent effectuer des calculs de hachage cryptographique lorsque ils envoient et reçoivent des messages. Cette charge peut ajouter de la latence aux échanges de messages DHCP. Parce que les agents de relais sont impliqués lorsque les clients réamorcent, les périodes de très forte activité de réamorçage vont résulter en un plus grand nombre de messages à traiter. Durant un événement de réamorçage d'extrémité de tête de câble MSO, par exemple, le temps nécessaire pour que tous les clients soient servis peut augmenter.

La sous option d'authentification contient un identifiant de clé de quatre octets, suivant l'exemple de la RFC sur l'authentification DHCP. D'autres protocoles d'authentification, comme DNS TSIG [RFC2845], utilisent un nom de clé. Un nom de clé est plus souple et potentiellement plus lisible par l'homme qu'un identifiant de clé. Les serveurs DHCP peuvent bien être configurés à utiliser des noms de clé pour les mises à jour du DNS en utilisant TSIG, de sorte que cela peut simplifier la configuration de serveur DHCP si la gestion de clé pour les deux protocoles pouvait être partagée.

D'un autre côté, il est crucial de minimiser l'expansion de taille causée par l'introduction de l'option Informations d'agent de relais. Des noms de clé exigeraient plus d'espace physique et cela entraînerait un codage plus complexe des sous option et d'analyse par les mises en œuvre. Ces considérations ont conduit à spécifier un identifiant de clé de longueur fixe plutôt qu'un nom de clé de longueur variable.

Parce que DHCP est un protocole UDP, les messages entre relais et serveurs peuvent être livrés dans un ordre différent de celui dans lequel ils sont générés. Le mécanisme de détection de répétition causera l'abandon par les receveurs des paquets qui sont livrés "en retard", conduisant le client à réessayer. Le mécanisme de répétition d'essai que mettent en œuvre la plupart des clients ne devrait pas causer d'énormes problèmes, mais il sera cause que les envoyeurs effectueront un travail de calcul qui sera perdu si l'ordre de leurs messages est changé.

Le groupe de travail DHC a développé deux documents décrivant l'authentification des options d'agent de relais DHCP pour s'accommoder des exigences des différents scénarios de déploiement : le présent document et "Authentification des options d'agent de relais en utilisant IPsec" [11]. Comme on le note à la Section 11, la sous option d'authentification peut être utilisée sans clés appariées entre chaque relais et serveur DHCP. Dans les déploiements où IPsec est déjà disponible et où des clés appariées peuvent être efficacement gérées, l'utilisation de IPsec comme décrite dans ce document peut être appropriée. Si IPsec n'est pas disponible ou si il y a plusieurs agents de relais pour lesquels plusieurs clés doivent être gérées, le protocole décrit dans le présent document peut être approprié. Comme c'est le cas chaque fois que deux solutions sont disponibles, l'administration de réseau locale peut choisir laquelle est la plus appropriée. Parce que les agents de relais et le serveur DHCP sont tous dans le même domaine administratif, le mécanisme approprié peut être configuré sur tous les élément de serveur DHCP qui inter opèrent.

La nécessité de la présente spécification a été rendue claire par les commentaires de Thomas Narten et John Schnizlein, et l'utilisation du format de l'option d'authentification DHCP a été suggérée par Josh Littlefield, à l'IETF 53.

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

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

[RFC3174] D. Eastlake 3 et P. Jones, "Algorithme US de hachage sécurisé n° 1 (SHA1)", septembre 2001. (Info, MàJ par 4634 et 6234)

[RFC1542] W. Wimer, "Précisions et extensions au protocole Boostrap", octobre 1993. (D.S.)

[11] Droms, R., "Authentication of Relay Agent Options Using IPsec", Travail en cours, février 2004.

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

Le présent document et les informations qui y sont contenues sont fournis 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 viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

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

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

Groupe de travail Réseau	M. Stapp, Cisco Systems
Request for Comments : 4030	T. Lemon, Nominum, Inc.
Catégorie : En cours de normalisation	mars 2005
Traduction Claude Bière de L'Isle

Mark Stapp	Ted Lemon
Cisco Systems, Inc.	Nominum, Inc.
1414 Massachusetts Ave.	950 Charter St.
Boxborough, MA 01719	Redwood City, CA 94063
USA	USA
téléphone : 978.936.0000	mél : Ted.Lemon@nominum.com
mél : mjs@cisco.com