Waarom gebruiken we IP-adressen?

zondag 12 februari 2006 20:31

💩

MAC-adressen zijn adressen voor gebruik in Ethernetnetwerken. Op 't internet ben je niet gelimiteerd tot ethernet: dialups, ATM, DSL, etc. is allemaal geen ethernet. Maar IP gaat er wel overheen.

Daarna heb je nog 't feit dat er totaal geen (bruikbare) hierarchie in MAC-adressen zit. MAC-adres 00:00:01:10:ab:01 kan in Nederland in gebruik zijn, maar het volgende (00:00:01:10:ab:02) in Nieuw-Zeeland. Dat is een routing probleem van hier tot.. ehm. Wellington.

En het derde probleem: in tegenstelling tot IP is ethernet niet gemaakt om in supergrote netwerken als het internet gebruikt te worden (wel op kleine schaal binnen dat netwerk natuurlijk). Op netwerken met een paar honderd hosts heb je al aardige hoeveelheden broadcastverkeer om MAC-adressen op te zoeken. Laat staan als het hele internet een groot Ethernet-netwerk was. (En dat zou moeten, want Ethernet is een layer2, niet-routed protocol.)

December schreef op zondag 12 februari 2006 @ 20:04:
[...]

Als je op 213.239.154.35 kijkt kom je op Tweakers.net terecht, terwijl volgens mij niet altijd dezelfde server T.net host. Maar het ging mij er in ieder geval om dat wanneer je een server/netwerkkaart verwisselt je niet gelijk een ander IP hebt, maar wel een ander MAC-adres

Dat IP-adres is toegewezen aan een loadbalancer. In het geval van tweakers.net is dat ook gewoon een Linux-machine. Zomaar hetzelfde IP-adres aan twee machines toewijzen kan niet, daar moet je wat meer truuken voor uithalen.

[ Voor 27% gewijzigd door CyBeR op 12-02-2006 20:11 ]

All my posts are provided as-is. They come with NO WARRANTY at all.

Acties:

Hahn

CyBeR schreef op zondag 12 februari 2006 @ 20:09:
[...]

Dat IP-adres is toegewezen aan een loadbalancer. In het geval van tweakers.net is dat ook gewoon een Linux-machine. Zomaar hetzelfde IP-adres aan twee machines toewijzen kan niet, daar moet je wat meer truuken voor uithalen.

Al zouden we werken met MAC-adressen, dan zou wanneer de loadbalancer een andere netwerkkaart krijgt, hij ineens een ander MAC-adres krijgen, waardoor T.net dus onder een ander MAC-adres valt. Dat was mijn punt

The devil is in the details.

zondag 12 februari 2006 21:11

Acties:

EricJH

Maar zou je niet analoog aan het huidige internet/netwerk gebeuren DNS en DHCP op basis van MAC adressen kunnen opzetten? Dus MAC ipv IP adres?

zondag 12 februari 2006 21:25

Acties:

zondag 12 februari 2006 21:48

💩

Nee, want het punt van MAC-adressen is dat ze toegekend worden aan een specifiek stuk hardware. Als je dat verandert is 't geen MAC-adres meer en ben je delen van IP aan 't hercreëren.

En dat verandert niets aan ht feit dat Ethernet een niet-routed protocol is dat werkt met broadcasts om frames rond te brengen.

All my posts are provided as-is. They come with NO WARRANTY at all.

Acties:

zondag 12 februari 2006 22:33

1. Controleer de kabel!

in ipv6 is je mac (mogelijk) een deel van het ip adres, dus eingenlijk is het niet zo'n slecht idee van de ts. Alleen was men in de beginjaren van internet nogal zuinig op elke byte. Die moeten namelijk in allerlei tablelen worden opgeneomen en daar wou je zuinig aan mee doen.

Need more data. We want your specs. Ik ben ook maar dom. anders: forum, ff reggen, ff topic maken
En als je een oplossing hebt gevonden laat het ook ujb ff in dit topic horen.

Acties:

zondag 12 februari 2006 22:49

💩

leuk_he schreef op zondag 12 februari 2006 @ 21:48:
in ipv6 is je mac (mogelijk) een deel van het ip adres, dus eingenlijk is het niet zo'n slecht idee van de ts. Alleen was men in de beginjaren van internet nogal zuinig op elke byte. Die moeten namelijk in allerlei tablelen worden opgeneomen en daar wou je zuinig aan mee doen.

Inderdaad. Maar ten eerste: mogelijk. Dat is bedacht om op een lokaal LAN de uniekheid te garanderen bij zeroconf. En ten tweede: dat stuk adres wordt voorafgegaan door minimaal een bit of 64 aan hierarchisch uitgegeven, routerbare address-space.

All my posts are provided as-is. They come with NO WARRANTY at all.

Acties:

Legio947

Topicstarter

CyBeR schreef op zondag 12 februari 2006 @ 20:09:En het derde probleem: in tegenstelling tot IP is ethernet niet gemaakt om in supergrote netwerken als het internet gebruikt te worden (wel op kleine schaal binnen dat netwerk natuurlijk). Op netwerken met een paar honderd hosts heb je al aardige hoeveelheden broadcastverkeer om MAC-adressen op te zoeken. Laat staan als het hele internet een groot Ethernet-netwerk was. (En dat zou moeten, want Ethernet is een layer2, niet-routed protocol.)

Als je een request doet naar een bepaald IP adres, werkt dat dan ook niet met broadcasts?

Als ik hier thuis nu "ping 66.249.93.99" (google) doe, dan moet er toch ook met behulp van broadcasts gezocht worden langs welke routers ik bij google raak?

Door de posts hierboven begin ik wel het nut ervan in te zien...

zondag 12 februari 2006 22:56

Acties:

zondag 12 februari 2006 23:52

💩

Legio schreef op zondag 12 februari 2006 @ 22:49:
[...]

Als je een request doet naar een bepaald IP adres, werkt dat dan ook niet met broadcasts?

Als ik hier thuis nu "ping 66.249.93.99" (google) doe, dan moet er toch ook met behulp van broadcasts gezocht worden langs welke routers ik bij google raak?

Gedeeltelijk, ja. (Op ethernetsegmenten om precies te zijn). Maar jouw broadcast komt niet aan bij google. Sowieso zoekt jouw pc niet 66.249.93.99 op, maar het MAC-adres dat hoort bij het IP-adres van jouw lokale router (ingesteld als default gateway).

Op een klein ethernetsegmentje is een broadcast geen enkel probleem. Ze komen bij elke host uit, maar ethernet doet aan minimaal 10mbit dus dat ene pakketje dat bij, zeg, 10 pc's uitkomt is totaal niet boeiend. Stel je nu voor dat dat broadcastpakketje opeens naar miljarden hosts over de hele wereld moet. Dan is 't opeens een vrij boeiende hoeveelheid verkeer.

All my posts are provided as-is. They come with NO WARRANTY at all.

Acties:

Verwijderd

titelfix

maandag 13 februari 2006 00:22

Acties:

jbvo

CyBeR schreef op zondag 12 februari 2006 @ 22:56:
[...]

Gedeeltelijk, ja. (Op ethernetsegmenten om precies te zijn). Maar jouw broadcast komt niet aan bij google. Sowieso zoekt jouw pc niet 66.249.93.99 op, maar het MAC-adres dat hoort bij het IP-adres van jouw lokale router (ingesteld als default gateway).

Op een klein ethernetsegmentje is een broadcast geen enkel probleem. Ze komen bij elke host uit, maar ethernet doet aan minimaal 10mbit dus dat ene pakketje dat bij, zeg, 10 pc's uitkomt is totaal niet boeiend. Stel je nu voor dat dat broadcastpakketje opeens naar miljarden hosts over de hele wereld moet. Dan is 't opeens een vrij boeiende hoeveelheid verkeer.

Ik dacht dat het zo was dat een ICMP-request sowieso naar de default gateway gestuurd word, zolang dat ip-adres maar niet eindigt op .255. De default gateway heeft vervolgens een tabel met daarin alle adressen van hosts en routers die direct op hem aangesloten zijn en stuurt het pakketje in de goede richting. Als hij het ip-adres niet kent, dan stuurt hij het weer naar zijn default gateway, net zolang totdat de goede weg gevonden is. Omdat routers op internet grotere tabellen bijhouden en ook meer met elkaar communiceren om deze tabellen bij te houden, weten zij sneller de goede weg naar het adres dan binnen jou netwerkje, waar de router alleen de lokale pc's en routers kent en verder alleen de default gateway van je ISP.

Dit is overigens allemaal heel simpel verwoord, er komen uiteraard allerlei protocollen aan te pas.

Overigens worden broadcasts op IP niveau volgens mij op dit moment vooral gebruik voor IP-requests aan de DHCP-server en verder niet veel, tenminste, dit las ik laatst ergens.

maandag 13 februari 2006 00:31

Acties:

maandag 13 februari 2006 09:47

💩

SneakyViper schreef op maandag 13 februari 2006 @ 00:22:
[...]

Ik dacht dat het zo was dat een ICMP-request sowieso naar de default gateway gestuurd word, zolang dat ip-adres maar niet eindigt op .255.

Nee. Je PC heeft ook een routetabel, zij het meestal een vrij simpele bestaand uit alleen de direct aangesloten netwerken en een default route. Als een uitgaand IP-packet een route-entry heeft die aangeeft dat de betreffende host direct aangesloten is wordt er een ARP op het netwerk gezet om het MAC-adres van de betreffende doos te achterhalen. Daarna gaan de packets direct tussen die host en jouw pc. ICMP of TCP of UDP maakt niet uit, ethernet zorgt ervoor dat de frames, met die packets er in, aankomen. Bij route entries via een router (zoals de default route) wordt een ARP verstuurd met het verzoek om het MAC-adres van de betreffende router. Het IP-packet heeft daarna het destination adres dat je opgaf met in het ethernet frame het MAC-adres van je router.

(de rest klopt).

Ethernet en IP en TCP zijn in principe onafhankelijke protocollen, hoewel TCP en IP bijna onlosmakelijk met elkaar verbonden zijn (vandaar dat er bijna altijd aan gerefereerd wordt als TCP/IP). In feite zijn het verschillende laagjes: ethernet frames bevatten IP-packets, en dat bevat dan weer TCP segments. Layers 2, 3 en 4 van het OSI-model achtereenvolgens. (meer info: http://en.wikipedia.org/wiki/OSI_model)

[ Voor 15% gewijzigd door CyBeR op 13-02-2006 00:34 ]

All my posts are provided as-is. They come with NO WARRANTY at all.

Acties:

Verwijderd

Fijn dat cyber het OSI-model aanhaalt.

IP = Laag 3.
MAC= Laag 2.

Laag 3 kan voor routering zorgen, dus netwerken scheiden enz, NAT dus alle maal heel cool.

Laag 2 kan dus niet scheiden, wat gebeurd er dus als we allemaal MAC-adressen zouden gebruiken. Iedereen zou in het zelfde netwerk moeten zitten en met miljarden pc's op de wereld lijkt mij dat niet zo handig. want alle broodkast (broadcast) zal dan langs iedereen gaan, dus dat gaat nooit werken.

Alternatieven voor ip??? Ja hoor, IPX!!! Mijn all time favourite, maar dat is alleen omdat ik graag tegenhangers van main stream dingen zie. Want ip is cool, en IPX niet. Dan heb je nog CLNP wat ook cool is, en nog wel gebruikt ook (niet door pc's) maar goed. Jij kent het niet, en dat is niet voor niks, ip heeft zich bewezen. klaar.

maandag 13 februari 2006 09:55

Acties:

Meester_J

de makkelijkste reden:

ip deelt het internet in logische stukken op, mac adressen niet.
je gaat het telefoonboek toch ook niet op straatnaam sorteren?

maandag 13 februari 2006 11:18

Acties:

Grolsch

een MAC adres is geen protocol, zoals eerder verteld. MAC is ook niet routeerbaar, daarom heeft men IP adressen uitgevonden.

Ook lijkt het mij administratief niet te beheren, omdat een MAC adres is gekoppelt aan netwerk kaart, IP adressen worden normaal gesproken uitgedeelt door een DHCP server

[ Voor 42% gewijzigd door Grolsch op 13-02-2006 11:19 ]

PVOUPUT - 13.400WP - Twente

maandag 13 februari 2006 11:34

Acties:

Verwijderd

mac is fysiek adres...

tcp/ip is gewoon het prototcol dat word gebruikt.... manier van opbouwen van verbindingen enz... tcp/ip is een slimme verbinding die zelf de kortste weg zoekt.. .controleert of data ook aan komt enz....

paar semestertjes cisco en dan word t wel redelijk duidelijk

maandag 13 februari 2006 11:40

Acties:

Me_dusa

Red een boom, eet een bever!

Grolsch schreef op maandag 13 februari 2006 @ 11:18:
snip...er

offtopic:
Zo, nu eerst een Bavaria

(sorry kon het niet laten)

Me_dusa

maandag 13 februari 2006 11:52

Acties:

Verwijderd

Een router met een volledige Internet routing tabel heeft op dit moment zo'n 120 000 routes. Daar heb je al een redelijk zware router voor nodig (een doorsnee Cisco 2600 trekt het niet), een routingtabel van MAC adressen zou meer dan 100 000 000 adressen bevatten.

In het kort: IP adressen kan je summarizen, MAC adressen niet.

maandag 13 februari 2006 13:21

Acties:

Kabouterplop01

chown -R me base:all

leuk_he schreef op zondag 12 februari 2006 @ 21:48:
in ipv6 is je mac (mogelijk) een deel van het ip adres, dus eingenlijk is het niet zo'n slecht idee van de ts. Alleen was men in de beginjaren van internet nogal zuinig op elke byte. Die moeten namelijk in allerlei tablelen worden opgeneomen en daar wou je zuinig aan mee doen.

Nou zuinig.... Ze hebben bij het ontwerpen in ieder geval geen rekening gehouden met het feit dat er zoveel ip adressen gebruikt gingen worden. Kijk maar eens naar dit IP adres: ( en de eigenlijke range die erbij hoort ) 127.0.0.0. Dit zijn toch aardig wat hosts in een netwerk als de hele range wordt benut.

maandag 13 februari 2006 14:08

Acties:

maandag 13 februari 2006 15:54

1. Controleer de kabel!

Kabouterplop01 schreef op maandag 13 februari 2006 @ 13:21:
[...]

Nou zuinig.... Ze hebben bij het ontwerpen in ieder geval geen rekening gehouden met het feit dat er zoveel ip adressen gebruikt gingen worden. Kijk maar eens naar dit IP adres: ( en de eigenlijke range die erbij hoort ) 127.0.0.0. Dit zijn toch aardig wat hosts in een netwerk als de hele range wordt benut.

Ze zijn niet zuinig geweest met het uitdelen van de ranges. dat is wat anders. Er zijn tenslotte ook heel wat grote ranges teruggeneomen. Maar met de bytes in een packet is met uitermate zuinig geweest. 4 bytes voor een adres.

Aan de ander kant was 4 bytes weer uitermate royaal. Vroege versies van ipx & netbios hadden geen ruimte om computers buiten het eigen lan te adresseren. Dat is juist hetgeen dat tcp/ip zo populair gemaakt heeft.

PS,

probeer ook eens ping 127.3.78.3 op je XP computer

is weer eens wat anders als 127.0.0.1

Need more data. We want your specs. Ik ben ook maar dom. anders: forum, ff reggen, ff topic maken
En als je een oplossing hebt gevonden laat het ook ujb ff in dit topic horen.

Acties:

maandag 13 februari 2006 17:16

Security is not an option!

leuk_he schreef op maandag 13 februari 2006 @ 14:08:
probeer ook eens ping 127.3.78.3 op je XP computer is weer eens wat anders als 127.0.0.1

dat is een undocumented feature, die je jezelf niet moet aanleren. behalve winxp reageert er namelijk helemaal niemand op dat adres...

Het belangrijkste punt waarom we IP gebruiken is dat een ip adres ruimte bied om zowel het netwerk als de individuele host te adresseren. Hierdoor hoeft niet voor elk systeem een route bijgehouden te worden, maar kunnen groepen met hosts bijeen gepakt worden.

Denk even 1973. Iedereen draait NCP. Je had de keuze uit het draadje en de host waarop de IMP verzond. Volgens sommige mensen kon het zo niet langer (kahn en cerf) en die hebben toen tcp/ip bedacht. een onlosmakelijk aan elkaar verbonden protocol suite voor het adresseren van interfaces (let wel, GEEN nodes) op een wereldomvattend netwerk. Het moest dus vooral scalable en resillient zijn.

over het verspillen van de 127.0.0.0/8 range: ze hadden bij de verdeling van het host/network portion bedacht hoeveel netwerken er nodig zouden zijn. 1 voor DoD, 1 voor AT&T, 1 voor europa, 1 voor azie, 1 voor test. Zelfs al zou je alles dubbel uit willen voeren, ze kwamen never nooit niet op de 255 netwerken die ze beschikbaar hadden. Het verbruik van IP adressen was dus niet echt een issue.

Overigens is 30% van de adres space nog steeds beschikbaar, dus we hoeven echt niet overhaast op ipv6 over te stappen...

Opbrengst van mijn Tibber Homevolt met externe kWh meter. | Opbrengst van mijn Tibber Homevolt volgens de Tibber Data API.

Acties:

Legio947

Topicstarter

Nu zie ik het nut van IP-adressen wel in. Nog een extra vraagje over de werking ervan, dit komt nogal tegenstrijdig over als ik hier voorgaande posts lees.

Een pc zou een interne routeringstabel hebben met alle deelnemers van het netwerk erin. Maar hoe weet een PC nu wie er allemaal op het netwerk aangesloten is? Bij grote netwerken doet een pc toch geen volledige scan telkens als hij opstart? Zo een tabel zou het nut van ARP pakketten toch teniet doen?

Een router zou een bepaalde request direct naar het juiste netwerk sturen (met behulp van de IP-domain nummers). Maar als er nu een router is die 2 netwerken aan elkaar linkt (Net1 en Net2). En aan Net2 hangen nog ergens 40 routers die Net2 met andere netwerken verbinden (dus niet 1 gateway, maar meerdere, of kan dit niet?). Hoe weet die router dan langs waar het pakket gezonden moet worden? Er moeten toch op een of andere manier eens broadcasts verzonden worden tot bij het doel?

maandag 13 februari 2006 17:29

Acties:

Kabouterplop01

chown -R me base:all

Via routeringsprocollen, die zijn er spciaal op gebouwd om alleen maar te weten waar welk netwerk zich bevindt, en wat de snelste weg is er naar toe, of wat de meest "betrouwbare" weg is.

[ Voor 5% gewijzigd door Kabouterplop01 op 13-02-2006 17:35 ]

maandag 13 februari 2006 17:55

Acties:

maandag 13 februari 2006 17:57

Security is not an option!

Daarvoor heb je het netmask.

als (dst ip XOR netmask) != (eigen ip XOR netmask) dan is het doel systeem niet direct benaderbaar, en zal het in de routetabel kijken wat de next hop is voor het betreffende netwerk (dst ip XOR netmask dus). Vaak zal dit een route naar je default gateway zijn. De router zorgt vervolgens voor de afhandeling van het pakket.

In het geval dat (dst ip XOR netmask) == (eigen ip XOR netmask), dan weet het systeem dat de doelhost zich in het zelfde netwerk bevind. Vervolgens zal deze een ARP request uitvoeren, met als inhoud: Ik zoek het mac adres van 'dst-ip', antwoord aan 'eigen-ip'. Deze wordt gezonden aan het broadcast adres. Nu zal het systeem met dst-ip antwoorden met daarin het mac adres. Vervolgens zal de data verstuurd worden naar het mac adres van de doelhost. In een netwerk heeft het IP adres dus ook minder relevantie als het mac adres.

[ Voor 3% gewijzigd door JackBol op 13-02-2006 17:56 ]

Opbrengst van mijn Tibber Homevolt met externe kWh meter. | Opbrengst van mijn Tibber Homevolt volgens de Tibber Data API.

Acties:

maandag 13 februari 2006 17:59

💩

Legio schreef op maandag 13 februari 2006 @ 17:16:
Nu zie ik het nut van IP-adressen wel in. Nog een extra vraagje over de werking ervan, dit komt nogal tegenstrijdig over als ik hier voorgaande posts lees.

Een pc zou een interne routeringstabel hebben met alle deelnemers van het netwerk erin. Maar hoe weet een PC nu wie er allemaal op het netwerk aangesloten is? Bij grote netwerken doet een pc toch geen volledige scan telkens als hij opstart? Zo een tabel zou het nut van ARP pakketten toch teniet doen?

Die tabel is vrij simpel. Stel je hebt je nic ingesteld met 10.1.2.3/255.255.255.0. Dat houdt dan in dat 10.1.2.0 tot en met 10.1.2.255 tot jouw netwerk behoren. Dus als jij iets wilt doen met 10.1.2.60 weet jouw computer 'ah, direct aangesloten op mijn netwerk.' en zoekt 'ie het MAC-adres op in z'n ARP-tabel (die bestaat als een cache zodat je niet voor elke packet dat adres moet opzoeken). Als 'ie daar niet instaat stuurt 'ie eerst een ARP-request om dat MAC-adres te achterhalen.

Een router zou een bepaalde request direct naar het juiste netwerk sturen (met behulp van de IP-domain nummers). Maar als er nu een router is die 2 netwerken aan elkaar linkt (Net1 en Net2). En aan Net2 hangen nog ergens 40 routers die Net2 met andere netwerken verbinden (dus niet 1 gateway, maar meerdere, of kan dit niet?). Hoe weet die router dan langs waar het pakket gezonden moet worden? Er moeten toch op een of andere manier eens broadcasts verzonden worden tot bij het doel?

Neuh. Routers werken op laag 3 van het OSI-model en checken dus alleen IP-adressen. Zij hebben MAC-adressen alleen nodig om een eventuele met ethernet-aangesloten volgende router te bereiken. Routers onderling wisselen met een protocol dat BGP heet hun routetabellen uit, zodat ze allemaal weten welke netwerken bestaan en wat de route er naartoe is.

All my posts are provided as-is. They come with NO WARRANTY at all.

Acties:

Verwijderd

Legio schreef op maandag 13 februari 2006 @ 17:16:
Nu zie ik het nut van IP-adressen wel in. Nog een extra vraagje over de werking ervan, dit komt nogal tegenstrijdig over als ik hier voorgaande posts lees.

Een pc zou een interne routeringstabel hebben met alle deelnemers van het netwerk erin. Maar hoe weet een PC nu wie er allemaal op het netwerk aangesloten is? Bij grote netwerken doet een pc toch geen volledige scan telkens als hij opstart? Zo een tabel zou het nut van ARP pakketten toch teniet doen?

Een router zou een bepaalde request direct naar het juiste netwerk sturen (met behulp van de IP-domain nummers). Maar als er nu een router is die 2 netwerken aan elkaar linkt (Net1 en Net2). En aan Net2 hangen nog ergens 40 routers die Net2 met andere netwerken verbinden (dus niet 1 gateway, maar meerdere, of kan dit niet?). Hoe weet die router dan langs waar het pakket gezonden moet worden? Er moeten toch op een of andere manier eens broadcasts verzonden worden tot bij het doel?

een pc heeft geen routeringstabel van alle deelnemers, versimpeld maar 2...
0.0.0.0 naar default gateway (alles naar je gateway)
192.168.1.x mask 255.255.255.0 naar je eigen interface (het subnet waar je inzit is "directly connected")

op het moment dat je naar een host in je eigen subnet iets wil sturen zal je met arp het mac address achterhalen van die machine. dus translatie ip naar mac. mac address wordt dan gebruikt voor de fysieke verzending van het pakketje.

op het moment dat je connect naar een host buiten je eigen netwerk, resolve je met arp niet het mac adres van die host, maar van je default gateway. je stuur een pakketje naar het mac adres van je default gateway, en je gateway stuurt dit weer door naar het mac adres van de volgende router, net zolang totdat je aangekomen bent in het subnet waar de host staat. Pas dan zal de router, die in dat segment staat met arp het mac adres van die host ophalen.

dus source/dest mac adressen veranderen met elke hop in de header van een pakketje, maar het source en dest ip niet...

en verwar arp (mac-ip translatie) ook niet met nameresolving (dns/wins/netbios; oftewel naam-ip translatie)

maandag 13 februari 2006 18:02

Acties:

maandag 13 februari 2006 18:03

1. Controleer de kabel!

Dirk-Jan schreef op maandag 13 februari 2006 @ 15:54:
Overigens is 30% van de adres space nog steeds beschikbaar, dus we hoeven echt niet overhaast op ipv6 over te stappen...

Het feit dat je thuis met moeite maar 1 semi-vast ip adres kunt krijgen en de rest via nat moet oplossen geeft aan dat ip adressen wel delgelijkop aan het raken zijn.

Legio schreef op maandag 13 februari 2006 @ 17:16:
Een pc zou een interne routeringstabel hebben met alle deelnemers van het netwerk erin. Maar hoe weet een PC nu wie er allemaal op het netwerk aangesloten is? Bij grote netwerken doet een pc toch geen volledige scan telkens als hij opstart? Zo een tabel zou het nut van ARP pakketten toch teniet doen?

Alleen Jouw netwerk, wat er achter de router zit weet jouw pc niet meer.

. Hoe weet die router dan langs waar het pakket gezonden moet worden? Er moeten toch op een of andere manier eens broadcasts verzonden worden tot bij het doel?

Ligt aan de instellingen va de routers. Gedeeltelijk is dit vast ingesteld in routers en gedeeeltelijk zijn er protocollen die vertellen wat iva welke routes moet. Maar dar verdienen gewoon veel mensen hun brood mee om dit goed te regelen.

Need more data. We want your specs. Ik ben ook maar dom. anders: forum, ff reggen, ff topic maken
En als je een oplossing hebt gevonden laat het ook ujb ff in dit topic horen.

Acties:

Fat Baba

daarom is er ook ip6
ip4 in ontworpen voor 1980 ofzo, er werdt toen nooit gedacht aan een groot internet

maandag 13 februari 2006 18:16

Acties:

maandag 13 februari 2006 23:09

Security is not an option!

leuk_he schreef op maandag 13 februari 2006 @ 18:02:
Het feit dat je thuis met moeite maar 1 semi-vast ip adres kunt krijgen en de rest via nat moet oplossen geeft aan dat ip adressen wel delgelijkop aan het raken zijn.

moah, ze zijn gewoon conservatief met uitdelen. Okay, voor de meer eisende thuisgebruiker is het lastig, maar voor 99% van de mensen voldoet het. Nu switchen naar ipv6 levert meer problemen op dan 10 jaar doorkabbelen met vieze oplossingen zoals (te) kleine DHCP ranges en NAT oplossingen en dan switchen. Maar als je een location vs endpoint discussie wilt voeren, moet je maar ff een ander topic openen.

Fat Baba schreef op maandag 13 februari 2006 @ 18:03:
daarom is er ook ip6
ip4 in ontworpen voor 1980 ofzo, er werdt toen nooit gedacht aan een groot internet

ipv4 ontworpen: 1973
ipv4 geimplementeerd: 1982 (the great switch)

jon postel: "we will only do this once"... hij had gelijk. nu kunnen we lekker dual-stacken en rustig migreren tussen ipv4 en ipv6. Als dadelijk Vista full fledged ipv6 support heeft, kunnen isps er ook over gaan nadenken om live ipv6 aan te bieden zonder tunnelconstructies.

Opbrengst van mijn Tibber Homevolt met externe kWh meter. | Opbrengst van mijn Tibber Homevolt volgens de Tibber Data API.

Acties:

woensdag 15 februari 2006 16:30

1. Controleer de kabel!

Dirk-Jan schreef op maandag 13 februari 2006 @ 18:16:
[...]
Maar als je een location vs endpoint discussie wilt voeren, moet je maar ff een ander topic openen.

Geen fauw idee waar dat over gaat zonder die termen te googlen. Dus ik heb niet een genoeg kennis om een topic daarover te openen. Maar wellicht wil je hier zelf nog een leuk verhaal plaatsen

Need more data. We want your specs. Ik ben ook maar dom. anders: forum, ff reggen, ff topic maken
En als je een oplossing hebt gevonden laat het ook ujb ff in dit topic horen.

Acties:

Verwijderd

Dirk-Jan schreef op maandag 13 februari 2006 @ 17:55:
Daarvoor heb je het netmask.

als (dst ip XOR netmask) != (eigen ip XOR netmask) dan is het doel systeem niet direct benaderbaar, en zal het in de routetabel kijken wat de next hop is voor het betreffende netwerk (dst ip XOR netmask dus).

Correct, behalve dat het niet XOR maar AND is.

(local ip AND netmask) = local network, (dst ip AND netmask) = dst network;
als local network = dst network --> dst ip bevindt zich op het local network.

1 XOR 1 = 0 - 1 AND 1 = 1
1 XOR 0 = 1 - 1 AND 0 = 0
0 XOR 1 = 1 - 0 AND 1 = 0
0 XOR 0 = 0 - 0 AND 0 = 0

woensdag 15 februari 2006 17:02

Acties: