Résumé

  • L’échéance du 1er janvier 1983 avait une force concrète sur ARPANET parce que les IMP pouvaient cesser de servir NCP ; elle ne constituait pas une loi mondiale des réseaux indépendants.
  • La migration associa des spécifications communes à une responsabilité locale : chaque site devait porter sa pile et ses applications, tandis que relais, sondages et coupures d’essai rendaient le risque visible.
  • Le succès resta imparfait : les services TCP observables étaient loin de 100 %, la distribution de la table des hôtes posa problème et la charge réelle révéla des défauts de performance après la date.

Une journée sans ancien courrier

Au milieu de 1982, selon le souvenir que Vint Cerf confia bien plus tard au Computer History Museum, ARPANET cessa pendant une journée de prendre en charge l’ancien protocole NCP. Ceux qui disposaient de TCP continuaient de communiquer ; les autres découvraient soudain qu’un logiciel encore installé ne valait pas un service encore fourni. Une seconde répétition, d’environ deux jours à l’automne, fit surtout sentir la dépendance au courrier électronique.

Ces essais n’étaient pas une consultation symbolique. Ils vérifiaient que la frontière technique annoncée existait vraiment. Cerf expliqua que les Interface Message Processors pouvaient rejeter ou ne pas servir l’ancien trafic de bout en bout. La règle quittait ainsi le papier : elle atteignait un équipement dont le comportement transformait l’incompatibilité en panne.

Il faut conserver les limites de ce témoignage. Les dates sont approximatives, et Cerf évoqua encore quelques exceptions accordées en janvier aux machines rencontrant des difficultés particulières. Le fameux « flag day » fut donc moins un coup de minuit parfait qu’une séquence : préparation, répétitions douloureuses, retrait du service normal, puis réparation des problèmes restants.

NCP savait parler à un réseau, pas à des réseaux

La raison de la rupture n’était pas une mode terminologique. NCP avait été conçu autour de l’environnement hôte-à-hôte d’ARPANET. Or la recherche financée par l’ARPA produisait aussi des réseaux radio par paquets, un réseau satellite et des réseaux locaux. Le protocole lié aux services d’un seul sous-réseau ne fournissait pas le langage commun nécessaire pour traverser ces techniques différentes.

RFC 801 situe le problème dès son introduction. Les travaux commencés en 1973 aboutirent à IP et TCP, capables de donner aux hôtes d’un ensemble de réseaux interconnectés un même environnement de communication. RFC 791 définissait le datagramme Internet ; RFC 793 confiait la fiabilité de bout en bout à TCP. Les réseaux sous-jacents n’avaient pas à devenir identiques pour participer à l’« ARPA Internet ».

Maintenir NCP indéfiniment n’aurait donc pas été une position neutre. Cela aurait prolongé une dépendance propre à ARPANET et obligé les services, les opérateurs et les hôtes intermédiaires à entretenir deux univers. La compatibilité ancienne avait un coût ; le site en retard n’était pas seul à le payer.

Le Department of Defense avait adopté IP et TCP comme normes de ses réseaux à paquets. Sur le réseau qu’il finançait, il pouvait annoncer qu’un accès durable supposait désormais cette compatibilité. Cette capacité ne provenait pas d’une souveraineté abstraite de l’auteur d’un RFC. Elle provenait du contrôle et de la responsabilité sur une infrastructure déterminée.

Le centre fixait la limite, les sites faisaient le travail

RFC 801 attribua la tâche d’implémentation à chaque organisation hôte. C’était une répartition réaliste du pouvoir. Aucun bureau central ne pouvait modifier à distance les systèmes d’exploitation hétérogènes, corriger les pilotes, réécrire les démons ou former les équipes locales. Le plan commun disait quel comportement devait interopérer et à quelle date l’ancien service finirait ; l’exécution demeurait distribuée.

La pile réseau seule ne suffisait pas. Les usages principaux — Telnet, transfert de fichiers et courrier — devaient fonctionner sur TCP. Un site n’était pas prêt parce qu’il savait répondre à un paquet IP de laboratoire. Il l’était lorsque ses utilisateurs retrouvaient les fonctions dont dépendait leur travail.

Le courrier imposa les exigences de continuité les plus sévères. RFC 773 voulait maintenir les noms de boîtes ARPANET, préserver les mécanismes anciens pendant la période intermédiaire et automatiser autant que possible le transfert entre NCP et TCP. Le nouvel environnement devait offrir un service au moins équivalent avant que l’ancien ne disparaisse.

Des hôtes à double pile servirent donc de relais. Une session Telnet pouvait entrer sous TCP dans un relais puis repartir sous NCP. Un fichier pouvait effectuer deux étapes. Un message pouvait être reçu dans un monde, mis en file d’attente et livré dans l’autre. Cette plomberie rendait possible une migration qui ne pouvait être simultanée.

Elle créait aussi ses propres risques. Un relais ajoutait une machine, des comptes, une capacité et une panne possible au chemin. RFC 801 s’inquiétait explicitement de sa fiabilité et de sa charge. Le pont devait donner du temps, pas transformer l’ancienne pile en rente permanente sur les ressources des autres.

La date prévue et le réseau observé

Dans le calendrier de RFC 801, janvier 1983 était net : tous les hôtes seraient capables de TCP, tous les services utiliseraient TCP, NCP et les relais sortiraient du service. Les sondages contemporains montrent une réalité beaucoup plus granuleuse.

David Smallberg interrogea les serveurs Telnet, FTP et SMTP. RFC 847 résume les séries hebdomadaires. Le 28 décembre 1982, 95 hôtes sur 314 acceptaient Telnet, 80 FTP et 72 SMTP. Le 4 janvier 1983, les nombres passèrent à 151, 132 et 124 sur 315. Le 22 février, ils atteignaient 190, 181 et 178 sur 325.

Ces fractions ne mesurent pas directement la conformité TCP. Certains hôtes étaient arrêtés, d’autres n’avaient aucune raison d’offrir ces services, et le groupe recensé changeait. Les auteurs estimaient que 11 % des machines avaient une fonction spéciale, abaissant le maximum raisonnable à environ 89 %. Il serait donc faux de dire que la moitié seulement avait « migré » ; il serait tout aussi faux de transformer l’échéance en état visible de 100 %.

Les sondages font mieux qu’un slogan. Ils distinguent l’implémentation d’une pile, l’ouverture d’un service, la disponibilité d’un hôte et l’expérience de l’utilisateur. Ils montrent surtout une hausse brutale autour de la coupure, sans prétendre qu’un chiffre unique résume tout le réseau.

Après la bascule, la production commença son propre test

Le rapport du National Research Council publié comme RFC 942 jugea plus tard que les essais avaient permis de conserver la capacité opérationnelle. Une trentaine d’hôtes TCP-only avaient participé pendant environ six mois avant la coupure. Pourtant, le retour à un niveau de service normal demanda quelques mois.

Le Network Information Center n’était pas prêt à distribuer correctement la nouvelle table des hôtes. Les machines de service connurent des problèmes de performance, car aucune n’avait supporté longtemps la charge complète des utilisateurs avant la transition. Les paramètres durent être ajustés après le passage en production. Les relais de courrier furent beaucoup utilisés ; les autres relais le furent moins.

Ce constat ne retire rien à la portée du basculement. Il empêche seulement de confondre retrait d’une ancienne promesse de compatibilité et maturité du nouvel ensemble. Une norme peut être assez solide pour être déployée tandis que la capacité, les données de configuration, les opérations et l’assistance restent fragiles.

Il montre également la limite du commandement central. Le commanditaire pouvait retirer NCP du sous-réseau. Il ne pouvait pas remplacer le savoir-faire des équipes de systèmes, des administrateurs de services, du NIC, des opérateurs de TAC ou des mainteneurs de relais. La limite était centralisée ; la compétence restait locale.

La portée exacte de l’autorité

À l’intérieur d’ARPANET, un site ne pouvait exiger éternellement que tous les autres financent l’ancien environnement. Le commanditaire assumait la continuité de son réseau et pouvait définir une condition de compatibilité, annoncer la fin du service et gérer des exceptions bornées. C’est une autorité réelle, mais circonscrite.

Hors de ce réseau, ni le DoD ni Jon Postel ne pouvaient faire fonctionner TCP/IP par déclaration. Des fabricants, des universités, des réseaux locaux et d’autres opérateurs devaient l’implémenter et choisir de s’interconnecter. Le protocole gagnait alors non parce qu’un registre attribuait un statut moral aux récalcitrants, mais parce que des systèmes mutuellement compatibles échangeaient réellement des données.

Cette séparation rejoint une discipline essentielle de l’Internet : une institution peut refuser ce qu’elle ne prend pas en charge sur son propre équipement ; elle ne peut transformer cette décision locale en titre sur les réseaux d’autrui. La puissance est légitime là où l’acteur exécute, explique, mesure et répond du dommage.

Le 1er janvier 1983 ne fut donc ni un plébiscite ni un sacre mondial. Il marqua le moment où NCP cessa d’être une prestation ordinaire sur ARPANET. Cette formulation modeste explique mieux le résultat historique. Le retrait rendit la migration inévitable pour les hôtes attachés à ce réseau ; l’interopérabilité rendit TCP/IP désirable au-delà.

Sources et limites de preuve

Le plan, la répartition des tâches et les jalons viennent de RFC 801. Les exigences de continuité du courrier sont dans RFC 773. Les règles communes sont décrites par RFC 791 et RFC 793 ; RFC 820 situe la transition dans l’environnement protocolaire de 1982.

Les comptes de services acceptant des connexions proviennent de RFC 847. Les enseignements opérationnels et les problèmes après bascule viennent de RFC 942. Les coupures d’essai, le mécanisme des IMP et les rares exceptions finales sont attribués à l’entretien de Vint Cerf conservé par le Computer History Museum.

Le dossier ne donne ni liste complète des exceptions, ni durée globale exacte d’indisponibilité, ni dénominateur universel. Il prouve une transition ARPANET planifiée et exécutée, suivie de plusieurs mois d’ajustement. Il ne prouve pas qu’un instant unique aurait fait adopter TCP/IP à tous les réseaux du monde.