Continuons avec des vieux RFC. Ce RFC de 1970 se distinguait par une augmentation spectaculaire de la taille des adresses réseau : elles passaient de 5 à 8 bits.

Quand le RFC a été publié, l'expérience Arpanet battait son plein. Comme l'avait prévu le , les anciennes adresses n'offraient pas assez de place, avec seulement 32 machines possibles. Notre , qui normalisait le nouveau protocole de bout en bout a changé cela. Rappelez-vous qu'Arpanet, contrairement à l'Internet, utilisait des protocoles complètement différents entre routeurs (qu'on appelait IMP à l'époque), ou entre routeur et machine terminale, qu'entre les machines terminales. Ce RFC s'occupe de ce dernier cas. Il normalise, de façon assez approximative, le format des messages échangés entre machines terminales.

On est très loin du futur IP. Le message est précédé d'un guide (leader, le terme de header n'était pas encore utilisé) qui comprenait une adresse, le type du message, des options et un identificateur de lien virtuel (permettant à deux machines d'avoir plusieurs communications simultanées ; il n'y avait pas de séparation entre couche 3 et couche 4 à l'époque). Là, vous vous demandez peut-être : « une seule adresse ? C'est la source ou la destination ? ». C'est la destination quand une machine émet un paquet et la source quand elle en reçoit un.

Ça peut sembler très primitif mais il faut voir qu'on en était vraiment au début. Ainsi, des choses qui paraissent évidentes aujourd'hui avaient besoin d'être précisées (« les programmes peuvent être écrits dans n'importe quel langage »). Ah, et c'est dans ce RFC que le protocole reçoit son nom, NCP. Cela signifiait Network Control Program mais le sigle sera repris ensuite pour Network Control Protocol. (Il sera remplacé par TCP/IP des années après.)

Le protocole est avec connexion (le concept de datagramme était encore flou) et le RFC décrit donc comment créer une connexion. On indique la machine (sur 8 bits, donc), et un identificateur de l'utilisateur sur la machine (24 bits dont 8 pour sa machine habituelle, chaque utilisateur avait donc un numéro unique sur tout l'Arpanet).

Le reste du RFC est consacré à discuter du problème de la connexion à distance (telnet, même si le « vrai » telnet n'est apparu que plus tard). Le décrivait déjà cette connexion à distance mais le va plus loin en rappelant que ce n'est pas tout de faire passer des bits, il faut aussi faire quelque chose face à la variété des terminaux physiques et de leur comportement. Par exemple, lorsqu'on tape un caractère, l'écho doit-il être généré localement ou à distance (en ce temps, on trouvait de tout) ? Le RFC ne fournit pas encore de solution.