Mon blog

Depuis 1996, le protocole de routage BGP permet d'étiqueter les routes annoncées avec une ou plusieurs communautés, une suite de chiffres sont la signification dépend en général de l'AS qui l'émet. Ces communautés, normalisées dans le RFC 1997, permettent d'indiquer, par exemple, qu'une route a été initialement apprise à tel point d'échange. Mais elles ont plusieurs limitations et ce RFC normalise donc une version améliorée, les communautés étendues.

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 « Extended Communities Attribute ». Il comporte huit octets, un ou deux pour le type et le reste pour les données. Pourquoi un nombre variable d'octets pour le type ? Parce qu'il peut y avoir des types ordinaires (un octet) et des types étendus (deux octets). Par exemple, les communautés pour AS de quatre octets, dans le RFC 5668, utilisent les types étendus. En outre, les deux premiers bits du type indiquent des propriétés qui peuvent être comprises même par un routeur qui n'a jamais vu ces communautés de ce type plus tôt. Le premier bit indique le type d'allocation par l'IANA (0 : allocation en « Premier Arrivé, Premier Servi », 1 : allocation plus restrictive). Le second indique si la communauté est transitive ou pas (si elle doit être transmise aux AS voisins ou pas). Ainsi, même sans avoir lu le RFC 5668, un routeur BGP sait que les communautés de type 0x02 sont transitives (puisque le deuxième bit est à zéro, signe de transitivité).

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 IPv4. Le type vaut 0x01 (si elle est transitive) ou 0x41, les données contiennent l'adresse (évidemment sur quatre octets) et un champ Local Administrator sur deux octets, qui contient ce que veut l'AS émetteur.

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. RFC 4364 pour un exemple d'utilisation). Les routeurs acceptés sont indiqués par leur adresse IP. Un mécanisme analogue permet d'indiquer le routeur d'origine (section 5).

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 RFC 7153.

À 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 http://onesc.net/communities/.