Depuis
Quelles limites des communautés ordinaires sont désormais dépassées (section 1 du RFC) ? Qu'apporte notre RFC ? D'abord, une augmentation de taille, qui permet d'encoder davantage de choses. Ensuite, l'ajout d'un champ « Type » qui permet de donner une structure aux communautés. Il autorise également des traitements (comme de filtrer ou, au contraire de laisser passer) appliqués à toutes les communautés d'un type donné (alors que, avec les communautés ordinaires, le traitement doit être spécifié pour chaque communauté, celles-ci n'ayant aucune structure normalisée).
La section 2 décrit notre nouvel attribut BGP, numéro 16, alias
«
La section 3 passe tout de suite aux applications pratiques en
réservant plusieurs types et en décrivant leur structure. La structure
des données, elle, dépend en effet du type. Ainsi, la section 3.2
spécifie une communauté attachée à une adresse
Autre exemple de communauté étendue, les destinataires de routes
(section 4) où un routeur qui émet une route indique dans la
communauté quels routeurs peuvent recevoir cette annonce (cf.
L'enregistrement des types possibles se fait dans un registre
IANA (cf. section 7). Consulter ce registre permet de voir le
grand nombre d'usages de ces communautés étendues. Rappelons que les
deux premiers bits indiquent si l'allocation est simplement « Premier
Arrivé, Premier Servi » ou plus formelle, et si la communauté est
transitive (transmise aux autres AS) ou pas. À noter que le registre a été par la suite
complètement réorganisé par le
À l'heure actuelle, ces communautés étendues semblent rares dans la nature. Les communautés documentées par les opérateurs (par exemple par Level 3 ou Cable & Wireless) sont généralement des communautés du type traditionnel. Au passage, un bon outil pour examiner les politiques d'étiquetage par communautés des principaux opérateurs est .