Le monde où l’IPv6 était une excellente conception (2017)

• Dans les premiers réseaux centrés sur les liaisons point à point, il n’y avait presque pas besoin d’un système d’adressage, mais la généralisation des réseaux en bus pour réduire les coûts a entraîné une accumulation de complexité avec les adresses MAC, le bridging et ARP
• Avec la combinaison d’Ethernet et d’IP, il est devenu nécessaire d’utiliser l’adressage MAC et les broadcasts ARP pour acheminer les paquets vers le prochain saut, et cette charge a fortement augmenté dans les grands réseaux interconnectés et sur le wifi
• La vision d’IPv6 reflétait l’espoir d’un monde plus simple qui abandonnerait les bus physiques et les internetworks de couche 2, en supprimant jusqu’au broadcast, à ARP, à DHCP et aux adresses MAC
• Mais dans les déploiements réels, IPv4 et l’ancien framing sont restés en place, et avec eux des héritages comme neighbor discovery, DHCP, NAT et le bridging de couche 2
• Pour maintenir les connexions pendant les déplacements, on continue d’utiliser le bridging de couche 2 et le tunneling centralisé plutôt que le routage Internet, tandis que des alternatives comme QUIC sont évoquées comme voie de contournement pour le roaming

---

Le moment où les réseaux en bus ont tout gâché

• Dans les premiers environnements de commutation de circuits téléphoniques et de lignes dédiées, il n’existait que des liaisons point à point, donc aucun système d’adressage n’était nécessaire, et les bits injectés d’un côté ressortaient simplement de l’autre après un certain délai
• Même après l’introduction du TDM et de la commutation à circuits virtuels, du point de vue de l’utilisateur, on restait dans un schéma où une entrée d’un côté ressortait à l’autre, et il n’y avait toujours pas besoin d’adresses
• Quand des ordinateurs dotés de plusieurs interfaces ont commencé à relayer des bits entre différentes lignes, les adresses IP, les sous-réseaux et le routage sont apparus, mais sur des liens point à point, il n’y avait toujours pas besoin d’adresses MAC
• Pour réduire le coût des connexions sur un site local, les réseaux en bus sont apparus, permettant de raccorder plusieurs équipements sur un même câble, et divers systèmes de couche 2 indépendants ont émergé en parallèle de l’Internet
• arcnet, un des premiers LAN, imposait de configurer manuellement des adresses de couche 2 sur 8 bits via des cavaliers ou des DIP switches, et les doublons provoquaient des pannes graves, mais les réseaux étant petits, cet inconvénient restait limité
• Ethernet a résolu le problème des doublons en introduisant des adresses MAC sur 48 bits, attribuées de façon quasi unique dès la fabrication
• Des technologies LAN comme IPX et Netware fonctionnaient très bien à l’intérieur d’un seul réseau en bus sans configuration d’adresses, et cette époque est décrite comme belle et fiable
• Les grands réseaux d’entreprise et universitaires ont dû interconnecter plusieurs bus à cause du goulet d’étranglement d’un seul bus à 10 Mbps, mais au lieu d’IP, encore peu mature à l’époque, ils ont choisi d’étendre bridging et switching basés sur les adresses Ethernet
• Comme les adresses Ethernet étaient attribuées séquentiellement en usine, elles n’avaient pas de structure hiérarchique, si bien que les tables de bridging ne pouvaient pas être agrégées efficacement comme les tables de routage IP modernes par sous-réseau
  • Pour un bridging efficace, il fallait se souvenir de quel bus dépendait chaque adresse MAC
  • Afin d’éviter une configuration manuelle, il a fallu introduire de l’apprentissage automatique et des interactions complexes
• Les réseaux de bridges complexes ont évolué avec des mécanismes comme le spanning tree, accompagnés de floods de broadcast, de chemins sous-optimaux et d’une faible capacité de débogage
• Les bridges intermédiaires n’avaient pas vraiment de notion d’adresse dans l’Ethernet classique, ce qui empêchait de créer des outils comme traceroute, et faisait du bridging une architecture pratiquement impossible à déboguer
• Malgré cela, le bridging était extrêmement rapide, presque à la vitesse du fil Ethernet, grâce à l’optimisation matérielle, ce qui constituait à l’époque un énorme avantage

L’Internet qui tourne au-dessus d’un bus

• À partir d’une architecture reliant des ordinateurs individuels par des liaisons longue distance point à point, le besoin de connecter des LAN entiers à distance est progressivement apparu
• Un simple bridging longue distance n’était pas viable à cause des problèmes de contrôle de congestion, et le bridging Ethernet ne fonctionnait que si toutes les liaisons avaient des débits comparables ou en présence de très peu de congestion
• Relier directement par bridging un Ethernet à 10 Mbps à une liaison point à point à 0,128 Mbps était voué à l’échec, et la découverte de chemins par flooding devenait trop coûteuse sur des liens lents
• Le routage sous-optimal, tolérable en local, devenait fatal sur des liens longue distance lents et chers, ce qui empêchait toute montée en charge
• Cet ensemble de problèmes relevait précisément de ce que l’Internet savait déjà traiter, et relier les bus LAN avec les technologies Internet offrait une bien meilleure architecture
• C’est ainsi qu’ont été conçus des formats de trame permettant d’embarquer des paquets Internet sur des LAN comme Ethernet ou arcnet, et c’est là que les ennuis ont commencé
• S’il y avait plusieurs routeurs IP sur un même segment Ethernet, il fallait distinguer lequel recevrait le paquet pour le relayer, et l’IP finale de destination ne suffisait pas à exprimer ce choix
• Il a donc fallu conserver la destination finale dans l’en-tête IP et indiquer le véritable prochain saut via l’adresse MAC de la trame Ethernet
• L’information réellement utile, du point de vue humain, est quelque chose comme envoyer la destination IP 10.1.1.1 vers l’adresse MAC du routeur 11:22:33:44:55:66, mais le système d’exploitation la représente plutôt sous une forme comme via l’IP du routeur 192.168.1.1
• Pour réaliser cette abstraction, le système d’exploitation devait d’abord retrouver l’adresse Ethernet du routeur IP, et c’est ainsi qu’ARP a été ajouté comme étape intermédiaire
• ARP fonctionne en envoyant un broadcast à tout l’Ethernet local pour trouver le propriétaire d’une IP donnée, et s’il y a des bridges, ce broadcast Ethernet doit être relayé sur toutes les interfaces
• Dans les grands Ethernet interconnectés, l’excès de broadcasts est devenu l’un des pires cauchemars, et le problème était encore plus grave sur le wifi
• Par la suite, les bridges et switches ont commencé à intégrer des hacks spécifiques pour réduire la portée des ARP, et certains équipements, en particulier les points d’accès wifi, allaient jusqu’à forger de fausses réponses ARP, mais cela relevait surtout du bricolage technique

Une mort causée par l’héritage

• Avec le temps, les protocoles non IP sur Ethernet ont presque entièrement disparu, et les réseaux se sont figés en une architecture composée d’un bus de couche 2 au-dessus des liaisons physiques, de bridges reliant ces bus, puis de routeurs de couche 3 au-dessus
• La configuration manuelle des IP étant devenue pénible, le besoin d’autoconfiguration est apparu, mais les équipements sortaient déjà d’usine avec une adresse Ethernet, alors qu’une adresse IPv4 de 32 bits ne suffisait pas pour une attribution permanente et universellement unique dès la fabrication
• Attribuer des adresses IP de façon simplement séquentielle aurait ramené au même manque de hiérarchie qu’Ethernet, ce n’était donc pas une vraie solution
• C’est ainsi que sont apparus bootp et DHCP, devenus eux aussi des protocoles nécessitant un traitement spécial, comme ARP
• Comme DHCP doit être émis d’abord par un nœud qui n’a pas encore d’adresse IP, il faut y insérer un en-tête IP pratiquement vide de sens mais conforme à la RFC, et le serveur DHCP doit le construire directement via un raw socket plutôt que via la couche IP du noyau
• bootp et DHCP doivent au fond connaître l’adresse Ethernet pour attribuer une adresse IP, ce qui leur donne un rôle proche d’un ARP inversé
• Il est mentionné que RARP faisait quelque chose de similaire de façon plus simple, mais qu’il n’est presque pas traité ici
• Au final, Ethernet et IP se sont imbriqués de plus en plus étroitement au point d’être aujourd’hui presque indissociables
• Les tables de routage IP prétendent désigner les routeurs par adresse IP, mais en pratique elles pointent indirectement vers des adresses MAC ; ARP traverse les bridges ; et DHCP ressemble à un paquet IP tout en relevant en réalité davantage d’un protocole Ethernet
• Dans le même temps, bridging et routage sont devenus toujours plus complexes, le bridging relevant plutôt de l’IEEE et du matériel, le routage plutôt de l’IETF et du logiciel, chacun faisant comme si l’autre n’existait pas
• Les opérateurs réseau choisissaient entre bridging et routage selon leurs exigences de performance et leur réticence à configurer un serveur DHCP, utilisant autant que possible le bridging et ne basculant vers le routage qu’en cas de besoin
• La complexité du bridging a finalement conduit à remonter les décisions de couche 2 dans les couches supérieures pour les administrer de manière centralisée via des protocoles IP, ce qui a donné le SDN
• Le SDN était préférable à des switches et bridges agissant chacun dans leur coin, mais l’auteur souligne l’aspect fondamentalement absurde de la chose, puisque l’IP lui-même, conçu pour piloter un réseau devenu trop grand, était déjà à l’origine une forme de réseau défini par logiciel
• IPv4 était au départ difficile à accélérer matériellement, et dans la pratique cette accélération matérielle est restée insuffisante ; la configuration DHCP était très pénible ; les opérateurs ont donc appris à bridge-r des périmètres toujours plus vastes
• Aujourd’hui, les grands datacenters sont décrits comme fonctionnant en pratique comme d’immenses réseaux en bus virtuels basés sur le SDN, qui bien souvent ne routent pas réellement les paquets

Oublions maintenant un instant tout ce qui précède

• Au début des années 1990, quand l’IETF concevait IPv6, beaucoup de confusion existait déjà, mais la conception s’est faite sur l’hypothèse qu’il serait encore possible d’éviter la catastrophe à venir
• L’un des changements clés de cette réflexion était que l’usage des réseaux en bus physiques avait déjà pratiquement cessé
• Ethernet n’était plus un vrai bus ; il faisait seulement semblant, et l’augmentation des débits avait rendu CSMA/CD intenable, entraînant un retour à une topologie en étoile
• Il est devenu courant de tirer un câble dédié de chaque station vers un switch central, au point de remplir murs, plafonds et planchers de gros faisceaux coûteux de câbles Ethernet
• Même le wifi, qui ressemble au bus ultime puisqu’il s’appuie sur un médium radio partagé, est décrit comme fonctionnant presque toujours en infrastructure mode, c’est-à-dire comme une immense étoile déguisée
• Même deux stations wifi reliées au même point d’accès ne communiquent pas directement : elles envoient au point d’accès des paquets contenant l’adresse MAC de l’autre nœud, puis le point d’accès les réémet
• Si un nœud X envoie vers un nœud Internet Z via un routeur IP Y et un point d’accès wifi A, alors Z est la destination IP, Y la destination Ethernet, et A le véritable correspondant radio, ce qui empile les couches d’adressage de façon compliquée
• Pour cela, 802.11 fournit un mode à 3 adresses qui permet d’embarquer à la fois la destination Ethernet réelle et la destination Ethernet intermédiaire
• Il existe en plus des bits to-AP et from-AP pour indiquer le sens station→AP et AP→station, et lorsque les deux bits sont à vrai, cela peut aussi représenter un fonctionnement de relais entre points d’accès
• Si A est un repeater qui doit renvoyer vers une station de base B, alors l’émetteur et le récepteur réels sur l’air, ainsi que la source et la destination Ethernet, sont tous différents, ce qui nécessite un mode à 4 adresses
• 802.11s mesh va jusqu’à un mode à 6 adresses, et l’auteur écrit qu’à ce stade il a renoncé à essayer de tout comprendre

Le monde où IPv6 était une bonne conception

• En réfléchissant à IPv6, l’IETF observait à la fois le désordre déjà présent et celui, plus grand encore, qui s’annonçait, et imaginait un monde nouveau débarrassé de l’héritage existant
• Les hypothèses de ce monde étaient la disparition des bus physiques, des internetworks de couche 2, du broadcast, des adresses MAC, d’ARP et de DHCP, ainsi qu’un en-tête IP simple compatible avec l’accélération matérielle, la fin de la pénurie d’adresses et la suppression, hors cœur de réseau, de la configuration IP manuelle
• Si la couche 2 était toujours point à point, il n’y aurait plus de destinataire naturel pour le broadcast, donc le multicast pourrait le remplacer, et comme le pair émetteur-récepteur serait évident, les adresses MAC deviendraient inutiles
• Avec la disparition des adresses MAC, la correspondance IP↔MAC ne serait plus nécessaire, et ARP comme DHCP pourraient donc disparaître ; on disposerait aussi d’un espace d’adressage suffisant pour réutiliser le routage sur de très grands sous-réseaux
• Dans ce monde, les repeaters wifi, les points d’accès wifi, les switches Ethernet et même le SDN auraient tous fonctionné comme des routeurs IPv6
• Cela aurait fait disparaître les ARP storms, les IGMP snooping bridges et les boucles de bridging, tout en permettant de suivre tous les problèmes de routage avec traceroute
• On aurait pu supprimer 12 octets d’adresses MAC source/destination par paquet Ethernet et 18 octets d’informations d’adressage par paquet wifi ; ainsi, même si IPv6 utilise des adresses 24 octets plus longues qu’IPv4, la suppression de l’en-tête Ethernet ramènerait le surcoût réel à seulement 12 octets
• Le texte explique que l’espoir de pouvoir un jour supprimer les adresses Ethernet elles-mêmes a contribué à justifier le choix d’une longueur d’adresse IPv6 jugée excessivement grande
• Mais cette belle architecture ne s’est jamais matérialisée dans le monde réel

Requiem pour un rêve

• La conclusion générale est résumée par une phrase d’un collègue : « les couches ne font que s’ajouter, elles ne disparaissent jamais »
• Les avantages d’IPv6 n’auraient eu de sens qu’à condition de pouvoir jeter l’héritage existant et repartir de zéro, mais en pratique cela s’est révélé presque impossible
• Même si le taux d’adoption d’IPv6 atteignait 99 %, tant qu’IPv4 n’aura pas complètement disparu, les adresses Ethernet et wifi ne disparaîtront pas non plus ; et tant que les standards de framing IEEE 802.3 et 802.11 resteront en place, les économies de bytes espérées ne se matérialiseront pas
• IPv6 a donc finalement eu besoin de neighbor discovery, plus complexe encore qu’ARP, et même si les réseaux en bus ont disparu, il reste nécessaire de simuler des comportements proches du broadcast pour reproduire ce qu’ARP faisait
• À la maison, il faut toujours faire tourner un serveur DHCP local pour faire fonctionner une vieille ampoule IPv4, et il faut toujours du NAT pour lui permettre d’atteindre Internet
• Plus grave encore, selon l’auteur, l’équipe IPv6 a laissé sans solution le problème de mobile IP, ce qui a rendu nécessaire le maintien de l’horrible bridging de couche 2
• L’idée semble avoir été de déployer IPv6 d’abord en quelques années, puis de régler plus facilement mobile IP une fois IPv4 et les adresses MAC disparus
• À l’époque, on imaginait à peine l’usage d’ordinateurs mobiles, si bien que le mieux qu’on pouvait concevoir était une scène un peu étrange où l’on déplace un ordinateur d’un port Ethernet à un autre tout en gardant une session ftp ouverte

Mobile IP, l’application qui tue

• L’histoire a ensuite fait des ordinateurs portables, c’est-à-dire des téléphones, un cas d’usage quotidien, avec des appareils se déplaçant entre plusieurs points d’accès sans fil
• Sur LTE, ce déplacement fonctionne généralement ; sur le wifi, parfois ; et le secret, affirme le texte, n’est pas le routage Internet mais le bridging de couche 2
• Le routage Internet ne gère pas du tout la mobilité : dès qu’un appareil se déplace dans un réseau IP et change d’adresse IP, toutes ses connexions ouvertes tombent
• Le wifi d’entreprise bridge tout le LAN en couche 2 pour que le serveur DHCP central attribue la même adresse IP quel que soit le point d’accès auquel on se connecte, en tolérant seulement quelques secondes de désordre pendant la reconfiguration des bridges
• Les réseaux wifi domestiques avec plusieurs extenders ou repeaters utilisent la même méthode
• En revanche, quand on passe à pied d’un réseau wifi différent à un autre, comme avec les wifi publics de magasins, on reçoit à chaque fois une nouvelle adresse IP et toutes les connexions sont interrompues
• LTE va plus loin encore et maintient la même adresse IP en traversant plusieurs stations de base sur des kilomètres ; il est mentionné que les réseaux mobiles utilisent en général des adresses IPv6
• Pour y parvenir, ils tunnellent le trafic vers un point central, puis le bridge-rent, avec de nombreux firewalls, dans un gigantesque LAN virtuel de couche 2, au prix d’une complexité énorme et d’une latence supplémentaire franchement embarrassante
• Les opérateurs aimeraient corriger cela, mais le texte suggère que c’est presque impossible

Comment faire réellement fonctionner mobile IP, méthode 1

• L’explication de l’échec de mobile IP aboutit à cette conclusion : la célèbre définition du 4-tuple utilisée pour identifier une session est fondamentalement mauvaise
• Les sessions TCP et UDP sont identifiées par (source ip, source port, destination ip, destination port) ; cette structure traverse les couches 3 et 4 et la rend fragile face aux changements d’adresse IP
• Le texte avance que si l’identification des sessions reposait uniquement sur les données de couche 4, mobile IP fonctionnerait parfaitement
• Exemple : lorsque X:1111 communique avec Y:80, si X change d’adresse pour devenir Q, le paquet devient (Q,1111,Y,80) ; Y ne le reconnaît plus comme appartenant à la session existante et le rejette ; et les paquets de réponse (Y,80,X,1111) n’atteignent plus X non plus
• Comme alternative, il est proposé d’élargir le numéro de port, aujourd’hui sur 16 bits, vers une valeur de hachage unique de 128 ou 256 bits, et d’identifier les sockets par un tag indépendant de l’adresse IP
• Dans ce cas, les paquets continueraient d’embarquer les informations d’adressage (X,Y) à la couche 3 pour le routage, mais le noyau, à la réception, n’utiliserait pas la couche 3 pour identifier la socket et s’appuierait uniquement sur l’uuid
• Le port de destination 80 ne serait nécessaire qu’au démarrage d’une nouvelle session pour distinguer le service souhaité, puis pourrait être ignoré ou omis
• Le noyau de Y mettrait en cache le fait que des paquets de session (uuid) sont récemment arrivés depuis X ; si X se déplace ensuite vers Q et envoie avec le même tag (uuid,80), Y pourrait rattacher cela à la session existante et mettre à jour la destination de réponse de X vers Q
• Cela permettrait de conserver la connexion, mais le texte ajoute qu’il faudrait des précautions supplémentaires pour empêcher la prise de contrôle de connexion par usurpation
• Cependant, ni UDP ni TCP ne fonctionnent de cette manière, et les changer aujourd’hui est présenté comme le genre de projet qui semblait au départ aussi simple que de remplacer IPv4 par IPv6, mais qui, des décennies plus tard, n’est toujours pas terminé à moitié

QUIC et la possibilité d’un contournement

• Sur une note plus positive, le texte évoque la possibilité d’une solution indirecte grâce à une nouvelle violation de couches
• En abandonnant le vieux TCP au profit de QUIC sur UDP, il devient possible de ne plus utiliser le 4-tuple UDP lui-même comme identifiant de connexion
• Si le port UDP correspond à un port spécial de couche de mobilité, il devient possible de réinterpréter son contenu comme des paquets internes portant le bon tag uuid, puis de les associer à la bonne session et à la bonne socket
• Le protocole expérimental QUIC disposerait déjà, au moins en théorie, d’un format de paquets adapté à cette approche
• Comme le chiffrement et l’authentification stateless utilisés par QUIC exigent déjà un identifiant ou une clé de session unique, le texte suggère qu’un support transparent du roaming pourrait être ajouté avec relativement peu de travail
• Si cela se produisait, il ne resterait plus qu’à supprimer d’Internet tout le reste d’UDP et de TCP, et alors, cette fois vraiment, le bridging de couche 2 ne serait plus nécessaire ; on pourrait aussi se débarrasser du broadcast, des adresses MAC, du SDN et de DHCP
• Le texte se termine sur la formule « restaurer l’élégance d’Internet »

Correctifs complémentaires

• Correction du 2017-08-16

  • L’idée présentée plus haut au sujet de mobile IP ne se limite pas à IPv6
  • Le texte est corrigé pour indiquer qu’elle pourrait aussi fonctionner en IPv4 avec NAT, et même en roaming à travers plusieurs NAT

• Correction du 2017-08-15

  • Comme méthode de prévention de la prise de contrôle de connexion, un échange de type SYN-ACK-SYNACK au démarrage de TCP est donné comme exemple le plus simple
  • Si Y faisait immédiatement confiance au premier paquet venu du nouvel hôte Q, il serait facile pour un attaquant, depuis n’importe où sur Internet, de détourner la connexion X→Y
  • Si Y envoie un cookie et que Q le reçoit, le traite et le renvoie à Y, alors l’attaque exige au minimum une capacité de type homme du milieu plutôt qu’une simple attaque externe
  • Avec un protocole chiffré comme QUIC, ce handshake pourrait en plus être protégé par la clé de session

• Correction du 2017-10-24

  • Outre QUIC, il existe d’autres protocoles candidats de remplacement de TCP intégrant ce type de support du roaming, et MinimaLT est cité en exemple
  • Il est écrit que MinimaLT aurait été le premier protocole à résoudre élégamment le problème du roaming, et que les solutions futures pourraient bien reprendre cette structure

• Correction du 2020-07-09

  • Le texte mentionne seulement que des réflexions supplémentaires sur la migration et l’interopérabilité IPv4/IPv6 ont été publiées dans un autre billet, sans ajouter d’explications dans le corps principal