Groupe de travail Réseau	E. Chen, Cisco Systems
Request for Comments : 5292	S. Sangli, Cisco Systems
Catégorie : Sur la voie de la normalisation	
Traduction Claude Brière de L'Isle	août 2008

Filtre de chemin sortant fondé sur le préfixe d’adresse pour BGP-4

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.

Résumé
Le présent document définit un nouveau type de filtre de routeur sortant (ORF, Outbound Router Filter) pour BGP, appelé "Filtre de chemin sortant de préfixe d’adresse", qui peut être utilisé pour effectuer un filtrage de chemin fondé sur le préfixe d’adresse. Ce type d’ORF prend en charge une correspondance fondée sur la longueur du préfixe ou la longueur de gamme, une correspondance de préfixe d’adresse fondée sur un caractère générique, ainsi que la correspondance exacte de préfixe d’adresse pour les familles d’adresses.
Table des matières
1. Introduction	1
2. Type d’ORF Préfixe d’adresse	1
3. Codage de l’ORF Préfixe d’adresse	2
4. Confrontation d’ORF Préfixe d’adresse	2
5. Considérations relatives à l’IANA	3
6. Considérations sur la sécurité	3
7. Références normatives	3
Adresse des auteurs	3
Déclaration complète de droits de reproduction	4

 	1.	Introduction

La capacité de filtrage de chemin sortant définie dans la [RFC5291] fournit un mécanisme pour qu’un locuteur BGP envoie à son homologue BGP un ensemble de filtres de chemins sortants (ORF, Outbound Route Filter) qui peut être utilisé par son homologue pour filtrer ses mises à jour d’acheminement sortantes au locuteur BGP.

Le présent document définit un nouveau type d’ORF pour BGP, appelé "filtre de chemin sortant de préfixe d’adresse" (ORF de préfixe d’adresse) qui peut être utilisé pour effectuer un filtrage de chemin fondé sur le préfixe d’adresse. L’ORF de préfixe d’adresse prend en charge la correspondance fondée sur la longueur du préfixe, ou fondée sur la gamme, la correspondance de préfixe d’adresse fondée sur un caractère générique, ainsi que la correspondance exacte de préfixe d’adresse pour les familles d’adresses [RFC4760].

 	2.	Type d’ORF Préfixe d’adresse

Le type d’ORF Préfixe d’adresse permet d’exprimer des ORF en termes de préfixes d’adresses. C’est-à-dire, il fournit un filtrage de chemin fondé sur le préfixe d’adresse, incluant la correspondance fondée sur la longueur du préfixe ou de la gamme, ainsi que la correspondance de préfixe d’adresse fondée sur un caractère générique.

Conceptuellement, une entrée d’ORF de préfixe d’adresse consiste en les champs <Séquence, Correspondance, Longueur Préfixe, Longueur minimum, Longueur maximum>.

Le champ "Séquence" spécifie l’ordre relatif de l’entrée parmi toutes les entrées d’ORF Préfixe d’adresse.

Le champ "Correspondance" spécifie si cette entrée est "PERMISE" (valeur 0) ou "REFUSÉE" (valeur 1).

Le champ "Longueur" indique la longueur (en bits) du préfixe d’adresse. Une longueur de zéro indique un préfixe qui correspond à toutes les adresses (comme spécifiées par la famille d’adresses ) (avec le préfixe lui-même de zéro octet).

Le champ "Préfixe" contient un préfixe d’adresse d’une famille d’adresses.

Le champ "Longueur minimum" indique la longueur minimum du préfixe (en bits) qui est exigée pour la "correspondance".  Le champ est considéré comme non spécifié avec une valeur de 0.

Le champ "Longueur maximum" indique la longueur maximum de préfixe (en bits) qui est exigée pour la "correspondance". Le champ est considéré comme non spécifié avec une valeur de 0.

Les champs "Séquence", "Longueur", "Longueur minimum", et "Longueur maximum" sont tous des entiers non signés.

Le présent document impose les exigences suivantes aux valeurs de ces champs  :

0 ≤ Longueur < Longueur minimum ≤ Longueur maximum

Cependant, les essais relatifs à la valeur de "Longueur minimum" ou "Longueur maximum" devraient être omis quand le champ "Longueur minimum" ou "Longueur maximum" (respectivement) est non spécifié.

De plus, la valeur "Longueur maximum" doit être de pas plus que la longueur maximum (en bits) d’une adresse d’hôte pour une famille d’adresses donnée [RFC4760].

 	3.	Codage de l’ORF Préfixe d’adresse

La valeur du type d’ORF pour le type d’ORF Préfixe d’adresse est 64.

Une entrée d’ORF Préfixe d’adresse est codée comme suit. Le champ "Correspondance" de l’entrée est codé dans le champ "Correspondance" de la partie commune [RFC5291], et les champs restants de l’entrée sont codés dans la "partie spécifique du type", comme le montre la Figure 1.

         +--------------------------------+
         |   Séquence (4 octets)          |
         +--------------------------------+
         |   Longueur minimum (1 octet)   |
         +--------------------------------+
         |   Longueur maximum (1 octet)   |
         +--------------------------------+
         |   Longueur (1 octet)           |
         +--------------------------------+
         |   Préfixe (longueur variable)  |
         +--------------------------------+

Figure 1 : Codage de l’ORF Préfixe d’adresse

Noter que le champ "Préfixe" contient le préfixe d’adresse suivi par assez de bits en queue pour faire que la fin du champ tombe sur une limite d’octet. La valeur des bits de queue est sans importance.

 	4.	Confrontation d’ORF Préfixe d’adresse

En plus des règles générales de correspondance définies dans la [RFC5291], plusieurs règles de correspondance spécifiques de l’ORF Préfixe d’adresse sont définies comme suit  :

Considérons une entrée d’ORF Préfixe d’adresse, et un chemin maintenu par un locuteur BGP avec des informations d’accessibilité de couche réseau (NLRI, Network Layer Reachability Information) de forme <Préfixe, Longueur>.

Le chemin est considéré comme "ne correspondant pas" à l’entrée d’ORF si les NLRI ne sont ni plus spécifiques que, ni égales aux champs <Préfixe, Longueur> de l’entrée d’ORF.

Quand les NLRI ne sont ni plus spécifiques que, ni égales aux champs <Préfixe, Longueur> de l’entrée d’ORF, le chemin n’est considéré correspondre à l’entrée d’ORF que si la condition de correspondance de NLRI mentionnée au Tableau 1 est satisfaite.

	Entrée d’ORF	Condition de correspondance de NLRI
Longueur minimum	Longueur maximum
non spécifiée	non spécifiée	Longueur de NLRI == Longueur d’ORF
spécifiée	non spécifiée	Longueur de NLRI ≥ Longueur minimum d’ORF
non spécifiée	spécifiée	Longueur de NLRI ≤ Longueur maximum d’ORF
spécifiée	spécifiée	Longueur de NLRI ≥ Longueur minimum d’ORF
		ET Longueur de NLRI ≤ Longueur maximum d’ORF

Table 1 : Correspondance d’ORF Préfixe d’adresse

Quand plus d’une entrée d’ORF Préfixe d’adresse correspond aux NLRI du chemin, la règle de "première correspondance" s’applique. C’est-à-dire, l’entrée d’ORF avec le plus petit numéro de séquence (parmi toutes les entrées d’ORF correspondantes) est considérée comme la seule correspondante, et elle va déterminer si le chemin devrait être annoncé.

L’allocation des numéros de séquence est une affaire locale pour le locuteur BGP qui envoie les entrées d’ORF Préfixe d’adresse.

 	5.	Considérations relatives à l’IANA

Le présent document spécifie un nouveau type de filtrage de chemin sortant (ORF, Outbound Route Filtering)  : ORF de préfixe d’adresse. La valeur de ce type d’ORF est 64.

 	6.	Considérations sur la sécurité

Cette extension à BGP ne change pas les problèmes de sécurité sous-jacents de la [RFC4271].

 	7.	Références normatives

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

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

[RFC5291]	E. Chen, Y. Rekhter, "Capacité de filtrage de chemin sortant pour BGP-4", août 20080. (P.S.)

 	Adresse des auteurs

Enke Chen	Srihari R. Sangli	
Cisco Systems, Inc.	Cisco Systems, Inc.	
170 W. Tasman Dr.	170 W. Tasman Dr.	
San Jose, CA 95134	San Jose, CA 95134	
mél : enkechen@cisco.com	mél : rsrihari@cisco.com	

 	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2008)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, 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, le IETF TRUST 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 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 le 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 administratif de l'IETF (IASA).