Groupe de travail Réseau	B. Volz, Cisco Systems, Inc.	
Request for Comments : 4580	juin 2006	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Option d'identifiant d'abonné d'agent de relais du protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de 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 Copyright
Copyright (C) The Internet Society (2006).

Résumé
Le présent mémoire définit une nouvelle option Identifiant d'abonné d'agent de relais pour le protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6). L'option permet à un agent de relais DHCPv6 d'associer un "Identifiant d'abonné" stable à des messages de client DHCPv6 d'une façon indépendante du client et de l'infrastructure du réseau physique sous-jacent.
Table des matières
1. Introduction	1
2. Option Identifiant d'abonné d'agent de relais	1
3. Comportement de l'agent de relais DHCPv6	2
4. Comportement du serveur DHCPv6	2
5. Considérations sur la sécurité	2
6 Considérations relatives à l'IANA	3
7. Remerciements	3
8. Références	3
8.1 Référence normative	3
8.2 Références pour information	3
Adresse de l'auteur	3
Déclaration complète de droits de reproduction	3

 	1.	Introduction

DHCPv6 [RFC3315] fournit des adresses IP et des informations de configuration pour les clients IPv6. Il inclut une capacité d'agent de relais, dans lequel les processus au sein de l'infrastructure réseau reçoivent des messages de diffusion groupée des clients et les relayent aux serveurs DHCPv6. Dans certains environnements de réseau, il sera utile à l'agent de relais d'ajouter des informations au message DHCPv6 avant de le relayer.

Les informations que les agents de relais fournissent peuvent aussi être utilisées dans la prise de décision du serveur sur les adresses, les préfixes délégués [RFC3633], et les paramètres de configuration que le client va recevoir.

Dans de nombreux environnements de fournisseur de service, on estime qu'il est souhaitable d'associer des informations spécifiques du fournisseur aux mesages DHCPv6 des clients qui soient indépendantes de la configuration physique du réseau et que l'agent de relais a apprises par des moyens qui sortent du domaine d'application du présent mémoire.

 	2.	Option Identifiant d'abonné d'agent de relais

Dans des environnements de fournisseur de service complexes, il est besoin de connecter une configuration DHCPv6 d'un consommateur avec les informations administratives du consommateur. L'option Identifiant d'abonné d'agent de relais porte une valeur qui peut être indépendante de la configuration physique du réseau à travers lequel l'abonné est connecté. Cette valeur complète, et peut être utilisée en plus, des informations fondées sur le réseau. Le "identifiant d'abonné" alloué par le fournisseur est destiné à être stable lorsque les consommateurs se connectent à travers différents chemins, et lorsque se produisent des changements de réseau.

Les informations d'identifiant d'abonné permettent au fournisseur de service d'allouer/activer des actions spécifiques de l'abonné ; par exemple, l'allocation d'adresses IP spécifiques, de préfixes, de configuration DNS, de déclencher la comptabilité, etc. Cette option est découplée de la structure physique du réseau d'accès, de sorte qu'un abonné qui se déplace d'un point d'accès à un autre, par exemple, ne va pas exiger de reconfiguration dans les serveurs DHCPv6 du fournisseur de services.

Les informations d'identifiant d'abonné sont seulement destinées à être utilisées au sein d'un seul domaine administratif et sont seulement échangées entre les agents de relais et les serveurs DHCPv6 au sein de ce domaine. Donc, le format et le codage des données de l'option ne sont pas normalisés, et la présente spécification n'établit aucune exigence de sémantique sur les données. La présente spécification définit seulement l'option pour convoyer ces informations des agents de relais aux serveurs DHCPv6.

Cependant, comme la sous option Identifiant d'abonné DHCPv4 [RFC3993] spécifie des données codées dans le code standard américain pour les échanges d’informations (ASCII, American Standard Code for Information Interchange) [RFC0854] de terminal réseau virtuel (NVT, Network Virtual Terminal) il peut être avantageux d'utiliser ce codage dans les environnements où DHCPv4 [RFC2131] et DHCPv6 sont tous deux utilisés,.

Le format de l'option Identifiant d'abonné d'agent de relais DHCPv6 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_SUBSCRIBER_ID      |      Longueur d'option        |
+---------------+---------------+---------------+---------------+
.                                                               .
.                     Identité d'abonné                         .
.                                                               .
+---------------+---------------+---------------+---------------+

OPTION_SUBSCRIBER_ID  : code d'option  : 38

Longueur d'option  : longueur, en octets, du champ Identifiant d'abonné. La longueur minimum est 1 octet.

Identité d'abonné  : identité de l'abonné.

 	3.	Comportement de l'agent de relais DHCPv6

Les agents de relais DHCPv6 peuvent être configurés à inclure une option Identifiant d'abonné dans les messages DHCPv6 relayés (RELAY-FORW). Comment l'identifiant d'abonné est alloué et les mécanismes utilisés pour le configurer sortent du domaine d'application de ce mémoire.

 	4.	Comportement du serveur DHCPv6

Cette option fournit des informations supplémentaires au serveur DHCPv6. Le serveur DHCPv6 peut utiliser ces informations, si elles sont disponibles, en plus des autres données d'option d'agent de relais, des autres options incluses dans les messages de client DHCPv6, et des informations de topologie de réseau physique, afin d'allouer des adresses IP, déléguer des préfixes, et/ou d'autres paramètres de configuration au client. Il n'y a pas de traitement supplémentaire particulier pour cette option.

Il n'est pas exigé qu'un serveur retourne cette option et ses données dans un message RELAY-REPLY.

 	5.	Considérations sur la sécurité

Comme l'option Identifiant d'abonné est seulement échangée entre les agents de relais et les serveurs DHCPv6, le paragraphe 21.1 de la [RFC3315] fournit des détails sur la sécurisation des messages DHCPv6 envoyés entre les serveurs et les agents de relais. La Section 23 de la [RFC3315] donne les considérations de sécurité générales pour DHCPv6.

 	6	Considérations relatives à l'IANA

L'IANA a alloué un code d'option DHCPv6 (38) pour l'option Identifiant d'abonné d'agent de relais.

 	7.	Remerciements

Merci à Richard Johnson, Theyn Palaniappan, et Mark Stapp car le présent document est pour l'essentiel une version révisée de leur mémoire [RFC3993].

 	8.	Références
 	8.1	Référence normative

[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)

 	8.2	Références pour information

[RFC0854]	J. Postel et J. Reynolds," Spécification du protocole TELNET", STD 8, mai 1983.

[RFC2131]	R. Droms, "Protocole de configuration dynamique d'hôte", mars 1997. (DS) (Mà J par RFC3396, RFC4361, RFC5494, et RFC6849)

[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. (MàJ par la RFC6603) (P.S. ; rendue obsolète par RFC8415)

[RFC3993]	R. Johnson et autres, "Sous-option d'identifiant d'abonné de l'option d'agent de relais pour le protocole de configuration dynamique d'hôte (DHCP)", mars 2005. (P.S.)

 	Adresse de l'auteur
Bernard Volz
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA  01719
USA

téléphone : +1 978 936 0382
mél : volz@cisco.com 

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2006).

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 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 encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait ê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.

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administatif (IASA) de l'IETF.