Groupe de travail Réseau	S. Sangli, Cisco Systems	
Request for Comments : 4360	D. Tappan, Cisco Systems	
Catégorie : Sur la voie de la normalisation	Y. Rekhter, Juniper Networks	
Traduction Claude Brière de L'Isle	février 2006	

Attribut Communautés étendues de BGP

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écrit l'attribut "Communauté étendue" de BGP-4. Cet attribut fournit un mécanisme pour étiqueter les informations portées dans BGP-4. Ces étiquettes peuvent être utilisées pour contrôler la distribution de ces informations, ou pour d'autres applications.
Table des matières
1. Introduction	1
1.1 Spécification des exigences	2
2. Attribut BGP Communautés étendues	2
3. Types BGP de communauté étendue définis	3
3.1 Communauté étendue spécifique d'AS de deux octets	3
3.2 Communauté étendue spécifique d'adresse IPv4	3
3.3 Communauté étendue opaque	4
4. Communauté de cible de chemin	4
5. Communauté d'origine de chemin	4
6. Opérations	5
7. Considérations relatives à l'IANA	5
8. Considérations sur la sécurité	6
9. Remerciements	6
10. Références normatives	6
11. Références pour information	7
Adresse des auteurs	7
Déclaration complète de droits de reproduction	7

 	1.	Introduction

L'attribut Communauté étendue fournit un mécanisme pour étiqueter les informations portées dans BGP-4 [RFC4271]. Il fournit deux améliorations importantes à l'attribut existant de communauté BGP [RFC1997] :
- une gamme, étendue, assurant que les communautés peuvent être allouées pour d'innombrables usages, sans crainte de recouvrement,
- l'ajout d'un champ Type fournit une structure pour l'espace de communauté.

L'ajout d'une structure permet l'usage d'une politique fondée sur l'application pour laquelle la valeur de communauté va être utilisée. Par exemple, on peut filtrer toutes les communautés d'un type particulier, ou permettre seulement certaines valeurs pour un type particulier de communauté. Il permet aussi de spécifier si une communauté particulière est transitive ou non transitive à travers la frontière d'un système autonome (AS, Autonomous System). Sans une structure, cela ne peut être réalisé qu'en énumérant explicitement toutes les valeurs de communauté qui vont être refusées ou acceptées et passées aux locuteurs BGP dans les AS voisins sur la base de la propriété transitive.

 	1.1	Spécification 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.	Attribut BGP Communautés étendues

L'attribut Communautés étendues est un attribut BGP transitif facultatif, dont le code de type est 16. L'attribut consiste en un ensemble de "communautés étendues". Tous les chemins avec l'attribut Communautés étendues appartiennent aux communautés mentionnées dans l'attribut.

Chaque communauté étendue est codée comme une quantité de huit octets, comme suit :

- Champ Type : 1 ou 2 octets
- Champ Valeur : octets restants

 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               |
|                                                               |
+---------------+---------------+---------------+---------------+

(*) Présent seulement pour les types étendus, autrement, utilisé pour le champ Valeur.

Champ Type : deux classes de champ Type sont introduites : type régulier et type étendu.
La taille du champ Type pour les types réguliers est 1 octet, et la taille du champ Type pour les types étendus est 2 octets.
La valeur de l'octet de poids fort du champ Type détermine si une communauté étendue est de type régulier ou étendu. La classe d'un type (régulier ou étendu) n'est pas codée dans la structure du type lui-même. La classe d'un type est spécifiée dans le document qui définit le type et le registre IANA.
L'octet de poids fort du champ Type est montré ci-dessous :

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|I|T|           |
+-+-+-+-+-+-+-+-+

I : bit d'autorité IANA
Valeur 0 : type alloué par l'IANA en utilisant la politique "premier arrivé premier servi".
Valeur 1 : une partie de cet espace de champ Type est pour les types alloués par l'IANA en utilisant la politique soit d'action de normalisation soit d'allocation précoce par l'IANA. Le reste de cet espace de champ Type est pour les utilisations expérimentales.

T : bit transitif
Valeur 0 : la communauté est transitive à travers les AS,
Valeur 1 : la communauté n'est pas transitive à travers les AS.

Les 6 bits restants indiquent la structure de la communauté

Champ Valeur : le codage du champ Valeur dépend du "type" de la communauté tel que spécifié par le champ Type.

Deux communautés étendues sont déclarées égales quand tous les 8 octets de la communauté sont égaux.

Les deux membres du couple <Type, Valeur> devraient être cités pour spécifier toute valeur de communauté. Les octets restants de la communauté sont interprétés sur la base de la valeur du champ Type.

 	3.	Types BGP de communauté étendue définis

Cette Section introduit quelques types étendus et définit le format du champ Valeur pour ces types. Les types introduits ici fournissent des "gabarits", où chaque gabarit est identifié par l'octet de poids fort du champ Type de la communauté étendue, et l'octet de moindre poids (sous type) est utilisé pour indiquer un type particulier de communauté étendue.

 	3.1	Communauté étendue spécifique d'AS de deux octets
C'est un type étendu dont le champ Type est composé de deux octets et le champ Valeur est composé de six octets.

 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 ou 0x40  |  sous type    |    Administrateur global      |
+---------------+---------------+---------------+---------------+
|                     Administrateur local                      |
+---------------+---------------+---------------+---------------+

La valeur de l'octet de poids fort de ce type étendu est 0x00 ou 0x40. L'octet de moindre poids de ce type étendu est utilisé pour indiquer les sous types.

Le champ Valeur consiste en deux sous champs :

Sous champ Administrateur global : 2 octets
Ce sous champ contient un numéro de système autonome alloué par l'IANA.

Sous champ Administrateur local : 4 octets
L'organisation identifiée par le numéro de système autonome dans le sous champ Administrateur global peut coder toute information dans ce sous champ. Le format et la signification de la valeur codée dans ce sous champ devraient être définis par le sous type de la communauté.

 	3.2	Communité étendue spécifique d'adresse IPv4
C'est un type étendu avec un champ Type composé de deux octets et un champ Valeur composé de six octets.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 ou 0x41  |  Sous type    |    Administrateur global      |
+---------------+---------------+---------------+---------------+
| Administrateur global (suite) |    Administrateur local       |
+---------------+---------------+---------------+---------------+

La valeur de l'octet de poids fort de ce type étendu est 0x01 ou 0x41. L'octet de moindre poids de ce type étendu est utilisé pour indiquer les sous types.

Le champ Valeur consiste en deux sous champs :

Sous champ Administrateur global : 4 octets
Ce sous champ contient une adresse IPv4 d'envoi individuel allouée par un des registres Internet.

Sous champ Administrateur local : 2 octets
L'organisation à qui a été allouée l'adresse IPv4 dans le sous champ Administrateur global peut coder toute information  dans ce sous champ. Le format et la signification de cette valeur codée dans ce sous champ devraient être définis par le sous type de la communauté.

 	3.3	Communauté étendue opaque
C'est un type étendu dont le champ Type est composé de deux octets et le champ Valeur est composé de six octets.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 ou 0x43  |  Sous type    |              Valeur           |
+---------------+---------------+---------------+---------------+
|                         Valeur (suite)                        |
+---------------+---------------+---------------+---------------+

La valeur de l'octet de poids fort de ce type étendu est 0x03 ou 0x43. L'octet de moindre poids de ce type étendu est utilisé pour indiquer les sous types.

C'est une communauté générique de type étendu. La valeur du sous type qui devrait définir le champ Valeur est à allouer par l'IANA.

 	4.	Communauté de cible de chemin

La communauté de cible de chemin identifie un ou plusieurs routeurs qui peuvent recevoir un ensemble de chemins (qui portent cette communauté) portés par BGP. Ceci est transitif à travers la frontière du système autonome.

La communauté de cible de chemin est un type étendu.

La valeur de l'octet de poids fort du champ Type pour la communauté de cible de chemin peut être 0x00, 0x01, ou 0x02. La valeur de l'octet de moindre poids du champ Type pour cette communauté est 0x02.

Quand la valeur de l'octet de poids fort du champ Type est 0x00 ou 0x02, le sous champ Administrateur local contient un nombre provenant de l'espace de numérotation qui est administré par l'organisation à laquelle le numéro de système autonome porté dans le sous champ Administrateur global a été alloué par une autorité appropriée.

Quand la valeur de l'octet de poids fort du champ Type est 0x01, le sous champ Administrateur local contient un nombre provenant de l'espace de numérotation qui est administré par l'organisation à laquelle l'adresse IP portée dans le sous champ Administrateur global a été allouée par une autorité appropriée.

Une utilisation possible de la communauté de cible de chemin est spécifiée dans la [RFC4364].

 	5.	Communauté d'origine de chemin

La communauté d'origine de chemin identifie un ou plusieurs routeurs qui injectent un ensemble de chemins (qui portent cette communauté) dans BGP. Ceci est transitif à travers la frontière de système autonome.

La communauté d'origine de chemin est d'un type étendu.

La valeur de l'octet de poids fort du champ Type pour la communauté d'origine de chemin peut être 0x00, 0x01, ou 0x02. La valeur de l'octet de moindre poids du champ Type pour cette communauté est 0x03.

Quand la valeur de l'octet de poids fort du champ Type est 0x00 ou 0x02, le sous champ Administrateur local contient un nombre provenant d'un espace de numérotation qui est administré par l'organisation à laquelle le numéro  de système autonome porté dans le sous champ Administrateur global a été alloué par une autorité appropriée.

Quand la valeur de l'octet de poids fort du champ Type est 0x01, le sous champ Administrateur local contient un nombre provenant d'un espace de numérotation qui est administré par l'organisation à laquelle l'adresse IP portée dans le sous champ Administrateur global a été allouée par une autorité appropriée.

Une utilisation possible de la communauté d'origine de chemin est spécifiée dans la [RFC4364].

 	6.	Opérations

Un locuteur BGP peut utiliser l'attribut Communautés étendues pour contrôler quelles informations d'acheminement il accepte ou distribue à ses homologues.

L'attribut Communautés étendues NE DOIT PAS être utilisé pour modifier l'algorithme BGP de choix du meilleur chemin d'une façon qui conduise à des boucles de transmission.

Un locuteur BGP qui reçoit un chemin qui n'a pas l'attribut Communautés étendu PEUT ajouter cet attribut au chemin quand il le propage à ses homologues.

Un locuteur BGP qui reçoit un chemin avec l'attribut Communautés étendu PEUT modifier cet attribut en accord avec la politique locale.

Par défaut si une gamme de chemins doit être agrégée et que les attributs de chemin des agrégats résultants ne portent pas l'attribut ATOMIC_AGGREGATE, l'agrégat résultant devrait alors avoir un attribut de chemin Communautés étendues qui contient l'union de toutes les communautés étendues provenant de tous les chemins agrégés. Le comportement par défaut pourrait être outrepassé via une configuration locale, et dans ce cas, le traitement de l'attribut Communautés étendu en présence d'une agrégation de chemins devient l'affaire de la politique locale du locuteur BGP qui effectue l'agrégation.

Si un chemin est une communauté étendue non transitive, alors avant d'annoncer le chemin à travers la frontière du système autonome, la communauté DEVRAIT être retirée du chemin. Cependant, la communauté NE DEVRAIT PAS être retirée quand le chemin est annoncé à travers la frontière de la confédération BGP.

Un chemin peut porter à la fois l'attribut BGP Communautés, comme défini dans la [RFC1997]), et l'attribut BGP Communautés étendues. Dans ce cas, l'attribut BGP Communautés est traité comme spécifié dans la [RFC1997], et l'attribut BGP Communautés étendues est traité comme spécifié dans le présent document.

 	7.	Considérations relatives à l'IANA

Toutes les communautés étendues de BGP contiennent un champ Type. L'IANA a créé un registre intitulé, "Type de communautés étendues BGP". L'IANA va tenir ce registre.

Le type peut être régulier ou étendu. Pour un type régulier, l'IANA alloue une valeur de 8 bits ; pour un type étendu, l'IANA alloue une valeur de 16 bits.

La valeur allouée pour un type régulier NE DOIT PAS être réutilisée comme valeur de l'octet de poids fort lors de l'allocation d'un type étendu. La valeur de l'octet de poids fort allouée pour un type étendu NE DOIT PAS être réutilisée pour l'allocation d'un type régulier.

Le champ Type indique si la communauté étendue est transitive ou non. Les futures demandes d'allocation d'une valeur de type devront spécifier si la valeur de type est destinée à une communauté étendue transitive ou non transitive.

Les futures allocations devront être faites en utilisant soit le processus d'action de normalisation défini dans la [RFC2434], soit le processus IANA d'allocation précoce défini dans la [RFC4020], soit la politique de "premier arrivé premier servi" définie dans la [RFC2434].

Le tableau suivant résume les gammes d'allocation des types :

Type	Action de normalisation	Premier arrivé premier servi
	Allocation précoce de l'IANA
regulier, transitif	0x90-0xbf	0x00-x3f
regulier, non transitif	0xd0-0xff	0x40-0x7f
étendu, transitif	0x9000-0xbfff	0x0000-0x3fff
étendu, non transitif	0xd000-0xffff 	0x4000-0x7fff

Les allocations consistent en un nom et la valeur.

Les valeurs de type 0x80-0x8f et 0xc0-0xcf pour les types réguliers, et 0x8000-0x8fff et 0xc000-0xcfff pour les types étendus sont pour utilisation expérimentale comme défini dans la RFC 3692.

Le présent document définit une classe de communautés étendues appelée "communauté étendue spécifique d'AS de deux octets" pour laquelle l'IANA va créer et tenir un registre intitulé "Communauté étendue spécifique d'AS de deux octets". Toutes les communautés dans cette classe sont des types étendus. Les futures allocations devront être faites en utilisant la politique de "premier arrivé premier servi" définie dans la [RFC2434]. Les valeurs de type pour les communautés transitives de la classe communauté étendue spécifique d'AS de deux octets sont de 0x0000 à 0x00ff, et pour les communautés non transitives de cette classe sont de 0x4000 à 0x40ff. Les allocations consistent en un nom  et la valeur.

Le présent document fait les allocations suivantes pour la communauté étendue spécifique d'AS de deux octets :

Nom	Valeur du type
Cible de chemin spécifique d'AS de deux octets	0x0002
Origine de chemin spécifique d'AS de deux octets	0x0003

Le présent document définit une classe de communautés étendues appelée "Communauté étendue spécifique d'adresse IPv4" pour laquelle l'IANA va créer et tenir un registre intitulé "Communauté étendue spécifique d'adresse IPv4". Toutes les communautés dans cette classe sont des types étendus. Les futures allocations devront être faites en utilisant la politique de "premier arrivé premier servi" définie dans la [RFC2434]. Les valeurs de type pour les communautés transitives de la classe communauté étendue spécifique d'adresse IPv4 sont de 0x0100 à 0x01ff, et pour les communautés non transitives de cette classe sont de 0x4100 à 0x41ff. Les allocations consistent en un nom  et la valeur.

Le présent document fait les allocations suivantes pour la communauté étendue spécifique d'adresse IPv4 :

Nom	Valeur du type
Cible de chemin spécifique d'adresse IPv4	0x0102
Origine de chemin spécifique d'adresse IPv4	0x0103

Le présent document définit une classe de communautés étendues appelée "Communauté étendue opaque" pour l'aquelle l'IANA va créer et tenir un registre intitulé "Communauté étendue opaque". Toutes les communautés dans cette classe sont des types étendus. Les futures allocations devront être faites en utilisant la politique de "premier arrivé premier servi" définie dans la [RFC2434]. Les valeurs de type pour les communautés transitives de la classe communauté étendue opaque sont de 0x0300 à 0x03ff, et pour les communautés non transitives de cette classe sont de 0x4300 à 0x43ff. Les allocations consistent en un nom  et la valeur.

Quand on demande une allocation de plus d'un des registres définis ci dessus, on peut demander d'allouer la même valeur de type dans ces registres. Si possible, l'IANA devrait satisfaire de telles demandes.

 	8.	Considérations sur la sécurité

Cette extension à BGP a des implications sur la sécurité similaires à celles des Communautés BGP [RFC1997].

Cette extension à BGP ne change pas les questions de sécurité sous-jacentes. Spécifiquement, un opérateur qui s'appuie sur les informations portées dans BGP doit avoir une confiance transitive en la source de l'information. Spécifier le ou les mécanismes pour fournir une telle relation sort du domaine d'appplication du présent document.

 	9.	Remerciements

Les auteurs remercient John Hawkinson, Jeffrey Haas, Bruno Rijsman, Bill Fenner, et Alex Zinin de leurs suggestions et retours.

 	10.	Références normatives

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

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

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

[RFC4020]	K. Kompella et A. Zinin, "Allocation précoce par l'IANA de codets pour des RFC en cours de normalisation", BCP 100, février 2005. (Remplacée par RFC7120)

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

 	11.	Références pour information

[RFC4364]	E. Rosen et Y. Rekhter, "Réseaux privés virtuels IP BGP/MPLS", février 2006. (P.S., MàJ par RFC4577, RFC4684)

 	Adresse des auteurs

Srihari R. Sangli	Dan Tappan	Yakov Rekhter	
Cisco Systems, Inc.	Cisco Systems, Inc.	Juniper Networks, Inc.	
mél : rsrihari@cisco.com 	250 Apollo Drive	1194 N. Mathilda Ave	
	Chelmsford, MA 01824	Sunnyvale, CA 94089	
	USA	USA	
	mél : tappan@cisco.com 	mél : yakov@juniper.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 administatif (IASA) de l'IETF.