Résumé

  • Le projet individuel du 28 octobre propose NEXT_HOP_MTU, attribut BGP facultatif et non transitif de quatre octets pour les routes unicast IPv4 et IPv6. Il exprime la taille de paquet IP acceptable à une frontière identifiée, pas le MTU minimal du trajet complet.
  • Le routeur qui ajoute la valeur part du MTU de son interface de bord. S’il accepte la valeur reçue d’un voisin, il garde la plus petite des deux ; sa politique locale peut encore la diminuer. Le réglage d’un MTU de transfert par destination exige une valeur valable sur tous les chemins de transfert.

Une promesse doit garder l’adresse de celui qui la fait

À l’entrée d’un réseau, un routeur voit une annonce pour un préfixe et connaît le MTU IP de l’interface par laquelle le trafic repart vers le voisin. La proposition lui permet d’attacher cette capacité à la route. Un équipement intérieur dispose alors d’un renseignement qu’il n’avait pas auparavant. Mais ce renseignement concerne le passage annoncé. Une interface plus étroite ailleurs sur le chemin conserve son veto. Le texte interdit d’en faire, à lui seul, un critère de sélection BGP ou un remplaçant de la découverte du MTU de chemin.

Le calcul empêche une promesse de grossir au fil des annonces. Si l’interface locale accepte L et qu’un voisin fournit une valeur R valable et acceptée, le routeur annonce min(L,R). Sinon, il part de L. La politique peut retrancher, jamais ajouter. Il ne peut substituer le MTU d’une interface interne au bord réellement franchi. Dans une session externe multihop, il ne peut fabriquer un bord à partir d’une interface sans rapport ; une valeur configurée doit rester au plus égale à l’interface vers le prochain saut. Cette retenue rend la promesse attribuable.

La proposition traite aussi l’absence comme une information. L’attachement et l’acceptation doivent pouvoir être activés séparément par voisin et famille d’adresses ; rien n’impose de les activer par défaut. Sans attribut, aucune promesse. Un réflecteur de routes qui ne change pas le prochain saut devrait conserver la valeur. À une nouvelle frontière externe, il faut reprendre le minimum. Pour agréger des routes, tous les composants doivent avoir une valeur valable ; pour programmer un MTU de transfert vers une destination, tous les chemins possibles aussi. Une seule branche sans preuve interdit le chiffre commun.

Une valeur mal formée est éliminée selon la logique de la RFC 7606, sans couper la session BGP ni retirer la route. Une modification du MTU au bord impose une nouvelle annonce. Le code d’attribut demandé reste TBD dans le projet ; le registre IANA dira si et quand il reçoit un numéro. Le document avertit qu’une valeur exagérée peut faire perdre des paquets, tandis qu’une valeur trop basse gaspille la capacité ; accepter le chiffre d’un voisin externe relève donc d’un choix de confiance.

La découverte du MTU de chemin en IPv6 reste nécessaire pour la route entière. La fiche IETF présente encore un projet individuel, sans mesure de déploiement. Un essai sur plusieurs frontières, conservant les interfaces, les valeurs reçues et les réductions appliquées, montrerait si chaque chiffre reste lié au passage qu’il décrit.

Sources : projet ; statut IETF ; registre IANA ; RFC 7606 ; RFC 8201.