Groupe de travail Réseau	M. Bagnulo, UC3M	
Request for Comments : 4581	J. Arkko, Ericsson	
RFC mise à jour  : 3972	octobre 2006	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Format de champ d'extension des adresses générées cryptographiquement (CGA)

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 document définit un format de Type-Longueur-Valeur pour les extensions d'adresse générée cryptographiquement (CGA, Cryptographically Generated Address). Ce document met à jour la RFC 3972.
Table des matières
1. Introduction	1
2. Format de champ d'extension CGA	1
3 Considérations relatives à l'IANA	2
4 Considérations sur la sécurité	2
5. Remerciements	2
6. Références normatives	2
Adresse des auteurs	2
Déclaration complète de droits de reproduction	3

 	1.	Introduction

La spécification d'adresse générée cryptographiquement (CGA, Cryptographically Generated Address) [RFC3972] définit des champs d'extension qui permettent que des informations supplémentaires soient incluses dans la structure de données de paramètre CGA. Jusqu'à présent il a semblé qu'il y ait suffisamment d'intérêt pour inclure des éléments de données supplémentaires dans la structure de données de paramètre de CGA par ces champs d'extension pour qu'il semble raisonnable de s'attendre à ce que plus d'un mécanisme exige son utilisation. Afin de simplifier l'ajout de plusieurs éléments de données, le présent document met à jour la [RFC3972], et il définit un format de Type-Longueur-Valeur pour les champs d'extension.

 	2.	Format de champ d'extension CGA
Les éléments de données à inclure dans les champs d'extension de la structure de données de paramètre de CGA DOIVENT  être codés en utilisant le format de Type-Longueur-Valeur (TLV) suivant :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type d'extension       |Longueur de données d'extension|
+---------------+---------------+---------------+---------------+
|                                                               |
~                    Données d'extension                        ~
|                                                               |
+---------------+---------------+---------------+---------------+

Type d'extension : identifiant de 16 bits du type du champ d'extension.

Longueur de données d'extension : entier non signé de 16 bits. Longueur du champ Données d'extension de cette option, en octets.

Données d'extension : champ de longueur variable. Données spécifiques du type d'extension.

 	3	Considérations relatives à l'IANA

L'IANA a créé et va tenir un registre intitulé "Type d'extensions de CGA". Les valeurs dans cet espace de nom sont des entiers non signés de 16 bits. Les valeurs initiales pour le champ Type d'extension de CGA sont données ci-dessous ; les futures allocations sont à effectuer par action de normalisation [RFC2434]. Les allocations consistent en un nom et la valeur.

Comme recommandé dans la [RFC3692], le présent document fait les allocations suivantes pour l'utilisation expérimentale et d'essais : 
la valeur 0xFFFD, avec le nom Exp_FFFD ;
la valeur 0xFFFE, avec le nom Exp_FFFE ,
la valeur 0xFFFF, avec le nom Exp_FFFF.

 	4	Considérations sur la sécurité

Aucun souci de sécurité n'est soulevé par l'adoption du format d'extension de CGA décrit dans le présent document. Cependant, une analyse de sécurité appropriée est nécessaire quand de nouvelles extensions de CGA sont définies afin de s'assurer qu'elles n'introduisent pas de nouvelles vulnérabilités aux schémas existants de CGA.

 	5.	Remerciements

Des commentaires sur le présent document ont été fournis par Sam Hartman, Allison Mankin, Pekka Savola, Thomas Narten, Tuomas Aura, Stefan Rommer, Julien Laganier, et James Kempf.

 	6.	Références normatives

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

[RFC3692]	T. Narten, "L'allocation de numéros expérimentaux et d'essai est considérée comme utile", janvier 2004. (BCP0082)

[RFC3972]	T. Aura, "Adresses générées cryptographiquement (CGA)", mars 2005. (MàJ par RFC4581, RFC4982) (P.S.)

 	Adresse des auteurs

Marcelo Bagnulo	Jari Arkko	
Universidad Carlos III de Madrid	Ericsson	
Av. Universidad 30	Jorvas  02420	
Leganes, Madrid  28911	Finland	
SPAIN	mél : jari.arkko@ericsson.com 	
téléphone : 34 91 6249500		
mél : marcelo@it.uc3m.es 		
URI : http://www.it.uc3m.es 		

 	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.