Comment est né l’Internet. Si en Juin 1996, 12 881 000 ordinateurs (du PC au supercalculateur massivement parallèle) étaient connectés à l’Internet , il y en avait que 100 en 1983, la très grande majorité d’entre-eux étant localisés dans des sites militaires ou des sites académiques. La première connexion à un ordinateur distant en utilisant l’infrastructure du téléphone a eu lieu le 11 Septembre 1940 à une conférence de l’ « American Mathematical Society ». C’est le professeur Georges Robert Stibitz (alors employé au Bell Labs) qui l’a inventé et démontré en se connectant à une télétype situé au Dartmouth College et en envoyant des donnés à un ordinateur des Bell Labs situé à New-York : les résultats revenaient en quelques secondes. Traditionnellement la naissance de ce qui deviendra le réseau des réseaux est fixée au 1 er septembre 1969 i jour de la fête du travail aux Etats-Unis. Le professeur Leonard Kleinrock de l’Université de Los-Angeles en Californie, entouré de quelques étudiants (dont Vint Cerf, premier président de l’Internet Society, l’ISOC ) s’emploie à se connecter à un ordinateur situé à l’Université de Stanford en californie. Voci comment il décrit la scène ii : « Nous avons établit une liaison téléphonique entre nous et les gens du SRI (Stanford Research Institute. Nous avons tapé un L et demandé au téléphone : vous voyez le L ? Ils nous répondirent : oui, on voit le L . Nous avons tapé un O et demandé : vous voyez le O ? Oui on voit le O . Nous avons tapé le G et la machine est tombée en panne ... » Une révolution avait commencée, après celle initialisée par la pose du premier câble transatlantique en 1858 : cette liaison télégraphique ne fonctionna (mal) que trois mois et permit d’envoyer 732 messages. Il fallut en fait attendre le 27 Juillet 1866 pour avoir une connectivité opérationelle (à 5 dollars (de l’époque) en or (ou 7 dollars 50 en billet !)) le mot. Son origine était soviétique : le lancement en 1957 du premier spoutnik par l’URSS avait conduit le président des Etats-Unis d’Amérique, Dwight D. Eisenhower a créer l’ARPA (Advanced Research Projects Agency), agence fédérale qui sous le contrôle du Département de la Défense (le DoD) devait conduire des programmes de recherche pouvant donner , dans le domaine militaire, une avancée décisive aux Etats-Unis. Nous étions alors en pleine guerre froide. Au milieu des années 1960 les Etats-Unis souhaitaient mettre au point un réseau de commandement militaire, pouvant résister à une attaque nucléaire. En 1962, le rapport de Paul Baran « On distributed communications » est publié par la « Rand Corporation ». Cette recherche, subventionnée par « l’US Air-Force » proposait un modèle de réseau de communication ou il n’y aurait pas de point d’autorité centralisée, et ou chaque noeud échappant à une attaque pourrait ré-établir le contact avec les noeuds survivants. Ainsi la destruction d’une partie du réseau ne détruirait pas l’ensemble et l’effet de cette destruction d’une partie sur l’ensemble du réseau serait minimal. Une des recommendations de ce rapport était de mettre en place un réseau national public permettant de transporter les données informatique, un peu comme le réseau téléphonique transporte la voix. « Il est temps maintenant de penser à un nouveau service public, un réseau de communication dédié à la transmission de données digitales pour un très grand nombre d’abonnés ». Il propose

d’utiliser la technologie de la commutation de paquets pour bâtir cette nouvelle infrastructure. Cette recherche ne rencontra pas une large audience , car elle était en partie couverte par le « secret défense ». Mais d’autres chercheurs travaillaient sur le même sujet, en particulier J.C.R Licklider qui se mit en congés de 1962 à 1964 pour conseiller l’ARPA et fût très influent sur la méthodologie utilisée par cette agence pour accorder des fonds. Le MIT, l’UCLA et la RAND se mirent à travailler sur ce concept d’un réseau décentralisé, à l’épreuve de toutes les attaques , dont tous les noeuds auraient le même statut, chaque noeud ayant l’autorité pour recevoir, transmettre, émettre des messages, messages qui seront eux-mêmes divisés en « paquets ». Chacun des paquets sera transmis séparément, trouvant sa route dans le réseau indépendamment de ses homologues. Et c’est ce dernier point, le mode dit « non-connecté » qui a fait toute la robustesse de ce réseau. Il est important d’en dire quelques mots. Schématiquement il existe deux possibilités pour transmettre de l’information sur un réseau : le mode connecté (ou point à point) et le mode non connecté. En mode connecté lorsque l’émetteur veut envoyer une information au récepteur (courrier électronique, image, programme) une connexion physique est établie de bout en bout : entre le terminal de l’émetteur et le terminal du récepteur. Si un élément constitutif de cette chaîne de liaison physique tombe en panne, la connexion s’arrête et il est nécessaire de la rétablir. En mode non connecté, le chemin particulier que prend un paquet n’a pas d’importance. Le paquet passe de noeud en noeud, s’approchant (plus ou moins nous en reparlerons) de sa destination finale, jusqu'à y aboutir. Si une partie du réseau ne fonctionnait plus, cela n’a pas d’importance : le paquet continuerait a être transmis par les noeuds fonctionnant encore. Cette approche garantit un système robuste. Dans les années 1960 IBM, General Electric et Tymeshare avaient mis en place des systèmes permettant un acccès distant par réseau téléphonique le plus souvent à un ordinateur : un peu comme avec le Minitel on peut se connecter à un centre serveur. L’énorme différence était que l’on avait là une technique maître (l’ordinateur central) / esclave (le terminal). Dans la structure d’ARPANET, au contraire, les noeuds ont tous la même autorité. Comme l’ont dit certains pionniers de l’architecture du réseau Internet « nous avons d’abord passé beaucoup de temps à étudier comment les opérateurs de télécommunications géraient leurs réseaux, puis nous avons fait exactement l’inverse. » En 1968, le « National Physical Laboratory » en Angleterre commença a tester un réseau basé sur ces principes. L’ARPA décida alors de financer un projet plus ambitieux. C’est Larry Roberts qui était à la tête du bureau IPTO (Information Processing Technolgy Office) de l’ARPA qui guida cette recherche. Les militaires mirent en place un appel d’offres iii pour un réseau de quatre ordinateurs pouvant évoluer jusqu’à 17 sites. C’est la firme BBN (Bolt Beranek and Newman, Inc) qui remporta le contrat. C’est Severo Ornstein de BBN qui analysa l’appel d’offres. Il se souvient avoir dit à sa hiérarchie: « Bien sur qu’on pourrait construire un truc comme ca. Mais franchement je ne vois pas à quoi cela pourrait bien servir. » Ornstein ,maintenant retraité, était responsable

dans cette entreprise de la définition du matériel pour les réseaux à commutation da paquets. Il est le fondateur de l’association « computer professionals for social responsablilty ».

Pr. Léonard Kleinrock devant le premier IMP. En décembre 1996 les quatres premiers sites mythiques du réseau ARPANET, tous situés en californie, étaient interconnectés : UCLA, SRI, UCSB (Université de Santa-Barbara) et l’Université de l’UTAH à Salt Lake City. Ces sites furent choisis car ils avaient déjà des contrats avec l’ARPA. Dès le départ ces centres utilisaient des ordinateurs différents :

Un Xerox DSS 7 sous SEX pour l’UCLA Un NIC DSS940/Genie pour Stanford Un IBM 370/65 sous OS/MVT pour l’UCSB Enfin, un DEC-PDP10 sous Tenex pour l’Université d’Utah

Seul les processeurs de messages (Information Message Processor, IMP) étaient communs : un ordinateur dérivé d’un Honeywell DDP 516 ivavec 12 K de mémoire développé par la société BBN. En 1972 d’autres ordinateurs chargés de commuter les messages furent mis en place: des Honeywell 316 qui tout en étant compatibles avec la génération précédente coûtait moitié moins cher. Certaines de ces machines furent configurés comme des TIPs (Terminal IMP) le premier a été installé à la NASA.

En Avril 1969 Steve Crocker, étudiant à l’UCLA écrivit le premier « Request for Comment » décrivant la façon dont la communauté du réseau allait travailler pour définir les protocoles et logiciels qui sont actuellement utilisés sur l’Internet. Il est à noter que c’est la même méthodologie de travail qui est utilisée aujourd’hui. Il est reproduit en annexe. C’est assez amusant de noter que c’est une communauté de très jeunes doctorants qui fut amenée a spécifier les protocoles utilisés sur le réseau. Ils attendaient tous la venue d’un « équipage confirmé » qu’ils pensaient être en charge de ce travail, mais cet équipage n’existait pas ! Reconnaissons qu’ils ont remarquablement assumé leurs responsabilités (et qu’ils ne se sont pas fait voler la vedette par leurs directeurs de thèses !). Le réseau commença alors son (tout) petit bonhomme de chemin : 15 noeuds (23 machines) en 1971, 37 en 1972. Déjà le réseau doublait chaque année ! En fait, statistiquement jusqu’en 1983 un nouvel ordinateur était relié au réseau tous les .... vingt jours. Mais quelque chose d’étrange arriva. Ce réseau qui avait été mis en place pour permettre à des scientifiques de haut niveau de partager du temps de calcul sur des supers ordinateurs répartis dans différents endroits était surtout utilisé pour se transmettre des messages électroniques (l’ancêtre de l’e-

mail), des nouvelles, du bavardage même. Ces chercheurs utilisaient ARPANET pour collaborer sur des projets, s’envoyer des notes sur leurs travaux en cours, et même pour faire du « radio-moquette ». Les scientifiques utilisaient le réseau pour de la communication de personne à personne. Ils étaient plus enthousiastes pour ce service que pour les super-calculs à distance. (à l’inverse des autorités administratives chargées de gérer les budgets des centres de calcul !). La première liste de diffusion importante s’appellait SF-lovers et était consacré à la science ... fiction ! Comme l’ont écrit Licklider et Vezza: « l’un des avantages du système de messagerie par rapport aux lettres classiques était que, dans un message ARPANET, l’on pouvait écrire sans élégance, faire des fautes de frappe, même si le message était à destination de quelqu’un de plus vieux dans une position hiérarchique supérieure. Le destinataire n’en prenait pas ombrage. Le formalisme et la perfection que la majorité des gens attend d’une lettre classique n’était pas nécessaire dans les messages électroniques, sans doute parce que le réseau était beaucoup plus rapide, et ressembalit pas mal au téléphone. L’avantage par rapport au téléphone c’est qu’il n’y avait pas de bavardage préliminaire et que l’on pouvait aborder directement le vif du sujet, que l’on avait une archive et que les deux correspondants n’avaient pas à être disponibles au même instant. » C’est cette même année , en Octobre, qu’eu lieu une démonstration d’ARPANET à la première conférence internationale sur les communications entre ordinateurs qui se tenait à Washington. Cette démonstration fut un succès, à la surprise d’AT&T qui ne pensait pas que ce réseau puisse fonctionner. La France avait au moins deux représentants à cette conférence : Lous Pouzin qui dirigeait le projet du réseau Cyclades à l’INRIA et Remi Després qui s’occupait du réseau de commutation de paquets de France-Telecom (qui est devenu Transpac). C’est à cette même conférence que fut créé l’INWG (International Network Working Group) dont Vint Cerf assura l’organisation et la présidence pour les quatres premières années. Le rôle de ce groupe de travail était d’arriver à un consensus sur la définition des protocoles utilisés sur les réseaux. Enfin c’est cette même année que Ray Tomlinson choisit le signe @ pour séparer les noms d’utilisateurs des noms de machines dans les adresses de courrier électronique ! (le fameux « at » que chacun veut désormais sur sa carte de visite). Il crée le programme SNDMSG qui permet d’envoyer du courrier électronique sur ARPANET. Ce fut un succès instantané. C’est en 1973 que le réseau fondé par l’ARPA (devenue DARPA, Defence Advance Research ...) devient international avec la connexion de l’ « Univesity College » de Londres et du « Royal Radar Establishment » en Norvège. Déjà au début 1973 une liaison satellite avait été établie entre la Calififornie et un TIP situé à Hawaï. Comme le réseau grandissait, les chercheurs apprirent quels hypothèses, quels modèles étaient inadéquats. Le réseau permit de découvrir les bugs beaucoup plus facilement qu’en laboratoire: un bug apparaissant une fois tout les deux ans dans un IMP apparaitrait toute les semaines dans un réseau composés de 100-IMP. Sa résolution en sera donc grandement facilité. Le travail principal était alors de définir des protocoles et de les implémenter. Mais dès 1969 les pionniers avaient spécifiés un protocole symétrique d’hôte à hôte: NCP (Network Control Program), et avaient envisagés les fonctionalites de programmes comme telnet et ftpv. C’est à la fin de l’année 1973 que commencèrent les premiers travaux sur les

protocoles TCP (Transport Control Protocol) qui sont actuellement utilisés. Les spécifications initiales furent réalisées dans le laboratoire de Vint Cerf à Stanford et présentées à une réunion de l’INWG à l’Université du Sussex en Septembre 1973. En Mai 1974 un article de Vint Cerf et de Bob Kahn paru dans les annales de l’IEEE viet le toute première spécification du protocole TCP fut publiée comme RFC en Décembre 1974.Les chercheurs travaillèrent à spécifier la suite de protocole TCP. Il y en a eu quatre versions, la quatrième publiée en 1978. Le document IEN-151 daté du 1er Avril 1980 et écrit par Vint Cerf décrit sur un plan historique et technique les évolutions de TCP de la version 1 à la version 4. Il est reproduit en annexe.

Vint Cerf C’est en 1977 que la première démonstration d’Internet eu lieu: une interconnexion utilisant ARPANET, les communications via satellite et de la transmission de paquets par radio. Afin de connecter un émetteur radio mobile, Jim Mathis conduisait une camionette sur une autoroute de San-Francisco avec un système de commutation de paquets par radio qui tournait sur un ordinateur LSI-11.

Les paquets partaient sur une passerelle située dans les locaux de BBN, puis traversaient l’océan Atlantique via une liaison par satellite point à point pour arriver en Norvège d’ou ils descendaient à Londres via une ligne terrestre, puis retournaient aux Etats-Unis à nouveau par satellite en utilisant le réseau SATNET qui avait des relais terrestre en Angleterre et en Suède. Ce qui était simulé dans cette expérience était une communication à partir d’un mobile dans un champ de bataille: le traffic partait de l’unité en mouvement via un réseau radio à commutation de paquet vers l’ARPANET puis grâce à une liaison satellite et terrestre à l’University College de Londres ou il était alors véhiculé par le réseau SATNET pour atteindre à nouveau l’ARPANET pour arriver finalement à l’USC sur un DEC KA-10 ! Chaque paquet parcourait environ 150 000 kilomètres: pas un seul bit n’a été perdu !

L’image de ce bébé panda a été digitalisée à l « University College » de Londres et utilisé pour tester les transmissions sur le réseau SATNET. Le 27 Octobre 1980 ARPANET a été inutilisable pendant plusieurs heures vii à cause d’un problème matériel dans les IMP. La décision de migrer l’ensemble des IMPs sur du matériel dit C30 à alors été prise. Cette panne du réseau à été la première grande panne du réseau Internet ! Les années 1980-1983 ont été les années de transition de NCP vers TCP/IP. viii C’est Daniel C. Lynch ix alors directeur de la division informatique de USC-ISI (Marina de Rey) qui dirigea l’équipe formée de 75 personnes chargée de cette migration.

En Juillet 1982 le premier ordinateur ne parlant que TCP/IP a été mis sur le réseau ARPANET. Il est extrêment difficile lors d’une migration d’un protocole vers un autre de montrer que l’équipe en charge de cette tache respectera les délais. A l’automne 1982 le protocole NCP ne fut plus opérationnel penadnt deux jours pour convaincre les récalcitrants. Au 1er Janvier 1983 il fût définitivement abandonné. Le 10 Mars 1983 , le sous secrétaire d’Etat à la défense, Richard D. Delauer, publie un important memorandum imposant l’utilsation du protocole TCP/IP pour le réseau de la défense américain (DDN, Defence Data Network) qui comportera en fait deux réseaux. L’un MILNET non couvert par le secret défense, l’autre réseau étant lui cassifié. Ce memorandum est reproduit en annexe.

ANNEXES. Le 1er RFC rédigé par Steve Crocker. Network Working Group 4689 RFC-3 April 1969 Steve Crocker UCLA DOCUMENTATION CONVENTIONS The Network Working Group seems to consist of Steve Carr of Utah, Jeff Rulifson and Bill Duvall at SRI, and Steve Crocker and Gerard Deloche at UCLA. Membership is not closed. The Network Working Group (NWG) is concerned with the HOST software, the strategies for using the network, and initial experiments with the network. Documentation of the NWG's effort is through notes such as this. Notes may be produced at any site by anybody and included in this series. CONTENT The content of a NWG note may be any thought, suggestion, etc. related to the HOST software or other aspect of the network. Notes are encouraged to be timely rather than polished. Philosophical positions without examples or other specifics, specific suggestions or implementation techniques without introductory or background explication, and explicit questions without any attempted answers are all acceptable. The minimum length for a NWG note is one sentence. These standards (or lack of them) are stated explicitly for two reasons. First, there is a tendency to view a written statement as ipso facto authoritative, and we hope to promote the exchange and discussion of considerably less than authoritative ideas. Second, there is a natural hesitancy to publish something unpolished, and we hope to ease this inhibition. FORM Every NWG note should bear the following information: 1. "Network Working Group" "Request for Comments:" x where x is a serial number. Serial numbers are assigned by Bill Duvall at SRI 2. Author and affiliation 3. Date

4. Title. The title need not be unique. DISTRIBUTION One copy only will be sent from the author's site to" 1. Bob Kahn, BB&N 2. Larry Roberts, ARPA 3. Steve Carr, UCLA 4. Jeff Rulifson, UTAH 5. Ron Stoughton, UCSB 6. Steve Crocker, UCLA Reproduction if desired may be handled locally. OTHER NOTES Two notes (1 & 2) have been written so far. These are both titled HOST Software and are by Steve Crocker and Bill Duvall, separately. Other notes planned are on 1. Network Timetable 2. The Philosophy of NI 3. Specifications for NIL 4. Deeper Documentation of HOST Software.

L’IEN-151 rédigé par Vint Cerf. IEN 151 Vint Cerf DARPA/IPTO 1 April 80 FINAL REPORT OF THE STANFORD UNIVERSITY TCP PROJECT Vinton G. Cerf 1 April 1980 ABSTRACT: This report provides a brief historical and technical summary of the Stanford University internet, host-to-host Transmission Control Protocol (TCP) project. Developed from 1973-1976 at Stanford, Bolt Beranek and Newman and University College London, the effort then continued at other research and development centers during 1977-1980. Originally designed as a monolithic internet protocol, the internet aspects were separated into a distinct protocol layer in early 1979 with the publication of version 4 of TCP. The resulting pair of protocols, TCP4 and Internet Protocol (IP) are now undergoing procedures for standardization within the DoD and Intelligence Community. The four most valuable results of the Stanford effort were the assessment of which functions could or should be implemented in the protocol and which should not, the implementation of an efficient, assembly-language version of TCP for an LSI-11 computer, the development of a "micro" operating system (MOS) for the same computer, and the specification of the TCP protocol. 1. Introduction: The Stanford TCP project was supported by the Defense Advanced Research Projects Agency (DARPA) under contract No. DAHC 15-73-C-0363 and MDA903-76-C-0206, ARPA Order No. 2494 during the period 1 July 1973 to 30 September 1976. During the time that the project was at Stanford, two versions of TCP were developed, one in December 1974 [1] and another which was published in March 1977 [2], by DARPA. Since that time, two other versions of TCP were developed, one n December 1974 [1] and another which was published in March 1977 [2], by DARPA. Since that time, two other versions have been published, versions 3 and 4 [3,4] in January 1978 and February 1979, respectively. Editing of these latter versions was the responsibility of J. Postel, Information Sciences Institute, University of Southern California. Intermediate versions were published in July 1976 [5], July 1978 [6], and August 1979 [7]. The July 76 version was developed for the Defense Communication Agency by J. Postel, L. Garlic, and R. Ram of Stanford Research Institute for the Defense Communication Agency in connection with the AUTODIN II project. The final versions of TCP and Internet Protocol were published in January, 1980 [14,15] by DARPA on behalf of the Defense Communication Agency. During the course of the DARPA Interneting program, which supported the Cerf [Page 1]

1 April 1980 IEN 151 TCP development, a great many people and groups were involved in or influenced the development of the TCP. The initial impetus for the effort resulted from work by R. Kahn and V. Cerf, which was published in May 1974 [8], but whose basic roots were already known in September 1973 [9]. An initial design for TCP was worked out during 1973-74 at Stanford among V. Cerf, Y. Dalal, C. Sunshine and R. Karp, with the participation of R. Tomlinson [Bolt Beranek and Newman], W. Plummer [BBN], R. Metcalfe [Xerox PARC] and D. Boggs [Xerox PARC]. Implementation, testing and further development were carried out jointly at Stanford with J. Mathis and J. Estrin, Bolt Beranek and Newman, and University College London [F. Deignan, C. J. Bennett, A. J. Hinchley and M. Galland.] Visiting at Stanford during this initial development period were G. LeLann [University of Rennes, France] and D. Belsnes [University of Oslo] who provided additional philosophical leavening which influenced the design of the protocol. By 1976, implementations had been written for the Tenex/PDP-10 [Tomlinson, Plummer - in BCPL], ELF/PDP-11 [Tomlinson, Plummer - in BCPL; Karp, Dalal, Cerf - BCPL], LSI-11 [Mathis - assembly language], PDP-9 [Deignan - BABBAGE] and some performance experience obtained [10]. Since then, implementations have been for UNIX [M. Wingfield - "c"; J. Haverty - assembly language], MOS 360 [B. Braden - assembly language], Multics [D. Clark - PL/1], TOPS-20 [W. Plummer - assembly language], and NORD-10 [A. Stensby]. 2. TECHNICAL ISSUES The initial concept behind TCP was very simple. Two processes wishing to communicate had only to know the other's "address". Data would be accounted for in 8-bit octets, and sequence numbers would be used to re-order the received data at the destination, if necessary. The first packet would have a special synchronization flag ["SYN"] which would alert the receiver that the sender's sequence numbers would start with the one associated with data sequence numbers so that end to end acknowledgments for data could also be used to acknowledge control. If resynchronization were needed, the sender could simply send another "SYN" packet. There would be no use for a "connection set-up" in the conventional sense. Finally, packet formats would permit internet gateways to fragment packets into identically formatted, smaller packets if necessary, to get through a net with a smaller packet size. Reassembly of fragments would be done by the destination. An initial implementation of the protocol by Tomlinson and Plummer was used to control a line printer which was supposed to spool output from a host computer onto paper. The first obvious problem which cropped up Cerf [Page 2]

1 April 1980 IEN 151 was an inability to distinguish an old duplicate SYN packet (created by retransmissions in the absence of an acknowledgments) from a new SYN packet which is trying to start a new sequence. This problem was documented in [11-13] and the solution proposed was called the "three-way" handshake" by its inventor, Ray S. Tomlinson. This addition to the original proposed protocol [8] was probably the most major change to its philosophy, since it introduced an explicit connection "set-up" exchange at the beginning to allow both ends to validate the connection sequence numbers. Basically, each end selects a starting sequence number, and receives both an acknowledgments and an indication of the start of the other end's sequence space. This validating exchange is intended to help each end distinguish old, duplicate SYNs from recent ones. For this to work correctly, some maximum throughput, so as to be able to select a suitably-sized sequence number space. In the end, a 32 bit sequence space was selected which would not wrap around for about 4 hours at 2 megabits/second. An alternative to the three-way handshake was examined in 1978 by D. Reed at MIT [16], in which the initiator of a "connection" employs a unique, non-reusable "socket identifier" as a way of distinguishing new from old connection requests. These identifiers are needed in TCP also, to distinguish among multiple connections, but the socket numbers are allowed to be reused, leading to the need to use sequence numbers and the three-way handshake to distinguish old from new connection requests. The strategy proposed by Reed required some non-volatile supply of new socket identifiers which would either never recur, or recur at such long cycles (days, weeks...) that there would never be any confusion or duplication of use. Obvious, if the socket identifiers cycled too quickly, a particular identifier might present itself for use anew while it was still in use on some connection. This idea was considered for TCP in 1978, but was not pursued as it created problems of "dangling, half-open server connections" when things went wrong. The second major issue had to do with the resynchronization of a connection after host failure. A variety of techniques were exploded and designed in detail. In the final TCP design, a simple strategy for recovering from "half-open" connections was developed. A hazard was found, however, based on violation of the assumption that sequence numbers would be consumed at no more than some maximum rate. If a connect stayed idle for a long enough period, the basic "initial sequence number" selection strategy outlined in [11-13] would encounter a hazard if the host failed just as the "next sequence number" to use fell into the so-called initial sequence number "forbidden zone". A complex set of tests were defined to catch this case, but required action on each packet transmitted to determine whether the hazardous "forbidden" zone had been entered. If so, the sequence numbers on the connection would be re-synchronized to skip around the danger area. The Cerf [Page 3]

1 April 1980 IEN 151 probability of the hazard actually occurring was judged to be quite small, and finally these tests were eliminated, vastly simplifying the TCP definition and implementation. The third critical issue had to do with the treatment of packets which required fragmentation to pass through a network. Gateways between nets were postulated which could detect that an incoming packet was too large to fit encapsulated in the packet format of the next network. A fragmentation strategy was developed which permitted an internet packet to be fragmented into smaller packets and marked in such a way that the resulting fragments could be routed independently of one another and could still be reassembled at the final destination. A major change to the TCP philosophy occurred when the basic interneting func tions (addressing, fragmentation and type of service selection) were separated from the end to end functions of TCP (sequencing, retransmission, duplicate detection, flow control and port multiplexing). At this point, the fragmentation problem was substantially simplified since it applied only to the internet packets and limited knowledge of protocols to the IP layer in the gateway. At the same time, this permitted other higher level protocols, adjacent to the TCP layer, to rely on the special services, including fragmentation and reassembly, of the IP protocol layer. Network Security The TCP concepts were applied to the ARPA network security program and an architecture was developed which accommodated the use of TCP as an end to end protocol, below which, end to end encryption could take place. This architecture became even simpler when the TCP was split from the internet protocol functions since security was provided at the IP level, allowing many different transport protocols, in addition to TCP, to be secured by the same basic system. Implementation and Experimentation Two TCPs were developed during this project: 1. BCPL for PDP-11 under ELF operating system. 2. Assembly Language for LSI-11 under MOS operating system. The former was useful for high-level description of the TCP functionality but was never very efficient. Extensive performance tests and timing analyses revealed that 75-80% of the overhead for the BCPL TCP running under ELF was attributable to either the slow interprocess Cerf [Page 4]

1 April 1980 IEN 151 communication system in ELF or the inefficient "Reliable Transmission Protocol" for the Very Distant Host interface to ARPANET. The RTP introduced a minimum round-trip time to the IMP and back of some 50 ms, limiting packet rates to about 20 packets/second. Performance tests conducted with a Babbage implementation at University College London [10] were even less satisfactory due to buffer limitations in the London PDP-9 computer and the very lengthy cross-net delays imposed by a 9.6 kb/s satellite circuit connecting London to the U.S. by way of Norway. The best packet rate we could sustain was about 2-3 packets/second. We found a significant improvement in performance to be possible upon using ARPANET "type 3" packets which are not limited to 8 outstanding messages as is normal ARPANET traffic. However, this mode of operation, if stressed, caused serious network congestion problems. To determine whether the limited performance of TCP was a design flaw, we implemented an assembly language version in about 1200 words of LSI-11 memory running under a small, 800 word micro-operating system. This version, while compatible with our 12,000 word BCPL version on ELF, was one tenth the size and achieved 37 kb/s on the LSI-11 and 50 kb/s on the PDP-11/20. The LSI-11 version was subsequently integrated in to the packet radio network at SRI as part of a Terminal Interface Unit. Conclusions This project successfully developed, implemented, documented and tested a reliable, internet work, host-to-host protocol, capable of operating in extremely hostile environments and able to recover from catastrophic failures in a graceful fashion. The adoption of the protocol for DoD use in packet networking is an indication of the far-reaching impact of this research. Cerf [Page 5]

1 April 1980 IEN 151 REFERENCES 1. Cerf V., Y. K. Dalal, C. A. Sunshine, "Specification of Internet Transmission Control Program", INWG General Note 72, IFIP Working Group 6.1, December 1974. 2. Cerf. V., "Specification of Internet Transmission Control Program - TCP (Version 2)", March 3. Cerf. V., J. Postel (eds), "Specification of Internetwork Transmission Control Program - TCP (Version 3)", January 1978. 4. J. Postel (ed), 'Transmission Control Protocol - TCP (Version 4)", February 1979. 5. J. B. Postel, L. L. Garlic, R. Rom, "Transmission Control Protocol Specification", Augmentation Research Center, Stanford Research Institute, Menlo Park, CA 15 July 1976 [for the U.S. Defense Communications Agency in connection with AUTODIN II]. 6. "Specification of Internetwork Transmission Control Program - TCP (Version 3.1)", July 1978. 7. DARPA, "Transmission Control Protocol, Version 4", August 1979 [edited by J. Postel]. 8. Cerf, V. G. and R. E. Kahn, "A Protocol for Network Intercommunication", IEEE Transactions on Communications, Vol. Com-22, No. 5, May 1974. 9. Cerf, V. and R.E. Kahn, "Proposed Protocol for Internet Host-to-Host Communication", INWG Note No. 39, September 1973. 10. Bennett, C. J. and A. J. Hinchley, "Quantitative Measurements of the Transmission Control Protocol", Proceedings of the Int'l Conference on Protocols, Andre Danthine [ed]. 11. Tomlinson, R.S., "Selecting Sequence Numbers", INWG Protocol Note No. 2, August 1974; Proceedings of the ACM SIGCOMM/SIGOPS Interprocess Communication Workshop, (Santa Monica, CA, March 24-25, 1975) and ACM Operating Systems Review, Vol. 9, No. 3, July 1975, Association for Computing Machinery, New York, 1975. 12. Dalal, Yoden, K., "More on Selecting Sequence Numbers", INWG Protocol Note, No. 4 IFIP Working Group 6.1, August 1974; also, in Proceeding of the ACM SIGCOMM/SIGOPS Interprocess Communications Workshop, (Santa Monica, CA, March 24-25, 1975) and ACM Operating Systems Review, Vol. 9, No. 3, July 1975, Association for Computing Machinery, New York, 1975. Cerf [Page 6]

1 April 1980 IEN 151 13. Dalal, Yogen K., "Establishing a Connection", INWG Protocol Note 14, IFIP Working Group 6.1, March 1975. 14. DARPA, "DoD Standard Transmission Control Protocol", (J. Postel, ed.) January 1980. 15. DARPA, "DoD Standard Internet Protocol", (J. Postel, ed.), January 1980. 16. Reed, David P., "Naming and Synchronization in a Decentralized Computer System", MIT Report LCS/TR-205, September, 1978. 17. Sunshine, C., "Interprocess Communication Protocols for Computer Networks", Ph.D. Dissertation, Stanford University, December 1975.

Memorandum (10 Mars 1983) portant création de MILNET et de l’obliagtion d’utiliser TCP/IP dans le « Defence Data Network ». [ PROTOCOLS:OSDIR-3.TXT ] [ OJ, 5/86 ] THE UNDER SECRETARY OF DEFENSE WASHINGTON D.C. 20301 10 March 1983 MEMORANDUM FOR THE MILITARY DEPARTMENTS DIRECTORS, DEFENSE AGENCIES DIRECTORS, JOINT STAFF, OJCS SUBJECT: Defense Data Network (DDN) Implementation References: (a) Dep Sec Def Memorandum, Subject: Termination of AUTODIN II, 2 April 1982 (b) DTACCS Memorandum, Subject: AUTODIN II Phase I Decision Paper and OSD Guidance for Data Network Developments, 16 July 1975 This memorandum directs the implementation of the Defense Data Network (DDN) in accordance with Reference (a). This memorandum replaces the previous guidance contained in Reference (b). The Director, Defense Communications Agency (DCA) is overall Program Manager for DDN. In order to ensure that DDN is implemented as an operationally and economically effective program, the following areas must receive expeditious attention: (1) The user system requirements for all DoD data communication systems must be confirmed. This must include accurate operational and technical information. (2) System users must select interfacing methods as well as the timeframes required for their systems to connect to the DDN. (3) An effective cost recovery scheme which provides for equitable user service costs must be established. The enclosure hereto contains Guidance and Program Direction applicable to DDN and other DoD Data Networks, and tasking in support of the Defense Data Network Program (to be reviewed by DUSD (C3I) on a continuing basis). In order to assure success of the DDN, a DDN Coordinating Committee has been established, chaired by the Director of Information Systems with membership from the OJCS, Services, and appropriate Defense Agencies. Intensive and continuing management support from every echelon will be required to make this vital effort a success.

Richard D. DeLauer

GUIDANCE AND PROGRAM DIRECTION APPLICABLE TO THE DEFENSE DATA NETWORK AND OTHER DoD DATA NETWORKS References: (a) Dep Sec Def Memorandum, Subject: Termination of AUTODIN II, 2 April 1982 (b) DTACCS, Memorandum, Subject: AUTODIN II Phase I Decision Paper and OSD Guidance for Data Network Developments, 16 July 1975 (c) DUSD (C3I) Memorandum, Subject: Defense Data Network -- Security Architecture Options, 10 May 1982 (d) Director of DCA Memorandum, Subject: Defense Data Network, -- Security Architecture Options, 19 Nov 1982 (e) Director of NSA Memorandum, Subject: DoD Policy on Standardization of Host-to-Host Protocols for Data Communications Networks, 23 March 1982 I. Applicability of Program Guidance and Direction This guidance shall be applicable to the Office of the Secretary of Defense, the Joint Chiefs of Staff, Military Departments, and Defense Agencies. The definition and scope of the Defense Data Network (DDN) will be updated or redefined as dictated by changes in user requirements, technological developments, and economic factors. Evolution of the DDN as a Defense Communications System (DCS) element will be governed by the DCS Five Year Plan (FYP) process. Any major changes in the scope, schedules, cost, or composition of the network must be reviewed and approved by DUSD (C3I). II. Definition of the DDN DDN is a data communications service which will utilize packet technology as its primary switching technique to fulfill the data communications needs of the DoD. The DDN is the data communications service of the Defense Communications System (DCS). The DDN Program Plan, revised 19 May 1982, and augmented by the DDN Security Architecture Reports, (Ref d and e) provides a comprehensive description of the initial planning for the network.

III. Program Strategy for Data Networks The DDN will supply data communications services in support of critical military operational systems, including WWMCCS and intelligence systems, general purpose ADP and other command based systems and data networks, which have requirements for long-haul data communication services. The DDN will provide connectivity for these subscriber systems with the goal of maximum potential for interoperability. The DDN is designed to incorporate the maximum practical modularity and flexibility in the backbone system and its various interfaces to accommodate significant changes in the user requirements, in ADP and data communications technology, and in the economic factors influencing this program. Contractual and implementation planning for DDN must accommodate variations in the number of switches to be implemented and in the overall implementation schedule of the program. Every attempt must be made to balance this flexibility against reasonable cost impacts to the backbone system and the individual subscriber systems. It is essential that the DDN planning be phased in a cohesive total program implementation that is operationally and economically viable. DUSD (C3I) memorandum, 10 May 1982, (Ref c) directed DCA and NSA to conduct a review if the DDN Security Architecture alternatives for the integration of the various subscriber communities that comprise the DDN. Refs d and e describe the network security architectures that were evaluated. The approved DDN network security architecture contains two segments, a classified segment and an unclassified segment. The two segments are connected together via gates which allow use of the unclassified segment backbone by the classified subscribers. DDN switches in the classified segment (C2I network) are protected to the SECRET level and military encryption devices are employed on all classified segment trunk and access lines. All subscribers on the classified segment are connected to the DDN via the Internet Private Line Interface (IPLI), or equivalent end-to-end encryption (E3) devices. The unclassified segment (MILNET) has switches in restricted locations and uses DES trunk encryption in CONUS, and has switches in SECRET-cleared facilities and uses military encryption devices on OCONUS trunk lines and on OCONUS-CONUS connections. The software in the packet switches and monitoring centers will not be reimplemented, but will be examined for security flaws and brought under strict configuration control. This architecture is referred to in the review as Option 2.2 -- WITH (with IPLIs on all classified hosts and without reimplementation of network software.) Near-term security for the DDN system will be provided through link encryption of the circuits and segregation of different subscriber communities. Provision of DES link encryption on the MILNET shall proceed as expeditiously as possible, but implementation of systems shall not be delayed solely because such encryption is not in place. Every effort must be made to expedite the development of end-to-end data encryption technology via the Internet Private Line Interface (IPLI) and BLACKER Programs. The focus of these efforts should be to provide host-to-host encryption protection. The BLACKER effort should provide remote key distribution and a trusted (multilevel secure) E3 device suitable for use on the DDN by programs such as the Inter-Service/Agency AMPE, World-Wide Military Command Control Systems (WWMCCS) Information Systems, and SACDIN.

The Director, DCA and all prospective users of the DDN should be fully aware of the requirements of the Privacy Act of 1974, should monitor all follow-on guidance deriving from this Act and related legislation, and should plan for all appropriate changes to the design or operation of their respective systems. The DDN already has design features which provide for "command privacy" and which will assist in minimizing problems from the perspective of "personal privacy." All DoD data communications systems are required to implement the DoD Standard Host-to-Host Transmission Control and Internet Protocols (TCP/IP) by Ref f. There are ongoing concerted efforts within the government and industry to develop additional standardized data communication protocols. These efforts must be monitored closely to ensure that they meet the functional requirements fo the DoD and whenever possible DoD protocols are in consonance with these efforts. At the present time, the network access method supported by the DDN is the 1822 interface with the Transmission Control and Internetwork Protocols (TCP/IP). Consistent with our policy of using commercial interface standards wherever possible, DCA is conducting an extensive review in coordination with the National Bureau of Standards of the various options in the X25 network access specifications. This review and subsequent testing should result in a specification of the X25 options which will be supported by the DDN. Essential characteristics of this specification will be efficient with TCP/IP, with existing 1822/TCP/IP implementations and with the DDN end-to-end encryption capabilities. The wide diversity of incompatible X25 implementations presently available or contemplated in the commercial market could lead to serious operational problems for the DDN and its users. Until the DDN X25 specification has been approved by the DoD Protocol Standards Steering Group, no implementations of X25 will be authorized for use on the DDN. IV. Guidance for DoD Data Networks A. Use of the DDN All DoD ADP systems and data networks requiring data communications services will be provided long-haul and area communications, interconnectivity, and the capability for interoperability by the DDN. Existing systems, systems being expanded and upgraded, and new ADP systems or data networks will become DDN subscribers. All such systems must be registered in the DDN User Requirements Data Base (URDB). Once registered in the URDB, requests by a Service/Agency for an exception to this policy shall be made to DUSD (C3I). Requests for exceptions for joint interest systems shall be routed to DUSD (C3I) through the JCS. Authorization for such special networks may be granted by DUSC (C3I) on the basis of special economic or operational considerations such as:

1. The nature of the data communications services required cannot be satisfied by DDN or a reasonable modification thereto, or 2. Critical operational requirements necessitate immediate implementation actions to provide a data communications service earlier than can be available within the DDN implementation schedule, or 3. The ADP system has time-phased requirements for communications support which can be satisfied and justified, on economic grounds, by an interim network with subsequent transition to DDN when economically feasible. The DDN Program Manager will, based on the latest information contained in the URDB, prepare projections at several time intervals (e.g., 6 months, one year, two years) of the future topology and data flow characteristics for the networks that comprise the DDN. These projections will be distributed for comment to the OJCS, Services and Agencies. Every attempt will be made in these topology projections to provide equivalent or better service to all current DDN subscribers. Services/Agencies should carefully review these projections and resolve any problems with the DDN program Manager. Only in case of irresolvable problems should the matter be brought to the attention of the DDN Coordinating Committee. The DDN Program Manager will provide for informal electronic mail capabilities of the MILNET similar to those presently on the ARPA network. Provisions for funding these services through the Communications Services Industrial Fund (CSIF) should be made available as soon as possible. Users are encouraged to connect general purpose ADP resources to the DDN for the purpose of sharing computational resources with others of the network. This provision includes the connection of commercially available resources where appropriate. B. Specific Network Guidance 1. ARPA Network Those Service/Agency ADP systems that are currently connected to the ARPA network or for which ARPA network connection is planned will form the baseline for the unclassified portion of DDN which has been designated the MILNET. The ARPA network will be partition into the MINET and an Experimental Network as quickly as possible. Electronic mail forwarding capabilities will be provided between the two networks. Positive network access control measures will be implemented on the MILNET and, once fully employed, will allow authorized MILNET users full internet access to the Experimental Network but prohibit full internet access to MILNET for the Experimental Network. The CONUS switches in the MILNET will be located on restricted access locations and use the DES encryption techniques on all trunks. OCONUS switches will be located in SECRET cleared facilities and military encryption devices will be used on all OCONUS trunks and all OCONUS-CONUS connections.

The Experimental Network (which will retain the name ARPANET network) will be utilized for computer network research and to test concepts to be employed in the DDN. The Experimental Network will be managed and operated by the DDN Program Office. Policies governing its operation will be established by a Steering Committee composed of the DDN Program Manager and sponsors of systems using the Network. The Chairman of this Steering Committee will be appointed by the Director of the Defense Advanced Research Projects Agency. 2. WWMCCS Intercomputer Network The communications subsystem of the WIN is the basis for the classified portion of the DDN. The DDN will provide service to the WWMCCS ADP community under the direction of the JCS and in accordance with a WIN-DDN Transition Plan to be developed by the DDN Program Manager and the JCS. Department of Defense Intelligence Information Systems and other classified subscriber communities will be added to the WIN communications subsystem to form the C2I network as soon as end-to-end encryption measures are available. 3. Movements Information Network The USEUCOM Movements Information Network (MINET) will initially be managed as a separate testbed network to determine if urgent transportation requirements of the United States Military in Europe can be satisfied by electronic means. As soon as the MILNET is physically partition from the experimental network, the MINET communications subnetwork will become an integral part of the MILNET. Additional users in Europe not covered in the original MINET planning documents will be integrated into the MILNET communications subnetwork by the DDN Program Manager in a manner not to degrade service to the MINET testbed. V. Tasking in Support of the Defense Data Network Program A. Tasking for the Chairman, Joint Chiefs of Staff 1. Revision of various MOPs as required to comply with the guidance contained herein, and publication of a new MOP addressing the DDN. 2. Validate joint-interest user system requirements and forward to DCA. B. Tasking for the Director, Joint Staff 1. The Joint Staff should monitor the general progress of the tasks identified in this enclosure and assist the DCA, Military Departments, and other Defense Agencies as appropriate. 2. The Joint Staff should continue consideration of the potential requirements of the Unified and Specified Commands which might logically relate to the DDN program. This would include the appropriate potential requirements for NATO interfaces, deployment of switches, interfaces to tactical data systems, changes in the level of survivability needed, and other longer range data communication planning issues.

C. Tasking for the Directory, DCA 1. The Directory, DCA should accomplish the following tasks and report to DUSD (C3I) as necessary. (a) Develop, operate and manage the DDN on a subscriber-to-subscriber basis. (b) Confirm user system requirements in order to establish and maintain a data base of data communications requirements for system planning and sizing. This action should include both updated projections based on the tasking included in other parts of this enclosure and identification of the specific timeframes when candidate user systems can be connected to the DDN. (c) Develop and refine a reporting format which will allow the Military Departments and Defense Agencies to provide the user requirements data, tasked elsewhere in this enclosure, in a consistent manner. (d) Revies the technical concept of operation for each candidate ADP system to ensure that the DDN can adequately support these ADP system requirements. (e) Coordinate with the appropriate agencies to ensure that the DDN specification properly identify and fully address network security and privacy requirements. (f) Provide technical review and validation of the protocols, interfaces, precedence, and security features of the DDN and the impacts on user systems. This validation should be accomplished through experimentation, consultation and coordination with the user communities, and evaluation by recognized experts from government and industry. (g) Develop a network reporting system that provides clear management visibility on network operations of the DDN. (h) Develop effective cost recovery alternatives for the DDN through the Communications Services Industrial Fund (CSIF) based on equitable rates reflecting actual system usage to the maximum extent feasible. (i) Establish appropriate management thresholds which will ensure early identification of major changes or problems in the program costs of schedules. (j) Investigate the potential use of network interfacing devices which will minimize subscriber conversion and operational impacts. (k) Assist the Military Departments and Defense Agencies in accomplishing their designated tasks.

D. Tasking for the Military Departments and Defense Agencies 1. Develop and forward in a timely manner the required information on all currently operational and planned ADP systems and ata networks that require long-haul and area data communications support. This information should be revised as necessary to keep the User Requirements Data Base as accurate as possible. 2. Plan and program to assist the Director, DCA in the implementation on the DDN and user systems. 3. Reassess current concepts of operations and reporting instructions in light of the features and capabilities available through the use of the DDN, and plan for possible improvements. 4. Carefully assess the security features of the DDN and determine how to maximize their security protection. Although these security features may be helpful for ADP system operations, they do not solve the multilevel security problems of the ADP systems. 5. MILDEPs and Agencies are responsible for interfacing their data communications systems to the DDN in accordance with DDN interfacing specification. Where mutually agreed by MILDEPs/Agencies and DCA, DCA will coordinate and manage the development of families of network interfaces. E. Additional Tasking for the Directors, National Security Agency and Defense Intelligence Agency Assist the Director, DCA in ensuring the security integrity of the communications systems, including segregation of GENSER-SI traffic, segregation of subscriber communities, Defense Switched Network (AUTOVON) dial-up circuit protection procedures, overall network security, and other appropriate areas of security.

i le premier IMP a été livré à l’UCLA le 30 Août 1969 ii Source : Sacramento Bee, May 1, 1996, p. D1 iii un RFQ: request for quotations ou combien ca coûte. iv le plus puissant mini ordinateur de l’époque. v le premier RFC concernant le transfert de fichier, le RFC 454, fur publié en 1973 vi A protocol for packet network intercommunication (IEEE Trans Comm) vii voir le RFC 789 qui décrit l’incident viii Voir ien201 et le rfc 801 qui décrivent la transition. ix qui a fondé Interop en 1985