Groupe de travail Réseau	D. Meyer	
Request for Comments : 4384	mars 2006	
BCP 114		
Catégorie : Bonnes pratiques actuelles	Traduction Claude Brière de L'Isle	

Communautés BGP pour collection de données

Statut de ce mémoire
Ce document spécifie les bonnes pratiques actuelles sur l'Internet pour la communauté de l'Internet, et demande des discussions et suggestions pour son amélioration. La diffusion du présent mémoire n'est soumise à aucune restriction.

Notice de Copyright
Copyright (C) The Internet Society (2006).

Résumé
Les communautés BGP [RFC1997] sont utilisées par les fournisseurs de services à de nombreuses fins, incluant l'étiquetage des consommateurs, des homologues, et des routes d'origine géographique. Un tel étiquetage est normalement utilisé pour contrôler la portée de la redistribution des routes au sein du réseau d'un fournisseur et pour ses homologues et ses consommateurs. Avec l'arrivée de collections de données BGP à grande échelle (et des recherches associées) il est devenu clair que les informations portées dans de telles communautés sont essentielles pour une compréhension plus profonde du système d'acheminement mondial. Le présent mémoire définit des communautés standard (sortantes) et leurs codages pour l'exportation aux collecteurs de routes BGP.
Table des matières
1. Introduction	1
2. Définitions	2
2.1 Homologues et échange de trafic	2
2.2 Routes de consommateur	2
2.3 Routes d'homologue	2
2.4 Routes internes	2
2.5 Routes internes plus spécifiques	2
2.6 Routes à destination particulière	3
2.7 Routes vers l'amont	3
2.8 Routes nationales	3
2.9 Routes régionales	3
3. Codages et valeurs de communauté de la RFC 1997	3
4. Valeurs de communauté pour collection de données BGP	3
4.1 Communautés étendues 	4
4.2 Communautés étendues spécifiques d'AS de quatre octets	5
5. Note sur la mise en paquet de BGP UPDATE	5
6. Remerciements	6
7. Considérations sur la sécurité	6
7.1 Longueur totale de l'attribut Chemin	6
8. Considérations relatives à l'IANA	6
9. Références	6
9.1 Références normatives	6
9.2 Références pour information	7
Adresse de l'auteur	7
Déclaration complète de droits de reproduction	7

 	1.	Introduction

Les communautés BGP [RFC1997] sont utilisées par les fournisseurs de services à de nombreuses fins, incluant l'étiquetage de chemins générés par le consommateur, l'homologue, et géographiques. Un tel étiquetage est normalement utilisé pour contrôler la portée de la redistribution des chemins au sein du réseau d'un fournisseur et à ses consommateurs et homologues. Les communautés sont aussi utilisées pour une large variété d'autres applications, comme de permettre aux consommateurs de régler des attributs comme LOCAL_PREF [RFC1771] en envoyant les communautés appropriées à leur fournisseur de services. D'autres applications incluent de signaler divers types de réseaux privés virtuels (VPN, Virtual Private Network) (par exemple, le service de LAN privé virtuel (VPLS, Virtual Private LAN Service) [RFC4761]) et de porter la bande passante de la liaison pour les applications d'ingénierie du trafic [RFC4360].

Avec l'avènement de la collecte de données BGP à grande échelle [RV] [RIS] (et les recherches associées) il est devenu clair que les informations géographiques et topologiques, ainsi que la relation qu'a le fournisseur avec la source d'un chemin (par exemple, transit, homologue, ou consommateur) portées dans de telles communautés sont essentielles pour une compréhension plus profonde du système mondial d'acheminement. Le présent mémoire définit des communautés standard à exporter aux collecteurs de chemins BGP. Ces communautés représentent une partie significative des informations portées par les fournisseurs de services au moment de cette rédaction, et à ce titre pourraient être utiles pour l'usage interne des fournisseurs de services. Cependant, une telle utilisation sort du domaine d'application du présent mémoire. Finalement, ceux qui sont impliqués dans l'analyse des données de BGP sont encouragés à vérifier que leur sources de données ainsi que leurs homologues mettent en œuvre ce schéma (car il y a une grande quantité de données existantes ainsi que de nombreux échanges de trafic traditionnels).

Le reste de ce mémoire est organisé comme suit. La Section 2 donne les définitions des termes utilisés ainsi que la sémantique des communautés utilisées pour la collecte des données BGP, et la Section 3 définit les codages correspondants pour les communautés de la [RFC1997]. Finalement, la Section 4 définit les codages à utiliser avec les communautés étendues de la [RFC4360].

 	2.	Définitions

Dans cette section, on définit les termes utilisés et les catégories de routes qui peuvent être étiquetées avec des communautés. Cet étiquetage est souvent appelé du coloriage, et on se réfère à la "couleur" d'un chemin pour désigner la valeur de sa communauté. Les catégories définies ici sont en gros modélisées sur celles décrites dans [WANG] et [HUSTON].

 	2.1	Homologues et échange de trafic
Considérons deux fournisseurs de services réseau, A et B. Les fournisseurs de services A et B sont définis comme étant des homologues quand (i) A et B échangent des routes via BGP, et (ii) l'échange de trafic entre A et B est libre de facturation. Cet arrangement est aussi normalement connu comme de l'échange de trafic (peering). Les homologues échangent normalement seulement leurs chemins d'utilisateurs respectifs (voir "Routes de consommateur" ci-dessous) et donc échangent seulement leur trafic de consommateur respectif. Voir dans [HUSTON] une discussion plus détaillée des modèles commerciaux autour des homologues et de l'échange de trafic.

 	2.2	Routes de consommateur
Les routes de consommateur sont celles qui sont entendues d'un consommateur via BGP et sont propagées aux homologues et autres consommateurs. Noter qu'un consommateur peut être une entreprise ou un autre fournisseur de service réseau. Ces routes sont parfois appelées routes de client [HUSTON].

 	2.3	Routes d'homologue
Les routes d'homologues sont les routes apprises des homologues via BGP, et non propagées aux autres homologues. En particulier, ces routes sont seulement propagées aux consommateurs du fournisseur de services.

 	2.4	Routes internes
Les routes internes sont celles que génère un fournisseur de services et qu'il passe à ses homologues et consommateurs. Ces routes sont fréquemment prises dans l'espace d'adresses alloué à un fournisseur.

 	2.5	Routes internes plus spécifiques
Les routes internes plus spécifiques sont celles qui sont fréquemment utilisées pour les besoins d'équilibrage de charge des circuits et la réduction de routes du protocole de passerelle intérieure (IGP, Interior Gateway Protocol). Elles peuvent aussi correspondre à des services aux consommateurs qui ne sont pas visibles en dehors du réseau du fournisseur de services. Les routes internes plus spécifiques ne sont exportées à aucun homologue externe.

 	2.6	Routes à destination particulière
Les routes à destination particulière sont celles qui ne rentrent dans aucune des autres classes décrites ici. Dans le cas où de telles routes ont besoin d'être distinguées, un fournisseur de services peut les colorier avec une valeur unique. Des exemples de routes à destination particulière incluent des routes d'envoi à la cantonade et des routes pour des réseaux superposés.

 	2.7	Routes vers l'amont
Les routes vers l'amont sont normalement apprises d'un fournisseur de services amont au titre d'un contrat de service de transit exécuté avec le fournisseur amont.

 	2.8	Routes nationales
Ce sont des ensembles de routes qui ont leur source et/ou sont reçues au sein d'un pays particulier.

 	2.9	Routes régionales
Plusieurs cœurs de réseau mondiaux mettent en œuvre une politique régionale fondée sur leur empreinte de déploiement et leurs impératifs stratégiques et d'affaires. Les fournisseurs de services ont souvent des interconnexions gratuites dans des systèmes autonomes (AS, Autonomous System) dans une région, et ce même AS est un consommateur dans une autre région. Cela rend obligatoire l'utilisation d'un acheminement régional, incluant des attributs de communauté réglés par le réseau en question pour permettre une discrimination facile entre les routes régionales. Par exemple, les fournisseurs de services peuvent traiter un ensemble de routes reçues d'un autre fournisseur de services en Europe différemment du même ensemble de routes reçu en Amérique du Nord, car il est de pratique courante de vendre le transit dans une région alors qu'on fait un échange de trafic dans l'autre.

 	3.	Codages et valeurs de communauté de la RFC 1997

Dans cette section, on donne les valeurs de communauté de la [RFC1997] pour les catégories décrites ci-dessus. Les communautés de la RFC 1997 sont codées avec le code de type BGP 8, et sont traitées comme des valeurs de 32 bits allant de 0x0000000 à 0xFFFFFFF. Les valeurs de 0x0000000 à 0x0000FFFF et de 0xFFFF0000 à 0xFFFFFFFF sont réservées.

Les bonnes pratique actuelles entre fournisseurs de services sont d'utiliser les deux octets de poids fort pour représenter le numéro d'AS du fournisseur, et les deux octets de moindre poids pour représenter la classification de la route, comme décrit 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            <AS>               |         <Valeur>              |
+---------------+---------------+---------------+---------------+

où <AS> est le numéro d'AS de 16 bits. Par exemple, le codage 0x2A7C029A représente l'AS 10876 avec la valeur 666.

 	4.	Valeurs de communauté pour collection de données BGP

Dans cette section, on définit le codage de communauté de la RFC 1997 pour les types de route décrits ci-dessus pour l'utiliser dans la collecte de données BGP. Il est prévu que les valeurs de communauté interne d'un fournisseur de service soient converties en ces valeurs standard pour être utilisées dans un collecteur de routes.

Le présent mémoire suit les bonnes pratiques actuelles d'utiliser le format de base <AS>:<Valeur>. Les valeurs des catégories de routes sont décrites dans le tableau suivant :

Catégorie	Valeur
Réservé	<AS>:0000000000000000
Routes de consommateur	<AS>:0000000000000001
Routes d'homologue	<AS>:0000000000000010
Routes internes	<AS>:0000000000000011
Routes internes plus spécifiques	<AS>:0000000000000100
Routes à destination particulière	<AS>:0000000000000101
Routes vers l'amont	<AS>:0000000000000110
Réservé	<AS>:0000000000000111 - <AS>:0000011111111111
Routes nationales et régionales	<AS>:0000100000000000 - <AS>:1111111111111111
Codé comme 	<AS>:<R><X><CC>
valeurs nationales et régionales réservées 	<AS>:0100000000000000 - <AS>:1111111111111111

où
<AS> sont les 16 bis de l'AS
<R> sont les 5 bits de l'identifiant de région
<X> est le bit d'indication de liaison par satellite. X = 1 pour les liaisons par satellite, 0 autrement.
<CC> sont les 10 bits du code de pays de la norme ISO-3166-2 [ISO3166].
et <R> prend les valeurs :
Afrique (AF)	00001
Océanie (OC)	00010
Asie (AS)	00011
Antarctique (AQ)	00100
Europe (EU)	00101
Amérique Latine/Caraïbes (LAC)	00110
Amérique du Nord (NA)	00111
Réservé	01000-11111

C'est-à-dire que :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            <AS>               |   <R>   |X|        <CC>       |
+---------------+---------------+---------+-+---+---------------+

Par exemple, le codage pour une route nationale sur une liaison terrestre dans l'AS 10876 provenant des îles Fidji serait :
<AS> = 10876 = 0x2A7C
<R>   = 00010
<X>   = 0
<CC>  = code de pays des îles Fidji = 242 = 0011110010

Dans ce cas, les 16 bits de moindre poids sont 0001000011110010 = 0x10F2.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           0x2A7C              |           0x10F2              |
+---------------+---------------+---------------+---------------+

Noter qu'un langage de configuration pourrait permettre la spécification de cette communauté comme 10876:4338 (0x10F2 == 4338 en décimal).

Finalement, on notera que ces catégories ne sont pas destinées à être mutuellement exclusives, et plusieurs communautés peuvent être rattachées lorsque approprié.

 	4.1	Communautés étendues
Dans certains cas, les valeurs et leur codage décrits à la Section 4 peuvent entrer en conflit avec les allocations de communauté existantes d'un fournisseur de services. Les communautés étendues[RFC4360] fournissent un mécanisme pratique qui peut être utilisé pour éviter de tels conflits.

L'attribut Communautés étendues est un attribut transitif facultatif de BGP avec le code de type 16 et consiste en un ensemble de communautés étendues du format 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 haut    |  Type bas(*)  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Valeur               |
|                                                               |
+---------------+---------------+---------------+---------------+

Pour les besoins de la collecte des données BGP, on code les communautés décrites à la Section 4 en utilisant le type de communauté étendu de deux octets spécifique de l'AS, qui a le format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      0x00     |  Sous type    |    Administrateur mondial     |
+---------------+---------------+---------------+---------------+
|                     Administrateur local                      |
+---------------+---------------+---------------+---------------+

L'attribut Communauté étendu de deux octets spécifique de l'AS code le numéro deux octets de système autonome du fournisseur de services (alloué par un registre régional de l'Internet, ou RIR) dans le champ Administrateur mondial, et le champ Administrateur local peut coder toute information.

Le présent mémoire alloue le sous type 0x0008 pour la collecte de données BGP, et spécifie que le champ <Valeur>, comme défini au paragraphe 3.1, est porté dans les octets de moindre poids du champ Administrateur local. Les deux octets de poids fort du champ Administrateur local sont réservés, et sont réglés à 0x00 à l'envoi et ignorés à réception.

Par exemple, le codage de communauté étendue pour 10876:4338 (représentant une route terrestre nationale dans l'AS 10876 des îles Fidji) serait :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      0x00     |      0x0008   |           0x2A7C              |
+---------------+---------------+---------------+---------------+
|      0x00     |      0x00     |           0x10F2              |
+---------------+---------------+---------------+---------------+

 	4.2	Communautés étendues spécifiques d'AS de quatre octets
Les quatre octets spécifique d'AS de la communauté étendue sont codés comme suit :
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      0x02     |    0x0008     |   Administrateur mondial      |
+---------------+---------------+---------------+---------------+
| Administrateur mondial (suite)|           0x10F2              |
+---------------+---------------+---------------+---------------+

Dans ce cas, les quatre octets du sous champ Administrateur mondial contiennent un numéro de système autonome de quatre octets alloué par l'IANA.

 	5.	Note sur la mise en paquet de BGP UPDATE

Noter que les communautés de collecte de données ont la possibilité de rendre l'ensemble d'attributs d'une route spécifique plus unique qu'il ne serait autrement (car chaque route collecte des données qui sont spécifiques de son chemin dans un ou plusieurs AS). Ceci peut à son tour affecter la possibilité de grouper plusieurs routes dans le même message de mise à jour BGP, et cela peut conduire à une augmentation de l'utilisation de bande passante, de cycles de CPU de routeur, et de mémoire.

 	6.	Remerciements

Le codage de communauté décrit dans le présent mémoire provient d'une intéressante suggestion de Akira Kato à WIDE. En particulier, l'idée était d'utiliser les valeurs de collecte de communauté pour choisir des chemins qui résulteraient (on l'espère) en un accès plus efficace à divers services. Par exemple, dans le cas du service d'envoi à la cantonade du DNS fondé sur la [RFC3258], les routeurs BGP peuvent voir plusieurs chemins pour le même préfixe, et d'autres pourraient être en provenance de la même origine avec des chemins différents, mais d'autres pourraient être de différentes régions/pays (avec le même AS d'origine).

Joe Abley, Randy Bush, Sean Donelan, Xenofontas Dimitropoulos, Vijay Gill, John Heasley, Geoff Huston, Steve Huter, Michael Patton, Olivier Marce, Ryan McDowell, Rob Rockell, Rob Thomas, Pekka Savola, Patrick Verkaik, et Alex Zinin ont tous fait des commentairss pertinents sur les versions antérieures de ce document. Henk Uijterwaal a suggéré d'utiliser les codes de pays de la norme ISO-3166-2.

 	7.	Considérations sur la sécurité

Bien que le présent mémoire n'introduise pas de considérations de sécurité supplémentaires dans le protocole BGP, les informations contenues dans les communautés définies dans ce mémoire peuvent dans certains cas révéler la structure du réseau qui n'était pas visible précédemment en dehors du réseau du fournisseur. Par suite, on devrait faire attention quand on exporte de telles communautés aux collecteurs de routes. Finalement, les routes exportées à un collecteur de routes devraient aussi être étiquetées avec la communauté NO_EXPORT (0xFFFFFF01).

 	7.1	Longueur totale de l'attribut Chemin
Les communautés décrites dans le présent mémoire sont destinées à être utilisées en sortie d'un collecteur de routes. Donc un opérateur peut choisir d'écraser ses communautés internes avec les valeurs spécifiées dans le présent mémoire quand il exporte ses routes à un collecteur de routes. Cependant, les opérateurs devraient en général s'assurer que le comportement de leur mise en œuvre de BGP est bien défini quand l'ajout d'un attribut cause le dépassement de 4096 octets par la PDU. Par exemple, comme il est de pratique courante d'utiliser des attributs de communauté pour mettre en œuvre une politique (entre autres fonctionnalités comme de permettre aux consommateurs de régler des attributs comme LOCAL_PREF) le comportement d'une mise en œuvre quand l'espace d'attributs est plein est crucial. Entre autres comportements, une mise en œuvre pourrait usurper les données de l'attribut prévu ou autrement causer des défaillances indéterminées. Ces comportements peuvent résulter en l'établissement d'attributs de communauté imprévus, et donc résulter en des implications de politique imprévues.

 	8.	Considérations relatives à l'IANA

Le présent mémoire alloue un nouveau sous type pour le type de communauté étendue spécifique d'AS dans la catégorie premier arrivé premier servi. L'IANA a alloué le sous type 0x0008 comme défini au paragraphe 4.1.

De plus, l'IANA a créé deux registres pour les communautés de collecte de données BGP, une pour les communautés standard et une pour les communautés étendues. Ces deux registres vont être initialement remplis par les valeurs décrites à la Section 4. Le consensus de l'IETF, comme décrit dans la [RFC2434], normalement à travers le groupe de travail Opérations d'acheminement mondial (grow), est exigé pour l'allocation de nouvelles valeurs dans ces registres (en particulier, pour <Valeur> ou <R> dans le tableau des valeurs de catégories de routes de la Section 4).

 	9.	Références
 	9.1	Références normatives

[ISO3166]	"ISO 3166 Maintenance agency (ISO 3166/MA)", à http://www.iso.org/iso/en/prods-services/iso3166ma/index.html , 2004.

[RFC1771]	Y. Rekhter, T. Li , "Protocole de routeur frontière v. 4 (BGP-4)", mars 1995. (Obsolète, voir RFC4271) (D.S.)

[RFC1997]	R. Chandra, P. Traina, T. Li, "Attribut Community de BGP", août 1996. (P.S.)

[RFC4360]	S. Sangli et autres, "Attribut BGP-4 Communauté étendue", février 2006. (P.S.)

 	9.2	Références pour information

[HUSTON]	Huston, G., "Interconnection, Peering, and Settlements", http://www.isoc.org/inet99/proceedings/1e/1e_1.htm 

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

[RFC3258]	T. Hardie, "Distribution des serveurs de noms d'autorité via des adresses partagées en envoi individuel", avril 2002. (Info.)

[RFC4761]	K. Kompella et Y. Rekhter, éditeurs "Service de LAN privé virtuel (VPLS) utilisant BGP pour l'auto découverte et la signalisation", janvier 2007. (P.S. ; MàJ par RFC8395)

[RIS]	"The RIPE Routing Information Service", à http://www.ripe.net/ris , 2004.

[RV]	Meyer, D., "The Routeviews Project", à http://www.routeviews.org , 2002.

[WANG]	Wang, F. and L. Gao, "Inferring and Characterizing Internet Routing Policies", ACM SIGCOMM Internet Measurement Conference 2003.

 	Adresse de l'auteur
David Meyer
mél : dmm@1-4-5.net 

 	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 administratif (IASA) de l'IETF.