Introductie naar de Internet Protocollen C R C R Computer Science Facilities Group C I L S Rutgers The State University of New Jersey 3 July 1985 Vertaling door H.W.Dankmeijer (PE1ECN) Dit is een introductie naar de Internet Netwerk Protocollen (TCP/IP). Het bevat een overzicht van de beschikbare faciliteiten en korte beschrijvingen van de belangrijkste protocollen in de familie. Auteursrecht (C) 1987, Charles L. Hedrick. Iedereen kan dit document reproduceren, geheel of gedeeltelijk, vooropgesteld dat: 1. iedere kopie of reproductie van het gehele document moet de Rutgers Universiteit als bron laten zien, en deze notitie moet bijgevoegd zijn. 2. Enig ander gebruik van dit materiaal moet refereren aan deze hand- leiding en Rutgers Universiteit, en dat het materiaal auteursrecht heeft van Charles Hedrick en met toestemming wordt gebruikt. Unix is een handelsmerk van AT&T Technologies, Inc. Inhoudsopgave 1. Wat is TCP/IP? 2. Algemene beschrijving van de TCP/IP protocollen 2.1 Het TCP niveau 2.2 Het IP niveau 2.3 Het Ethernet niveau 3. Bekende vaste ingangen en de toepassings laag 3.1 Een voorbeeld toepassing: SMTP 4. Andere protocollen dan TCP : UDP en ICMP 5. Bijhouden van namen en informatie: het domein systeem 6. Routing 7. Details van Internet adressen: subnetten en uitzendingen ("broadcasts") 21 8. Datagram fragmentatie en weer samenvoegen 9. Ethernet adres omzetting : ARP 10.Verkrijgen van meer informatie Dit document is een korte introductie naar TCP/IP, gevolgd door sugges- ties wat te lezen voor meer informatie. Dit is niet bedoeld als een com- plete beschrijving. Het kan een redelijk idee geven van de mogelijkheden van de protocollen. Wanneer U echter meer details wilt weten over de technologie, zult U de standaarden zelf willen lezen. In de tekst vindt U referenties naar die standaarden, in de vorm van "RFC" of "IEN" getallen. Dat zijn document nummers. Het laatste deel van dit document geeft infor- matie hoe U kopieen van die standaarden kunt krijgen. 1. Wat is TCP/IP? TCP/IP is een verzameling protocollen, die ontwikkeld zijn om computers gebruik te laten maken van gemeenschappelijke hulpbronnen, via een net- werk. Het werd ontwikkeld door een groep onderzoekers op het ARPAnet. Het ARPAnet is zeker het meest bekende TCP/IP netwerk. Vanaf Juni 1987, had- den tenminste 130 verkopers producten die TCP/IP ondersteunen, en duizen- den verschillende netwerken gebruiken het. Eerst enige basis definities. De meest nauwkeurige naam voor de groep protocollen die wij beschrijven is de "Internet Protocol Suite". TCP en IP zijn twee van de protocollen in deze familie. (Zij zullen hierna wor- den beschreven). Omdat TCP en IP de meest bekende protocollen zijn, is het de gewoonte geworden om de term TCP/IP of IP/TCP te gebruiken voor de gehele familie protocollen. Het is niet de moeite waard om deze gewoonte te bestrijden. Het kan echter tot wat vreemde dingen leiden. Bijvoor- beeld: Ik betrap mij er zelf op te praten over NSF als gebaseerd op TCP/ IP, zelfs wanneer dit TCP in het geheel niet gebruikt. (Het gebruikt IP, maar het gebruikt een alternatief protocol, UDP, in plaats van TCP. Deze alfabet soep zal worden duidelijk gemaakt in de volgende hoofdstukken. Het Internet is een verzameling van netwerken, inclusief het Arpanet, NSFnet, regionale netwerken zoals NYsernet, lokale netwerken van een aantal Universiteiten en onderzoeks instituten en een aantal militaire netwerken. De uitdrukking "Internet" is van toepassing op deze complete groep van netwerken. De subgroep die wordt gemanaged door het departement van defensie wordt genoemd als de "DDN" (Defence Data Network). Dit om- vat sommige onderzoek georienteerde netwerken, zoals Arpanet en de meer strikt militaire netwerken. (Omdat veel van de financiering voor het ontwikkelen van Internet protocollen is gedaan via de DDN organisatie, kunnen de uitdrukkingen Internet en DDN soms identiek zijn). Al deze netwerken zijn met elkaar verbonden. Gebruikers kunnen berichten sturen van iedereen naar iedereen, uitgezonderd wanneer er beperkingen betreffende veiligheid of politieke beperkingen op toegang aanwezig zijn. Officieel gesproken, zijn de Internet protocol documenten eenvoudig stan- daarden, die door de Internet gemeenschap voor eigen gebruik zijn overge- nomen. Meer recent heeft het departement van defensie een MILSPEC defini- tie van TCP/IP uitgegeven. Dit was bedoeld om een meer formele definitie te zijn, geschikt voor gebruik bij aankoop specificaties. De meesten van de TCP/IP gemeenschap blijven de Internet standaarden gebruiken. De MILSPEC versie is bedoeld hiermee overeenkomstig te zijn. Hoe het ook wordt genoemd, TCP/IP is een familie protocollen. Enkele zor- gen voor "low level" functies die nodig zijn voor veel toepassingen. Deze houden in IP, TCP en UDP. (Deze zullen later wat meer uitgebreid worden beschreven). Anderen zijn protocollen voor speciale taken, zoals het uit- wisselen van bestanden tussen computers, zenden van post of uitvinden wie is ingelogd op een andere computer. TCP/IP werd aanvankelijk het meest gebruikt tussen minicomputers en mainframes. Die machines hadden hun ei- gen schijven en stonden opzichzelf. De meest "traditionele" TCP/IP dien- sten zijn: - Bestanden overdracht. Met het bestanden overdracht protocol (FTP) kan de gebruiker van iedere computer bestanden halen van een andere compu- ter, of bestanden naar een andere computer zenden. Veiligheid wordt verzorgd door van de gebruiker een gebruikersnaam en een wachtwoord voor de andere computer te eisen. Voorzieningen zijn gemaakt voor de behandeling van bestanden overdracht tussen machines met een verschil- lende karakter set, eind van de regel afspraken, enz. Dit is niet hele- maal hetzelfde als meer recent "network file system" of "netbios" pro- tocollen, die hierna zullen worden beschreven. FTP is echter een sys- teem dat iedere keer wordt gebruikt als een bestand uit een ander sys- teem moet worden opgehaald. Het wordt gebruikt om het bestand naar het eigen systeem te kopieren. U werkt dan met de lokale kopie. (Zie RFC 959 voor specificaties voor FTP). - Inloggen op afstand. Met het netwerk terminal protocol (TELNET) kan een gebruiker op iedere computer op het netwerk inloggen. U start een sessie op afstand door de computer te specificeren, waarmee verbonden moet worden. Vanaf dat moment, totdat de sessie beeindigd wordt, zal alles wat U typt naar de andere computer gezonden worden. In feite praat U nog steeds tegen Uw eigen computer, maar het telnet programma maakt Uw computer effectief onzichtbaar zolang het loopt. Ieder karak- ter dat U typt wordt direct naar het andere systeem gezonden. In het algemeen gedraagt de verbinding naar de andere computer zich als een inbelverbinding. Het verre systeem zal U vragen om in te loggen en een wachtwoord te geven. Wanneer U van het andere systeem uitlogt, verlaat U het telnet programma en U zult nu tegen Uw eigen computer praten. Microcomputer toepassingen van telnet omvatten meestal een terminal emulator voor een algemeen type terminal. (Zie RFC's 854 en 855 voor specificaties van telnet. Tussen haakjes, het telnet programma moet niet worden verward met Telenet, een verkoper van commerciele netwer- ken.) - Computer post. Hiermee kunt U berichten zenden naar gebruikers op an- dere computers. Origineel had men de neiging slechts 1 of 2 specifieke computers te gebruiken. Zij hadden "post bestanden" op beide machines. Het computer post systeem is eenvoudig een manier om post aan een an- dere gebruiker's post bestand toe te voegen. Er zijn hiermee enige pro- blemen, in een omgeving waar microcomputers worden gebruikt. Het ergste probleem is dat een micro niet goed geschikt is om computer post te ontvangen. Wanneer U post zendt, verwacht de post software dat een open verbinding bestaat naar de geadresseerde computer, om de post te kunnen verzenden. Wanneer dit een microcomputer is, kan deze zijn uitgescha- keld, of er draait een ander programma dan het post systeem. Om deze reden, wordt post meestal behandeld door een groter systeem, waar het practisch is om de post server continu te laten lopen. Microcomputer post software wordt dan een gebruikers-interface die post ophaalt van de post server. (Zie RFC 821 en 822 voor specificaties van computer post. Zie RFC 937 voor een protocol ontworpen voor microcomputers, ge- bruikt voor het lezen van post van een post server.) Deze diensten moeten aanwezig zijn in iedere toepassing van TCP/IP, afge- zien dat micro-georienteerde toepassingen computer post niet zouden kun- nen ondersteunen. Deze traditionele toepassingen spelen nog steeds een belangrijke rol in netwerken gebaseerd op TCP/IP. De manier waarop net- werken worden gebruikt is aan het veranderen. Het oude model van een aan- tal grote, op zichzelf staande computers, begint te veranderen. Nu hebben verschillende installaties, verschillende soorten computers, inclusief microcomputers, werkstations, minicomputers en mainframes. Die computers zullen waarschijnlijk geconfigureerd zijn om bepaalde taken uit te voeren. Hoewel men meestal met een bepaalde computer werkt, zal die computer op het netwerk andere computers oproepen voor speciale diensten. Dit heeft geleid tot het server/client model van netwerken diensten. Een server is een systeem dat een speciale dienst voor de rest van het netwerk uitvoert. Een client is een ander systeem dat die dienst gebruikt. (De server en client hoeven niet op verschillende computers te zijn. Het kunnen ver- schillende programmas zijn die op dezelfde computer lopen). Hier volgen de soorten servers die typisch in een moderne computer opstelling aan- wezig zijn. Deze computer diensten kunnen allen verschaft worden binnen het raamwerk van TCP/IP. - Netwerk bestand systemen. Hiermee kan een systeem toegang hebben tot bestanden op een andere computer in een wat meer geintegreerde manier dan FTP. Een netwerk bestand systeem geeft de illusie dat schijven of andere apparaten van een systeem, direct verbonden zijn met andere systemen. Het is niet nodig om speciale netwerk software te gebruiken, om toegang te hebben tot een bestand op een ander systeem. Uw computer denkt eenvoudig dat hij wat extra schijven heeft. Die extra "schijn- bare" schijven hebben betrekking op de schijven van het andere systeem. Deze mogelijkheid is nuttig voor diverse doeleinden. U kunt hiermee grote schijven op een paar computers zetten, maar ook de anderen toe- gang geven tot die schijfruimte. Naast economische voordelen, kunnen hierdoor mensen op verschillende computers werken en gemeenschappelij- ke bestanden gebruiken. Het maakt onderhoud en backup van het systeem gemakkelijker, want U hoeft zich geen zorgen te maken over het updaten en backup van kopieen op veel verschillende machines. Een aantal ver- kopers bieden nu hoge prestatie computers aan zonder schijven. Zij zijn geheel afhankelijk van de schijven van gemeenschappelijke "be- standsservers". (zie RFC's 1001 en 1002 voor een beschrijving van PC- georienteerde NetBios over TCP. In het werkstation en het minicomputer gebied, is het Sun Netwerk File System veelal gebruikt. Protocol spe- cificaties zijn beschikbaar van Sun Microsystems). - Afdrukken op afstand. Hiermee hebt U toegang tot printers op andere computers, alsof zij direct aan Uw computer waren aangesloten. (Het meest gebruikte protocol is het lineprinter protocol van Berkeley Unix. Helaas is hiervoor geen protocol document beschikbaar. De C code kan echter eenvoudig van Berkeley verkregen worden en toepassingen zijn algemeen). - Uitvoeren op afstand. Hiermee kunt U een bepaald programma op een andere computer laten lopen. Dat is nuttig wanneer U het meeste werk op een kleine computer kunt doen, maar enkele taken vereisen de capa- citeiten van een groter systeem. Er zijn een aantal verschillende soor- ten van uitvoering op afstand. Sommige werken op een opdrachten basis. M.a.w. U vraagt dat een bepaalde opdracht of een groep opdrachten op een bepaalde computer moet lopen. (Meer ontwikkelde systemen zullen een systeem kiezen dat vrij is). Er zijn ook "remote procedure call" systemen waarmee een programma een subroutine oproept dat op een andere computer loopt. (Er zijn veel van dit soort protocollen. Berkeley Unix heeft twee servers om opdrachten op afstand uit te voeren: rsh en rexec. De handleiding beschrijft de protocollen die zij gebruiken. De gebrui- kers-bijdrage software, met Berkeley 4.3 bevat een "verspreide shell" die taken verdeelt over een groep systemen, afhankelijk van de belas- ting. Oproep mechanismen op afstand procedures zijn een onderwerp van onderzoek sinds een aantal jaren, dus veel organisaties hebben toepas- singen voor die mogelijkheden. De meest verspreide, commercieel onder- steunde oproep procedure op afstand protocollen schijnen te zijn Xerox's Courier en Sun's RPC. Protocol documenten zijn beschikbaar van Xerox en Sun. Er is een algemene toepassing van Courier via TCP als deel van de gebruikers-bijdrage software met Berkeley 4.3. Een toepas- sing van RPC werd op Usenet gezet door Sun en verschijnt ook als deel van de gebruikers-bijdrage software met Berkely 4.3). - Namen servers. In grote installaties zijn er een aantal verschillende verzamelingen van namen die moeten worden beheerd. Dit houdt in ge- bruikers en hun wachtwoorden, namen en netwerk adressen voor computers, enz. Het is zeer vervelend om al deze gegevens op alle computers, up to date te houden. Dus worden de databases op een klein aantal systemen gehouden. Andere systemen hebben toegang tot die gegevens via het net- werk. (RFC 822 en 823 beschrijven het namen server protocol, gebruikt om host namen en Internet adressen op het Internet bij te houden). Dit is nu een vereist onderdeel van iedere TCP/IP toepassing. IEN 116 be- schrijft een ouder namen server protocol, dat wordt gebruikt door en- kele terminal servers en andere producten, om hostnamen op te zoeken. Sun's Yellow Pages systeem is ontworpen als een algemeen systeem om ge- bruikersnamen te behandelen, groepen die bestanden delen en andere data- basis die door Unix systemen worden gebruikt. Het is commercieel wijd verspreid en beschikbaar. (De protocol definitie is beschikbaar van Sun). - Terminal servers. Veel installaties verbinden terminals niet meer di- rect naar computers. In plaats daarvan verbinden zij naar terminal servers. Een terminal server is eenvoudig een kleine computer die al- leen weet hoe telnet te laten lopen (of een ander protocol om login op afstand te doen). Wanneer Uw computer daarmee is verbonden, typt U een- voudig de naam van de computer en U bent ermee verbonden. In het algemeen is het mogelijk om actieve verbindingen op dezelfde tijd met meer computers te hebben. De terminal server heeft de moge- lijkheid om snel tussen de verbindingen te schakelen, en te informeren wanneer output van een andere verbinding te wachten staat. (Terminal servers gebruiken het telnet protocol, zoals reeds vermeld. Echter iedere echte terminal server zal ook namen service ondersteunen en een aantal andere protocollen). - netwerk georienteerde window systemen. Tot voor kort moesten hoge pres- tatie, grafische programmas uitgevoerd worden op een computer waaraan een bit-map grafisch scherm direct was aangesloten. Met netwerk window systemen kan een monitor op een andere computer worden gebruikt. Een compleet netwerk window systeem laat de werkzaamheden distribueren, naar systemen die daarvoor het beste geschikt zijn. (Het meest toege- paste window systeem is X. Een protocol beschrijving is beschikbaar van MIT's Project Athena. Een referentie toepassing is algemeen be- schikbaar van MIT. Een aantal firmas ondersteunen ook NeWS, een Window systeem gedefinieerd door Sun. Beide systemen zijn ontworpen om TCP/IP te gebruiken). Sommige van de hierboven beschreven protocollen zijn ontworpen door Sun, Berkeley of andere organisaties. Zij zijn dus officieel niet onderdeel van de Internet protocol familie. Zij gebruiken echter TCP/IP, zoals normale TCP/IP toepassing protocollen doen. Aangezien de protocol defini- ties niet als eigendom worden beschouwd en aangezien commercieel onder- steunde toepassingen wijd verkrijgbaar zijn, is het redelijk aan te nemen dat deze protocollen een effectief onderdeel van de Internet familie zijn. De lijst hierboven is slechts een keuze uit de soort diensten beschik- baar met TCP/IP. Het omvat echter de meesten van de "belangrijke" toepas- singen. De andere, algemeen gebruikte, protocollen zijn meer gespeciali- seerde toepassingen, gericht op het verkrijgen van diverse soorten infor- matie, zoals wie is ingelogd, de tijd van de dag, enz. Wanneer U een toe- passing nodig hebt die hier niet is genoemd, adviseren wij U eens door de huidige editie van Internet Protocollen te gaan (momenteel RFC 1011, Juli 1987! PE1ECN), die een lijst geeft van alle protocollen en ook eens te kijken naar enige van de belangrijke TCP/IP toepassingen, om te zien wat de diverse commerciele firmas hebben toegevoegd. 2. Algemene beschrijving van de TCP/IP protocollen TCP/IP is een gelaagde groep protocollen. Om te begrijpen wat dit bete- kent, is het nuttig om een voorbeeld te bekijken. Een typische situatie is het verzenden van post. Ten eerste, er is een protocol voor post. Dit definieert een groep opdrachten die de ene machine naar de andere zendt, zoals opdrachten die aangeven wie de afzender van het bericht was, aan wie het is gezonden en dan de tekst van het bericht. Dit protocol neemt echter aan dat er een manier is om betrouwbaar tussen de twee com- puters te communiceren. Post (Mail), zoals andere toepassingsprotocollen, defineert eenvoudig een groep opdrachten en berichten die moeten worden verzonden. Het is ontworpen om te gebruiken met TCP en IP. TCP is verant- woordelijk dat de berichten aan het andere einde worden ontvangen. Het houdt bij wat is verzonden en zendt weer opnieuw alles dat niet doorge- komen is. Wanneer een bericht te lang is voor e e n datagram, zoals de tekst van de post, zal TCP het splitsen in verschillende datagrammen en ervoor zorgen dat ze allen in orde worden ontvangen. Aangezien die func- ties nodig zijn voor veel toepassingen, zijn zij samen in een apart pro- tocol gezet, in plaats van een onderdeel te zijn van de specificaties voor het verzenden van post. U moet bij TCP denken als een soort biblio- theek van routines die toepassingen kunnen gebruiken wanneer zij betrouw- bare netwerk communicatie nodig hebben met een andere computer. Op de- zelfde wijze roept TCP de diensten van IP op. Hoewel de diensten die TCP verstrekt, nodig zijn voor veel toepassingen, zijn er nog sommige toepas- singen die ze niet nodig hebben. Er zijn echter enige diensten die iedere toepassing nodig heeft. Dus zijn die diensten samen in IP ondergebracht. Evenals TCP kan IP gezien worden als een bibliotheek van routines waarvan TCP gebruik maakt, maar die ook beschikbaar zijn voor toepassingen die TCP niet gebruiken. Deze strategie van een opbouw in verschillende protocol-lagen wordt "layering" genoemd. We beschouwen de toepassingsprogrammas, zoals post, TCP, IP, als aparte "lagen", die gebruik maken van de diensten van de laag eronder. In het algemeen gebruiken TCP/IP toepassingen 4 lagen: - een toepassing protocol, zoals post - een protocol zoals TCP die diensten geeft die nodig zijn voor veel toepassingen. - IP, dat de basis dienst verzorgd om datagrammen op hun bestemming te krijgen. - De protocollen die nodig zijn om een speciaal fysiek medium te besturen, zoals Ethernet of een point to point lijn. TCP/IP is gebaseerd op het "catenet model". (Dit wordt meer gedetailleerd beschreven in IEN 48). Dit model neemt aan dat er een groot aantal onaf- hankelijke netwerken zijn, die met elkaar verbonden zijn door "gateways" (toegangspoorten). De gebruiker moet in staat zijn om toegang te hebben op computers op ieder van die netwerken. Datagrammen zullen dikwijls een dozijn verschillende netwerken passeren, voordat zij hun eindbestemming bereiken. De routing die nodig is om dit te bereiken, moet geheel on- zichtbaar zijn voor de gebruiker. Wat de gebruiker betreft, is een "Internet adres" alles wat hij moet weten, om toegang tot een ander sys- teem te krijgen. Dit is een adres dat eruit ziet als 128.6.4.194. Het is in feite een 32-bit getal. Het wordt echter normaal geschreven als 4 de- cimale getallen, die ieder 8-bits van het adres vertegenwoordigen. (De term "octet" wordt door Internet documentatie gebruikt voor zulke 8-bit brokken. De term "byte" wordt niet gebruikt, want TCP/IP wordt onder- steund door sommige computers die een ander byte grootte hebben dat 8 bits.) In het algemeen geeft de structuur van het adres enige informatie hoe naar het systeem te komen. Bijvoorbeeld, 128.6 is een netwerk getal toegewezen door een centrale autoriteit aan de Rutgers Universiteit. Rutgers gebruikt het volgende octet om aan te geven op welke van de cam- pus Ethernets het betrekking heeft. 128.6.4 is een Ethernet gebruikt door de Computer Science Department. Het laatste octet geeft de mogelijkheid van 254 systemen op ieder Ethernet. (Het is 254, want 0 en 255 zijn niet toegestaan, om redenen die later zullen worden besproken). Merk op dat 128.6.4.194 en 128.6.5.194 verschillende systemen zijn. De structuur van een Internet adres wordt later meer gedetailleerd beschreven. Natuurlijk verwijzen wij normaal met een naam naar systemen, in plaats van een Internet adres. Wanneer wij een naam specificeren, zoekt de net- werk software dit op in zijn database en komt met het bijbehorende Inter- net adres. De meeste van de netwerk software werkt uitsluitend alleen met het adres. (RFC 882 beschrijft de namen server technologie, die gebruikt wordt voor het opzoeken). TCP/IP is gebouwd op "verbindingsloze" technologie. Informatie wordt uit- gewisseld als een reeks van "datagrammen". Een datagram is een verzame- ling gegevens dat wordt verstuurd als een enkel bericht. Ieder van die datagrammen wordt individueel via het netwerk verzonden. Er zijn voor- zieningen om verbindingen te openen (zoals een conversatie die enige tijd zal duren). Op een bepaald niveau wordt echter informatie van die verbin- dingen opgebroken in datagrammen, die door het netwerk geheel separaat worden behandeld. Bijvoorbeeld, U wilt een 15000-octet groot bestand uit- wisselen. De meeste netwerken kunnen een 15000-octet niet verwerken. Dus de protocollen zullen dit verdelen in zoiets als 30 500-octets datagram- men. Ieder van die datagrammen zal naar het andere eind worden gezonden. Daar zullen zij weer worden samengesteld in een 15000-octet bestand. Ter- wijl echter de datagrammen onderweg zijn, weet het netwerk niet dat er een verbinding tussen ze is. Het is heel goed mogelijk dat datagram 14 aankomt v o o r datagram 13. Het is ook mogelijk dat ergens in het net- werk een fout optreedt en sommige datagrammen komen helemaal niet aan. In dat geval moet het datagram weer opnieuw gezonden worden. De term "datagram" en "packet" schijnt overigens bijna uitwisselbaar. Technisch gezien is datagram het juiste woord bij het beschrijven van TCP/IP. Een datagram is een eenheid van gegevens, wat precies is waarmee protocollen omgaan. Een packet is een fysiek ding dat op een Ethernet verschijnt of een kabel. In de meeste gevallen bevat een packet eenvoudig een datagram, dus er niet veel verschil. Zij kunnen echter verschillen. Wanneer TCP/IP wordt gebruikt, bovenop X.25, breekt de X.25 interface de datagrammen op in 128-byte packets. Dat is onzichtbaar voor IP, want de packets worden weer samengevoegd tot een enkel datagram aan de andere eind voor te worden behandeld door TCP/IP. Dus in dit geval zou een IP datagram door verschillende packets worden vervoerd. Zoals bij de meeste media, zijn er efficientie voordelen om e e n datagram per packet te zen- den, en het onderscheid is dus aan het verdwijnen. 2.1 Het TCP niveau Twee aparte protocollen zijn betrokken in het behandelen van TCP/IP data- grammen. TCP (het "Transmission Control Protocol") is verantwoordelijk voor het verdelen van het bericht in datagrammen, weer samenstellen aan het andere eind, opnieuw verzenden als iets verloren is gegaan en de din- gen weer in de juiste volgorde zetten. IP (het "internet protocol"), is verantwoordelijk voor de routing van de afzonderlijke datagrammen. Het lijkt alsof TCP al het werk doet en in kleine netwerken is dat ook zo. In het Internet echter, een datagram naar zijn bestemming te krijgen kan een ingewikkeld karwei zijn. Een verbinding kan ertoe leiden dat een datagram door verschillende netwerken bij Rutgers gaat, een seriele lijn naar het John von Neuman Supercomputer Center, enkele Ethernets daar, een aantal 56kbaud telefoon lijnen naar een ander NSFnet en meer Ethernets op een andere campus. Het bijhouden van de routes naar alle bestemmingen en ver- werken van incompatibiliteiten tussen verschillende transport media, blijkt een ingewikkeld werk te zijn. De interface tussen TCP en IP is be- trekkelijk eenvoudig. TCP geeft IP eenvoudig een datagram met een bestem- ming. IP weet niet welke verbinding er is tot ieder datagram ervoor of erna. Het zal U opgevallen zijn dat er hier iets ontbreekt. We hebben gesproken over Internet adressen, maar niet over het bijhouden van meerdere verbin- dingen op een bepaald systeem. Het is duidelijk niet genoeg om een data- gram naar de juiste bestemming te krijgen. TCP moet weten van welke ver- binding dit datagram een onderdeel is. Deze taak wordt genoemd als "de- multiplexing". Er zijn in feite verschillende niveaux van multiplexing gaande in TCP/IP. De informatie nodig om deze demultiplexing te doen, wordt ondergebracht in een serie "hoofden". Een hoofd is eenvoudig een paar extra octets, die door het protocol aan het begin van een datagram, worden bevestigd, om het in 't oog te houden. Het lijkt erg op het stoppen van een brief in een envelop en het adres op de envelop zetten. Op moder- ne netwerken gebeurt dit regelmatig. Het is alsof U de brief in een klei- ne envelop stop, Uw secretaresse stopt die in een grotere envelop, de campus post afdeling stopt het in een nog grotere, enz. Hier is een over- zicht van hoofden die aan een bericht worden bevestigd, dat door een typisch TCP/IP netwerk gaat: We beginnen met een enkele gegevens stroom, zeg een bestand dat U naar een andere computer probeert te zenden: .............................................. TCP breekt dit op in hanteerbare brokken. (Om dit te doen, moet TCP de grootte weten van een datagram dat Uw netwerk kan verwerken. In werke- lijkheid geven de TCP's aan ieder eind de grootte van een datagram dat zij kunnen verwerken en nemen dan de kleinste). .... .... .... .... .... .... .... .... TCP zet een hoofd aan het begin van ieder datagram. Dat hoofd bevat ten- minste 20 octets, maar de meest belangrijke zijn de bron en bestemming "poort nummer" en "volgorde nummer". De poort nummers worden gebruikt om de verschillende conversaties bij te houden. Neem aan dat 3 verschil- lende mensen bestanden uitwisselen. Uw TCP kan poort nummers 1000, 1001, en 1002 aan deze uitwisseling toewijzen. Wanneer U een datagram verzendt, wordt dit het "bron" poort nummer, aangezien U de bron van het datagram bent. Natuurlijk heeft de TCP aan het andere eind een eigen poort nummer toegewezen voor de conversatie. Uw TCP moet bovendien het poort nummer weten dat door het andere eind gebruikt wordt. (Het vindt dit uit, wan- neer de conversatie begint, zoals wij later zullen uitleggen). Het zet dit nummer in het "bestemming" poort veld. Wanneer de andere kant een datagram aan U terugstuurt, worden natuurlijk de bron en bestemming poort nummers omgekeerd, aangezien het dan de bron is en U de bestemming. Ieder datagram heeft een volgorde nummer. Dit wordt gebruikt door de an- dere kant om zeker te zijn dat de datagrammen in orde zijn ontvangen en dat er geen vermist zijn. (Zie de TCP specificatie voor details). TCP nummert niet de datagrammen maar de octets. Dus als er 500 octets gege- vens zijn in ieder datagram, kan het eerste datagram genummerd 0 zijn, de tweede 500, de volgende 1000, de volgende 1500, enz. Tenslotte wil ik het Controlegetal noemen. Dit is een getal dat is berekend door alle oc- tets in het datagram op te tellen. (meer of minder, zie de TCP specifica- tie). Het resultaat wordt in het hoofd gezet. TCP aan het andere eind berekent het controle getal opnieuw. Wanneer zij niet overeenkomen, dan is er iets met het datagram gebeurt tijdens het verzenden en het wordt weggegooid. Dus hier is hoe het datagram er nu uitziet: +------------------------+--------------------------+ | Bron Poort Nummer | Bestemming Poort Nummer | | +------------------------+--------------------------+ | Volgorde Nummer | +---------------------------------------------------+ | Bevestigings Getal | +---------------------------------------------------+ | Gegevens| Gereser-|U|A|P|R|S| Venster | | Offset | veerd |R|C|S|S|Y| | | | |G|K|H|T|N| | +------------------------+--------------------------+ | Controle Getal | Urgentie pointer | +------------------------+--------------------------+ | Uw gegevens .... volgende 500 octets | | .......... | Wanneer we het TCP hoofd afkorten als "T", zie het hele bestand er nu als volgt uit: T.... T.... T.... T.... T.... T.... T.... T.... U zult opmerken dat er items in het hoofd staan die ik hiervoor niet heb beschreven. Zij zijn hoofdzakelijk nodig voor het besturen van de verbin- ding. Om er zeker van te zijn dat het datagram op zijn bestemming is aan- gekomen, moet de ontvanger een bevestiging terugzenden. Dit is een data- gram waarvan het "Bevestigings getal" veld is ingevuld. Bijvoorbeeld, verzenden van een packet met een bevestiging van 1500, geeft aan dat U alle gegevens hebt ontvangen tot octet nummer 1500. Wanneer de afzender geen bevestiging krijgt binnen een redelijke tijd, zendt het de gegevens opnieuw. Het venster wordt gebruikt om te controleren hoeveel gegevens onderweg zijn op een gegeven moment. Het is niet practisch om voor ieder datagram op bevestiging te wachten, voor de volgende te zenden. Dat zou alles teveel vertragen. Aan de andere kant kunt U niet aan het zenden blijven, of een snelle computer zou de capaciteit van een langzame doen overlopen, om gegevens op te nemen. Dus ieder eind geeft aan hoeveel nieuwe gegevens het op het moment kan opnemen, door het aantal octets in het "Venster" veld te zetten. Als de computer gegevens ontvangt, neemt de hoeveelheid overgebleven ruimte in het venster veld af. Wanneer het nul is geworden, moet de zender stoppen. Wanneer de ontvanger de gegevens verwerkt, verhoogt het zijn venster, ten teken dat het gereed is meer ge- gevens te ontvangen. Dikwijls kan hetzelfde datagram gebruikt worden om ontvangst van een groep gegevens te bevestigen en toestemming te geven voor extra nieuwe gegevens (door een bijgewerkt venster). Het "Urgentie" veld laat het ene eind aan het andere vertellen de verwerking van een bepaald octet vooruit te zetten. Dat is dikwijls nuttig voor verwerken van asynchrone gebeurtenissen, bijvoorbeeld wanneer U een controle karak- ter typt of een andere opdracht die de output onderbreekt. De andere vel- den vallen buiten bestek van dit document. 2.2 Het IP niveau TCP zendt ieder van deze datagrammen naar IP. Natuurlijk moet het IP het Internet adres opgeven van de computer aan het andere eind. Dit is alles waarmee IP zich bezig houdt. Het is niet interessant wat in het datagram staat, of zelfs in het TCP hoofd. De job van IP is om eenvoudig een route te vinden voor het datagram en het naar het andere eind te krijgen. Om gateways of andere tussenliggende systemen het datagram te laten doorzen- den, voegt het zijn eigen hoofd toe. De hoofdzaken in dit hoofd zijn de bron en bestemming Internet adressen (32-bit adressen, zoals 128.6.4.194) het protocol nummer en een ander controle getal. Het bron Internet adres is eenvoudig het adres van Uw machine. (Dit is nodig zodat de andere kant weet waar het datagram vandaan kwam). Het doel adres is het adres van de andere machine. (Dit is nodig zodat gateways onderweg weten waarnaar het datagram naartoe moet). Het protocol nummer vertelt IP aan de andere kant om het datagram naar TCP te zenden. Hoewel het meeste IP verkeer TCP ge- bruikt, zijn er andere protocollen die IP gebruiken, dus U moet IP ver- tellen aan welk protocol het datagram moet worden gezonden. Tenslotte, het controlegetal laat IP aan de andere kant nagaan dat het hoofd niet beschadigd is onderweg. TCP en IP hebben aparte controlegetallen. IP moet in staat zijn te controleren dat het hoofd onderweg niet beschadigd is, of het kan het bericht naar de verkeerde plaats zenden. Om redenen die hier niet belangrijk zijn, is het efficienter en veiliger om TCP een apart controlegetal te laten berekenen voor het TCP hoofd en gegevens. Wanneer IP zijn hoofd heeft bevestigd, ziet het bericht er als volgt uit: +---------------------------------------------------+ | Versie| IHL |Soort Service| Totale Lengte | +-----------------------+---------------------------+ | Indentificatie |Flags | Fragment Offset | +-----------------------+---------------------------+ | Levensduur | Protocol | Hoofd controle getal | +-----------------------+---------------------------+ | Bron Adres | +---------------------------------------------------+ | Bestemmings- Adres | +---------------------------------------------------+ | TCP hoofd, dan Uw gegevens ........ | | | Wanneer we het IP hoofd weergeven door een "I", ziet Uw bestand er nu als volgt uit: IT.... IT.... IT.... IT.... IT.... IT.... IT.... IT.... Het hoofd bevat weer enige extra velden die niet besproken zijn. De meesten vallen buiten bestek van dit document. De flags en fragment off- set worden gebruikt om de onderdelen van een datagram bij te houden, als het is opgebroken. Dat kan gebeuren wanneer datagrammen worden verzonden via een netwerk waarvoor zij te groot zijn. (Dit zal hierna wat meer be- sproken worden) De levensduur is een getal dat wordt verlaagd wanneer een datagram door een systeem gaat. Wanneer het nul is, wordt het datagram ter zijde gelegd. Dit wordt gedaan in het geval een gesloten kring zich ergens in een systeem ontwikkeld. Natuurlijk moet dit onmogelijk zijn, maar goed ontworpen netwerken zijn gebouwd om "onmogelijke" situaties het hoofd te kunnen bieden. Het is mogelijk dat niet meer hoofden nodig zijn. Als Uw computer een directe telefoonlijn heeft die het met de bestemmings-computer verbindt, of naar een gateway, kan het eenvoudig de datagrammen op de lijn verzen- den (hoewel waarschijnlijk een synchroon protocol, zoals HDLC zal worden gebruikt en het zal tenminste enkele octets aan het begin en eind toevoe- gen). 2.3 Het Ethernet niveau De meeste van onze netwerken gebruiken nu echter Ethernet. Dus moeten we de Ethernet hoofden beschrijven. Helaas heeft Ethernet zijn eigen adressen. De mensen die Ethernet ontwierpen, wilden er zeker van zijn geen twee machines dezelfde Ethernet adressen zouden hebben. Verder wil- den zij niet dat de gebruiker zich zorgen hoefde te maken over het toe- wijzen van adressen. Dus komt iedere Ethernet controller met een door de fabriek ingebouwd adres. Om er zeker van te zijn dat zij nooit adressen opnieuw zouden moeten gebruiken, hebben de Ethernet ontwerpers 48 bits voor het Ethernet adres toegewezen. Mensen die Ethernet apparatuur maken, moeten bij een centrale autoriteit registreren, om er zeker van te zijn dat de nummers niet die van een andere fabrikant overlappen. Ethernet is een "uitzend medium". Dat is in feite zoals een oude gemeenschappelijke groeps telefoonlijn. Wanneer U een packet op het Ethernet zendt, ziet iedere machine op het netwerk het packet. Dus er is iets nodig om ervoor te zorgen dat de juiste machine het krijgt. Zoals U al dacht, dit betreft het Ethernet hoofd. Ieder Ethernet packet heeft een 14-octet hoofd, dat bevat de bron en het bestemming Ethernet adres, en een type code. Iedere machine wordt verondersteld alleen te letten op packets met zijn eigen Ethernet adres in het bestemmingsveld. (Het zeer goed mogeljk om te be- driegen, wat een van de redenen is waarom Ethernet communicatie niet erg veilig is). NB. er is geen relatie tussen het Ethernet adres en het In- ternet adres. Iedere machine moet een lijst hebben welk Ethernet adres overeenkomt met welk Internet adres. (Wij zullen later uitleggen hoe die lijst is samengesteld). Naast de adressen bevat het hoofd een type code. De type code is om verschillende protocol families op hetzelfde netwerk te kunnen gebruiken. Dus U kunt TCP/IP, DECnet, Xerox, NS, enz. op het- zelfde moment gebruiken. Ieder van deze protocollen zal een andere waar- de in het type veld zetten. Tenslotte is er een controlegetal. De Ether- net controller berekent een controlegetal van het gehele packet. Wanneer de andere kant het packet ontvangt, berekent het opnieuw het controlege- tal, en gooit het packet weg als het niet overeenkomt met het origineel. Het controlegetal wordt aan het eind van het packet geplaatst, niet in het hoofd. Het uiteindelijke resultaat is dat het bericht er als volgt uitziet: +--------------------------------------------------+ | Ethernet bestemmings-adres (eerste 32 bits) | +------------------------+-------------------------+ | Ethernet bestemming | Ethernet bron | | (Laatste 16 bits) | (Eerste 16 bits) | +------------------------+-------------------------+ | Ethernet bron adres (laatste 32 bits) | +------------------------+-------------------------+ | Type code | | +------------------------+-------------------------+ | IP hoofd, dan TCP hoofd, dan Uw gegevens | | | | ........ | | eind van Uw gegevens | +--------------------------------------------------+ | Ethernet controlegetal | +--------------------------------------------------+ Wanneer we het Ethernet hoofd weergeven door een "E", en het Ethernet controlegetal door een "C", ziet Uw bestand er als volgt uit": EIT....C EIT....C EIT....C EIT....C EIT....C Wanneer deze packets door het andere eind worden ontvangen, worden na- tuurlijk alle hoofden verwijderd. De Ethernet interface verwijdert het Ethernet hoofd en het controlegetal. Het kijkt naar de type code. Aan- gezien de code is toegewezen aan IP, zal de Ethernet driver het datagram naar IP doorgeven. IP verwijdert het IP hoofd. Het kijkt naar het IP pro- tocol veld. Aangezien het protocol type TCP is, geeft IP het datagram door naar TCP. TCP kijkt nu naar het volgorde nummer. Het gebruikt de volgorde nummers en andere informatie om alle datagrammen in het origi- nele bestand te combineren. Dit beeindigt onze eerste samenvatting van TCP/IP. Er zijn nog enkele belangrijke concepten, waar we niet aan toe gekomen zijn, dus gaan we nu terug en voegen details toe aan bepaalde gebieden. (Voor gedetailleer- de beschrijvingen van de hier besproken onderwerpen, zie RFC 793 voor TCP, RFC 791 voor IP en RFC's 894 en 826 voor zenden van IP over Ether- net). 3. Bekende vaste ingangen en de toepassingslaag Tot zover hebben wij besproken hoe een gegevens stroom wordt opgebroken in datagrammen, naar een andere computer worden gezonden, en weer worden samengesteld. Er is echter meer nodig om iets nuttigs te bereiken. Er moet voor U een weg zijn om een verbinding naar een gespecificeerde com- puter te openen, in te loggen, het te vertellen welk bestand U wilt heb- ben en het verzenden van het bestand te besturen. (Wanneer U een andere toepassing in gedachten hebt, bijv. computer post, is een analoog proto- col nodig). Dit wordt gedaan door "toepassing protocollen". Het toepas- sing protocol loopt "bovenop" TCP/IP. Dat betekent, wanneer zij een be- richt willen verzenden, geven zij het bericht aan TCP. TCP zorgt ervoor dat het aan de andere kant wordt afgeleverd. Omdat TCP en IP voor alle netwerk details zorgen, kunnen de toepassing protocollen een netwerk ver- binding zien alsof het een eenvoudige byte stroom is, zoals een terminal of telefoon lijn. Alvorens meer in detail te gaan omtrent toepassing protocollen, moeten we beschrijven hoe U een toepassing vindt. Veronderstel U wilt een bestand zenden naar een computer met Internet adres 128.6.4.7. Om het proces te starten, moet U meer hebben dan alleen het Internet adres. U moet met de FTP server aan het andere eind verbinden. In het algemeen zijn netwerk programmas gespecialiseerd voor een speciale groep taken. De meeste sys- temen hebben aparte programmas om bestanden uitwisseling te verwerken, terminal op afstand inloggen, post, enz. Wanneer U verbindt met 128.6.4.7 moet U opgeven dat U met de FTP server wilt praten. Dat wordt gedaan door het hebben van "vastgelegde ingangen" voor iedere server. U herinnert zich dat TCP poort nummers gebruikt om individuele conversaties bij te houden. Gebruikers programmas gebruiken meestal min of meer willekeurige poort nummers. Specifieke poort nummers zijn echter toegewezen aan pro- grammas die op verzoeken zitten te wachten. Bijvoorbeeld, wanneer U een bestand wilt verzenden, start U een programma, genoemd "ftp". Het zal een verbinding openen, gebruik makende van een willekeurig nummer, zeg 1234. voor het poort nummer aan zijn eigen kant. Het zal echter poortnummer 21 specificeren voor het andere eind. Dit is het officiele poort nummer voor de ftp server. NB. Er zijn hier twee verschillende programmas aan het werk. U hebt ftp aan Uw kant lopen. Dat is het programma dat is ont- worpen om opdrachten van Uw terminal te accepteren en ze aan de andere kant door te geven. Het programma waar U tegen praat op de andere machine, is de FTP server. Het is ontworpen om opdrachten te accepteren van de netwerk verbinding, in plaats van een interactieve terminal. Het is niet nodig voor Uw programma om een vast ingangs-nummer voor zichzelf te ge- bruiken. Niemand zal proberen het te vinden. Servers moeten echter vaste ingangsnummers hebben, zodat mensen verbindingen kunnen openen en op- drachten zenden. De officiele poort nummers voor ieder programma staan in "Assigned Numbers". Een verbinding wordt in feite omschreven door een groep van 4 getallen. Het Internet adres aan iedere kant en de TCP poort nummers aan iedere kant. In ieder datagram staan alle 4 nummers. (De Internet adressen staan in het IP hoofd en de TCP poort nummers staan in het TCP hoofd). Om verwarringen te voorkomen, hebben geen twee verbindingen dezelfde groep nummers. Het is echter voldoende dat e e n nummer anders is. Bijvoorbeeld, het is zeer goed mogelijk voor twee gebruikers op een ma- chine om bestanden naar dezelfde andere machine te zenden. Dit kan re- sulteren in verbindingen met de volgende parameters: Internet adressen TCP poorten Verbinding 1 128.6.4.194, 128.6.4.7 1234, 21 Verbinding 2 128.6.4.194, 128.6.4.7 1235, 21 Aangezien het dezelfde machines betreft, zijn de Internet adressen het- zelfde. Aangezien zij beiden aan bestands-uitwisseling doen, is een kant van de verbinding het vaste poortnummer voor FTP. Het enige dat verschil- lend is, is het poortnummer voor het programma dat de gebruikers hebben lopen. Dat is voldoende verschil. In het algemeen vraagt tenminste een kant van de verbinding aan de netwerk software om een poort nummer toe te wijzen dat gegarandeerd enig is. Normaal is dit de gebruikers kant, want de server moet het vaste poortnummer gebruiken. Nu we weten hoe we verbindingen moeten openen, laten we teruggaan naar de toepassing programmas. Zoals eerder vermeld, wanneer TCP een verbin- ding geopend heeft, hebben we iets dat ook een eenvoudige draad kan zijn. Alle het moeilijke werk wordt door TCP en IP gedaan. We moeten echter nog wel afspreken wat we via die verbinding gaan verzenden. In feite is dit eenvoudig een afspraak over welke groep opdrachten de toepassing kan begrijpen, en het formaat waarin het wordt gezonden. In het algemeen is het een combinatie van opdrachten en gegevens. Zij gebruiken samenhang om onderscheid te maken. Bijvoorbeeld, het post protocol werkt als volgt: Uw post programma opent een verbinding naar de post server aan de andere kant. Uw programma geeft het de naam van Uw machine, de afzender van het bericht, en degenen aan wie U het wilt zenden. Het zendt dan een opdracht zeggende dat het bericht gestart wordt. Op dat moment, stopt de andere kant met het behandelen van, wat het ziet als opdrachten, en begint het bericht te accepteren. Uw kant begint met het verzenden van de tekst van het bericht. Aan het eind van het bericht, wordt een speciaal merkteken gezonden (een punt in de eerste kolom). Daarna begrijpen beide programmas dat U weer opdrachten gaat zenden. Dit is de eenvoudigste manier om din- gen te doen, en de meeste toepassingen gebruiken het. Bestanden uitwisseling is wat meer ingewikkeld. Het bestandsuitwisseling protocol betreft twee verschillende verbindingen. Het begint precies zo- als post. Het gebruikers' programma zendt opdrachten zoals "log me in als deze gebruiker", "hier is mijn wachtwoord", "zend mij het bestand met deze naam". Wanneer eenmaal de opdracht om gegevens te zenden is gegeven, wordt een tweede verbinding geopend voor de gegevens zelf. Het zou in principe zeer goed mogelijk zijn om de gegevens over dezelfde verbinding te zenden, zoals post doet. Bestanden uitwisseling neemt echter vaak veel tijd in beslag. De ontwerpers van ftp wilden de gebruikers in staat stel- len om opdrachten te geven tijdens het uitwisselen van gegevens. Bijvoor- beeld, de gebruiker wil een inlichting hebben, of hij wil de uitwisseling afbreken. De ontwerpers vonden dat het beste was om een aparte verbind- ding te gebruiken voor de gegevens en de originele opdracht verbinding voor opdrachten te gebruiken. (Het is ook mogelijk om opdracht verbindin- gen op verschillende computers te openen en ze te vertellen een bestand te zenden van de ene naar de andere. In dat geval, zouden de gegevens niet over de opdracht verbinding kunnen gaan). Terminal verbindingen op afstand gebruiken weer een ander mechanisme. Voor inloggen op afstand is er maar e e n verbinding. Het zendt normaal gegevens. Wanneer het nodig is om een opdracht te zenden (bijv. om het terminal type in te stellen of om een mode te veranderen), wordt een spe- ciaal karakter gebruikt om aan te geven dat het volgende karakter een op- dracht is. Wanneer de gebruiker dat speciale karakter typt als een gege- ven, worden er twee gezonden. Wij gaan de toepassing protocollen niet in detail beschrijven in dit do- cument. Het is beter om de RFC's zelf te lezen. Er zijn echter enkele algemene afspraken gebruikt door toepassingen, die hier zullen worden be- sproken. Ten eerste, de algemene netwerk weergave: TCP/IP is bedoeld om op iedere computer te gebruiken. Helaas zijn niet alle computers het er- over eens hoe gegevens moeten worden weergegeven. Er zijn verschillen in karakters codes (ASCII versus EBCDIC), in eind van regel afspraken (carriage return, line feed), en hoe terminals verwachten dat karakters worden gezonden, individueel, of iedere keer een hele regel. Om het mo- gelijk te maken dat verschillende soorten computers kunnen communiceren, definieert ieder protocol een standaard weergave. NB. TCP en IP zijn niet geinteresseerd in de weergave. TCP zendt eenvoudig octets. De programmas aan beide einden moeten echter wel overeenkomen hoe de octets moeten wor- den geinterpreteerd. De RFC voor iedere toepassing specificeert de stan- daard weergave voor die toepassing. Normaal is het "net ASCII". Dit gebruikt ASCII karakters, met het eind van een regel aangeduid door een carriage return gevolgd door een line feed. Voor inloggen op afstand, is er ook een definitie voor een "standaard terminal", die blijkt te zijn een half duplex terminal met echoing op de lokale machine. De meeste toe- passingen hebben ook voorzieningen voor de twee computers om het eens te worden over andere weergaven die zij geschikter vinden. Bijvoorbeeld, PDP-10's hebben 36 bit woorden. Er is een manier dat twee PDP-10's over- een kunnen komen om een 36-bit binair bestand te zenden. Ook kunnen twee systemen die vol-duplex terminal conversaties verkiezen, het hierover eens worden. Iedere toepassing heeft echter een standaard weergave, die iedere machine moet ondersteunen. 3.1 Een toepassing voorbeeld: SMTP Om een beter idee te hebben wat toepassing protocollen betekenen, ga ik een voorbeeld van SMTP geven, dat is het post protocol. (SMTP is "simple mail transfer protocol"). Wij nemen aan dat een computer genoemd TOPAZ. RUTGERS.EDU het volgende bericht wil verzenden. Datum: Zat, 27 Jun 87 13:26:31 CET Van : hedrick@topaz.rutgers.edu To : levy@red.rutgers.edu Onderwerp: vergadering Laten we Maandag samenkomen om 13:00. Ten eerste, merk op dat het formaat van het bericht zelf wordt beschreven door een Internet standaard (RFC 822). De standaard geeft aan dat het bericht moet worden verzonden als net ASCII (het moet ASCII zijn met car- riage return en linefeed om de regels af te bakenen). Het beschrijft ook de algemene structuur, als een groep van hoofdregels, dan een lege regel en dan de inhoud van het bericht. Tenslotte beschrijft het de syntaxis van de hoofdregels in detail. In het algemeen bestaan ze uit een sleutel- woord en dan een waarde. Merk op dat de geadresseerde is opgegeven als LEVY@RED.RUTGERS.EDU. Aan- vankelijk waren adressen eenvoudig "persoon op machine". Recente stan- daarden hebben dingen meer flexibel gemaakt. Er zijn nu voorzieningen voor systemen om post van andere systemen te verwerken. Hiermee kan auto- matische verzending gedaan worden door computers die niet met het Inter- net zijn verbonden. Het kan worden gebruikt worden om post te zenden voor een aantal systemen, naar een centrale post server. Het is inderdaad niet vereist dat ook werkelijk een computer met de naam RED.RUTGERS.EDU be- staat. De namen server kan zodanig worden ingericht dat U post zendt naar afdelingsnamen en de post voor iedere afdeling wordt automatisch afgele- verd aan de bestemde computer. Het is ook mogelijk dat het deel voor '@', iets anders is dan de gebruikersnaam. Het is mogelijk voor programmas om ingesteld te worden voor het verwerken van post. Er zijn ook voorzie- ningen voor het behandelen van mailing lijsten en namen zoals "post- master" of "operator". De manier hoe een bericht naar een ander systeem wordt gezonden is be- schreven in RFC's 821 en 974. Het programma dat de verzending gaat doen, stelt de namenserver enige vragen, om te bepalen waarnaar toe het bericht moet worden gezonden. De eerste vraag is om uit te vinden welke machines post kunnen behandelen voor de naam RED.RUTGERS.EDU. In dit geval ant- woordt de server dat RED.RUTGERS.EDU zijn eigen post afwerkt. Het pro- gramma vraagt dan naar het adres van RED.RUTGERS.EDU, wat 128.6.4.2 is. Dan opent het post programma een TCP verbinding naar poort 25 op 128.6. 4.2. Poort 25 is de vaste ingang, gebruikt voor ontvangst van post. Wanneer deze verbinding eenmaal is gemaakt, begint het post programma op- drachten te zenden. Hier volgt een typische conversatie. Iedere regel is gemerkt van wie het afkomstig is, TOPAZ of RED. TOPAZ begon de verbin- ding: RED 220 RED.RUTGERS.EDU SMTP Service op 29 Jun 87 05:17:18 CET TOPAZ HELO topaz.rutgers.edu RED 250 RED.RUTGERS.EDU - Hallo, TOPAZ.RUTGERS.EDU TOPAZ POST Van: RED 250 POST geaccepteerd TOPAZ Ontvanger naar: RED 250 Ontvanger geaccepteerd TOPAZ GEGEVENS RED 354 Start post input; beindig met . TOPAZ Datum : Zat, 27 Jun 87 13:26:31 CET TOPAZ Van: hedrick@topaz.rutgers.edu TOPAZ Aan: levy@red.rutgers.edu TOPAZ Onderwerp: vergadering TOPAZ TOPAZ Laten we Maandag samenkomen om 13:00 TOPAZ . RED 250 OK TOPAZ QUIT RED 221 RED.RUTGERS.EDU Service sluit kanaal af Ten eerste, alle opdrachten gebruiken normale tekst. Dit is typisch voor de Internet standaarden. Veel protocollen gebruiken standaard ASCII op- drachten. Dat maakt het gemakkelijk om te zien wat er gebeurt en om pro- blemen op te sporen. Bijvoorbeeld, het post programma houdt een log bij van iedere conversatie. Wanneer iets verkeerd gaat, kan het logbestand naar de post-directeur gezonden worden. Aangezien het normale tekst is, kan hij direct zien wat er aan de hand is. Het laat ook toe dat men di- rect met de server kan communiceren, voor testdoeleinden. (Sommige nieu- were protocollen zijn zo complex dat dit niet practisch is. De opdrachten moeten een syntaxis hebben waarvoor een taalkennis van betekenis nodig zou zijn. Er is dus een tendens voor gebruik van binaire formaten in nieuwere protocollen. In het algemeen zijn zij gestructureerd zoals C of Pascal structuren). Ten tweede, merk op dat de antwoorden allemaal beginnen met getallen. Dit is ook typisch voor Internet protocollen. De getallen laten het gebrui- kersprogramma ondubbelzinnig antwoorden. De rest van het antwoord is tekst, dat normaal voor menselijk gebruik is die de zaak in gaten houdt, of naar een log kijkt. Het heeft geen effect op de werking van de pro- grammas. (Er is echter een punt waar het protocol een deel van de tekst van het antwoord gebruikt). De opdrachten zelf laten eenvoudig het post- programma aan e e n kant, tegen de post server te zeggen welke informa- tie het moet weten om het bericht af te leveren. In dit geval, zou de post server de info kunnen verkrijgen, door naar het bericht zelf te kij- ken. Maar in meer ingewikkelde gevallen, zou dat niet veilig zijn. Iedere sessie begint met een HELO, die de naam geeft van het systeem dat de ver- binding begon. Dan worden de afzender en ontvangers gespecificeerd. (Er kunnen meer RCPT opdrachten zij wanneer er meerdere ontvangers zijn). Tenslotte worden de gegevens zelf gezonden. De tekst van het bericht wordt beeindigd door een regel met alleen een punt. (Wanneer zo'n regel in het bericht staat, wordt de punt verdubbeld). Nadat het bericht is ge- accepteerd, kan de afzender een ander bericht zenden, of de sessie beein- digen, zoals in het voorbeeld hierboven. In het algemeen is er een patroon in de antwoord getallen. Het protocol definieert de specifieke groep antwoorden die kunnen worden gezonden, als reacties op een gegeven opdracht. Programmas die ze niet in detail willen analyseren, kunnen alleen naar de eerste digit kijken. In het algemeen betekenen antwoorden die met een 2 beginnen, succes. Die met een 3 begin- nen, geven aan dat verdere actie nodig is, zoals hierboven is te zien. 4 en 5 geven fouten aan. 4 is een "tijdelijke" fout, zoals het vullen van een schijf. Het bericht zou worden opgeslagen en later opnieuw gepro- beerd. 5 is een permanente fout, zoals een niet bestaande ontvanger. Het bericht zou naar de afzender moeten worden teruggezonden met een fouten melding. (Voor meer details over de vermelde protocollen in dit hoofdstuk, zie RFC's 821/822 voor post, RFC 959 voor bestands-uitwisseling en RFC 's 854/855 voor login's op afstand. Voor de vaste poort nummers, zie de laatste editie van Assigned Numbers, en mogelijk ook RFC 814). 4.Andere protocollen dan TCP : UDP en ICMP Tot zover hebben wij alleen verbindingen besproken die TCP gebruiken. Zoals we gezien hebben is TCP verantwoordelijk voor het opbreken van be- richten in datagrammen en ze weer correct samenstellen. In veel toepas- singen hebben we echter berichten die in een enkel datagram passen. Een voorbeeld is het opzoeken van een naam. Wanneer een gebruiker een verbin- ding met een ander systeem probeert te maken, zal hij in het algemeen het systeem bij naam specificeren, in plaats van het Internet adres. Zijn systeem moet de naam naar een adres vertalen, alvorens het iets kan doen. Slechts enkele systemen hebben een database die gebruikt wordt om namen naar adressen te vertalen. Dus zal het gebruiker's systeem een verzoek willen sturen naar een van de systemen die zo'n database hebben. Dit ver- zoek zal zeer kort zijn. Het zal zeker in een datagram passen, en ook het antwoord. Natuurlijk doet TCP meer dan alleen dingen opbreken in datagram- men. Het zorgt er ook voor dat de gegevens aankomen, opnieuw verzenden van datagrammen wanneer nodig. Maar voor een vraag die in een enkel data- gram past, hebben we niet een complex protocol als TCP nodig. Wanneer we geen antwoord krijgen na enige seconden, kunnen we gewoon opnieuw vragen. Voor toepassingen zoals deze, zijn er alternatieven. Het meeste bekende alternatief is UDP ("User Datagram Protocol"). UDP is ontworpen voor toepassingen waar geen reeksen van datagrammen samenge- steld moeten worden. Het past in het systeem zoals TCP. Er is een UDP hoofd. De netwerk software zet het UDP hoofd vooraan Uw gegevens, precies zoals het een TCP hoofd vooraan Uw gegevens zou zetten. Dat zendt UDP de gevevens naar IP, die het IP hoofd eraan toevoegt en zet UDP protocol nummer in het protocol veld in plaats van TCP's protocol nummer. Het deelt de gegevens niet op in meerdere datagrammen. Het houdt niet bij wat het heeft gezonden, dus kan het opnieuw zenden. Het enige dat UDP verstrekt is poort nummers, zodat verschillende programmas UDP direct kunnen gebruiken. Een UDP hoofd is korter dan een TCP hoofd. Het heeft bron en bestemming poort nummers en een controle getal, maar dat is alles. Geen volgorde nummer, omdat het niet nodig is. UDP wordt ge- bruikt door protocollen die het opzoeken van namen behandelen (zie IEN 116, RFC 882 en 883), een aantal indentieke protocollen. Een ander alternatief protocol is ICMP ("Internet Control Message Proto- col"). ICMP wordt gebruikt voor fouten meldingen en andere berichten, bedoeld voor de TCP/IP software zelf, in plaats van door een bepaald ge- bruikers-programma. Bijvoorbeeld, als U probeert met een host te verbin- den, kan Uw systeem terugkomen met een ICMP mededeling, zeggende "host unreachable" (host onbereikbaar). ICMP kan ook gebruikt worden om infor- matie omtrent het netwerk uit te vinden. Zie RFC 792 voor details over ICMP. ICMP is gelijk aan UDP, wat betreft het behandelen van berichten in e e n datagram. Het is zelf nog eenvoudiger dan UDP. Het heeft zelfs geen poortnummers in zijn hoofd. Aangezien alle UDP berichten worden ver- werkt door de netwerk software zelf, zijn geen poortnummers nodig om te zeggen waarheen een UDP bericht moet gaan. 5. Bijhouden van namen en informatie: het domein systeem Zoals we eerder hebben aangegeven, heeft netwerk software in het algemeen een 32-bit internet adres nodig, om een verbinding te openen en een data- gram te zenden. Gebruikers geven er echter de voorkeur aan met computer- namen te werken in plaats van getallen. Er is dus een database waarmee de software een naam kan opzoeken en het bijbehorende nummer vinden. Toen Internet nog klein was, was dit gemakkelijk. Ieder systeem zou een be- stand moet hebben waarin alle andere systemen staan, met naam en adres. Er zijn nu zoveel computers, dat dit niet meer practisch is. Dus zijn die bestanden vervangen door een groep namenservers die de hostnamen bijhou- den en het bijbehorende Internet adres. (In feite zijn die servers wat algemener dan dat). Een groep van gekoppelde servers worden gebruikt, in plaats van een enkele centrale server. Er zijn nu zoveel verschillende instituten verbonden met het Internet, dat het niet practisch zou zijn om een centrale autoriteit te informeren, wanneer zij een nieuwe computer hebben geinstalleerd of verplaatst. Dus is de naam autoriteit gedelegeerd aan individuele instituten. De namenservers vormen een boom, overeenkom- stig een institutionele structuur. De namen zelf volgen een identieke structuur. Een typisch voorbeeld is de naam BORAX.LCS.MIT.EDU. Dit is ene computer van het Laboratory for Computer Science (LCS) bij MIT. Om het Internet adres te vinden, zou U mogelijk 4 verschillende servers moeten raadplegen. Ten eerste, zou U een centrale server (genoemd de stam), waar de EDU server is. EDU is de server die onderwijs instituten bijhoudt. (Er zijn verschillende servers op ieder niveau, zodat er rekening mee gehouden is dat er een defect is). U zou dan EDU vragen waar de server voor MIT is. U zou dan weer de namen en Internet adressen krijgen van verschillende servers voor MIT. Deze servers zijn niet allemaal bij MIT, om rekening te houden met een netspanning onderbreking bij MIT. Dan zou U MIT vragen waar de server voor LCS is en tenslotte zou U een van de LCS servers naar BORAX vragen. Het uiteindelijke resultaat zou dan het Internet adres voor BORAX.LCS.MIT.EDU zijn. Ieder van deze niveaux wordt aangeduid als een "domein". De complete naam BORAX.LCS.MIT.EDU, wordt een "domein naam" genoemd. (Eveneens zijn de namen van het hogere niveau do- meinen, zoals LCS.MIT.EDU, MIT.EDU en EDU). Gelukkig hoeft U meestal niet werkelijk door dit alles heen te gaan. Ten eerste de stam namen servers zijn ook de namen servers voor de hoge ni- veau domeinen, zoals EDU. Dus een enkel verzoek aan een stam server, brengt U naar MIT. Ten tweede, software herinnert zich in het algemeen antwoorden die het voordien heeft ontvangen. Dus als we een naam op LCS.MIT.EDU opzoeken, herinnert onze software zich waar de servers te vinden zijn voor LCS.MIT.EDU, MIT.EDU en EDU. Het herinnert zich ook de vertaling van BORAX.LCS.MIT.EDU. Ieder deel van de informatie heeft een "levensduur". Typisch is dit enige dagen. Daarna verloopt de informatie en moet opnieuw worden opgezocht. Hierdoor kunnen instituten de dingen wijzigen. Het domain systeem is niet beperkt tot het vinden van Internet adressen. Een domain naam is een knooppunt (node) in een database. Het knooppunt kan gegevens hebben die een aantal verschillende eigenschappen definie- ren. Voorbeelden zijn Internet adres, computer type en een lijst van diensten die door een computer worden verstrekt. Een programma kan naar een specifiek stuk informatie vragen, of alle informatie over een bepaal- de naam. Het is mogelijk voor een knooppunt in de database om gekenmerkt te zijn als een "alias" (of bijnaam) voor een ander knoopunt. Het is ook mogelijk om het domein systeem te gebruiken om gebruikers informatie op te slaan, mailing lijsten en andere zaken. Er is een Internet standaard die de werking van die databases definieert, evenals de te gebruiken protocollen om verzoeken te doen. Iedere netwerk aanwending moet in staat zijn zulke verzoeken te doen, omdat het nu de officiele manier is om host namen te evalueren. In het algemeen zullen netwerk aanwendingen tegen een server op hun eigen systeem praten. Die server zorgt voor de contacten naar andere servers. Dit houdt de hoeveel- heid code laag dat in ieder toepassing programma aanwezig is. Het domein systeem is in bijzonder belangrijk voor het verwerken van com- puter post. Er zijn opgaven die definieren welke computer post afhandelt, voor een bepaalde naam, te specificeren waar een persoon zijn post moet ontvangen en mailing lijsten definieren. (Zie RFC's 882, 883 en 973 voor specificaties van het domein systeem. RFC 974 definieert het gebruik van het domein systeem voor verzenden van post). 6. Routing De omschrijving hierboven geeft aan dat de IP toepassing verantwoordelijk is ervoor te zorgen dat de datagrammen op de bestemming komen die is aangegeven door het bestemmings-adres, maar weinig was gezegd hoe dit gedaan moet worden. De taak om uit te vinden hoe een datagram naar zijn bestemming te krijgen, wordt genoemd "routing". Veel van de details han- gen in feite af van de speciale toepassing. Sommige algemene dingen kun- nen echter worden gezegd. Ten eerste is het nodig om het model, waarop IP is gebaseerd, te begrij- pen. IP neemt aan dat een systeem is verbonden met een lokaal netwerk. We nemen aan dat het systeem datagrammen kan zenden naar ieder ander sys- teem op zijn eigen netwerk. (In het geval van Ethernet, vindt Ethernet eenvoudig het adres van het bestemmings-systeem en zet het datagram op het Ethernet). Het probleem komt wanneer een systeem wordt gevraagd om een datagram naar een ander netwerk te zenden. Dit probleem wordt opge- lost door gateways. een gateway is een systeem dat een netwerk met e e n of meerdere netwerken verbindt. Gateways zijn dikwijls normale computers die meer dan e e n netwerk interface hebben. Bijvoorbeeld, we hebben een Unix machine die twee verschillende Ethernet interfaces heeft. Het is dus verbonden met netwerken 128.6.4 en 128.6.3. Deze machine kan functioneren als een gateway tussen de twee netwerken. De software op die machine moet zodanig worden ingesteld, dat het datagrammen zal verzenden van het ene netwerk naar het andere. Dat betekent, wanneer een machine op netwerk 128.6.4 een datagram naar de gateway zendt en het datagram is geadres- seerd aan een machine op netwerk 128.6.3, zal de gateway het naar de be- stemming doorzenden. Veel communicatie centras hebben dikwijls gateways, die een aantal verschillende netwerken verbinden. (In veel gevallen geven specifieke gateway systemen een betere prestatie en betrouwbaarheid dan algemene systemen die als gateways werken). Routing een IP is geheel gebaseerd op het netwerk nummer van het bestem- mings-adres. Iedere computer heeft een lijst van netwerk nummers. Voor ieder netwerk is een gateway vermeld. Dat is de gateway die wordt ge- bruikt om naar dat netwerk te komen. NB. de gateway hoeft niet direct naar dat netwerk te verbinden. Het moet alleen de beste plaats zijn om daar te komen. Bijvoorbeeld bij Rutgers is onze interface naar NSFnet op het John Neuman Supercomputer Center (JvNC). Onze verbinding naar JvNC gaat via de hoge snelheid seriele lijn, verbonden met een gateway, waarvan het adres 128.6.3.12 is. Systemen op net 128.6.3 zullen 128.6.3. 12 gebruiken als de gateway voor netwerken buiten de campus. Systemen op 128.6.4. zullen echter 128.6.4.1 gebruiken als gateway voor dezelfde net- werken buiten de campus. 128.6.4.1 is de gateway tussen de netwerken 128. 6.4 en 128.6.3, dus dat is de eerste stap om naar JvNC te komen. Wanneer een computer een datagram wil zenden, kijkt het eerst of het be- stemmings-adres op het systeem zijn eigen netwerk is. Wanneer dit zo is, kan het datagram direct gezonden worden. Anders verwacht het systeem een opgave te vinden voor het netwerk van het bestemmings-adres. Het data- gram wordt naar de gateway gezonden die in de lijst staat. Die lijst kan behoorlijk groot zijn. Bijvoorbeeld, het Internet heeft vele honderden individuele netwerken. Dus zijn er methoden ontwikkeld om de grootte van de routing tabellen te reduceren. E e n van die strategieen baseert zich op "default routes". Dikwijls is er maar e e n gateway om uit een netwerk te komen. Die gateway kan een lokaal Ethernet met een groot campus net- werk verbinden. In dat geval hebben wij geen speciale opgave nodig in de lijst, voor ieder netwerk in de wereld. We geven eenvoudig die gateway als "default" op. Wanneer geen speciale route wordt gevonden voor een datagram, wordt het naar de default gateway gezonden. Een default gateway kan zelfs worden gebruikt, wanneer er meerdere gate- ways op een netwerk zijn. Er zijn voorzieningen voor gateways, om een be- richt te zenden, zeggende "Ik ben niet de beste gateway, gebruik deze in plaats". (Het bericht wordt verzonden via ICMP, Zie RFC 792). De meeste netwerk software is ontworpen om deze berichten te gebruiken om opgaven aan hun routing lijsten toe te voegen. Veronderstel netwerk 128.6.4 heeft twee gateways, 128.6.4.59 4n 128.6.4.1. 128.6.4.59 leidt naar verschil- lende andere Rutgers netwerken. 128.6.4.1 leidt indirect naar het NSFnet. Neem aan, we stellen 128.6.4.59 in als een default gateway en hebben geen andere routing lijst opgaven. Wat gebeurt er nu wanneer we een datagram naar MIT willen zenden? MIT is netwerk 18. Aangezien we geen opgave voor netwerk 18 hebben, wordt het datagram naar de default 128.6.4.59 gezonden. Die gateway is echter de verkeerde. Dus zal het het datagram naar 128.6. 4.1 zenden. Maar het zal ook een fouten melding terugzenden, in feite zeggende: "om naar netwerk 18 te komen, gebruik 128.6.4.1". Onze software zal dan een opgave aan de routing lijst toevoegen. (De fou- tenmelding wordt met het ICMP protcol gezonden. Het bericht type wordt "ICMP redirect" genoemd). De meeste IP experts bevelen aan dat individuele computers niet zouden moeten proberen om het gehele netwerk bij te houden. In plaats daarvan, zouden zij moeten beginnen met default gateways en laat de gateways de routes opgeven, zoals zojuist beschreven. Dat zegt echter niet hoe de gateways de routes moeten zien te vinden. De gateways kunnen niet van deze strategie afhangen. Zij moeten redelijk complete routing lijsten hebben. Hiervoor is een soort routing protocol nodig. Een routing proto- col is eenvoudig een techniek voor de gateways, om elkaar te vinden, en de beste manier up to date bijhouden, om naar ieder netwerk te komen. RFC 1009 bevat een overzicht van gateway ontwerp en routing. Rip.doc is misschien een goede introductie voor het onderwerp. Het bevat wat les - materiaal en een gedetailleerde beschrijving van het meest gebruikte routing protocol. 7. Details over Internet adressen: subnetten en uitzendingen (broadcasts) Zoals reeds vermeld, zijn Internet adressen 32-bit getallen, normaal ge- schreven als 4 octets (in decimaal), zoals, 128.6.4.7. Er zijn feitelijk 3 verschillende typen van adressen. Het probleem is dat het adres het netwerk en de host in het netwerk moet weergeven. Er werd voorzien dat er uiteindelijk veel netwerken zouden zijn. Veel zouden klein zijn, maar mogelijk zouden 24 bits nodig zijn om alle IP netwerken te vertegenwoor- digen. Men dacht ook dat sommige, zeer grote netwerken, 24 bits nodig zouden hebben om al hun hosts te vertegenwoordigen. Dit zou leiden tot 48 bit adressen. Maar de ontwerpers wilden toch 32 bit adressen gebrui- ken. Aangenomen werd dat de meeste netwerken klein zullen zijn. Dus wer- den drie verschillende adres bereiken opgezet. Adressen, beginnende met 1 tot 126 gebruiken alleen de eerste octet van het netwerk nummer. De andere drie octets zijn beschikbaar voor het host nummer. Dus zijn 24 bits beschikbaar voor hosts. Die nummers worden gebruikt voor grote net- werken. Er kunnen maar 126 van die zeer grote netwerken zijn. Het Arpanet is er e e n, en er zijn enkele grote commerciele netwerken. Maar weinig normale organisaties krijgen e e n van die "klasse A" adressen. Voor nor- male organisaties, worden "klasse B" adressen gebruikt. Klasse B adressen gebruiken de eerste twee octects voor het netwerk nummer. De netwerknum- mers zijn 128.1 tot 191.254 (We vermijden 0 en 255, om redenen die we later zullen zien. We vermijden ook adressen, beginnende met 127, want dat is gebruikt door sommige systemen voor speciale doeleinden). De laatste twee octets zijn beschikbaar voor host adressen, dus 16 bits voor host adressen. Dit is genoeg voor 64516 computers, dat voldoende moet zijn voor de meeste organisaties. (Het is mogelijk om meer dan e e n klasse B adressen te krijgen, wanneer U tekort komt). Tenslotte, klasse C adressen gebruiken 3 octets, in het bereik 192.1.1 tot 223.254.254. Dat laat 254 hosts toe op ieder netwerk, maar er kunnen veel van die net- werken zijn. Adressen boven 223 zijn gereserveerd voor toekomstig gebruik, zoals klassen D en E (die momenteel niet gedefinieerd zijn). Veel grote organisaties vinden het prettig om hun netwerk in "subnetten" te splitsen. Bijvoorbeeld, Rutgers heeft een klasse B adres toegewezen gekregen, 128.6. Wij vinden het gemakkelijk om het derde octet van het adres te gebruiken om aan te geven op welk Ethernet een host aanwezig is. Die verdeling is niet van belang buiten Rutgers. Een computer bij een ander instituut, zou alle datagrammen geadresseerd aan 128.6, hetzelfde behandelen. Zij zouden niet naar het derde octet van het adres kijken. Dus computers buiten Rutgers, zouden geen verschillende routes hebben voor 128.6.4 of 128.6.5. Maar binnen Rutgers, behandelen we 128.6.4 en 128.6.5 als aparte netwerken. In feite hebben gateways binnen Rutgers, aparte opgaven voor ieder van de Rutgers subnetwerken, waarbij gateways buiten Rutgers alleen e e n opgave hebben voor 128.6. Wij zouden precies hetzelfde kunnen doen door een klasse C te gebruiken voor ieder Ethernet. Wat Rutgers betreft, zou het voor ons even gemakkelijk zijn geweest om een aantal klasse C adressen te hebben. Het gebruik van klasse C adressen maakt het voor de rest van de wereld niet gemakkelijk. Ieder instituut dat met ons zou willen praten, zou een aparte opgave moeten hebben voor ieder van onze netwerken. Als ieder instituut dit zou doen, zouden er veel te veel netwerken zijn om bij te houden, voor een redelijke gateway. Door een klasse B netwerk onder te verdelen, verbergen wij onze interne structuur voor anderen en besparen hun de moeite. Deze subnet strategie vereist speciale voorzieningen in de netwerk software. Het is beschreven in RFC 950. 0 en 255 hebben speciale betekenis. 0 is gereserveerd voor machines die hun adres niet weten. In bepaalde omstandigheden is het mogelijk voor een machine om niet het netwerk nummer te kennen, of zelfs zijn eigen host adres. Bijvoorbeeld, 0.0.0.23 zou een machine zijn die weet dat zijn host nummer is 23, maar weet niet op welk netwerk. 255 wordt gebruikt voor uitzendingen ("broadcast"). Een broadcast is een bericht warvan U wilt dat iedereen op het netwerk het ziet. Broadcasts worden soms gebruikt in gevallen, wanneer U niet weet tegen wie te praten. Bijvoorbeeld, stel U moet een hostnaam opzoeken en zijn Internet adres. Soms weet U niet het adres van de dichtstbijzijnde namen server. In dat geval zou U het verzoek als een broadcast kunnen zenden. Er zijn ook ge- vallen waar een aantal systemen in informatie geinteresseerd zijn. Het is goedkoper om een enkele broadcast te zenden in plaats van individuele datagrammen aan iedere host te zenden, die in de informatie geinteres- seerd is. Om een broadcast te zenden, gebruikt U een adres dat is gemaakt door Uw netwerk adres te gebruiken, met allemaal eenen in het deel van het adres waar het host nummer staat. Bijvoorbeeld, als U op netwerk 128. 6.4 bent, zou U 128.6.4.255 gebruiken voor broadcasts. Hoe dit gedaan wordt, hangt af van het medium. Het is niet mogelijk om broadcasts op het Arpanet te zenden, of op point to point lijnen. Het is echter mogelijk op een Ethernet. Wanneer U een Ethernet adres gebruikt met al zijn bits aan (allemaal eenen), wordt iedere machine op het Ethernet verondersteld naar dat datagram te kijken. Hoewel het officiele broadcast adres voor netwerk 128.6.4 nu 128.6.4.255 is, zijn er enige andere adressen die kunnen worden behandeld als broad- casts door bepaalde toepassingen. Voor het gemak staat de standaard ook toe dat 255.255.255.255 wordt gebruikt. Dat betreft alle hosts op het lokale netwerk. Het is vaak eenvoudiger om 255.255.255.255 te gebruiken in plaats van het netwerk nummer voor het lokale netwerk uit te vinden en een broadcast adres te maken, zoals 128.6.4.255. Bovendien mag in bepaal- de oudere toepassingen de 0 in plaats van 255 worden gebruikt om het broadcast adres te maken. Zulke toepassingen zouden 128.6.4.0 gebruiken in plaats van 128.6.4.255 als broadcast adres op netwerk 128.6.4. Ten- slotte kunnen bepaalde oudere toepassingen subnetten niet begrijpen. Dus nemen zij aan dat het netwerk nummer 128.6 is. In dat geval zullen zij een broadcast adres aannemen van 128.6.255.255 of 128.6.0.0. Totdat on- dersteuning van de broadcasts goed is toegepast, kan het een wat gevaar- lijke feature zijn om te gebruiken. Omdat 0 en 255 worden gebruikt voor onbekende broadcast adressen, moeten normale hosts nooit adressen gegeven worden die een 0 of 255 bevatten. Adressen moeten nooit beginnen met 0, 127, of een getal boven 223. Adres- sen die deze regel overtreden, worden soms "marsmannetjes" genoemd, omdat geruchten rond gaan dat de Centrale Universiteit van Mars netwerk 255 ge- bruikt. 8. Datagram fragmentatie en samenvoegen TCP/IP is ontworpen om met veel verschillened soorten netwerken te ge- bruiken. Helaas kunnen netwerk ontwerpers het er niet over eens zijn hoe groot packets kunnen zijn. Ethernet packets zijn 1500 octets lang. Arpa- net packets hebben een maximum van ongeveer 1000 octets. Sommige, zeer snelle netwerken, hebben veel grotere packets. Aanvankelijk zou U kunnen denken dat IP zich eenvoudig op de kleinst mogelijke grootte zou vastleg- gen. Helaas zou dit serieuze problemen geven. Wanneer grote bestanden worden uitgewisseld, zijn grote packets veel efficienter dan kleinere. Wij willen dus is staat zijn om het grootst mogelijke packet te verwer- ken. Maar we willen ook in staat zijn om netwerken met kleine begrenzin- gen te behandelen. Hiervoor zijn twee voorzieningen. Ten eerste, TCP heeft de mogelijkheid om over de packet grootte te "onderhandelen". Wan- neer een tcp verbinding voor het eerst opent, kunnen beide zijden de ma- ximale datagram grootte zenden die zij kunnen verwerken. De kleinste van die getallen wordt dan gebruikt voor de rest van de verbinding. Hierdoor kunnen toepassingen die grote datagrammen kunnen verwerken, deze ook ver- werken, maar laat ze ook praten met toepassingen die ze niet kunnen ver- werken. Dit lost echter het probleem niet geheel op. Het meest serieuze probleem is dat de twee kanten niet noodzakelijk alle tussenliggende stappen kennen. Bijvoorbeeld, wanneer gegevens gezonden worden tussen Rutgers en Berkeley, zullen beide computers wel op Ethernets zijn. Dus zullen beide voorbereid zijn om 1500 octets datagrammen te verwerken. De verbinding zal op een bepaalde plaats overgaan op het Arpanet. Dat kan packets van die grootte niet verwerken. Om die reden zijn er voorzienin- gen om datagrammen in stukken op te splitsen. (dit wordt genoemd "frag- mentatie"). Het IP hoofd bevat velden die aangeven dat een datagram is gesplitst en genoeg informatie om de onderdelen weer samen te stellen. Wanneer een gateway een Ehernet verbindt met het Arpanet, moet het in staat zijn 1500-octet packets op te nemen en ze in stukken te splitsen die op Arpanet passen. Verder moet iedere host toepassing van TCP/IP in staat zijn stukken te accepteren en ze weer samen te stellen. Dat wordt "reassembly" (samen- voegen) genoemd. TCP/IP toepassingen verschillen in de manier waarop zij de grootte van de datagrammen beslissen. Het is redelijk gewoon dat toepassingen 576- byte datagrammen gebruiken, wanneer zij niet kunnen vaststellen dat het gehele pad grotere packets kan verwerken. Deze tamelijk conservatieve strategie wordt gebruikt in verband met het aantal toepassingen met bugs in de code om fragmenten weer samen te stellen. De toepassers proberen dikwijls te voorkomen dat ooit fragmentatie ontstaat. Verschillende toe- passers hebben verschillende benaderingen, om te beslissen wanneer het veilig is om grote datagrammen te gebruiken. Sommige gebruiken ze alleen voor het lokale netwerk. Anderen zullen ze gebruiken voor ieder netwerk op dezelfde campus. 576 bytes is een "veilige" grootte, die iedere toe- passing moet ondersteunen. 9. Ethernet adres omzetting : ARP Er was eerder een korte discussie over hoe IP datagrammen eruit zien op een Ethernet. De discussie liet het Ethernet hoofd en het controlegetal zien. Het liet echter een punt open: Het zei niet hoe uit te vinden welk Ethernet adres te gebruiken, wanneer U met een bepaald Internet adres wilt praten. Er is een apart protocol daarvoor, genoemd ARP ("address resolution protocol"). (NB. ARP is geen IP protocol, dus ARP datagrammen hebben geen IP hoofden). Neem aan U bent op systeem 128.6.4.194 en U wilt verbinden met systeem 128.6.4.7. Uw systeem zal eerst vaststellen dat 128.6.4.7 op hetzelfde netwerk is, zodat het direct via Ethernet kan pra- ten. Dan zal het 128.6.4.7. in zijn ARP lijst opzoeken, om te zien of het het Ethernet adres al kent. Wanneer zo, zal het een Ethernet hoofd toe- voegen en het packet verzenden. Maar neem aan dat dit systeem niet in de ARP lijst staat. Er is geen manier om het packet tezenden, want U hebt het Ethernet adres nodig. Dus wordt het ARP protocol gebruikt om een ARP verzoek uit te zenden. Hoofdzakelijk zegt een ARP verzoek "Ik heb het Ethernet adres voor 128.6.4.7 nodig". Ieder systeem luistert naar ARP verzoeken. Wanneer en systeem een ARP verzoek voor zichzelf ziet, moet het antwoorden. Dus 128.6.4.7 zal het verzoek zien, en antwoorden met een ARP antwoord, in feite zeggende "128.6.4.7. is 8:0:20:1:56:34". (Ethernet adressen zijn 48 bits. Dat is 6 octets. Ethernet adressen worden gebrui- kelijk in hex en met de getoonde onderbrekingen gegeven). Uw systeem zal deze informatie opslaan in zijn ARP lijst, zodat toekomstige packets di- rect door kunnen gaan. De meeste systemen behandelen de ARP lijst als een tijdelijke opslag en verwijderen opgaven als ze een bepaalde tijd niet zijn gebruikt. ARP verzoeken moeten, tussen twee haakjes, als "broadcasts" worden ge- zonden. Er is geen mogelijkheid dat een ARP verzoek direct naar het juis- te systeem kan worden gezonden. Tenslotte is de hele reden om een ARP verzoek te zenden, dat U het Ethernet adres niet kent. Dus wordt een Ethernet adres met allemaal eenen gebruikt; ff:ff:ff:ff:ff:ff. Volgens af- spraak moet iedere machine op het Ethernet op packets met dit adres let- ten. Dus zien alle machines alle ARP verzoeken. Zij kijken ook of het verzoekj voor hun eigen adres is. Wanneer niet, kunnen ze het negeren. (Sommige hosts zullen een ARP verzoek gebruiken om hun kennis over andere hosts op het netwerk te updaten, zelfs als het verzoek niet voor hun is). Packets waarvan het adres aangeeft broadcast (dus. 255.255.255.255 of 128.6.4.255), worden ook met een Ethernet adres met allemaal eenen gezon- den. 10. Verkrijgen van meer informatie Dit hoofdstuk bevat documenten die de meest belangrijke protocollen be- schrijven. Er zijn letterlijk honderden documenten, dus hebben we er de belangrijkste uitgekozen. Internet standaarden worden RFC's genoemd. RFC in de afkorting van Request for Comment. Een standaard voorstel wordt uitgegeven als een voorstel en krijgt een RFC nummer. Wanneer het uitein- delijk geaccepteerd is, wordt het aan de Officele Internet Protocollen toegevoegd, maar wordt nog steeds vermeld onder het RFC nummer. We hebben ook twee IEN's toegevoegd. (IEN's waren een aparte classificatie voor meer informele documenten. Die classificatie bestaat niet meer. RFC's worden nu gebruikt voor alle officiele Internet documenten en een mailing list wordt gebruikt voor informele rapporten). De afspraak is dat wanneer een RFC wordt herzien, de herziene versie een nieuw nummer krijgt. Dit is prima voor de meeste doeleinden, maar het geeft problemen met twee docu- menten: Toegewezen nummers en Officiele Internet Protocollen. Die docu- menten worden steeds herzien, dus de RFC nummers veranderen steeds. U moet in rfc-index.txt kijken om het nummer van de laatste editie te vin- den. Iedereen die serieus geinteresseerd is in TCP/IP moet de RFC lezen die IP beschrijft (791). RFC 1009 is ook nuttig. Het is een specificatie voor gateways, te gebruiken door NSFnet. Het geeft een overzicht van veel van de TCP/IP technologie. U zou mogelijk ook de beschrijving van e e n van de toepassing protocollen moeten lezen, om een gevoel te krijgen van hoe de dingen werken. Post is misschien een goede (821/822). TCP (793) is natuurlijk een zeer fundamentele specificatie. De spec. is tamelijk ingewikkeld, dus U moet deze lezen als U de tijd en het geduld hebt om hierover na te denken. Gelukkig is de auteur van de belangrijkste RFC's (Jon Postel) een zeer goede schrijver. De TCP RFC is veel gemakkelijker te lezen dan U zou verwachten, in verband met de complexiteit die het beschrijft. U kunt naar de andere RFC's kijken als U nieuwsgierig wordt omtrent hun onderwerp. Hier is een lijst van de documenten die U misschien zou willen hebben. rfc-index lijst van alle RFC's rfc1012 een wat completere lijst van alle RFC's rfc1011 Officiele protocollen. Het is nuttig om deze eens te bekijken, om te zien voor welke taken protocollen gebouwd zijn. Dit defi- nieert welke RFC's werkelijk standaarden zijn, tegenover ver- zoeken om commentaar. rfc1010 Toegewezen nummers. Wanneer U met TCP/IP werkt, wilt U waar- schijnlijk een afdruk hiervan als referentie. Het is niet erg spannend om te lezen. Het geeft alle officieel gedefinieerde bekende vaste ingangen en een hoop andere dingen . rfc1009 NSFnet gateway specificaties. Een goed overzicht van IP routing en gateway technologie. rfc1001/2 netBIOS: netwerken voor PC's rfc973 update van domeinen rfc959 FTP (bestands uitwisseling) rfc950 subnetten rfc937 POP2: protocol voor lezen van post op PC's rfc894 hoe IP op een Ethernet wordt gezet, zie ook rfc825 rfc882/3 domeinen (de database om te gaan van host namen naar Internet adres en vice versa, ook gebruikt om UUCP te verwerken) zie ook rfc973 rfc854/5 telnet, protocol voor logins op afstand rfc826 ARP, protocol voor het vinden van Ethernet adressen. rfc821/2 post rfc814 namen en poorten, algemene concepten achter de vaste poorten rfc973 TCP rfc792 ICMP rfc768 UDP rip.doc details van het meest algemeen gebruikte routing protocol ien-116 oude namen server (nog steeds nodig voor verschillende soorten systemen) ien-48 Het Catenet model, algemene omschrijving van de filosofie achter TCP/IP De volgende documenten zijn wat meer gespecialiseerd. rfc813 window en bevestiging strategieen in TCP rfc815 datagram samenstelling technieken rfc816 fouten signalering en oplossing technieken rfc879 de maximale segment grootte optie in TCP rfc896 controle van opstoppingen rfc827,888,904,975,985 EGP en aanverwante zaken Voor diegenen die dit document op afstand zullen lezen, in plaats van bij Rutgers: De belangrijkste RFC's zijn verzameld in een drie-delen set, het DDN Protocol Handbook. Het is beschikbaar van het DDN Netwerk Infor- mation Center, SRI International, 333 Ravenswood Avenue, Menlo Park, Ca- lifornia 94025 (telefoon: 800-235-3155). U zou ze kunnen verkrijgen via anonymous FTP sri-nic.arpa. Bestandsnamen zijn : RFC's: rfc:rfc-index.txt rfc:rfcxxx.txt IEN's: ien:ien-index.txt ien:ien-xxx.txt rip.doc is beschikbaar door anonymous FTP van topaz.rutgers.edu, als /pub/tcp-ip-docs/rip.doc. Sites met toegang tot UUCP maar geen FTP, kunnen ze ophalen via UUCP van UUCP host rutgers. De bestandsnamen zouden zijn: RFC's: /topaz/pub/pub/tcp-ip-docs/rfc-index.txt /topaz/pub/pub/tcp-ip-docs/rfcxxx.txt IEN's: /topaz/pub/pub/tcp-ip-docs/ien-index.txt /topaz/pub/pub/tcp-ip-docs/ien-xxx.txt /topaz/pub/pub/tcp-ip-docs/rip.doc NB. SRI-NIC heeft de complete set van RFC's en IEN's , maar Rutgers en Topaz hebben alleen die speciaal hierboven genoemd zijn. -------------ooooooooooooooo---------------