Résumé

  • AMS-IX exploite deux serveurs de routes amstellodamois sous AS6777, rs1.ams-ix.net et rs2.ams-ix.net ; adhérer suppose de s'y connecter aux deux.
  • La norme n'impose qu'un seul comportement, la transmission intacte du NEXT_HOP, et classe la préservation de l'AS_PATH et du MED parmi les recommandations, avec un motif explicite.
  • Le seul partage de responsabilités noir sur blanc dans la documentation publiée place la cohérence de la liste de préfixes et la conformité de la configuration chez le participant.

Un réseau qui rejoint le serveur de routes de la place d'Amsterdam cesse de construire une session par pair pour n'en construire qu'une vers une machine qui réannonce ce que les autres annoncent. AMS-IX en publie deux : rs1.ams-ix.net sur 80.249.208.255 et 2001:7f8:1::a500:6777:1, rs2.ams-ix.net sur 80.249.209.0 et 2001:7f8:1::a500:6777:2, l'un comme l'autre sous AS6777. Les conditions sont précises — se connecter aux deux, annoncer des nombres et des longueurs de préfixes identiques de part et d'autre, ouvrir la session sur le port TCP 179 — et la documentation AMS-IX du serveur de routes les énonce sans détour.

Ce qu'elle ne fait pas, c'est engager l'exploitant sur un ensemble symétrique de garanties. Elle décrit un comportement. Les obligations qu'elle détaille sont celles du participant.

La seule chose que la norme ne négocie pas

RFC 7947 définit le serveur de routes d'un point d'échange, et son exigence la plus ferme porte sur une adresse : « the NEXT_HOP attribute MUST be passed unmodified » (section 2.2.1, septembre 2016). Cette phrase explique pourquoi un serveur de routes n'est un routeur dans aucun sens qui compte pour un paquet. Le prochain saut que voit le client est l'adresse du pair annonceur sur la matrice de commutation ; le trafic traverse donc la matrice de pair à pair et ne passe jamais par la machine qui a parlé BGP en son nom. RFC 7948, le document d'exploitation publié le même mois, trace la même frontière : distribuer une information de joignabilité n'est pas acheminer du trafic.

Tout le reste de la section consacrée aux attributs est plus souple, et volontairement. Le serveur de routes « SHOULD NOT prepend its own AS number » à ce qu'il relaie (section 2.2.2.1). Il propage le MULTI_EXIT_DISC et « SHOULD NOT modify its value » (section 2.2.3). La section 2.2 fait de la transparence des attributs le comportement par défaut tout en autorisant explicitement des exceptions lorsque la configuration locale le justifie, et la section 2.1 admet purement et simplement le filtrage par politique.

Le RFC donne son motif pour s'arrêter au niveau SHOULD sur l'AS_PATH : un parc installé de clients anciens rejette une session dont le premier AS est inattendu, et une règle impérative les aurait laissés sur le carreau. La norme impose donc aux implémentations de permettre la désactivation du contrôle du premier AS, de préférence par pair, plutôt que d'assumer la garantie plus lourde. C'est un compromis d'ingénierie déguisé en niveau d'exigence, et cela compte pour quiconque croyait la place engagée par un devoir absolu de laisser ses attributs de chemin tranquilles.

Ce que l'exploitant met réellement au procès-verbal

AMS-IX publie sa moitié de l'arrangement. Le serveur n'insère pas AS6777 dans les AS_PATH des routes relayées, et les contrôles du premier AS doivent être désactivés là où ils s'appliquent. Les pairs d'export se choisissent par entrées RPSL et par communautés : la communauté 0:6777 bloque tout export, 6777: active un pair choisi, et les nouvelles sessions passent par défaut sur un filtrage combiné IRRDB et RPKI. Les routes apprises peuvent servir le participant et ses clients en aval, mais leur redistribution vers des transitaires, des pairs externes ou le serveur de routes d'un autre point d'échange est interdite.

Deux phrases de ce texte méritent d'être lues deux fois. La première avertit que les données IRRDB et RPKI ne comportent aucune garantie de validité et ne doivent pas être utilisées seules — c'est la description, par l'exploitant lui-même, du filtrage qu'il applique par défaut. La seconde est la clause de responsabilité : « Participants are responsible for ensuring that their routing configuration complies with this policy. »

RFC 7948 était arrivé à la même répartition bien avant. Il décrit la responsabilité du client, chargé de veiller à ce que sa liste de préfixes déclarée soit compatible avec ce qu'il annonce (section 4.3), recommande une atténuation des fuites du côté de l'exploitant et demande une comparaison automatisée entre les routes reçues et les listes configurées, partout où un filtrage entrant par client existe.

Le rôle que dessinent les documents est administratif plutôt que tutélaire : le serveur de routes filtre, sélectionne et réannonce, l'exploitant publie ce qu'il fait, et personne n'accepte un devoir de vérification énuméré envers chaque participant pris individuellement.

Ce que je cherchais, et ce que dit le texte

J'allais chercher un marché documenté : une session vers chaque membre, en échange d'une liste publiée de ce que la place vous doit. Les documents n'en couvrent que la première moitié. Le marché est réel — le nombre de sessions s'effondre pour de bon — mais il se paie en exposition et non en niveaux de service. Un MUST catégorique garde les paquets hors du locuteur partagé. Deux SHOULD, un argument de compatibilité et une porte ouverte à la configuration locale laissent les mains libres à l'opérateur sur le chemin et sur le MED.

La lecture utile n'est donc pas qu'AMS-IX néglige son serveur de routes. C'est que l'ensemble est conçu comme un administrateur doté d'un mandat borné : autorisé à prendre des décisions de plan de contrôle, interdit de transmettre le moindre paquet, et redevable pour l'essentiel par du texte publié. Cette lecture est la mienne, pas celle de l'IETF ni celle du point d'échange, et aucune position formelle ne l'énonce.

Ce qu'un participant peut réellement vérifier

La fiche d'annuaire de ce serveur de routes rassemble les mêmes faits publiés au même endroit, et le problème de vérification se niche précisément dans ce qu'ils laissent ouvert. Un participant ne peut pas auditer la conformité interne du locuteur partagé en lisant une page de politique. Il peut en revanche lire les routes qu'il reçoit et confirmer que le prochain saut qu'il voit est bien le pair, et non le serveur de routes. Il peut observer si 0:6777 et 6777: produisent l'export annoncé. Il peut maintenir les deux sessions et comparer ce que chaque serveur envoie, de sorte qu'une divergence apparaisse comme une divergence et non comme un mystère.

La documentation n'est pas datée dans sa version publiée, a été consultée le 12 novembre 2026 et sa validité à la date de parution n'est pas confirmée. Le comportement en production n'a pas été testé ici, et rien n'établit, sur la page examinée, que les valeurs par défaut du filtrage et les communautés d'export se comportent à l'identique sur rs1 et rs2.

Une seule clause de responsabilité explicite, portant sur la cohérence de la liste de préfixes, a été trouvée ; l'absence d'une garantie plus large de l'exploitant sur cette page est une observation sur cette page, non la preuve qu'un tel texte n'existe nulle part ailleurs.

Le résumé honnête de l'échange

Un serveur de routes parle, il n'achemine pas, et la paperasse prend la même forme : une promesse inconditionnelle qui garde le trafic hors de la boîte, et deux promesses conditionnelles qui laissent à la place les coudées franches sur les attributs qui orientent ce trafic. Un réseau qui veut davantage de garanties ne les trouvera pas dans le texte de politique. Il les trouvera, ou pas, dans ses propres routes reçues — exactement là où les documents situent déjà la responsabilité.