GRE-in-UDP RFC 8086 et GENEVE : Polarisation de Hachage ECMP et VPN Multipath

Les infrastructures dorsales de VPN d'entreprise et les architectures de réseaux mondiaux Anycast exigent une très haute extensibilité de bande passante. Lors de l'agrégation de milliers de tunnels clients à travers des fournisseurs d'accès et des interconnexions cloud, le trafic dorsal ne peut dépendre d'une liaison physique unique. Les réseaux modernes à hautes performances s'appuient sur le routage multipath à coût égal (Equal-Cost Multi-Path ou ECMP) et sur les groupes d'agrégation de liens (LAG) pour distribuer les paquets sur des dizaines de chemins parallèles.

Cependant, les protocoles classiques de tunnel point-à-point — en particulier Generic Routing Encapsulation (GRE, RFC 2784) et IP-in-IP (RFC 2003) — rencontrent des dysfonctionnements structurels dans les matrices de commutation modernes. Parce que ces protocoles encapsulent la charge utile interne directement dans des en-têtes IP externes dépourvus de numéros de port de couche transport (Layer 4), les commutateurs intermédiaires de transit s'avèrent incapables d'identifier et de distinguer les flux de données individuels.

Ce phénomène entraîne une sévère polarisation de hachage ECMP (Hash Polarization). Une multitude de sessions de travail indépendantes se retrouvent épinglées sur une liaison physique unique, provoquant congestion, pertes de paquets et gigue de transmission, alors même que les liaisons adjacentes demeurent totalement inoccupées. Pour remédier à ce problème d'infrastructure, l'IETF a publié la norme RFC 8086 (Encapsulation GRE dans UDP) et développé des standards d'encapsulation contemporains tels que GENEVE (RFC 8926).

Le goulot d'étranglement de l'overlay : pourquoi les tunnels VPN traditionnels brisent le routage multipath

Dans un réseau IP classique sans encapsulation d'overlay, les commutateurs de transit répartissent les flux en calculant un hachage ECMP sur les en-têtes de transport. Les sessions TCP et UDP comportent des numéros de port source et destination variés, apportant une entropie naturelle qui permet aux équipements réseau de ventiler régulièrement les paquets entre les chemins physiques disponibles.

Dès que le trafic pénètre dans un tunnel VPN point-à-point traditionnel, cette granularité disparaît :

1. Encapsulation : La passerelle d'entrée enveloppe le paquet IP original (portant la charge utile TCP/UDP) au sein d'un en-tête GRE.
2. Assignation de protocole externe : La passerelle configure le champ Protocol de l'en-tête IP externe sur la valeur 47 (GRE).
3. Perte totale d'entropie : L'en-tête externe ne comporte aucun port de couche 4. L'ensemble des paquets transitant entre la passerelle A (198.51.100.1) et la passerelle B (203.0.113.2) partage exactement les mêmes adresses IP et le même numéro de protocole.

Pour les routeurs de transit des réseaux d'opérateurs, des millions de conversations d'utilisateurs finaux apparaissent alors comme un seul flux indivisible.

Anatomie du hachage ECMP : comment les commutateurs intermédiaires sélectionnent les liaisons physiques

Les routeurs de cœur de réseau et les commutateurs de structure Spine-Leaf s'appuient sur des circuits intégrés spécifiques (ASIC) pour acheminer des millions de paquets par seconde à vitesse filaire. Afin d'empêcher la désynchronisation et le désordre des paquets (qui déclenche des retransmissions TCP prématurées et effondre le débit), les puces de commutation n'utilisent pas d'équilibrage circulaire (Round-Robin). Elles appliquent au contraire une fonction de hachage déterministe (telle que CRC32 ou Jenkins Hash) aux champs d'en-tête.

Le calcul de l'index de liaison physique sortante repose sur une opération modulo :

$$ ext{Index de liaison} = ext{Hash}( ext{Champs de flux}) \pmod N$$

Où $N$ correspond au nombre total de chemins parallèles de coût égal disponibles sur l'équipement (généralement 8, 16, 32 ou 64 liaisons).

Le dilemme du 5-Tuple : absence de ports de transport dans le protocole GRE 47

Les puces ASIC inspectent classiquement un quintuplet standard (5-tuple) : IP source, IP destination, protocole de transport, port source et port destination. Face à un paquet sous protocole 47 :

;; Paquet IP standard (TCP/UDP)
[ En-tête IP externe ] [ En-tête TCP/UDP ] [ Charge utile ]
-> Données de hachage : IP source, IP dest, Protocole (6/17), Ports (Forte entropie)

;; Paquet de tunnel GRE traditionnel (RFC 2784)
[ En-tête IP externe ] [ En-tête GRE ] [ Paquet IP interne ]
-> Données de hachage : IP source, IP dest, Protocole (47), [Pas de ports] (Entropie nulle)

La puce ASIC est contrainte de se replier sur un hachage restreint à deux ou trois champs (adresses IP et protocole 47). Étant donné que ces paramètres demeurent rigoureusement constants sur toute la durée de vie du tunnel, la valeur de hachage calculée est identique pour la totalité des paquets.

Polarisation du hachage : congestion massive sur les réseaux physiques à liaisons multiples

Lorsque plusieurs étages successifs de commutateurs emploient un algorithme identique, la polarisation s'amplifie. La topologie physique subit une surcharge critique concentrée :

[ Flux clients 1..1000 ]
           |
     [ Passerelle A ] (Encapsulation GRE, Proto=47)
           |
   [ Commutateurs transit ] (Calcul ECMP)
     /     |       [Lien 1] [Lien 2] [Lien 3] ... [Lien N]
  100%      0%       0%            0%
(Saturé)  (Inactif) (Inactif)    (Inactif)
           |
     [ Passerelle B ]

Bien que l'infrastructure physique sous-jacente dispose de dizaines de liens à très haute capacité, le tunnel GRE classique condamne l'ensemble des données à emprunter un unique goulet d'étranglement. Cela génère des retards de file d'attente et des pertes de paquets, annihilant l'intérêt du routage multipath.

Architecture de la RFC 8086 : encapsulation de GRE dans des datagrammes UDP

Afin de lever cette contrainte tout en conservant une interopérabilité totale avec les équipements de réseau existants, l'IETF a formalisé la RFC 8086 (Encapsulation GRE dans UDP). Ce standard encapsule la trame GRE complète à l'intérieur d'un en-tête UDP standard :

+-------------------------------------------------------------------+
|         En-tête IP externe      |  (Protocol = 17, UDP)            |
+-------------------------------------------------------------------+
|        En-tête UDP externe      |  (Port source = Entropie, Port = 4754) |
+-------------------------------------------------------------------+
|          En-tête GRE            |  (RFC 2784 / RFC 2890)           |
+-------------------------------------------------------------------+
|        Paquet IP interne        |  (Charge utile IPv4 ou IPv6)     |
+-------------------------------------------------------------------+

Les caractéristiques clés de la RFC 8086 comprennent :

1. Port de destination réservé : L'IANA a assigné le port UDP standard 4754 pour identifier formellement le protocole GRE-in-UDP.
2. Préservation fonctionnelle : Le protocole conserve les fonctionnalités complètes de GRE, incluant les clés d'identification (Key), les numéros de séquence et le support multiprotocole.
3. Compatibilité universelle : Tous les commutateurs de transit prennent nativement en charge le hachage 5-tuple sur les datagrammes UDP, sans exiger de mise à jour matérielle ou logicielle.

Le port source d'entropie : dispersion dynamique des flux sans inspection approfondie des paquets

L'avantage déterminant de la RFC 8086 réside dans l'utilisation du port source UDP externe comme vecteur d'injection d'entropie dynamique.

Dans une approche conventionnelle, pour équilibrer le trafic encapsulé, les commutateurs intermédiaires devraient réaliser une inspection approfondie des paquets (DPI), traversant les en-têtes GRE pour lire les champs IP et TCP/UDP internes. Cependant, une telle analyse matérielle en profondeur s'avère prohibitive en termes de coûts énergétiques et de latence, et devient totalement impossible dès lors que la charge utile est chiffrée.

GRE-in-UDP délègue élégamment cette responsabilité à la passerelle d'entrée du tunnel :

1. Calcul à l'entrée : Lorsque la passerelle reçoit un paquet client interne, elle applique un hachage sur son quintuplet d'origine pour obtenir une valeur sur 16 bits.
2. Mappage de port : La passerelle associe cette valeur à la plage de ports éphémères définie par l'IANA (de 49152 à 65535).
3. Encapsulation : Ce port dynamique est directement inséré dans le champ de port source UDP externe.

$$ ext{Port source UDP externe} = 49152 + ( ext{Hash}( ext{5-Tuple interne}) \pmod{16384})$$

Pour une même session applicative, le quintuplet interne reste inchangé, garantissant un port source externe constant et empêchant le réordonnancement des paquets. En revanche, deux sessions distinctes génèrent des ports sources différents, permettant aux commutateurs intermédiaires de répartir naturellement les flux sur l'ensemble des liaisons physiques ECMP.

Comparaison des normes d'encapsulation : GRE-in-UDP, VXLAN et GENEVE RFC 8926

Plusieurs technologies d'encapsulation sur UDP coexistent dans les réseaux modernes. Le tableau ci-dessous récapitule leurs propriétés architecturales :

Si GENEVE (RFC 8926) s'impose comme la solution privilégiée pour les réseaux SDN nécessitant le transport de métadonnées complexes, GRE-in-UDP offre une compacité d'en-tête et une simplicité de traitement idéales pour les dorsales de transport WAN et les infrastructures VPN à haute performance.

Surcharge d'en-tête et MTU de chemin : atténuer le gonflement d'encapsulation et le MSS Clamping

L'ajout d'en-têtes UDP et GRE augmente la taille physique de chaque paquet sur le réseau. Si les hôtes terminaux transmettent des trames Ethernet standards de 1500 octets, l'encapsulation excédera l'unité maximale de transmission (MTU) physique, provoquant fragmentation ou rejet des paquets.

[ MTU Ethernet physique initial : 1500 octets ]
- [ En-tête IPv4 externe : 20 octets ]
- [ En-tête UDP externe : 8 octets ]
- [ En-tête GRE de base : 4 octets ]
= [ MTU résiduelle interne : 1468 octets ] (1456 octets avec options de clé/séquence)

Afin d'éviter les ruptures de connectivité liées aux trous noirs de PMTUD (Path MTU Discovery), plusieurs mécanismes complémentaires sont mis en place :

1. Ajustement MSS TCP (MSS Clamping) : La passerelle ajuste dynamiquement la valeur MSS lors de la négociation initiale TCP SYN, limitant la taille des segments TCP clients à 1420 octets.
2. Découverte de MTU de chemin : Respect strict de la RFC 8201 avec transmission transparente des messages ICMP d'erreur (Type 3, Code 4).
3. Déploiement de Jumbo Frames : Configuration d'une MTU physique à 9000 octets sur les réseaux dorsaux privés pour absorber la surcharge d'encapsulation.

Sémantique des sommes de contrôle : sommes nulles et règles de validation UDP en IPv6

L'en-tête UDP contient un champ de somme de contrôle (checksum) de 16 bits. En IPv4 standard, ce calcul est optionnel ; une valeur de 0x0000 indique que la somme n'a pas été calculée par l'émetteur.

Structure d'en-tête et accélération Zero-Checksum dans la commutation à haut débit

Pour les tunnels GRE-in-UDP sous IPv4, la section 3.2 de la RFC 8086 autorise la fixation du checksum UDP externe à zéro. Étant donné que la charge utile interne intègre déjà ses propres mécanismes de validation d'intégrité (tels que la somme de contrôle TCP, l'authentification WireGuard ChaCha20-Poly1305 ou le protocole IPsec ESP), le recalcul d'un checksum UDP externe consomme inutilement des ressources CPU sur les passerelles.

L'usage d'une somme nulle permet aux cartes réseau (NIC) d'assurer l'expédition des paquets à vitesse maximale sans dégradation des performances logicielles.

Gestion des exigences de somme de contrôle IPv6 externe via les RFC 6935 et RFC 6936

En IPv6 standard (RFC 8200), la somme de contrôle UDP est rigoureusement obligatoire. Tout équipement IPv6 recevant un datagramme UDP avec une somme de contrôle nulle est tenu de le rejeter.

Cette contrainte représentait une limitation majeure pour le transport de tunnels à grand volume sur IPv6. Pour lever cet obstacle, les RFC 6935 et RFC 6936 ont assoupli les exigences pour les protocoles d'encapsulation, autorisant le checksum UDP à zéro sous des conditions opérationnelles strictes :

• Les extrémités du tunnel doivent attester que la charge utile interne bénéficie d'une détection d'erreurs robuste.
• La passerelle doit appliquer une vérification stricte par port afin qu'aucune application UDP conventionnelle ne traite des données corrompues.
• Le transit doit être restreint à des réseaux managés présentant des taux d'erreur binaire quasi nuls.

Backbone Anycast RiceGuard : architecture maillée multipath sans polarisation

VPNRice intègre le maillage RiceGuard de Couche 3 pour interconnecter ses points de présence Anycast à travers les opérateurs de transit Tier-1. Dans des environnements de distribution géographique à haute densité, la polarisation de hachage dégraderait directement la fluidité des communications en direct.

L'infrastructure RiceGuard élimine la polarisation grâce au routage d'entropie UDP natif :

• Entropie dynamique : Les nœuds Anycast génèrent des clés de hachage 16 bits injectant des ports sources variés sur les datagrammes inter-datacenters.
• Répartition multipath symétrique : Le trafic VPN est ventilé de manière homogène sur 32 et 64 chemins ECMP sans nécessiter d'analyse approfondie de la part des opérateurs.
• Maintien de l'affinité de session : L'entropie reste strictement constante au cours d'une même session, évitant tout désordre de paquets et limitant la gigue sous le seuil d'une milliseconde.
• Prévention de la fragmentation : RiceGuard régule les seuils MSS pour empêcher toute perte de connectivité. Les utilisateurs peuvent vérifier la configuration de leur liaison via /what-is-my-ip.

Les clients souhaitant sécuriser leurs communications peuvent installer les applications dédiées depuis /download. Les mécanismes de résilience des passerelles Anycast lors de transitions BGP sont décrits dans /news/bgp-graceful-restart-rfc-4724-llgr-anycast-resilience, et les optimisations de réutilisation des ports de passerelle sont détaillées dans /news/tcp-time-wait-state-rfc-1337-port-exhaustion-vpn.

Mise en œuvre pratique : configuration de GRE-in-UDP et FOU sous Linux

Le noyau Linux prend en charge nativement les tunnels encapsulés dans UDP grâce à l'infrastructure Foo-over-UDP (FOU). Les administrateurs peuvent déployer une liaison GRE-in-UDP à l'aide des commandes usuelles de la suite iproute2.

Activation des modules du noyau et ouverture des ports d'écoute :

Charger les modules requis et configurer le port de réception FOU sur la passerelle A :

# Chargement des modules noyau pour FOU et GRE
modprobe fou
modprobe ip_gre

# Ouverture du port de réception FOU pour GRE-in-UDP (port standard RFC 8086 : 4754)
ip fou add port 4754 gue

Configuration de l'interface tunnel GRE-in-UDP :

Créer l'interface virtuelle configurée pour générer automatiquement l'entropie de port source :

# Création de l'interface tunnel sur la passerelle A
ip link add name tun-gre-udp type gre     remote 203.0.113.2 local 198.51.100.1     ttl 64     encap fou encap-sport auto encap-dport 4754

# Attribution de l'adresse IP interne et activation de l'interface
ip addr add 10.200.0.1/30 dev tun-gre-udp
ip link set dev tun-gre-udp up mtu 1440

Le paramètre encap-sport auto est fondamental : il ordonne au noyau Linux de calculer automatiquement le hachage d'entropie pour chaque flux interne et d'inscrire le résultat dans le port source UDP externe.

Validation de la distribution multipath par télémétrie :

Consulter les attributs détaillés du lien :

ip -d link show tun-gre-udp

La sortie confirme l'activation effective de l'encapsulation :

tun-gre-udp: gre/ip remote 203.0.113.2 local 198.51.100.1 ttl 64
    encap fou encap-sport auto encap-dport 4754

Vérifier la dispersion des paquets sur l'interface physique externe au moyen de tcpdump :

tcpdump -ni eth0 udp port 4754

Les captures confirment la bonne répartition dynamique des ports sources :

21:20:15.102482 IP 198.51.100.1.53120 > 203.0.113.2.4754: UDP, length 1448
21:20:15.102590 IP 198.51.100.1.61445 > 203.0.113.2.4754: UDP, length 1448
21:20:15.102645 IP 198.51.100.1.49812 > 203.0.113.2.4754: UDP, length 1448

Chaque flux de données est émis avec un port source distinct (53120, 61445, 49812), permettant aux commutateurs de transit de répartir harmonieusement les charges sur les différents canaux ECMP.