Groupe de travail Réseau	J. Scudder, Juniper Networks	
Request for Comments : 5492	R. Chandra, Sonoa Systems	
RFC rendue obsolète : 3392 	février 2009	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Annonce de capacités avec BGP-4

Statut de ce mémoire
Ceci est un document de l’Internet sur la voie de la normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc5492 

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. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Résumé
Le présent document définit un paramètre facultatif, appelé Capacités, qui est destiné à faciliter l'introduction de nouvelles capacités dans le protocole de routeur frontière (BGP, Border Gateway Protocol) en fournissant une annonce de capacité sans exiger que l'échange BGP soit terminé.
Le présent document rend obsolète la RFC 3392.
Table des matières
1. Introduction	2
2. Langage des exigences	2
3. Vue d'ensemble du fonctionnement	2
4. Paramètre facultatif de capacités (type de paramètre 2)	3
5. Extensions de traitement d'erreur	3
6. Considérations relatives à l'IANA	3
7. Considérations sur la sécurité	4
8. Remerciements	4
9. Références	4
9.1 Références normatives	4
9.2 Références pour information	4
Appendice A. Comparaison entre la RFC 2842 et la RFC 3392	4
Appendice B. Comparaison entre la RFC 3392 et le présent document	5
Adresse des auteurs	5

 	1.	Introduction

La spécification BGP-4 de base [RFC4271] exige que quand un locuteur BGP reçoit un message OPEN avec un ou plusieurs paramètres facultatifs non reconnus, le locuteur doit terminer l'échange BGP. Cela complique l'introduction de nouvelles capacités dans BGP.

La présente spécification définit un paramètre facultatif et des règles de traitement qui permettent aux locuteurs BGP de communiquer leurs capacités dans un message OPEN. Une paire de locuteurs BGP qui prennent en charge la présente spécification peut établir l'échange même quand il est présenté avec des capacités non reconnues, pour autant que toutes les capacités requises pour prendre en charge l'échange soient supportées.

 	2.	Langage 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].

 	3.	Vue d'ensemble du fonctionnement

Quand un locuteur BGP [RFC4271] qui prend en charge l'annonce de capacités envoie un message OPEN à son homologue BGP, le message PEUT inclure un paramètre facultatif, appelé Capacités. Le paramètre fait la liste des capacités prises en charge par le locuteur.

Un locuteur BGP détermine les capacités prises en charge par son homologue en examinant la liste de capacités présente dans le paramètre facultatif Capacités porté par le message OPEN que le locuteur reçoit de l'homologue.

Un locuteur BGP qui prend en charge une capacité particulière peut utiliser cette capacité avec son homologue après que le locuteur a déterminé (comme décrit ci-dessus) que l'homologue prend en charge cette capacité. Dit simplement, une certaine capacité peut être utilisée sur un échange si cette capacité a été annoncée par les deux homologues. Si l'un ou l'autre des homologues ne l'a pas annoncée, la capacité ne peut pas être utilisée.

Un locuteur BGP détermine que son homologue ne prend pas en charge l'annonce de capacités si, en réponse à un message OPEN qui porte le paramètre facultatif Capacités, le locuteur reçoit un message NOTIFICATION avec le sous code Erreur réglé à "Paramètre facultatif non pris en charge". (C'est une conséquence de la spécification BGP-4 de base [RFC4271] et non une nouvelle exigence.) Dans ce cas, le locuteur DEVRAIT tenter de rétablir une connexion BGP avec l'homologue sans envoyer le paramètre facultatif Capacités à l'homologue.

Si un locuteur BGP qui prend en charge une certaine capacité détermine que son homologue ne prend pas en charge cette capacité, il PEUT envoyer un message NOTIFICATION à l'homologue et terminer l'échange (voir les détails à la Section 5 "Extensions de traitement d'erreur"). Par exemple, un locuteur BGP peut avoir besoin de terminer l'échange si il l'a établi pour échanger des chemins IPv6 et si il détermine que son homologue ne prend pas en charge les extensions multi protocoles pour BGP-4 [RFC4760]. Le sous code d'erreur dans le message NOTIFICATION est alors réglé à "Capacité non prise en charge". Le message DOIT contenir la ou les capacités qui causent l'envoi du message par le locuteur. La décision d'envoyer le message et de terminer l'échange est locale pour le locuteur. Si il est terminé, un tel échange NE DEVRAIT PAS être rétabli automatiquement.

Si un locuteur BGP reçoit de son homologue une capacité qu'il ne prend pas en charge ou reconnaît lui-même, il DOIT ignorer cette capacité. En particulier, le message NOTIFICATION Capacité non prise en charge NE DOIT PAS être généré et la session BGP NE DOIT PAS être terminée en réponse à la réception d'une capacité qui n'est pas prise en charge par le locuteur local.

 	4.	Paramètre facultatif de capacités (type de paramètre 2)

C'est un paramètre facultatif qui est utilisé par un locuteur BGP pour porter à son homologue BGP la liste des capacités prises en charge par le locuteur. Le codage des paramètres facultatifs BGP est spécifié au paragraphe 4.2 de la [RFC4271].  Le type de paramètre du paramètre facultatif de capacités est 2.

Le paramètre contient un ou plusieurs triplets <Code de capacité, Longueur de capacité, Valeur de capacité>, où chaque triplet est codé comme montré ci-dessous :

          +-------------------------------+
          | Code de capacité (1 octet)    |
          +-------------------------------+
          | Longueur de capacité (1 octet)|
          +-------------------------------+
          | Valeur de capacité (variable) |
          ~                               ~
          +-------------------------------+

L'utilisation et la signification de chacun de ces champs sont comme suit :

Code de capacité : entier binaire non signé de un octet qui identifie sans ambiguïté les capacités individuelles.

Longueur de capacité : entier binaire non signé de un octet qui contient la longueur du champ Valeur de capacité en octets.

Valeur de capacité : champ de longueur variable qui est interprété conformément à la valeur du champ Code de capacité.

Les locuteurs BGP NE DEVRAIENT PAS inclure plus d'une instance d'une capacité avec les mêmes code de capacité, longueur de capacité, et valeur de capacité. Noter cependant que le traitement de plusieurs instances d'une telle capacité n'exige rien de spécial car des instances supplémentaires ne changent pas la signification de la capacité annoncée; donc, un locuteur BGP DOIT être prêt à accepter de telles instances multiples.

Les locuteurs BGP PEUVENT inclure plus d'une instance d'une capacité (identifiée par le code de capacité) avec un champ Longueur de capacité non à zéro, mais avec une valeur de capacité différente et une même ou différente longueur de capacité. Le traitement de ces instances de capacité est spécifique du code de capacité et DOIT être décrit dans le document qui introduit la nouvelle capacité.

Le paramètre facultatif Capacités (type de paramètre OPEN facultatif 2) DEVRAIT seulement être inclus une fois dans le message OPEN. Si le locuteur BGP souhaite inclure plusieurs capacités dans le message OPEN, il DEVRAIT le faire comme expliqué ci-dessus -- en faisant la liste de toutes ces capacités comme des TLV au sein d'un seul paramètre facultatif Capacités. Cependant, pour la rétro compatibilité, un locuteur BGP DOIT être prêt à recevoir un message OPEN qui contient plusieurs paramètres facultatifs Capacités, dont chacun contient un ou plusieurs TLV Capacités. L'ensemble des capacités devrait être traité de la même façon dans l'un et l'autre cas, qu'il soit énuméré dans un seul paramètre facultatif Capacités du message OPEN ou réparti dans plusieurs paramètres facultatifs Capacités.

 	5.	Extensions de traitement d'erreur

Le présent document définit un nouveau sous code d'erreur, Capacité non prise en charge. La valeur de ce sous code est 7. Le champ Données dans le message NOTIFICATION DOIT faire la liste de l'ensemble des capacités qui causent l'envoi du message par le locuteur. Chaque capacité est codée de la même façon qu'elle le serait dans un message OPEN.

Comme expliqué dans la section "Vue d'ensemble du fonctionnement", la NOTIFICATION "Capacité non prise en charge" est un moyen pour qu'un locuteur BGP se plaigne de ce que son homologue ne prenne pas en charge une capacité sans laquelle l'échange ne peut pas se faire. elle NE DOIT PAS être utilisée quand un locuteur BGP reçoit une capacité qu'il ne comprend pas ; de telles capacités DOIVENT être ignorées.

 	6.	Considérations relatives à l'IANA

Le présent document définit un paramètre facultatif de capacité ainsi qu'un champ Code de capacité. L'IANA tient le registre des valeurs de code de capacité. La valeur de code de capacité 0 est réservée. Les valeurs de code de capacité 1 à 63 sont allouées par l'IANA selon la politique de "revue de l'IETF" définie dans la [RFC5226]. Les valeurs de code de capacité 64 à 127 seront allouées par l'IANA selon la politique du "premier arrivé, premier servi" définie dans la [RFC5226]. Les valeurs de code de capacité 128 à 255 sont pour "utilisation privée" comme défini dans la [RFC5226].

L'IANA a créé et tient un registre pour les paramètres facultatifs de message OPEN, appelé "Types de paramètre facultatif de BGP OPEN". Les paramètres facultatifs sont identifiés par le type de paramètre, qui est un entier non signé de un octet. Les valeurs (0 réservé, 1 à 255) sont à allouer selon la politique de "revue de l'IETF" définie dans la [RFC5226].

Le registre a été rempli avec les deux codes de type de paramètre actuellement définis :
o  Paramètre de type 1 : Authentification (déconseillé) [RFC4271], [RFC5492].
o  Paramètre de type 2 : Capacités [RFC5492]

 	7.	Considérations sur la sécurité

La présente extension à BGP ne change pas les questions de sécurité sous-jacentes inhérentes au BGP existant [RFC4272].

 	8.	Remerciements

Les auteurs tiennent à remercier les membres du groupe de travail IDR et l'IESG et ses directeurs de leur relecture et commentaires.

 	9.	Références
 	9.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)

[RFC4271]	Y. Rekhter, T. Li et S. Hares, "Protocole de routeur frontière version 4 (BGP-4)", janvier 2006. (D.S.) (MàJ par RFC6608, RFC8212, 9072)

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

 	9.2	Références pour information

[RFC4272]	S. Murphy, "Analyse des faiblesses de la sécurité de BGP", janvier 2006. (Information)

[RFC4760]	T. Bates, R. Chandra, D. Katz et Y. Rekhter, "Extensions multi protocoles pour BGP-4", janvier 2007.

 	Appendice A.	Comparaison entre la RFC 2842 et la RFC 3392

En plus de plusieurs changements rédactionnels mineurs, la RFC 3392 précisait aussi comment traiter les instances multiples de la même capacité.

 	Appendice B.	Comparaison entre la RFC 3392 et le présent document

Le présent document fait des changements rédactionnels mineurs et met à jour les références, précise l'utilisation du message de notification Paramètres facultatifs non pris en charge, précise le comportement quand le paramètre Capacités est inclus plusieurs fois dans le message OPEN, et précise les exigences en changeant un certain nombre de "DEVRAIT" en "DOIT".

 	Adresse des auteurs

John G. Scudder
Juniper Networks
mél : jgs@juniper.net

Ravi Chandra
Sonoa Systems
mél : rchandra@sonoasystems.com