Mon blog

Depuis le RFC 1997 en août 1996, les annonces BGP effectuées par un routeur sont fréquemment marquées par une communauté, un nombre qui identifie des caractéristiques particulières d'une route, comme, par exemple, le fait qu'elle ne doive pas être réexportée vers d'autres AS. Ces communautés étaient traditionnellement encodées sous la forme { numéro d'AS : valeur de la communauté } en profitant du fait que les communautés du RFC 1997 faisaient quatre octets (deux pour l'AS et deux pour la valeur spécifique à l'AS). Avec l'arrivée des AS sur quatre octets, il fallait un nouveau type de communauté.

Le RFC 1997 recommandait ce type d'encodage, qu'on retrouve dans la documentation des politiques de routage de nombreux AS. Par exemple, whois -h whois.ripe.net AS3356 nous montre :

remarks:        --------------------------------------------------------
remarks:        prefix type communities
remarks:        --------------------------------------------------------
remarks:        3356:123  - Customer route
remarks:        3356:666  - Peer route
remarks:        --------------------------------------------------------
remarks:        error type communities
remarks:        --------------------------------------------------------
remarks:        3356:911  - "internal use" communities received from peer
remarks:        --------------------------------------------------------
remarks:        city communities (some cities not listed as they home off
remarks:        one of the below)
remarks:        --------------------------------------------------------
remarks:        3356:2001 - CHI1 - Chicago
remarks:        3356:2002 - SDG1 - San Diego
remarks:        3356:2003 - LAX1 - Los Angeles
remarks:        3356:2004 - DEN1 - Denver
...

où on voit une communauté encodée sous forme de numéro d'AS (3356), d'un deux-points et d'une valeur.

Mais, depuis le RFC 4893, en mai 2007, les numéros d'AS peuvent faire quatre octets et, à partir du 1er janvier 2010, ce sera même la taille par défaut, distribuée par les RIR. L'ancien encodage ne convenait pas.

Notre RFC 5668 propose donc un nouveau mécanisme. Il s'appuie sur les « communautés étendues » du RFC 4360, qui normalisait un type de communauté n'ayant plus la limitation des quatre octets et où les deux premiers octets indiquaient le type de communauté.

Notre RFC 5668 déclare donc un nouveau type de communauté étendue, pour les AS à quatre octets. Sa structure est détaillé dans la section 2. Le premier octet du champ Type du RFC 4360 vaut 0x02 pour les communautés transitives et 0x42 pour les autres (le tout est enregistré dans le registre IANA). Le champ Valeur de la communauté étendue, pour qui le RFC 4360 réserve six octets est séparé en deux, la partie Global Administrator, qui stocke l'AS sur quatre octets, et la partie Local Administrator, qui stocke une valeur spécifique à l'AS, sur les deux octets restants.

Petit piège mentionné en section 3, bien que ces communautés étendues pour AS 4-octets permettent de représenter les anciens AS 2-octets (en ajoutant des zéros devant), cela ne doit pas être fait, pour éviter qu'une communauté puisse être codée de deux façons différentes (ce qui compliquerait les comparaisons).

Il n'y a pas de nouvelle représentation texte standard de ces communautés, on reprend l'existante, comme dans l'exemple de l'AS 3356 plus haut.