Groupe de travail Réseau	A. Zinin, Alcatel-Lucent	
Request for Comments : 5613	A. Roy, Cisco Systems	
RFC rendue obsolète : 4813	L. Nguyen, Cisco Systems	
Catégorie : Sur la voie de la normalisation	B. Friedman, Google, Inc.	
	D. Yeung, Cisco Systems	
Traduction Claude Brière de L'Isle	août 2009	

Signalisation de liaison locale OSPF

Résumé
OSPF est un protocole d'acheminement d'état de liaison intra-domaine. Les routeurs OSPF échangent des informations sur une liaison en utilisant des paquets qui suivent un format fixé bien défini. Le format n'est pas assez souple pour permettre de nouvelles caractéristiques qui doivent échanger des données arbitraires. Le présent document décrit une technique rétro-compatible pour effectuer la signalisation de liaison locale, c'est-à-dire, échanger des données arbitraires sur une liaison. Le présent document remplace la spécification expérimentale publiée dans la RFC 4813 pour l'avancer sur la voie de la normalisation.

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. 
Table des matières
1. Introduction	1
1.1 Notation des exigences	2
2. Solution proposée	2
2.1 Bit L dans le champ Options	2
2.2 Bloc de données LLS	3
2.3 TLV LLS	3
2.4 TLV Options et fanions étendus	4
2.5 TLV Authentification cryptographique (seulement OSPFv2)	4
2.6 TLV privés	5
3. Considérations relatives à l'IANA	5
4. Problèmes de compatibilité	6
5. Considérations sur la sécurité	6
6. Références	6
6.1 Références normatives	6
6.2 Références pour information	6
Appendice A. Remerciements	7
Appendice B. Changements par rapport à la RFC 4813	7
Adresse des auteurs	7

 	1.	Introduction

Le présent document décrit une extension à OSPFv2 [RFC2328] et OSPFv3 [RFC5340] pour permettre que des informations supplémentaires soient échangées entre les routeurs sur la même liaison. Les formats de paquets OSPFv2 et OSPFv3 sont fixes et ne permettent pas d'extension. Le présent document propose d'ajouter un bloc de données facultatif composé de triplets Type/Longueur/Valeur (TLV) aux paquets OSPFv2 et OSPFv3 existants pour porter ces informations supplémentaires. Dans le présent document, OSPF va être utilisé quand la spécification est applicable à la fois à OSPFv2 et OSPFv3. De même, OSPFv2 ou OSPFv3 seront utilisés quand le texte est spécifique du protocole.

Une façon potentielle de résoudre cette tâche pourrait être d'introduire un nouveau type de paquet. Cependant, cela voudrait dire d'introduire des paquets supplémentaires dans le réseau, ce qui peut n'être pas souhaitable et peut causer des problèmes de rétro compatibilité. Le présent document décrit comment échanger des données en utilisant les types de paquet OSPF standard.

 	1.1	Notation des exigences
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].

 	2.	Solution proposée

Pour effectuer la signalisation de liaison locale (LLS, link-local signaling) les routeurs OSPF ajoutent un bloc de données spécial à la fin des paquets OSPF ou juste après le bloc de données d'authentification quand l'authentification cryptographique est utilisée. La longueur du bloc LLS n'est pas incluse dans la longueur du paquet OSPF, mais est incluse dans la longueur du paquet IPv4/IPv6. La Figure 1 illustre comment le bloc de données de LLS est rattaché.

   +---------------------+ --              --  +---------------------+
   | Longueur d'en-tête  | ^   Longueur    ^   | Longueur d'en-tête  |
   |  IPv4 = HL+X+Y+Z    | |   d'en-tête   |   |   IPv6 = HL+X+Y     |
   |                     | v               v   |                     |
   +---------------------+ --              --  +---------------------+
   | Longueur d'en-tête  | ^               ^   | Longueur d'en-tête  |
   |   OSPF = X          | |               |   | OSPFv3  = X         |
   |.....................| | X             | X |.....................|
   |                     | |               |   |                     |
   | Données OSPFv2      | |               |   | Données OSPFv3      |
   |                     | v               v   |                     |
   +---------------------+ --              --  +---------------------+
   |     Données         | ^               ^   |                     |
   | d'authentification  | | Y             | Y |  Données de LLS     |
   |                     | v               v   |                     |
   +---------------------+ --              --  +---------------------+
   |                     | ^
   |  Données de LLS     | | Z
   |                     | v
   +---------------------+ --

Figure 1 : Bloc de données de LLS dans OSPFv2 et OSPFv3

Le bloc LLS PEUT être rattaché aux paquets OSPF Hello et description de base de données (DD, Database Description). Le bloc LLS NE DOIT PAS être rattaché à d'autre type de paquet OSPF à la création et DOIT être ignoré à réception.

Les données incluses dans le bloc LLS rattachées à un paquet Hello PEUVENT être utilisées pour la signalisation dynamique car les paquets Hello peuvent être envoyés à tout moment. Cependant, la livraison de données de LLS dans les paquets Hello n'est pas garantie. Les données envoyées avec des paquets DD sont garanties d'être livrées au titre du processus de formation d'adjacence.

Le présent document ne spécifie pas comment les données transmises par le mécanisme de LLS devraient être interprétées par les routeurs OSPF. Comme des routeurs qui ne comprennent pas la LLS peut recevoir ces paquets, les changements faits à cause du TLV de bloc de LLS n'affectent pas l'acheminement de base quand ils interagissent avec des routeurs non LLS.

 	2.1	Bit L dans le champ Options
Un nouveau bit L (L pour LLS) est introduit dans le champ Options OSPF (voir les Figures 2a et 2b). Les routeurs établissent le bit L dans les paquets Hello et DD pour indiquer que le paquet contient un bloc de données de LLS. En d'autres termes, le bloc de données LLS est seulement examiné si le bit L est établi.

             +---+---+---+---+---+---+---+---+
             | * | O | DC| L |N/P| MC| E | * |
             +---+---+---+---+---+---+---+-+-+

Figure 2a : Champ Options OSPFv2

   0                   1                       2
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4  5 6 7  8  9  0  1  2  3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+--+--+--+
   | | | | | | | | | | | | | | |L|AF|*|*|DC| R| N|MC| E|V6|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+--+--+--+

Figure 2b : Champ Options OSPFv3

Le bit L NE DOIT PAS être établi sauf dans les paquets Hello et DD qui contiennent un bloc de LLS.

 	2.2	Bloc de données LLS
Le bloc de données utilisé pour la signalisation de liaison locale est formaté comme décrit ci-dessous (voir l'illustration de la Figure 3).

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Somme de contrôle          |   Longueur des données de LLS |
+---------------+---------------+---------------+---------------+
|                                                               |
|                           TLV de LLS                          |
.                                                               .
.                                                               .
.                                                               .
+---------------+---------------+---------------+---------------+

Figure 3 : Format de bloc de données de LLS

Le champ Somme de contrôle contient la somme de contrôle IP standard pour le contenu entier du bloc de LLS. Avant de calculer la somme de contrôle, le champ Somme de contrôle est réglé à 0. Si la somme de contrôle est incorrecte, le paquet OSPF DOIT être traité, mais le bloc de LLS DOIT être éliminé.

Le champ de 16 bits Longueur de données de LLS contient la longueur (en mots de 32 bits) du bloc de LLS incluant l'en-tête et la charge utile.

Noter que si le paquet OSPF est authentifié cryptographiquement, le bloc de données de LLS DOIT aussi être authentifié cryptographiquement. Dans ce cas, la somme de contrôle LLS régulière n'est pas calculée, mais est plutôt réglée à 0.

Le reste du bloc contient un ensemble de triplets de Type/Longueur/Valeur (TLV) comme décrit au paragraphe 2.3. Tous les TLV DOIVENT être alignés sur 32 bits (avec bourrage si nécessaire).

 	2.3	TLV LLS
Le contenu d'un bloc de données de LLS est construit en utilisant des TLV. Voir à la Figure 4 le format de TLV.

Le champ Type contient l'identifiant de TLV, qui est unique pour chaque type de TLV. Le champ Longueur contient la longueur du champ Valeur (en octets). Le champ Valeur est variable et contient des données arbitraires.

 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               |           Longueur            |
+---------------+---------------+---------------+---------------+
|                                                               |
.                                                               .
.                             Valeur                            .
.                                                               .
+---------------+---------------+---------------+---------------+

Figure 4 : Format des TLV LLS

Noter que les TLV sont toujours bourrés à une limite de 32 bits, mais les octets de bourrage ne sont pas inclus dans le champ Longueur de TLV (bien qu'ils soient inclus dans le champ Longueur des données de LLS dans l'en-tête de bloc de LLS). Les types de TLV non reconnus sont ignorés.

 	2.4	TLV Options et fanions étendus
Ce paragraphe décrit un TLV appelé Options et fanions étendus (EOF). Le format du TLV EOF est montré à la Figure 5.

Les bits dans le champ Valeur n'ont aucune signification du point de vue du mécanisme de LLS. Les bits PEUVENT être alloués pour annoncer les capacités de liaison locale OSPF. Les bits PEUVENT aussi être alloués pour effectuer une signalisation booléenne de liaison locale.

La longueur du champ Valeur dans le TLV EOF est de 4 octets.

La valeur du champ Type dans le TLV EOF est 1. Le TLV EOF DOIT seulement apparaître une fois dans le bloc de données de LLS.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             1                 |            4                  |
+---------------+---------------+---------------+---------------+
|                  Options et fanions étendus                   |
+---------------+---------------+---------------+---------------+

Figure 5 : Format du TLV EOF

Actuellement, les [RFC4811] et [RFC4812] utilisent des bits dans le champ Options étendues du TLV EOF.

Les bits des options et fanions étendus sont définis à la Section 3.

 	2.5	TLV Authentification cryptographique (seulement OSPFv2)
Le présent document définit un TLV spécial qui est utilisé pour l'authentification cryptographique (CA-TLV) du bloc de données de LLS. Ce TLV DOIT seulement être inclus dans le bloc de LLS quand l'authentification cryptographique est activée sur l'interface correspondante. Le résumé de message du bloc de LLS DOIT être calculé en utilisant la même clé et lemême algorithme d'authentification qu'utilisés pour le paquet OSPFv2. Le numéro de séquence cryptographique est inclus dans le TLV et DOIT être le même que celui qui figure dans les données d'authentification OSPFv2 pour que le bloc de LLS soit considéré comme authentique.

Le TLV est construit comme montré à la Figure 6.

 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 = 2                |   Longueur d'auth.            |
+---------------+---------------+---------------+---------------+
|                     Numéro de séquence                        |
+---------------+---------------+---------------+---------------+
|                                                               |
.                                                               .
.                           AuthData                            .
.                                                               .
+---------------+---------------+---------------+---------------+

Figure 6 : Format du TLV Authentification cryptographique

La valeur du champ Type pour le TLV CA est 2.

Le champ Longueur dans l'en-tête contient la longueur de la portion données du TLV incluant 4 octets pour le numéro de séquence et la longueur en octets du bloc de résumé de message pour tout le bloc de LLS.

Le champ Numéro de séquence contient le numéro de séquence cryptographique qui est utilisé pour empêcher des attaques en répétition simples. Pour que le bloc de LLS soit considéré comme authentique, le numéro de séquence dans le TLV CA DOIT correspondre au numéro de séquence dans le champ Authentification de l'en-tête de paquet OSPFv2 (qui DOIT être présent). En cas de discordance de numéro de séquence ou d'échec d'authentification, tout le bloc de LLS DOIT être ignoré.

Le TLV CA NE DOIT PAS apparaître plus d'une fois dans le bloc de LLS. Aussi, quand il est présent, ce TLV DOIT être le dernier TLV dans le bloc de LLS. Si il apparaît plus d'une fois, seule la première occurrence est traitée et toutes les autres DOIVENT être ignorées.

Le champ AuthData contient le résumé de message calculé pour le bloc de LLS jusqu'au champ du TLV CA (c'est-à-dire, il exclut les AuthData du TLV CA).

Le TLV CA n'est pas applicable à OSPFv3 et il NE DOIT PAS être ajouté à un paquet OSPFv3. Si on le trouve à réception, ce TLV DOIT être ignoré.

 	2.6	TLV privés
Les valeurs de type de LLS dans la gamme de 32768 à 65536 sont réservées pour une utilisation privée. Les quatre premiers octets du champ Valeur DOIVENT être le code d'entreprise privée [ENTNUM]. Cela permet que plusieurs extensions de fabricant privé coexistent dans un réseau.

 	3.	Considérations relatives à l'IANA

Le présent document utilise le registre qui a été créé à l'origine dans la [RFC4813]. L'IANA a mis à jour le registre pour pointer sur le présent document :

o	"Signalisation de liaison locale (LLS, Link-Local Signalling) de plus court chemin ouvert en premier (OSPF, Open Shortest Path First) - Identifiants de Type/Longueur/Valeur (TLV)"

L'IANA a alloué le bit L dans le registre "Options OSPFv2" et dans le registre "Options OSPFv3" conformément au paragraphe 2.1.

Les types de TLV LLS sont conservés par l'IANA. Les extensions à OSPF qui exigent un nouveau type de TLV LLS DOIVENT être revues par un expert désigné provenant du domaine "Acheminement".

Les critères pour allouer des TLV de LLS sont :

o	LLS ne devrait pas être utilisé pour des informations qu'il vaudrait mieux annoncer dans une annonce d'état de liaison de liaison locale (LSA, Link State Advertisement).

o	LLS devrait être confiné à la signalisation entre voisins directs.

o	La discrétion devrait être utilisée dans le volume des informations signalées en utilisant LLS du fait des implications évidentes de MTU et de performances.

Suivant les politiques mentionnées dans la [RFC5226], les valeurs de type de LLS dans la gamme de 0 à 32767 sont allouées par revue de l'IETF et les valeurs de type de LLS dans la gamme de 32768 à 65535 sont réservées pour utilisation privée.

Le présent document alloue les types de TLV LLS dans OSPFv2/OSPFv3.

Type de TLV	Nom	Référence
   0	Réservé
   1	Options et fanions étendus	[RFC5613]
   2	Authentification cryptographique *	[RFC5613]
3-32767	Réservé pour allocation par l'IANA
32768-65535	Utilisation privée

* le TLV Authentification cryptographique n'est défini que pour OSPFv2

L'IANA a changé le nom du sous registre de "Options étendues de LLS de type 1" en "Options et fanions étendus de LLS de type 1".

Le présent document alloue aussi les bits suivants dans le TLV EOF mentionné au paragraphe 2.5 :

Bit	Nom	Référence
0x00000001	Resynchronisation LSDB (LR)	[RFC4811]
0x00000002	Signal de redémarrage (bit RS)	[RFC4812]

Les futures allocations de bits d'options et fanions étendus DOIVENT être revues par un expert désigné dans le domaine "Acheminement".

 	4.	Problèmes de compatibilité

Les modifications de formats de paquet OSPF sont compatibles avec l'OSPF standard car les routeurs OSPF qui ne prennent pas en charge LLS vont ignorer le bloc de données de LLS après le paquet OSPF ou le résumé de message cryptographique. Au moment de la rédaction du présent mémoire, il y a des mises en œuvre déployées avec un logiciel conforme à la [RFC4813]. Les routeurs qui ne mettent pas en œuvre la [RFC4813] ignorent les données de LLS à la fin du paquet OSPF. Une considération attentive devrait être apportée au transport de données de LLS supplémentaires, car cela peut affecter le temps d'établissement d'adjacence OSPF du fait de délais de propagation et/ou de temps de traitement supplémentaires.

 	5.	Considérations sur la sécurité

Les considérations sur la sécurité héritées de OSPFv2 sont décrites dans la [RFC2328]. Cette technique fournit le même niveau de sécurité que le protocole OSPFv2 de base en permettant que les données de LLS soient authentifiées en utilisant la même authentification cryptographique que OSPFv2 (voir les détails au paragraphe 2.5).

Les considérations sur la sécurité héritées de OSPFv3 sont décrites dans les [RFC5340] et [RFC4552]. OSPFv3 utilise IPsec pour l'authentification et le chiffrement. Avec IPsec, l'en-tête d'authentification (AH, Authentication Header) l'encapsulation de charge utile de sécurité (ESP, Encapsulating Security Payload) ou les deux sont appliqués à la charge utile OSPFv3 entière incluant le bloc de LLS.

 	6.	Références
 	6.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. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC2328]	J. Moy, "OSPF version 2", STD 54, avril 1998. (MàJ par la RFC6549, RFC8042, 9355)

[RFC4552]	M. Gupta, N. Melam, "Authentification/confidentialité pour OSPFv3", juin 2006. (P.S.)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5340]	R. Coltun et autres, "OSPF pour IPv6", juillet 2008. (P.S. ; Remplace RFC2740  ; MàJ par RFC8362)

 	6.2	Références pour information

[ENTNUM]	IANA, "Private enterprise numbers", http://www.iana.org.

[RFC4811]	L. Nguyen et autres, "Resynchronisation de bases de données d'état de liaison hors bande OSPF (LSDB)", mars 2007. (Info.)

[RFC4812]	L. Nguyen, A. Roy, A. Zinin, "Signalisation de redémarrage OSPF", mars 2007. (Information)

[RFC4813]	B. Friedman et autres, "Signalisation de liaison locale OSPF", mars 2007. (Expérimentale)

 	Appendice A.	Remerciements
Les auteurs tiennent à remercier Russ White, Acee Lindem, et Manral Vishwas de leur relecture du présent document.

 	Appendice B.	Changements par rapport à la RFC 4813
Cette Section décrit les changements substantiels à la [RFC4813].
o	Ajout de la prise en charge de OSPFv3,
o	Les TLV privés DOIVENT utiliser le code d'entreprise privée,
o	Les niveaux d'exigence ont été précisés en plusieurs endroits,
o	Le document est passé du statut de Expérimental à Sur la voie de la normalisation.

 	Adresse des auteurs
Alex Zinin	Abhay Roy	Liem Nguyen	
Alcatel-Lucent	Cisco Systems	Cisco Systems	
Singapore	170 West Tasman Drive	170 West Tasman Drive	
mél : alex.zinin@alcatel-lucent.com	San Jose, CA  95134	San Jose, CA  95134	
	USA	USA	
	mél : akr@cisco.com	mél : lhnguyen@cisco.com	

Barry Friedman	Derek Yeung	
Google, Inc.	Cisco Systems	
1600 Amphitheatre Parkway	170 West Tasman Drive	
Mountain View, CA  94043	San Jose, CA  95134	
USA	USA	
mél : barryf@google.com	mél : myeung@cisco.com