nnTCP/IPMarco Sommani - Ottobre 1990 Storia di ARPAnet Alla fine degli anni '60 nasce il progetto ARPAnet, su iniziativa della Defense Advanced Research Project Agency (DARPA). ARPAnet utilizza minicomputers della BBN detti Packet Switched Nodes (PSN), collegati da linee punto-punto. Gli host si collegano ai PSN con una speciale interfacia, detta In segiuto viene reso possibile anche il collegamento host-PSN tramite linea seriale con protocollo HDLC/LAPB. Nel 1984 il DoD separa ARPAnet (che continua ad esistere per ricerche sperimentali) MILnet, utilizzata regolarmente per le comunicazioni del DoD. Le due sottoreti rimangono interconnesse. Nel 1990 termina il progetto ARPAnet e scompare la sottorete che portava il suo nome. La tecnologia ARPAnet è tuttora utilizzata in parti di MILnet.

nnTCP/IPMarco Sommani - Ottobre 1990 Nascita di Internet Negli anni '70 DARPA promuove anche studi sulla commutazione di pacchetto via satellite o via radio. Nasce l'esigenza di interconnettere reti eterogenee ( ). Ciò porta alla definizione dell'architettura TCP/IP. Primi esperimenti: Nel 1983 DARPA impone ad ogni host connesso ad ARPAnet di usare il TCP/IP. Nasce così un insieme di reti interconnesse per mezzo di protocolli TCP/IP. Questo insieme prende il nome di Internet. L'Inclusione dei protocolli TCP/IP nel Berkeley Unix ne provoca una rapidissima diffusione, anche al di fuori di Internet.

nnTCP/IPMarco Sommani - Ottobre 1990 Internet negli Stati Uniti Attualmente il nucleo della rete Internet negli Stati Uniti è gestito e finanziato da cinque agenzie governative: National Science Foundation (NSF). Defense Advanced Research Project Agency (DARPA). Department of Energy (DOE). National Aeronautics and Space Administration (NASA). Department of Health and Human Services (DHHS).

nnTCP/IPMarco Sommani - Ottobre 1990 Comitati di Coordinamento Le cinque agenzie governative sono coordinate dal Federal Networking Committee (FNC). Le altre reti di Internet possono utilizzare la dorsale del FNC purché si impegnino a farlo per soli scopi di ricerca. L'insieme delle reti statunitensi autorizzate a usare la dorsale forma la National Research and education Network (NREN). I contatti fra il FNC e gli organismi analoghi di altri paesi sono tenuti dal Coordinating Committee for International Research Networking (CCIRN).

nnTCP/IPMarco Sommani - Ottobre 1990 Internet in Europa Già nella prima metà degli anni '80 vengono stabiliti i primi collegamenti transatlantici fra sedi europee e il resto dell'Internet statunitense. In seguito, su iniziativa soprattutto di EUnet (la rete UUCP europea) e dei fisici delle alte energie, vengono creati alcuni collegamenti TCP/IP europei internazionali. Nel 1989 i gestori dell'embrione di rete TCP/IP europea creano un gruppo di lavoro, detto RIPE (Réseaux IP Européens), con lo scopo di creare l'inrastruttura organizzativa necessaria alla crescita di Internet in Europa. RIPE è tuttora una associazione di volontari, la cui utilità è tuttavia riconosciuta da tutti gli enti che finanziano le reti per la ricerca in Europa e in USA. È allo studio la proposta di creazione di un centro operativo di RIPE finanziato dalla Comunità Europea e da altre fonti.

nnTCP/IPMarco Sommani - Ottobre 1990 Internet in Italia Il primo collegamento italiano viene realizzato nel maggio '86: il CNUCE di Pisa avvede alla rete via satellite SATnet (una delle reti che formano Internet). Lo sviluppo di Internet in Italia è attualmente coordinato da EUnet e dal Gruppo Armonizzazione Reti per la Ricerca, di cui fanno parte: CILEA, CINECA, CNR, ENEA, INFN, Tecnopolis-CSATA. Attualmente le seguenti linee internazionali collegano l'Italia al resto di Internet: CNAF (Bologna) - CERN (Ginevra) (collegamento GARR), DIST (Genova) - INRIA (Sophia-Antipolis) (collegamento EUnet).

nnTCP/IPMarco Sommani - Ottobre 1990 Documenti ufficiali di Internet Tutti i documenti ufficiali di Internet e le informazioni utili per il suo utilizzo sono ottenibili via rete collegandosi con il Network Information Systems Center (NIC o SRI-NIC), che si trova presso lo SRI International a Menlo Parl (California). SRI-NIC svolge anche funzioni di Registrar, assegnando indirizzi etc. Alcuni documenti ottenibili dallo SRINIC sono identificati dalla sigla RFCnnnn. RFC sta per Request for Comments. Il contenuto degli RFC è di varia natura, ma alcuni di questi contengono le specifiche dei protocolli ufficiali della rete Internet (e quindi dell'architettura TCP/IP). Informazioni su Internet sono reperibili anche presso NIS.NSF.NET, NIS.EU.NET e altri server.

nnTCP/IPMarco Sommani - Ottobre 1990 L'Internet Activity Board Il coordinamento della proettazione, l'evoluzione e la gestione di Internet è condotto dall'Internet Activity Board (IAB). Possono far parte dell'IAB tutti i volontari che abbiano qualche incarico di rilievo correlato con le attività di Internet. Alcuni compiti dell'IAB sono Approvare gli standard di Internet, Coordinare il processo di pubblicazione degli RFC, Fare piani a lunga scadenza per l'evoluzione di Internet, Rapresentare la comunità Internet a livello internazionale per tutte le questioni tecnico-politiche. Tutte le decisioni dell'IAB vengono rese pubbliche per mezzo di RFC.

nnTCP/IPMarco Sommani - Ottobre 1990 Il modello Catenet L'interconnessione delle reti in Internet avviene in modo conforme al modello Catenet. Il modello Catenet è descritto nel documento IEN 48: "The Catenet Model for Internetworking" scritto da Vint Cerf nel IEN significa Internet Engineering Note. Anche gli IEN sono ottenibili dallo SRI-NIC.

nnTCP/IPMarco Sommani - Ottobre 1990 Caratteristiche del modello Catenet Il sistema di indirizzamento è unico per tutto l'insieme di reti interconnesse. I dati vengono trasmessi dal mittente al destinatario in forma di datagram, ossia pacchetti contenenti nell'intestazione gli indirizzi del mittente e del destinatario. Le reti sono interconnesse da gateway, ossia da macchine che ricevono il datagram da una rete e lo ritrasmettono su un'altra dopo aver consultato opportune tabelle di routing. I gateway fanno parte del sistema di indirizzamento globale. L'inoltro di un datagram su una rete può richiedere l'inserimento del datagram in uno o più pacchetti del tipo utilizzato sulla sottorete. Talvolta la trasmissione di un datagram su una sotorete può richiederne la suddivisione in più datagram. In tal caso la ricostruzione del datagram originario viene fatta dal computer destinatario.

nnTCP/IPMarco Sommani - Ottobre 1990 L'indirizzamento di Internet Il sistema di indirizzamento golbale della rete Internet utilizza indirizzi di 4 bytes. Si è soliti rappresentare gli indirizzi di Internet come quattro numeri decimali separati da punti. Ogni numero decimale rappresenta il valore di un byte dell'indirizzo. Ad esempio, l'indirizzo x'020B80FE' viene comunemente rappresentato come La parte iniziale di un indirizzo Internet identifica una rete, la parte rimanente un host su tale rete. Secondo questa terminologia anche i gateway sono host. Un host connesso a più reti ha almeno un indirizzo Internet per rete. Ciò è vero in particolare per i gateway.

nnTCP/IPMarco Sommani - Ottobre 1990 Classificazione degli indirizzi Internet In un indirizzo Internet, il confine fra indirizzo di rete e indirizzo di host è determinato dal valore dei primi due bit. Se il primo bit è 0, la rete è di classe A. Il primo byte identifica la rete, i tre successivi l'host. Se il valore dei primi due bit è 10, la rete è di clase B. I primi fue bytes identificano la rete, i due successivi l'host. Se il valore dei primi due bit è 11, la rete è di classe C. I primi tre bytes identificano la rete, l'ultimo l'host. Un indirizzo Internet in cui la porzione host ha tutti i bit a 0 ha il significato di "questo" host. Un indirizzo Internet in cui la porzione host ha tutti i bit a 1 ha il significato di "tutti gli host di questa rete" (broadcast address). Una rete di classe C può avere al massimo 254 host.

nnTCP/IPMarco Sommani - Ottobre 1990 Informazioni per un gateway Per il suo corretto funzionamento, un gateway di Internet ha bisogno delle seguenti tabelle: Una tabella delle reti adiacenti, contenente l'indicazione del tipo di rete e dell'indirizzo Internet che il gateway ha su tale rete. La tabella delle "route", che per ogni indirizzo di rete indica l'indirizzo di un host su una rete adiacente a cui passare i datagram. Per le reti non di tipo punto-punto, una tabella di mapping da cui ricavare l'indirizzo nativo di ogni host sulla rete adiacente. Generalmente è necessario costruire manualmente solo la tabella delle reti adiacenti e quella del mapping per le reti multihost senza possibilità di broadcasting (p. es. X.25).

nnTCP/IPMarco Sommani - Ottobre 1990 Esempio delle informazioni di un gateway Tabella delle reti adiacenti 1. Tipo:EthernetIndirizzo IP: X Point-to-point Tabella delle route Rete24via Mapping X.25 L'host ha indirizzo X Mapping Ethernet L'host ha indirizzo MAC A C

nnTCP/IPMarco Sommani - Ottobre 1990 Subnetting La proliferazione del numero di reti in Internet causa problemi di memoria sui gateway e una cattiva utilizzazione delle linee di trasmissione, che vengono monopolizzate dai gateway per scambiare informazioni di routing. L'RFC950 (Internet Standard Subnetting Procedure) consente di avere insiemi di reti adiacenti aveti tutte lo stesso indirizzo di rete. Alcuni dei bit della parte locale dell'Internet address vengono utilizzati per distinguere una sottorete da un'altra. Solo gli host adiacenti ad almeno una delle reti "subnetted" devono sapere quali sono i bit che identificano le sottoreti.

nnTCP/IPMarco Sommani - Ottobre 1990 Internet Protocol L'RFC791, pubblicato nel 1981, definisce l'Internet Protocol (IP), che viene utilizzato per trasportare i datagram su Internet. Campi importanti del datagram IP sono: Un identificatore di 16 bit assegnato al datagram dal mittente. L'Internet address del mittente. L'Internet address del destinatario (può essere un indirizzo di broadcast). L'identificatore del protocollo di livello superiore a cui è destinato il datagram (Protocol Number). Il "time to live": si tratta di un valore di 16 bit che deve essere decrementato almeno di 1 da ogni gateway. Permette di evitare che un datagram resti in circolazione per sempre. Su tutti gli host su cui esiste l'IP deve esistere l'ICMP (Internet Control Message Protocol, RFC792), usato soprattutto per lo scambio di informazioni di controllo co i gateway.

nnTCP/IPMarco Sommani - Ottobre 1990 Reti su cui è standardizzato il trasporto di datagram IP ProtocolloNome estesoRFC IP-ARPAInternet Protocol on ARPAnetBBN1822 IP-WBInternet Protocol on Wideband Network907 IP-X25Internet Protocol on X25 Networks877 IP-EInternet Protocol on Ethernet Networks894 IP-EEInternet Protocol on Exp. Ethernet Nets895 IP-IEEEInternet Protocol on IEEE IP-DCInternet Protocol on DC Networks891 IP-HCInternet Protocol on Hyperchannel1044 IP-ARCInternet Protocol on ARCNET1051 IP-SLIPTransmission of IP over Serial Lines1055 IP-NETBIOSTransmission of IP over NETBIOS1088 IP-FDDITransmission of IP over FDI1103

nnTCP/IPMarco Sommani - Ottobre 1990 Soluzioni non standard per il trasporto di datagram IP Oltre alle possibilità elencate nela precedente tabella, esistono soluzioni proprietarie per il trasporto di datagram IP su reti particolari. Queste soluzioni richiedono in genere l'utilizzo di un prodotto (HW e/o SW) ben preciso. Fra le soluzioni proprietarie vale la pena di ricordare: SNALINK E' la soluzione IBM per il trasporto di ip su SNA. D-Bridge. E' la soluzione Wollongong per il trasporto di IP su reti DECnet. TCP/IP Portal. E' la soluzione DEC per il trasporto di IP su reti DECnet. L'RFC1171 descrive il Point to Point Protocol (PPP), un proposed standard per trasportare più protocolli di tipo datagram sulla stessa linea seriale. Fra i protocolli previsti ci sono IP, DECnet e CLNS OSI. Attualmente non è ancora ufficiale lo standard per il trasporto di IP su linee seriali sincrone. Lo SLIP (RFC1055) è solo per linee asincrone.

nnTCP/IPMarco Sommani - Ottobre 1990 Lista parziale di Protocol Numbers La seguente tabella è un estratto di quella completa, disponibile sull'RFC1060 (Assigned Numbers). DecimaleSiglaProtocollo 1ICMPInternet Control Message 6TCPTransmission Control Protocol 8EGPExterior Gateway Protocol 9IGPany private interior gateway 17UDPUser Datagram Protocol 29ISO-TP4ISO Transport Protocol Class 4 88IGRPIGRP

nnTCP/IPMarco Sommani - Ottobre 1990 Protocolli di routing Generamente i gateway costruiscono e aiornano le tabelle di routing scambiando informazioni con i gateway che si trovano sulle reti adiacenti. Esistono vari protocolli che descrivono il modo in cui devono avvenire gli scambi di informazioni fra gateway. In un messaggio di routing normalmente un gateway invia ad altri gateway una lista di coppie (rete, distanza), che mostra quanto ciascuna "dista" dal gateway. I vari protocolli di routing differiscono fra loro soprattutto per il modo in cui viene calcolata e interpretata la distanza. Il Routing Information Protocol (RIP) è molto diffuso perchè fa parte della distribuzione Unix di Berkeley, ma è adatto solo a reti piccole con collegamenti a velocità omogenee. Alcuni Routing Protocol sono descritti sugli RFC, altri sono proprietari.

nnTCP/IPMarco Sommani - Ottobre 1990 Autonomous Systems I gateway di Internet sono raggruppatti in Autonomous Systems (AS), costititi da gateway che comunicano con lo stesso Routing Protocol. Per lo scambio di informazioni di routing fra gateway di AS distinti esiste l'Exterior Gateway Protocol (EGP, RFC904). L'EGP era stato pensato per una Internet costituita da un AS centrale (il Core) e tanti AS connessi direttamente al Core. E' estremamente difficile gestire l'attuale topologia di Internet con l'EGP. Il Border Gateway Protocol (BGP, RFC1105) non ha le limitazioni dell'EGP, ma è ancora nella fase sperimentale. Suddividendo Internet in vari AS si riesce, fra l'altro, a ridurre il numero di reti che deve essere mantenuto nelle tabelle di ciascun gateway.

nnTCP/IPMarco Sommani - Ottobre 1990 ARP L'Address Resolution Protocol (ARP, RFC826) permette di evitare la costruzione manuale di tabelle di mapping sulle reti su cui esiste possibilità di broadcasting. Un host che vuole conoscere l'indirizzo nativo corrispondente ad un indirizzo Internet di un host su una rete adiacente invia la richiesta sulla rete con un pacchetto di broadcast. L'host che ha l'indirizzo Internet richiesto invia una risposta all'host richiedente. L'host richiedente trova l'indirizzo cercato nel campo Sender Address del pacchetto di risposta.

nnTCP/IPMarco Sommani - Ottobre 1990 TCP Il protocollo IP non garantisce la consegna dei datagram al destinatario. Per consentire la consegna della corretta succesione di dati al destinatario è stato definito il Transmission Control Protocol (TCP, RFC793). Varie applicazioni possono utilizzare i servizi TCP contemporaneamente sullo stesso host. Vengono distinte per mezzo del port number (16 bit). Alcuni Port Numbers sono riservati per determinate applicazioni.

nnTCP/IPMarco Sommani - Ottobre 1990 Utilizzo del TCP Un'applicazione che intenda servirsi del TCP deve: 1.Mettersi in contatto col il programma TCP locale specificando il proprio Port Number. 2.Chiedere l'apertura di una connessione con un'applicazione TCP remota, specificandone Internet Address e Port Number (caso "Client") oppure Attendere l'arrivo di una richiesta di connessione dall'applicazione remota (caso "Server"). 3.Scambiare dati con il partner fino alla chiusura della connessione. 4.Provocare o prendere atto della chiusura della connessione.

nnTCP/IPMarco Sommani - Ottobre 1990 UDP Alcune applicazioni particolari (es.: la consultazione del directory) possono funzoinare con un servizio di tipo datagram, senza l'overhead introdotto dal TCP per garantire l'affidabilità di un servizio Connection Oriented. Per queste applicazioni è stato definito lo User Datagram Protocol (UDP, RFC768). I pacchetti UDP, come i pacchetti TCP, sono trasportati nel campo dati dei datagram IP. Un campo importante dell'header UDP è il Port Number, che permette di distinguere fra più applicazioni UDP sullo stesso host. Le stazioni UDP, come quelle TCP, devono farsi conoscere al programma UDP locale specificando un Port Number.

nnTCP/IPMarco Sommani - Ottobre 1990 Il DomainName System Normalmente gli utenti identificano gli host remoti con un nome simbolico anziché con l'indirizzo Internet. In Internet i nomi simbolici vengono assegnati da autorità organizzate secondo una struttura gerarchica e vengono detti "domini". L'organizzazione gerarchica si riflette nella forma stessa del nome. es.: nome3.nome2.nome1.nome0 "nome0" viene detto "top level domain" e deve essere registrato presso lo SRI- NIC. L'autorità che ha registrato "nome0" è libera di assegnare nomi del tipo "*.nome0" e può a sua volta assegnare ad autorità di livello inferiore il dirito di assegnare nomi del tipo "*.nome1.nome0". Questo schema per l'assegnazione dei nomi è detto Domain Style Addressing ed è descritto nell'RFC920.

nnTCP/IPMarco Sommani - Ottobre 1990 Top Level Domains Sono accettati come top level domains i seguenti nomi: 1.I codici ISO di due lettere delle nazioni (es.: IT per l'Italia), 2.Codici di tre lettere che identificano la categoria dell'ente cui appartengono le risorse (es.: EDU per education, COM per commercial, ORG per organization, MIL per military, GOV per government, etc.). Il secondo tipo di calssificazione è particolarmente diffuso in Nord America, il primo nel resto del mondo. Il top level domain dell'Italia (IT) è stato registrato dall'istituto CNUCE di Pisa.

nnTCP/IPMarco Sommani - Ottobre 1990 Name Server Anticamente la traduzione fra nomi simbolici e indirizzi Internet avveniva consultando un file (HOSTS.TXT) che doveva essere aggiornato periodicamente su tutti gli host della rete. Questo metodo è ancora usato su molte LAN che usano il TCP/IP senza essere su Internet. Su Internet la traduzione viene fatta consultando un archivio distribuito, cui accedono processi detti Name Server (RFC1032, RFC1033, RFC1034 e RFC1035). Ogni Name Server possiede gli archivi relativi a un sottoinsieme connesso dell'albero dei nomi (la "zona"). L'archivio di una zona contiene anche gli indirizzi dei Name Server delle zone subordinate.

nnTCP/IPMarco Sommani - Ottobre 1990 Le Zone Ogni zona è un sottoalbero. Con il termine "Name Server di X.Y.Z" si indica un Name Server responsabile di un sottoalbero con radice X.Y.Z. La stessa zona è gestita usualmente da più di un Name Server. In questo caso gli archivi vengono aggiornati manualmente su un solo Name Server, detto primario. Gli altri Name Server, detti secondari, richiedono periodicamente al primario copie aggiornate degli archivi. I Name Server che conoscono l'indirizzo dei Name Server dei top level domain sono detto Root Name Server. I non-root Name Server devono conoscere l'indirizzo di qualche Name Server gerarchicamente superiore.

nnTCP/IPMarco Sommani - Ottobre 1990 Name Resolver Un programma che deve tradurre un nome simbolico in indirizzo di Internet ricorre al Name Resolver locale. Il Name Resolver conosce gli indirizzi di uno o più Name Server non troppo distanti a cui inviare le interrogazioni. Se la interrogazione riguarda una risorsa fuori della zona del Name Server consultato, questo deve consultare i suoi archivi per scoprire il nome di un Name Server più vicino alla risorsa nell'albero gerarchico. L'interrogazione può essere passata a questo secondo Name Server, o il nome di questo può essere restituito al Name Resolver perché prosegua nella ricerca. Tutte le risposte dei Name Server hanno un "time to live" che indica per quanto tempo possono essere ritenute valide. Ciò permette ai Name Server di conservare le risposte relative a risorse di altre zone e di utilizzarle per rispondere a interrogazioni successive.

nnTCP/IPMarco Sommani - Ottobre 1990 Applicazioni TCP Alcune applicazioni TCP particolarmente note sono: TELNETTelnet Protocol (RFC854). Permette il logon su host remoti. TN3270È un TELNET Client presente su molti host ASCII, che provvede alla traduzione TTY-3270, consentendo il logon su host IBM. FTPFile Transfer Protocol (RFC959). Permette di collegarsi con host remoti per trasferire files fra archivi remoti e archivi locali. Normalmente per acceder all'archivio di un utente remoto ocorre conoscerne la password, ma su molti host esistono archivi accessibili senza password in sola lettura ("anonymous FTP"). SMTPSimple Mail Transfer Protocol (RFC821). Permette di inviare posta a utenti su host remoti. Tutte queste applicazioni richiedono la presenza sull'host remoto del server corrispondente.

nnTCP/IPMarco Sommani - Ottobre 1990 SMTP e RFC822 Generalmente chi scrive un messaggio di posta elettronica non si connette con il server remoto, ma interagisce con un agente locale che deposita il messaggio sullo spazio disco locale. Il "Client" SMTP generalmente è un "daemon", che legge i messaggi da disco e li trasmette ai destinatari stabilendo connessioni TCP con i "Server" SMTP remoti. Il "Client" SMTP trove le informazioni necessarie al corretto instradamento dei messaggi nella loro intestazione. L'RFC822 (Standard for the Format of Internet Text Messages) descrive il formato delle intestazioni dei messaggi da mandare via SMTP. Un tipico indirizzo RFC822 ha la forma dove generalmente "localpart" è il nome di uno user e "globalpart" il nome di un host (in forma Domain Style). L'RFC822 descrive anche campi che interessano solo gli utenti finali, quali la data, l'oggetto, etc.

nnTCP/IPMarco Sommani - Ottobre 1990 Record MX I "Client" SMTP, prima di chiedere al Name Server l'Indirizzo Internet corrispondente a un nome simbolico, cercano un record di tipo MX con quel nome. Il valore del record MX contiene il nome di un altro host Internet in grado di consegnare la posta al destinatario. I record MX sono descritti sull'RFC974 (Mail Routing and the Domain System). I record MX permettono di inviare posta da Internet ad altre reti (l'MX record deve puntare a un mail gateway) o a PC che si connetto a Internet saltuariamente. L'RFC987 (Mapping between X.400 and RFC822) descrive il funzionamento dei gateway fra posta RFC822 e posta X.400. Esistono già in funzione alcuni gateway RFC987.

nnTCP/IPMarco Sommani - Ottobre 1990 Network Management Sono stati definiti due protocolli di management per le reti TCP/IP: SNMPSimple Network Management Protocol (RFC1157). CMOTCommon Management Information Services and Protocol over TCP/IP (RFC1095). Entrambi i protocolli prevedono un agent sull'oggetto da controllare e un manager sulla stazione che controlla la rete. Quasi tutti gli oggetti critici (es.: i router) di recente produzione contengono l'agent SNMP. Esiste già un certo numero di prodotti per fare il management SNMP. Il CMOT è il protocollo di management dell'OSI usato sopra il TCP. Attualmente è poco usato perché il MIB (Management Information Base) dell'OSI è solo parzialmente definito.