Vint Cerf had meer aandacht aan beveiliging willen besteden bij ontwikkeling TCP

Vint Cerf had graag meer aandacht aan de beveiliging van TCP/IP willen besteden. Bij het ontwikkelen deed hij dat niet omdat sleutelbeheer volgens hem nog ingewikkeld was, maar achteraf had hij daar meer mee willen doen, zegt de uitvinder van het internetprotocol.

Cerf zegt in een interview met IEEE Spectrum dat hij 'niet genoeg aandacht besteedde aan beveiliging' bij het opstellen van TCP. Dat was in die tijd ook logisch, zegt hij. "Voordat publickeycryptografie beschikbaar was, was sleutelbeheer een ingewikkeld, handmatig proces. Het was vreselijk en schaalde niet. Daarom stopte ik het niet in het internet." Cerf zegt dat hij geen spijt heeft van die beslissing. Het internet werd in zijn begindagen nog voornamelijk door studenten gebruikt. Cerf zegt dat dat 'wel de laatste groep is die ik vertrouw met sleutelbeheer'. Toch zegt hij: "Er zijn momenten dat ik zou willen dat we meer aandacht hadden besteed aan end-to-endbeveiliging van het systeem."

Een andere toepassing waar Cerf anders op terugkijkt, is de grootte van internetadressen. IPv4-adressen zijn nu 32 bits. "Nu lacht iedereen erom en vraagt me waarom ik geen 128bit-adressen gebruikte", zegt hij. IPv6-adressen zijn zo groot, maar de uitrol ervan verloopt moeizaam. Ook die keus vindt Cerf goed te verdedigen. "In 1973 zeiden mensen dat je gek was als je 3,4 keer tien tot de 38e macht aan adressen nodig dacht te hebben voor een experiment waarvan je niet zeker weet of het iets gaat worden." Hij noemt 32bit-adressen 'een fout', maar zegt er ook bij: "Ik had 128bit-adressen in die tijd echt niet kunnen verkopen."

Cerf zegt verder ook nog dat hij het web onderschatte. Hij zegt 'totaal niet te hebben durven voorspellen dat zoekmachines nodig zouden zijn'. "Ik zag de lawine aan content die op internet kwam nadat het web beschikbaar werd totaal niet aankomen", zegt hij.

Reacties (72)

[GekkePrutser]

Ik vind dit ook niet helemaal onlogisch. Encryptie kan je beter niet op de laag van TCP afhandelen. Dan stop je veel te veel functionaliteit in die laag van het OSI model. Doe dat alsjeblieft op een hogere laag. TCP is voor het garanderen van bevestigde communicatie die in de juiste volgorde aan moet komen. Dat moet stabiel zijn, terwijl de cryptowereld nog steeds onderhevig is aan veranderende inzichten (denk aan bijvoorbeeld quantum wat er nu aan zit te komen). Dus die laag moet daar makkelijk mee om te gaan.

Als je te veel functionaliteit in een laag van het protocol stopt, dan wordt het een overgecompliceerd geheel.

[Luchtbakker]

"Ik had 128bit-adressen in die tijd echt niet kunnen verkopen."

Wat ik lees in dit artikel is de houding wat we tot de dag van vandaag nog steeds hebben. Namelijk; we ontwikkelen iets wat wel verkoopbaar is. Want als niemand het wilt door de complexiteit dan gaat niemand het doorontwikkelen en gebruiken.

Eigenlijk een verkeerde gedachtegang, maar zo lijkt de wereld er zelfs 50 jaar later nog steeds zo uit te zien.

[Reactie gewijzigd door Luchtbakker op 1 augustus 2024 06:05]

[84hannes]

Eigenlijk een verkeerde gedachtegang,

Dat ben ik niet met je eens. Als je iets nieuws maakt of koopt kijk je naar de toepassingen van vandaag en morgen, niet die van over tien jaar. Als ik morgen een fiets koop, dan is die geschikt om naar mijn werk te fietsen, maar niet om een pakketbezorgdienst te beginnen. Als ik dat over twee jaar toch wil doen dan moet ik me dan maar aanpassen.

Toen ASCII werd bedacht was 7-bits genoeg om alle Engelse teksten te encoderen. Er was een extra bit over voor leuke features. Als ze toen al hadden bedacht dat je eigenlijk 32-bits nodig hebt, dan had je 4x zoveel floppies nodig gehad om bepaalde data op te slaan;'dat had de voortgang van de computer veel meer vertraagd dan de late introductie van eerst utf-16, en daarna utf-8. Achteraf kun je zeggen dat UTF-16 een vergissing was, maar zowel ASCII en UTF-8 waren in hun tijd een goede oplossing.

[beerse]

Dat ascii is een mooi voorbeeld. Ooit was het met 5, 6 of 7 bits genoeg om tekst over te sturen. Overigens na dat morse het aantal 'bits' per karakter wel heel vrij had gelaten (bedenk hier bij een 0 voor een punt en een 1 voor een streepje). Ondertussen worden karakters weer gegeven in een variabele maat: Unicode (https://nl.wikipedia.org/wiki/Unicode)

Met het adresseren van nodes in een netwerk was ooit een 32 bits getal genoeg: Het ip adres. Nu zijn we met IPv6 naar een nieuw nummersysteem overgegaan maar nog steeds wel een vast aantal nummers.

Bedenk dat in de tijd dat IPv4 is ontwikkeld iedere bit duur was en dat er dus zuinig met ruimte werd omgesprongen. Het systeem van telefoonnummers met variabele maten was te lastig.

[jiriw]

De 'rusten' bij CW/Morse zijn wel essentieel. Anders kan je het einde van een letter/woord en het begin van de volgende niet onderscheiden. Een punt is '1' lang, een streep '3', de rust tussen twee symbolen (punt of streep) is ook '1' lang, de rust tussen twee letters is '3' lang en tussen twee woorden '7' lang.
Je zou morse dus kunnen coderen met bits in aan/uit tijden maar dan is de letter '1' bijvoorbeeld 17 bits lang (10111011101110111) plus een rust van 3 of 7 nullen afhankelijk of de letter aan het einde van een woord staat.
Of je kan het coderen met vijf symbolen en dan is de letter '1' 9 quints groot (102020202) met quint 3 of 4 er achteraan voor volgende letter of volgend woord.
De letter 'e' (het kortste morseteken) is dan (1) binair met dezelfde 3 of 7 nullen rust of (1) quinair met daar achter een (3) of (4) quinair.

[beerse]

Groot gelijk. En over dat van die pauzes: bij seriële communicatie wordt tussen de karakters ook gewerkt met herkenning: hier het gebruik van een start-bit, 1 of 2 stop bits en een parity.

Over het 'verlengen' van de codering om meer te kunnen weergeven: Bij de seriële communicatie met 5 of 6 bits wordt maar 1 kast van de letters mee gestuurd. Volgens mij alleen de kleine letters. Als dan een hoofdletter nodig was, moest dat worden vooraf gegaan door een \ (of was dat nu juist een /?). Er is in die tijd best wel wat creatiefs verzonnen. Gelukkig zijn bepaalde zaken geautomatiseerd en anderen in het museum gezet.

[gast128]

Achteraf kun je zeggen dat UTF-16 een vergissing was

UTF-16 is een variabele lengte encoding (e.g. 2 of 4 bytes) en kan daarmee alle code points coderen. De voorloper en wat u waarschijnlijk bedoelde is UCS-2. Dit heeft een vaste lengte van 2 bytes per code point en kan daarmee niet alles meer coderen. UCS-2 wordt veel gebruikt in Windows en in C++ / wchar_t.

[Sandor_Clegane]

Er is zelfs een term voor: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

Ron Jeffries, a co-founder of XP, explained the philosophy: "Always implement things when you actually need them, never when you just foresee that you [will] need them."[8] John Carmack wrote "It is hard for less experienced developers to appreciate how rarely architecting for future requirements / applications turns out net-positive."[9]

[boner]

vergeet niet dat we destijds voornamelijk terminal verkeer hadden. Elke toetsaanslag werd verstuurd en kwam retour. Per toetsaanslag betekent dit 4 pakketjes over het netwerk. En met modems van 300 bps of minder was de overhead een onaanvaardbare hoeveelheid.

[Blokker_1999]

Vergeet niet dat opslag in die tijd ook nog eens extreem duur was. Ik denk dat hij zelfs moeite heeft moeten doen om 32bit verkocht te krijgen wanneer 16bit in die begindagen ook al goed genoeg was. De architectuur van computers was zelfs maar 8 bit in die tijd.

Daarnaast is het niet eens zo slecht, want IPv6 voegt echt wel een pak meer toe dan enkel grotere adressen, en zonder dat zetje van die adres schaarste zou het waarschijnlijk nooit geadopteerd geraken. Dus in dat opzicht is het niet slecht om te ontwerpen voor wat we in de komende 10 of 20 jaar nodig denken te hebben en de problemen van onze kortzichtigheid later aan te pakken.

[Tinus7]

Dat denk ik ook inderdaad. De kosten en benodigde processorkracht voor routers was waarschijnlijk een beperkende factor. Daarnaast was met 64 bits adressen de overhead van de tcp headers in elk pakketje te groot geworden. Met de lage snelheden van dataverbindingen van die tijd was dat mogelijk zelfs onwerkbaar geworden, of in ieder geval nog trager dan het al was.

[locke960]

De originele tcp specificatie uit 1974 heeft het over 20 bit adressen

4 bits: Destination network address
1010-1111 are addresses of ARPANET, UCL, CYCLADES, NPL, CADC, and EPSS respectively.

16 bits: Destination TCP address

Dus toen dachten ze nog max 16 netwerken met elkaar te verbinden
En een TCP adres was iets dat zich binnen een netwerk bevond, niet een globaal uniek adres zoals we nu over een TCP/IP adres denken.

32 bit adressen en het idee van subnets, zoals we dat nu gebruiken, zijn pas later toegevoegd.

[hcQd]

De architectuur van computers was zelfs maar 8 bit in die tijd.

8-bit zag je nauwelijks, behalve bij microprocessors. Minicomputers en mainframes waren meestal 16, 18, 32, 36, 60 of 64 bits.

[eheijnen]

Stukje uit wikipedia over de conceptie van internet en de oorspronkelijke bedoeling:

The origins of the Internet date back to the development of packet switching and research commissioned by the United States Department of Defense in the late 1960s to enable time-sharing of computers.[2] The primary precursor network, the ARPANET, initially served as a backbone for the interconnection of regional academic and military networks in the 1970s to enable resource sharing.

Dat dat zou uit de klauwen zou lopen heeft echt niemand gezien in die tijd. Ik heb 25 jaar geleden nog mensen horen schreeuwen dat Amazon nooit wat zou worden....

[Cergorach]

~15 jaar geleden riep men dat ook over Twitter en dat is recent voor $44 miljard verkocht...

En hoeveel mensen riepen 35 jaar geleden "Leer een echt vak jongen! Die computer(spelletjes) gaat nooit wat worden!" als je aan het prutten was op je C64...

[eheijnen]

"Hindsight is a Wonderful thing"....

[Tjidde]

In 1998 dachten veel mensen dat ze nooit een mobiele telefoon zouden hebben. Laat staan een mobiele telefoon met internet...

Het is extreem moeilijk om te gokken of een nieuwe techniek/product de wereld veranderd of niet.

Voor hetzelfde geld, had nooit iemand iets gezien in computing en was de computer(en dan ook het internet) nooit van de grond gekomen en was het een extreem niche markt gebleven. Iets wat in de 70 denk ik niet zo gekke gedachte was.

[The Zep Man]

Wat ik lees in dit artikel is de houding wat we tot de dag van vandaag nog steeds hebben. Namelijk; we ontwikkelen iets wat wel verkoopbaar is. Want als niemand het wilt door de complexiteit dan gaat niemand het doorontwikkelen en gebruiken.

Niemand wilde het toendertijd door de hogere prijs. Verder was het internet zoals wij dat nu kennen toen helemaal geen use case van het protocol:

Cerf zegt verder ook nog dat hij het web onderschatte. Hij zegt 'totaal niet te hebben durven voorspellen dat zoekmachines nodig zouden zijn'. "Ik zag de lawine aan content die op internet kwam nadat het web beschikbaar werd totaal niet aankomen", zegt hij.

Dat zag je ook in de begindagen, dat hele publieke IPv4 klasse A-ranges gereserveerd werden door techbedrijven. En waarom niet? Adressen zat!

En over beveiliging in het artikel: toen keek men volledig anders naar cryptografie als dat men er nu naar kijkt. Tot in de jaren 90 ging de VS nog krampachtig met encryptie om. Kan je nagaan hoe die houding was in de jaren 70. Als het woord 'beveiliging' genoemd zou worden bij het maken van het protocol in die tijd, dan zou TCP/IP nooit verder gekomen zijn dan de tekentafel.

[Reactie gewijzigd door The Zep Man op 1 augustus 2024 06:05]

[Tjidde]

Buiten dat het lang geduurd heeft voordat sommige landen encryptie accepteerde.

In de jaren 70 was het veel meer een ons kent ons clubje aan ontwikkelaars. Allemaal hadden ze hetzelfde idee, leuke dingen maken om beter met elkaar te kunnen communiceren. Dan kan ik mij goed voorstellen beveiliging en encryptie niet boven aan je lijst staat. Maar op een "makkelijke" manier data uitwisselen is dan veel leuker en is ook verkoopbaar aan een manager.

Het voordeel van TCP nu is wel dat het eigenlijk heel simpel is. Het doet precies wat het zegt dat het doet. Of je nu een bericht stuurt met "Hallo Zep Man" in plain text of waarbij de tekst is gemuteerd is met behulp van encryptie. Maakt voor TCP niet uit. Wat juist de grootste kracht is van het protocol. Ga je al in dat protocol encryptie verwerken, zie ik een grotere kans dat het mis gaat en jij nooit mijn Hallo krijgt .

[dasiro]

Het voordeel van TCP nu is wel dat het eigenlijk heel simpel is. Het doet precies wat het zegt dat het doet. Of je nu een bericht stuurt met "Hallo Zep Man" in plain text of waarbij de tekst is gemuteerd is met behulp van encryptie. Maakt voor TCP niet uit. Wat juist de grootste kracht is van het protocol. Ga je al in dat protocol encryptie verwerken, zie ik een grotere kans dat het mis gaat en jij nooit mijn Hallo krijgt .

het grote voordeel dat encryptie op een hogere layer ligt zorgt ervoor dat we nu nog altijd het protocol gebruiken, want anders zou het al meerdere keren moeten zijn aangepast, want traffic decrypten was toen ofwel te traag of iets later te onveilig.

Verschillende van de standaarden die vroeger ontworpen zijn, hebben de tand des tijds kunnen doorstaan terwijl we de laatste jaren constant met revisies van nieuwere standaarden om de oren worden geslagen. Er werden toen beslissingen genomen waar de industrie die nog in haar kinderschoenen stond uiteindelijk mee akkoord ging ipv dan maar telkens een nieuwe standaard op te richten. In dat oogpunt zal de wereld nooit meer zo gestructureerd worden als toen.

[Verwijderd]

Http/3 is dat maar dan over udp, met software die packets controleerd en je je eigen encryptie kan toepassen.

[RobTweaks]

Vraag is dan: Is er een beter alternatief? Ik zie 't meer als een MVP. Het MVP is destijds opgeleverd en wordt sinds jaar en dag iteratief doorontwikkeld.

[Luchtbakker]

Volgens mij had Vint Cerf nooit het idee dat het zo groot was geworden, anders had hij denk ik wel verder door ontwikkeld. Maar dat is met heel veel projecten zo.

[nzall]

Niemand had in Februari 2004 kunnen vermoeden dat dat slaapkamerproject van een tweedejaars Harvard student één van de hoekstenen van het Internet zou worden.

[mdavids]

Hij heeft wel eens gezegd dat het een experiment was dat uit het lab was ontsnapt.

[Gamebuster]

Precies! Daarom geef ik user-ids ook altijd 512bit integers. Je weet maar nooit wanneer die 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084097e gebruiker zich inschrijft!

[The Zep Man]

Je weet maar nooit wanneer die 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084097e gebruiker zich inschrijft!

Even een vraag over compatibiliteit: is dat een longnum of een hex string (dankzij de 'e' aan het einde)? Dan kan ik ondersteuning voor jouw user ID's toevoegen aan mijn library (naast miljoenen andere user ID-formaten).

[Reactie gewijzigd door The Zep Man op 1 augustus 2024 06:05]

[Gamebuster]

Nee, die e is de e in "de 2e gebruiker". Vervang de 2 door groter getal.

Gewoon een integer dus! Je kan uint512_t gebruiken om 'm op te slaan.

[Reactie gewijzigd door Gamebuster op 1 augustus 2024 06:05]

[DLGandalf]

Er zijn pakweg 2^256 atomen in het heelal. Met 256bits zit je dus wel redelijk safe, als we even aannemen dat een gebruiker uit meer dan 1 atoom bestaat.

[Gamebuster]

Hoeveel atomen heb je nodig om 256 bits getal op te slaan?

[SanSnoopy]

Of noem het normale kosten-batenanalyses die rekening houden met de werkelijkheid. Hadden ze zelf dan maar even publickeycryptografie moeten ontwikkelen, of alles wat daar dan ook weer nodig voor was? En ook maar even secure DNS, of ook... Zo krijg je nooit realistische, verkoopbare scopes.

En langs de andere kant weet je nooit hoe het gebruik ervan zal uitpakken, welke edge cases toch een grotere impact hebben dan gedacht.

Zoals ik het lees: moest iets à la publickeycryptografie voor handen zijn, dan hadden ze het geïntegreerd. Lijkt mij persoonlijk een nuchtere, acceptabele manier van werken.

[kdekker]

Je kunt geen toekomst voorspellen en kosten spelen altijd een rol. Zeker in de IT is verder vooruitzien op mogelijke ontwikkelingen voor de komende paar jaar al erg lastig. Achteraf is dan makkelijk praten.

Toen tcp/ip startte was een 20MB harde schijf groot en 1MB geheugen. De argumenten die genoemd worden zijn zeer valide.

[Cergorach]

Eigenlijk een verkeerde gedachtegang, maar zo lijkt de wereld er zelfs 50 jaar later nog steeds zo uit te zien.

Dat komt omdat in 50 jaar mensen niet zo fundamenteel veranderen. En dan doel ik niet op de ontwikkelaar in dit geval, maar de rest van de mensheid die het moet gaan gebruiken. Mensen gaan niet voor het 'beste' product, maar voor het meest populaire. Mensen gaan niet voor het 'beste' product, maar voor het makkelijkste bruikbare. Natuurlijk is de formule niet zo simpel, maar daar komt het in de basis wel op neer.

Dat je vervolgens daarop producten ontwikkeld is natuurlijk hoe de ontwikkeling werkt, je gaat namelijk niet voor de grootste ontwikkeling, maar voor de breedste adoptie. Want hoe meer mensen het kunnen/willen gebruiken, hoe hoger je de basis trekt. Of hoe lager je drempel maakt, hoe meer mensen er over die drempel heen willen. Je kan vervolgens later weer een drempel introduceren, etc.

Binnen de IT moeten we eigenlijk ook zo producten kiezen. Hoeveel personeel met kennis hierover is een serieuze overweging wanneer je een (complex) IT product kiest. De keuze tussen UltraEdit en Notepad++ zal weinig impact hebben, maar welk VM systeem je gebruikt voor al je IT klanten is opeens een heel stuk impactvoller.

Je kan een super ingewikkeld product maken, maar als haast niemand het daardoor gebruikt had je net zo goed niet het product kunnen maken. K.I.S.S.

[Ludewig]

Mensen gaan niet voor het 'beste' product, maar voor het makkelijkste bruikbare.

Maar het is helemaal niet zo dat het meest complexe product ook het beste is. Bruikbaarheid is ook een kwaliteit. En kosten net zo goed. En prestaties. Ten tijde dat het Internet werd ontwikkeld was het veel duurder dan nu om 64 of 128 bit in het geheugen op te slaan en langzamer om te verwerken.

[Verwijderd]

Het is tegenwoordig een editor met co pilot ondersteuning, die houdt je scherp.

[Arrigi]

Je hebt het over 1978. Een src+dst ipv6 adres voor één pakketje is al 256 bit, om van de rest van de header en de data nog niet te spreken.

De Zilog Z80 was populair in de jaren 70 en 80. Dat ding kon in z'n geheel 64kB addresseren. Een TRS-80 uit 1977 kwam standaard met 4KB geheugen.

Een BBC micro die 4 jaar later beschikbaar was kwam met 16kB geheugen. Alsof je nu een PC hebt met 8GB geheugen en iemand stelt voor dat we met 128MB grote adressen gaan werken. Er zijn trouwens ook nog smartphones met 3GB.
Maar ja, nú voldoen die 32MB adresjes nog wel, maar wat in 2060?

In een tijd waarin je dacht misschien met enkele honderden computers te communiceren was dit al een heel vooruitstrevend voorstel.

[The Zep Man]

Je hebt het over 1978. Een src+dst ipv6 adres voor één pakketje is al 256 bit, om van de rest van de header en de data nog niet te spreken.

De Zilog Z80 was populair in de jaren 70 en 80. Dat ding kon in z'n geheel 64kB addresseren. Een TRS-80 uit 1977 kwam standaard met 4KB geheugen.

Een BBC micro die 4 jaar later beschikbaar was kwam met 16kB geheugen.

Hoeveel van die genoemde systemen waren meegenomen in de scope om TCP/IP te ondersteunen? Volgens mij was dat nooit het plan.

Al wil je een correcte vergelijking doen, dan moet je je richten op de specificaties van systemen uit die tijd waar TCP/IP voor bedoeld was. Dan moet je bijvoorbeeld denken aan mainframes.

[Reactie gewijzigd door The Zep Man op 1 augustus 2024 06:05]

[Tjidde]

Ik kan mij goed voorstellen dat Cerf het totaal verkeerd heeft ingeschat.

In 73 was de computer laat staan het internet nog zo'n niche ding. Waarbij ik goed kan voorstellen je niet kan inbeelden dat uit eindelijk bijna heel de wereld er dagelijks gebruik van maakt.

Ook bij software die ik ontwikkel, probeer ik het zou te ontwikkelen met het idee dat er meer en grotere data dan de status nu is er doorheen kan. Echter zit daar wel een limiet aan. Hoe ver vooruit kan je kijken zonder extreme overkill. 99% van de software die ontwikkeld word gaat van MVP v1 naar MVP v2 etc...

Daarnaast ga jij er vanuit dat je nu iets op je werk (of als hobby) doet dat ruim 50jaar later nog steeds extreem veel gebruikt zal worden? Ik niet, ik verwacht tegen die tijd wel een keer een nieuwbouw of iets dergelijks. Omdat technieken verbeteren.

Al zal ooit een nieuw protocol in plaats van TCP/IP een nog lastigere wedstrijd worden dan IPv6, iets wat al jaren en jaren duurt en mogelijk nog lang door zal etteren.

[Verwijderd]

Http/3 is udp met software, geen tcp

[Frame164]

Je moet altijd een compromis zoeken tussen wat technische wenselijk, technisch beschikbaar en commercieel acceptabel is. Als je nu mogelijke security zaken wilt opnemen die pas over 20 jaar haalbaar zijn wordt wat je nu gaat bouwen veel te duur. En als je wacht totdat het realistischer wordt, is er iets anders op de horizon wat een probleem zou kunnen worden.

[Osiummaster]

Ethernet is ondanks zijn gedateerdheid nog steeds verreweg het beste protocol voor intra communicatie. Alle kabels naar een switch en die kopt de berichten vervolgens door naar het juiste apparaat. En het is nog vrij rap ook. Vind het zeer knap hoe future-proof het toendertijd allemaal al was verzonnen. Vele protocollen zijn gevallen maar UDP en TCP blijven heersers.

[feuniks]

Om heel eerlijk te zijn is ethernet geen protocol, maar een netwerkstandaard. En die is van oorsprong zelfs erg dom. Een concurrerende standaard was Token Ring en die was beter / netter, maar veel duurder. Ethernet heeft van oudsher veel last van collisions, omdat ieder apparaat luistert of de lijn vrij is en dan probeert te zenden, zodat je vaak hebt dat dan juist twee of meer apparaten op diezelfde kabel aan het versturen zijn. Token Ring had dat niet, omdat ieder apparaat een tijd toegewezen kreeg dat het kon / mocht versturen. Een 4 Mbps Token Ring netwerk was vaak sneller dan een 10 Mbps Ethernet netwerk, zeker als er meer apparaten op aangesloten waren.
Alleen is er op een gegeven moment in plaats van een enkele dikke coax kabel een sternetwerk met utp kabels gekomen bij ethernet en toen daar in "het midden" een apparaat kwam te staan had je net zoiets als de MAU bij Token Ring. De hub was in het begin nog dom. Dit is allemaal trouwens laag 1 van het OSI model. Hij stuurde alle verkeer naar alle poorten, maar op een gegeven moment heeft men daar een switch van gemaakt, die in laag 2 van het OSI model zit.

Echter gaat het artikel hier niet over. TCP zit veel hoger in het OSI model (laag 4) en eigenlijk gaat het artikel in tegenstelling tot wat de titel doet vermoeden meer over IP, wat in laag 3 zit. Voor zowel TCP als IP is het onbelangrijk wat eronder zit. Dat is nu eigenlijk altijd een vorm van Ethernet, maar het had ook Token Ring kunnen zijn of een heel andere netwerkvorm.

[Ludewig]

Token Ring werkt goed als alles foutloos loopt, maar vereist een nogal complexe opzet.

Als je bijvoorbeeld de PC ontkoppeld of hij crashed terwijl hij het token heeft, dan verdwijnt het token. Dus moet er een Monitor op het netwerk zijn die in de gaten houdt of het token verdwijnt en dan een nieuwe maakt. En dan moet je maar hopen dat de PC echt weg was en niet slechts traag, want dan heb je twee tokens.

Als het ontvangende station een bericht niet oppakt, dan blijft het bericht rondgaan. De Monitor moet dat bericht dan weghalen. Door deze opzet ben je dus heel erg afhankelijk van een correct functionerende Monitor. Als je handmatig moet instellen wie dat doet, dan moet je dus precies weten wat je doet.

Ethernet is veel simpeler en is in de praktijk daardoor robuuster. Niet voor niets gebruikt ook Wifi een model waar ze gewoon maar uitzenden en botsingen opmerken.

Overigens is hebben switches het grootste nadeel van Ethernet weggenomen. Feitelijk zit alles dat aangesloten zit op een switch op z'n eigen netwerk en botst dus niet meer met het deel van het netwerk dat aan een andere poort hangt. En switches zijn zo goedkoop geworden dat de meeste Ethernet netwerken nu point-to-point zijn, waarbij de switches feitelijk zorgen voor een directe verbinding tussen apparaten, zonder collisions behalve tussen upload en download.

[Reactie gewijzigd door Ludewig op 1 augustus 2024 06:05]

[verstrooid_prof]

Ethernet is veel simpeler en is in de praktijk daardoor robuuster. Niet voor niets gebruikt ook Wifi een model waar ze gewoon maar uitzenden en botsingen opmerken

In zekere zin is Ethernet trouwens eerst als "wifi" op de markt gekomen. Het stukje Ether in Ethernet is echt wel van radio-transmissie.

[likewise]

Om heel correct en tevens eerlijk te zijn is Ethernet wel degelijk een protocol. Namelijk een data link layer protocol.

En ik denk dat IP nog redelijk vaak over niet-Ethernet gaat, zoals de fibers op de zeebodem, of over cellular.

[CH4OS]

Maar ethernet (layer 1) is hardware, waar UDP en TCP/IP juist software zijn (en in layer 4 zitten). Totaal andere zaken dus (en zelfs OSI layers). Het is immers prima mogelijk om UDP en TCP/IP door bijvoorbeeld WIFI heen te duwen, maar ook door glasvezel.

Of ik begrijp niet helemaal wat je zegt, dat kan natuurlijk ook.

[Osiummaster]

Ik denk dat mijn bewoording inderdaad niet helemaal klopt. Ik heb het meer over het algemeen gebruik van de RJ45 poort en protocollen die magischerwijs stand houden na vele jaren waar al het andere weg begint te vallen (zelfs USB A moet plaats gaan maken voor USB C nu).

Vooral dat ze voor lokaal thuisgebruik tot industrieel gebruik tot wereldwijde communicatie universeel geschikt zijn is toch wel erg knap.

[RefriedNoodle]

Maar ethernet (layer 1) is hardware

Ethernet is al een stapje boven de hardwarelaag, en is dus layer 2, niet layer 1.

[koen.daalman]

Vrijdag besteedde The Waveform-podcast (van MKBHD) ook al aandacht aan het ontstaan van het internet met meer van dit soort leuke weetjes. Interressant luistervoer.

[MGutker]

Dit is wel erg interresant inderdaad. Ik zal toch ook eens die MKBHD podcast moeten luisteren, bedankt voor de tip!

[ex87]

Er zijn 2 delen (rond dit specifieke onderwerp) die echt vermakelijk waren:

ICANN and the 7 Keys to the Internet
- https://www.youtube.com/watch?v=26WvISI14g0
The Secret History of the Internet
- https://www.youtube.com/watch?v=3TzOkOCjFx0

Ik zou ze persoonlijk wel allebei luisteren

[skralan]

Als ik als simpele app/web ontwikkelaar keuzes moet maken in mijn project dan heb ik twee jaar later al wel eens spijt van sommige zaken. Ik kan me niet inbeelden hoe moeilijk keuzes maken moet zijn geweest voor de ontwikkeling van tcp/het internet. Het feit dat het zó goed stand houdt is evenveel waanzinnig als dat het inspirerend is.

[pennywiser]

TCP is gevangen in brede adoptie, dat is wat anders dan een website die je morgen met het nieuwste framework hebt draaien. Vergelijk MP3, x86 en zo zijn er wel meer.

[Verwijderd]

Dial up modem was leuk met at commands, daar heb ik op school nog 2 bootfloppies gemaakt. De een belde de ander en toen magischerwijs ging die toen laden van de andere kant.

[Snow_King]

Ik ben helemaal pro-IPv6 en ben er ook zeker van dat uiteindelijk IPv6 de overhand gaat nemen. We kunnen simpelweg echt niet anders.

Toevallig ben ik nu twee startende bedrijven aan het helpen, je wil niet weten hoe lastig het is de markt op de komen nu er geen IPv4 beschikbaar is en je moet kopen tegen hele hoge bedragen.

We ontwikkelen nu de gehele infra IPv6-first en alleen IPv4 waar echt nodig. CloudFlare zit er volledig voor en die doet de IPv6<>IPv4 translatie voor ons.

Was IPv4 vanaf het begin 48-bits of 64-bits geweest en dan denk ik dat we niet heel snel aan IPv6 waren begonnen.

128-bits is super om te hebben, maar niet perse nodig. Al was IPv6 niet sneller gegaan als het 64-bits was geweest.

[The Zep Man]

128-bits is super om te hebben, maar niet perse nodig. Al was IPv6 niet sneller gegaan als het 64-bits was geweest.

Als wij enkel het internet nemen zoals dat geleverd wordt als WAN-verbinding, dan is 128 bit nodig. Een enkele internetaansluiting krijgt minimaal een /64-range en idealiter een /48-range toegewezen. Ook worden voor veel peer-to-peer verbindingen van slechts twee apparaten aparte /64 ranges gebruikt, want de aanbevolen grootte van een IPv6 subnet is /64 (waar veel ondersteunende zaken vanuit gaan).

IPv6 is 128 bit, maar veel van de ruimte zal ongebruikt blijven doordat van de gereserveerde ruimte van de meeste WAN-verbindingen slechts een fractie gebruikt wordt. Door te kiezen voor 128 bit in plaats van 64 bit, wordt het probleem vele jaren verder de toekomst ingeschopt. Tevens was 128 bit-adressering op het moment dat het bedacht werd (in de jaren 90) niet zo duur meer ten opzichte van de jaren 70.

[Reactie gewijzigd door The Zep Man op 1 augustus 2024 06:05]

[Snow_King]

Ik snap helemaal wat je zegt, maar mijn punt was meer dat of IPv6 nu 64 of 128-bits is, de adoptie was niet sneller gegaan. Het is de overstap van IPv4 naar IPv6 en de twee protocollen die niet met elkaar kunnen praten die het lastiger maken.

128-bit is gewoon top!

[The Zep Man]

Ik snap helemaal wat je zegt, maar mijn punt was meer dat of IPv6 nu 64 of 128-bits is, de adoptie was niet sneller gegaan.

Dat klopt. De noodzaak van IPv6 was nooit direct aanwezig. Het wordt langzamerhand steeds meer nodig, maar het voortbestaan van IPv4 heeft een sterk dempende werking.

[pennywiser]

Ikzelf denk dat IPv4 altijd naast IPv6 zal blijven bestaan. Er zijn er wel meer die dat denken.

Is IPv4 niet beschikbaar, of moet je het kopen tegen hoge bedragen, dat zijn 2 verschillende dingen. Want dat laatste is al een tijdje zo. Dus als een bedrijf begint, had je dat 10 jaar geleden ook al kunnen voorzien dat het duur worden om een IPv4 blok te kopen.

Geen IPv4 meenemen in je development is een beetje niet wijs volgens mij. T-Mobile glas heeft niet eens IPv6. Dan kan je heel nobel de adoptie willen bevorderen, maar willen jullie dan niet bredere toegang aan je applicaties geven? Ik snap dat niet helemaal. Maar het is dus niet IPv6 only want je laat cloudflare het voor je oplossen. Zo zie je maar.

Let wel, ik ben zeer voor IPv6, ik zie een transitie naar IPv6 only alleen niet gebeuren voorlopig.

[Reactie gewijzigd door pennywiser op 1 augustus 2024 06:05]

[The Zep Man]

Ikzelf denk dat IPv4 altijd naast IPv6 zal blijven bestaan. Er zijn er wel meer die dat denken.

"Ikzelf denk dat IPv4 zal uitsterven. Er zijn er wel meer die dat denken".

Als je zoekt naar een eigen ingevuld antwoord op een vraag, dan zal je dat vinden op het internet.

[Reactie gewijzigd door The Zep Man op 1 augustus 2024 06:05]

[pennywiser]

Ik lees in jouw link 2040 of later, of "waarschijnlijk nooit".

[Verwijderd]

Ik lees op Reddit 8 jaar oude commentaren. Ik zou zeggen dat ip v4 voor de westerse landen overblijft en de rest op v6

[Snow_King]

IPv4 is niet nodig, zo draaien alle Facebook datacenters intern ook volledig IPv6. Alleen op de services naar de buitenwereld praat men nog IPv4.

Zo gaan deze bedrijven het ook inzetten. Intern volledig IPv6 en alleen IPv4 via CloudFlare waardoor de diensten wel te bereiken zijn.

Maar het is bizar dat je zo veel geld voor wat IP-blokken moet betalen, dat hindert nieuwe bedrijven echt om de markt op de komen.

En 10 jaar geleden waren deze ondernemers 15, hadden ze dat doen al moeten voorzien?

[lkruijsw]

Dat de uitrol van IPv6 moeizaam is, komt mede doordat we geen enkele push introduceren om de server kant naar IPv6 te krijgen.

Voor de service providers naar de consument is er wel incentive om naar IPv6 te gaan, omdat je heel veel klanten hebt en dan zijn de IPv4 adressen gewoon op. Als je echter een website hebt waarvoor je maar een paar IPv4 adressen nodig hebt, dan betaal je gewoon. En dan houden we de situatie dat veel websites nog IPv4 only zijn.

Terwijl het heel makkelijk te pushen is. Geef een penatly als je een domein hebt waarvoor je in de DNS alleen een IPv4 adres hebt. Verhoog die penalty elk jaar. En over 10 jaar moet je een IPv6 adres aanbieden anders verlies je het domein.

[Snow_King]

SIDN moet gewoon zeggen: Wil je een nieuw .nl domein? Geen IPv6? Dan kan je het domein niet vastleggen.

Of maak alle domeinen die geen IPv6 hebben gewoon 2x zo duur bij SIDN. Gaat een hoop hosters in beweging brengen.

[lkruijsw]

Dat is precies wat ik bedoel. Het is ook eenvoudig af te dwingen.

[Snow_King]

Ik heb SIDN hier al enkele keren op gewezen, maar men lijkt dat nog niet te durven.

Maak de domeinen gewoon duurder, zeg dat je geen domein meer kan vastleggen zonder IPv6 (en DNSSEC!) op de DNS en dwing af dat als er een MX-record is deze ook via IPv6 resolved.

Zo veel te verzinnen, maar daadkracht ontbreekt gewoon echt.

[mrmrmr]

Als ik chef was bij SIDN zou ik het ook niet doen. Ze gaan niet over IP space.

RIPE regelt de IP-adressen in onze streken.

Ik ben voor het verplicht aanbieden van DNSSEC. En het pushen van DANE.

Wat Vint Cerf betreft: er is zoveel dat hij onmogelijk kon voorspellen. De flexibiliteit en snelheid van IP is wat het heeft gered. Zelfs op interne netwerken zijn we overgegaan op IP sinds de jaren '90, terwijl het tevoren een ratjetoe was van diverse niet-universele protocollen.

[mdavids]

SIDN doet het anders; geen stok maar een wortel - dus domeinnamen met IPv6 (en/of DNSSEC en/of DMARC/DKIM/SPF) zijn goedkoper (voor de registrar). Dar gaat via de zogenaamde incentive-regleing.

Hier enkele grafieken met de stand van zaken:

https://stats.sidnlabs.nl...reikbaarheid%20via%20ipv6

https://stats.sidnlabs.nl...C%20ipv6%2C%20of%20beiden

[Reactie gewijzigd door mdavids op 1 augustus 2024 06:05]

[Jim80]

IPv4 en IPv6 zijn ook totaal verschillende protocollen en hebben eigenlijk weinig met elkaar te maken. Vandaar de moeilijke uitrol. Had men het iets meer compatibel gehouden, bijvoorbeeld 2 extra 8-bit cijfers aan een v4 adres toevoegen, was de uitrol misschien al compleet.

[RefriedNoodle]

Had men het iets meer compatibel gehouden, bijvoorbeeld 2 extra 8-bit cijfers aan een v4 adres toevoegen, was de uitrol misschien al compleet.

Dan zat je nog steeds met een uitdaging om een 48-bits adres te koppelen aan een 128-bits adres.

Anderzijds, als we toen al 48 bits hadden, hadden we nu 35.000 adressen per persoon op aarde. Vroeg of laat zou zelfs dat niet genoeg zijn, maar misschien hadden we wat meer ademruimte dan nu.

[Stephanoid]

Ik zie een heleboel reacties over ipv6 en dat het verplicht zou moeten worden.
Maar ipv6 is nodeloos complex, lost een probleem op dat eigenlijk niet bestaat.
Een grote misvatting destijds en nog steeds is dat elke adres bij elk ander adres zou moeten kunnen.
Je kunt met (carrier) nat en tunnels en ipv4 prima uit de voeten, nog eeuwenlang desnoods.
Dat er mensen zijn die ipv4 reeksen verzamelen en duur verkopen, tsja, dat is misschien iets waar wat aan gedaan kan worden. Dat je bijvoorbeeld aan moet kunnen tonen dat je ip reeks ook echt gebruikt wordt.
Ipv6 lijkt misschien de holy grail als je er op afstand naar kijkt, maar echt, het zou me niet verbazen als er ooit nog eens ipv4v2 komt, wat binnen een paar jaar volledig geaccepteerd wordt. Waarna ipv6 een stille dood sterft.
Nog even afgezien van het feit dat ze binnen ipv6 zoveel adressen verspillen dat je daarmee binnen een eeuw ook alweer problemen krijgt.