Gå til innhold

Hvordan fungerer IPv4 og IPv6 i et hjemmenettverk?


Anbefalte innlegg

Jeg har kjørende en dual stack IPv4 og IPv6 i hjemmenettverket. Spørsmålet er så: Hvordan fungerer dette og hvordan leser man disse konfigureringsdataene? 

# ipconfig /all

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek RTL8294EU Wireless LAN 802.11n USB 2.0 Network Adapter
   Physical Address. . . . . . . . . : 00-E0-4C-53-DB-44
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2a05:9cc3:57:6f2f:2e24:e4ee:ca04:fce5(Preferred)
   Temporary IPv6 Address. . . . . . : 2a05:9cc3:57:6f2f:bcd3:f43a:de4b:4fd(Preferred)
   Link-local IPv6 Address . . . . . : fe80::dcc2:de4b:12a7:c5e2%8(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.1.119(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Wednesday, January 15, 2023 9:07:52 AM
   Lease Expires . . . . . . . . . . : Wednesday, January 15, 2023 11:07:52 AM
   Default Gateway . . . . . . . . . : fe80::9482:88ff:fea9:1b4d%8
                   	                   192.168.1.1
   DHCP Server . . . . . . . . . . . : 192.168.1.1
   DHCPv6 IAID . . . . . . . . . . . : 721477601
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-27-74-DA-C6-EC-8E-A5-4D-3D-64
   DNS Servers . . . . . . . . . . . : 2a05:9cc3:f000:1::4
                            		   2a05:9cc4:f000:1::4
                                       192.168.0.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Nettverket er satt opp med "dual stack" konfigurering med automatisk tildeling av adresser for IPv4 og IPv6. (Dataene er forandret litt på for å oppnå anonymisering, men prinsippene skal fortsatt være der.)

Nettverkskortet har en IPv4 adresse og 3 stk IPv6 adresser. Hvorfor er det 3 samtidige Ipv6 adresser? Hva skal de brukes til? Hvordan skjer den automatiske tildelingen av adresser i IPv4 og IPv6? Er det noen sikkerhetsmessige problemstillinger ute og går?

Hensikten med tråden er å få til en mest mulig lettfattelig forklaring på hvordan IPv4/IPv6 dual stack fungerer i et hjemmedatanettverk. Det er absolutt tillatt og anbefalt å stille utdypende spørsmål.

Endret av arne22
Lenke til kommentar
Videoannonse
Annonse
13 minutes ago, NULL said:

Det du lurer på, litt oppsummert, er hva "Link-local IPv6 Address" og "Temporary IPv6 Address" er/brukes til?

Tja, "personen jeg" vet nok egentlig det det nå. (Tror jeg da..) Tanken var å få opp en tråd der "folk flest" kan få et kjapt overblikk over hvordan dual stack IPv4/Ipv6 fungerer, eventuell sikkerhetsrissiko, funksjonelle egenskaper osv.   

En forklaring på "Link-local IPv6 Address" og "Temporary IPv6 Address", hvor disse adressene kommer fra og hva de brukes til, ville nok kunne være en god start.  Ville ellers tro at "IPv6 address" med tilhørende "funksjoner for automatisk tildeling" hører med i den samme problemstillingen. 

Har lært meg disse tingene ganske nylig og det kan vel også være ting som jeg fortsatt tar feil av.

Som sagt: Litt oppsummering generell teknisk oppklaring, fra andre enn meg, det ville nok være meget bra.

 

Endret av arne22
Lenke til kommentar

Kort forklart slik jeg husker det/forstår det:
Ttemporary ipv6 address er en auto-generert (SLAAC) adresse. Denne kan "inneholde" (dvs. delvis baseres på) mac-adr. For å forhindre "gjenkjenning" av mac på tvers av nettverk (for enheter som flytter seg) så finnes "privacy-extension" som lager relativt kortvarige "midlertidige" SLAAC-adresser som ikke baseres på mac. Etterhvert som denne midlertidige adressen nærmer seg "levetiden" lager maskinen en ny midlertidig adresse mens den forrige midlertidige adressen fortsetter å eksistere en stund til, men merkes som "deprecated", slik at evt. trafikk tilbake til denne adressen også kan mottas. Er ikke "privacy-extension" aktivert, finnes typisk kun én temporary adresse som ikke endrer seg underveis.

Link-local er, som nevnt i andre tråder, noe tilsvarende 169.254.0.0/16 med den forskjellen at der ipv4 normalt kun auto-genererer en 169.254-adresse dersom den ikke får ip på andre måter, vil ipv6 alltid ha en auto-generert link-local adresse for hvert nettverkskort (interface), ofte baser på mac-adr. til interfacet. Link-local adressen brukes bl.a. til å motta info om prefix, gateway-ip, dns, om dhcpv6 er tilgjengelig, sjekke om auto-genererte adresser er ledig og til routing (du ser default gateway for ipv6 er en link-local adresse). Siden hvert interface har en link-local adresse er det også en "zone index" for hver av disse, angitt med %<indeks> etter ip'en, for å eksplisitt spesifisere hvilket interface en pakke skal sendes ut via i tilfelle tvetydighet i routing-tabellen.
Link-local adresser har prefix fe80 og network/subnett id 0, slik at alle interface vil ha fe80::/64 som "nettverk id", derfor zone index for å spesifisere hvilket interface, siden det ikke "automatisk" kan avgjøres hvilken link en annen adresse, f.eks. fe80::1234:5678:9abc:def0, befinner seg på. Windows bruker interface nummer som zone index, mens *nix-varianter ofte bruker interface navn.

Merk at det ikke vil vises noen dhcp-server adresse for ipv6, siden dette fungerer forskjellig fra ipv4. For å motta info fra dhcpv6 brukes link-local og multicast. Klienten sender ut forespørsel via sin(e) link-local adresse(r) til multicast ff02::1:2, og serveren svarer tilbake til klientens link-local. Derfor trenger ikke klienten å huske/vite hvilken adresse en dhcpv6-server har.
Dhcpv6 client DUID  brukes av serveren til å tildele en adresse, og er også den som evt. ip reserveres på (tilsvarende mac-adr. med dhcpv4).

Og en kan ha både stateless (SLAAC) og stateful (typisk dhcpv6) adresser samtidig.

Tror dette er sånn noenlunde korrekt 🤓

Wikipedia har mye god info på ipv6, begynn f.eks. her: https://en.wikipedia.org/wiki/IPv6_address

Endret av HawP
Lenke til kommentar

Meget bra! Og, ja vi bør alltid legge referanser til hvor vi har hentet opplysningene, slik at man kan etterprøve. Det er noen detaljer i innlegget over som jeg ikke har fått med meg tidligere og som jeg vil se litt nærmere på. Poster litt om det etterpå. Ettersom det var snakk om å se på "forskjellene", så tar jeg først litt om IPv4 som har fungert stort sett likt gjennom de siste 30 årene, eller mer enn det.

Nettverkskortet over er konfigurert både for IPv4 og for IPv6.

IPv4 Kort fortalt:

For konfigurering til IPv4 på et lokalnettverk, bak en NAT ruter, så behøves i utgangspunktet bare disse opplysningene:

  1. En lokal IP-Adresse, typisk format 192.168.0.11
  2. En lokal gateway adressem typisk format: 192.168.0.1, med tilhørende nettverksmaske, typisk format 255.255.255.0
  3. En adresse til en DNS server som sørger for å "oversette" globale IPv4 adresser til domenenavn, for eksempel vg.no

Det er det hele og det er hele den konfigureringen som i utgangspunktet er nødvendig for å å få et IPv4 nettverkskort til å fungere.

De tre "settene" med konfigureringsdata kan settes opp manuelt, eller automatisk vha en DHCP server som kjører på lan.

Visse nummerserier av ip adresser er reservert for "internt bruk" ut i fra internasjonal standard. I et NAT nettverk, så kan man bruke de samme lokale adressene i mange lokale nettverk, uten å tenke på hvordan naboen bruker de samme adressene.

Når man kommuniserer ut mot Intetnett så er adressen til PC, anonymisert gjennom bruken av en NAT router. Når man bruker CGNAT så skjer denne anonymiseringen 2 ganger. For et ordinært IPv4 lokalnett med en NAT router så er det mulig å gi tilgang til PC'er inne på LAN (lokalnettet) gjennom bruk av "portforwarding". For CGNAT så er dette ikke praktisk mulig, på grunn av at man bruker 2 eller flere NAT routere koblet i serie.

Når man skal scanne et IPv4 lokalnett utenfra for å se hvilke "veier inn i nettverket" som en hacker kan benytte seg av, så holder det men en enkel scanning av en enkelt IP adresse (nettverkets globale adresse), så har man oversikt over "åpne porter" på hele nettverket. (Men man kan selvfølgelig bruke mange forskjellige typer avanserte scanninger mot den ene globale IP'en.)  

Jeg forsøkte å google litt på det som går på scanning av global IP adresse, men jeg fant egentlig ikke så mye. Har alltid scannet mine egne IP adresser gjennom alle år. Fant noe info hos Nordvpn, som jo egentlig er en reklameside, så man bør vel ta opplysningene med en "stor klype salt", men inntil en bedre beskrivelse av det som går på risiko rundt global IP adresse er funnet, så legger jeg ut link til opplysningene hos Nordvpn.  (Selv om det vel til dels er litt feil og unøyaktigheter i disse opplysningene, så er det jo også beskrevet en del riktige prinsipper.)

Her er ellers en ekstern portscanner som jeg har brukt gjennom mange år til å scanne mine IPv4 hjemmedatanettverk, når jeg ikke har tatt med brydderiet med å logge inn på en ekstern server for scanning.

https://www.grc.com/faq-shieldsup.htm (Velg fra menyen under Sevices, ShiledsUp)

ShieldsUp ser ut til å bare fungere i forhold til IPv4. Denne ser ut til å kunne scanne en og en IPv6 port.

Jeg fant en nettside som jeg synes gir en ganske grei oversikt over "TCP/IP slik som vi lærte det i gamle dager". Selv om nettsiden kanskje inneholder noen opplysninger som er litt "gammeldagse" (inndeling i klasser), så blir de prinsippene som beskrives allikevel "gode nok" for å forstå de grunnleggende forskjellene mellom IPv4 og IPv6. Inntil noen kommer opp med en bedre referanse så bruker jeg denne:

https://estudie.no/tcp-ip/

Og så en annen nettside:

CCNA Routing an switching

 

 

 

Endret av arne22
Lenke til kommentar

Her kommer en post med en mest mulig presis, etterprøvbar og lett forståelig beskrivelse av hvordan IPv6 fungerer i forhold til et hjemmedatanettverk. Her kommer det forhåpentligvis tilbakemeldinger slik at feil og unøyaktigheter kan rettes opp.

IPv6 Kort fortalt.

I eksemplet over så er konfigureringsdata for IPv6 disse dataene:

IPv6 Address. . . . . . . . . . . : 2a05:9cc3:57:6f2f:2e24:e4ee:ca04:fce5(Preferred)
Temporary IPv6 Address. . . . . . : 2a05:9cc3:57:6f2f:bcd3:f43a:de4b:4fd(Preferred)
Link-local IPv6 Address . . . . . : fe80::dcc2:de4b:12a7:c5e2%8(Preferred)
Default Gateway . . . . . . . . . : fe80::9482:88ff:fea9:1b4d%8
DHCPv6 IAID . . . . . . . . . . . : 721477601
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-27-74-DA-C6-EC-8E-A5-4D-3D-64
DNS Servers . . . . . . . . . . . : 2a05:9cc3:f000:1::4
                            		2a05:9cc4:f000:1::4

Alle dataene har blitt konfigurert og satt opp automatisk. Hva betyr så disse dataene, hvordan har de blitt tildelt, og har disse dataene noen sikkerhetsmessig betydning?

  • IPv6 Address. Dette PC'ens globale adresse som den kan bruke til å kommunisere ut mot Internett. For mitt modem så ser det ut til at det ikke finnes noen IPv6 brannmur, slik at alle som jeg kommuniserer mot på Internett ved hjelp av denne adressen, kan se hva adressen er, slik at de har mulighet til portscan og angrep. IPv6 adressen er i dette tilfellet satt opp automatisk. Det er to kjente og forholdsvis vanlige metoder for automatisk oppsett av IPv6 adresse.  Det er Stateless Address Autoconfiguration (SLAAC) og DHCPv6. Ved førstnevnte metode SLAAC så setter nettverkskortet adressen selv, ut i fra en forespørsel til omgivelsene. Ved andre metode DHCPv6 til tildeles nettverkskortet en adresse fra en DHCPv6 server. Det finnes også en metode som ser ut til å være en variant av DHCP6 som heter DHCPv6 Prefix Delegation. Det er også mulig å legge inn IPv6 addressen manuelt, men det forutsetter at man får tildelt og opplyst en globalt routbar adresse fra ISP. Det ser ellers ut til å finnes litt forskjellige varianter av disse automatiske rutinene. Det kan se ut som at IPv6 adressen ikke inneholder MAC addressen, men at MAC addressen (vanligvis?) brukes som grunndata for å produsere IPv6 adressen.
     
  • Temporary IPv6 address. Disse er ment å skulle være midlertidig og å skifte over tid. Dersom PC bruker de midlertidige IPv6 adressene til å kommunisere ut mot Internett, så vil en hacker i forholdvis mindre grad kunne bygge opp kunnskap om hva som ligger inne på LAN over tid. Temporary IPv6 address  kan genereres ut i fra de samme hovedprinsipper som gjelder for "IPv6 address", men det fungerer ikke helt likt. Man bruker allikevel SLAAC og DHCPv6 som hovedprinsipp for å tildele eller å fordele disse midlertidige adressene. Typisk levetid for en "Temporary IPv6 address" ser ut til å være fra 1-7 dager, slik at en hacker vil kunne ha rimelig god tid. Hvis man vil finne ut av konfigurert levetid for "Temporary IPv6 address" på en Windows PC, så må man først installere PowerShell og så kan man kjøre kommando " Get-NetIPv6Protocol | select * ". (Det kan se ut som at levetiden er 7 dager på min PC.) "IPv6 Address" og "Temporary IPv6 Address" er begge globale addresser som er rutbare til/fra Internett og som kan brukes til hackerens angrep mot egen PC. (Hvis det ikke finnes en brannmur som er satt opp for å forhindre dette.) Begge disse to typer adresser kan brukes kan brukes av egen PC til å kommunisere ut mot Internett. Om det er den ene eller den andre adresse som brukes kommer an på PC'ens konfigurering. I dette tilfellet så finnes det bare en slik "Temporary IPv6 Address", men det skal også være mulig å ha en automatisk konfigurering med mange slike "Temporary IPv6 Address'er"  
  • Link-local IPv6 Address. Denne ser ut til å genereres av operativsystemet selv på basis av MAC adressen. Denne adressen skal kunne kommunisere inne på lokalnettet, men den er ikke rutbar over Internett. Prefikset "fe80" skal indikere at der er en link-local adresse.

  • Default Gateway. Denne adressen er jo "veien ut til Internett" for PC'ene inne på LAN. Adressen begynner jo på "fe80" likt med en "link local adresse, og hvorfor det er slik, er foreløpig ukjent. Gatewau adresen er i dette tilfellet satt opp automatisk. 

  • DHCPv6 IAID. Dette skal være en "Identity Association Identifier"  som er en "unique 32-bit identifier" som DHCPv6 serveren bruker i forbindelse med sin funksjon. Det ser ut som at denne settes av serveren.

  • DHCPv6 Client DUID (Client Device Identifier) Denne ser også ut til å være en nødvendig "identifikator" for DHCPv6 serveren som settes av klienten selv. 

Denne kommandoen: "netsh interface ipv6 show address" indikerer at både "IPv6 adressen" og "Temporary IPv6 address" er satt i regi av ISP og bruk av DHCPv6 ved at begge adressene står ført opp med en "levetid" på ca 1 døgn. De metodene som Microsoft beskriver for å få tildelt flere "Temporary IPv6 address'er" fungerer ikke og jeg gjetter på at dette skyldes at DHCPv6 server overstyrer det som ellers ville ha skjedd i regi av SLAAC.  

Edit: Jeg forsøker å forenkle og utelater litt på detaljnivå for å få fram hovedprinsippene. Tilbakemeldinger og koreksjoner mottas med takk.

Endret av arne22
Lenke til kommentar

Bare sånn når det gjelder skanning - du er kjent med tjenester som Shodan, Censys o.l.? Hvis man er på jakt etter IP-er med spesifikke tjenester, kan det være langt mer effektivt å søke de opp hos de som allerede har gjort det  enn å skanne seg fram til dem...

Lenke til kommentar
4 hours ago, NULL said:

Bare sånn når det gjelder skanning

Takker for info! Hvis man scanner andre så gjør man jo fort noe ulovlig. Tanken var nok bare å scanne seg selv, for å se hva man har kjørende åpent mot internett, slik at man kan angripes av andre, gjennom "åpne porter". På typiske webservere, så hagler det jo på med hundrevis og tusenvis av angrep, hvis man åpner feil port. 

Edit:

Testet med Shodan og Censys mot egen server akkurat nå. Fikk ikke fram så mye på Shodan, men på Censys så kom det faktisk fram mer enn det jeg hadde trodd. Takk for tips 🙂 (En åpen port av det litt robuste slaget, som jeg trodde ingen ville legge merke til, men den stenges nå, selv om den er robust.)

Edit: Testet Sensys mot nyåpnet port på lokal Windows maskin. Synlig vha online IPv6 portscan, men ikke synlig hos Sensys. (Som forventet.) Kunne der imot gi navn på ISP og forholdsvis nøyaktig geografisk plassering av IPv6 adresse. Det ser ut som at det er 0,0 sikkerhet i dette modemet når man kjører IPv6, mens at sikkerheten er OK for IPv4. 

Endret av arne22
Lenke til kommentar

Nå er det lenge siden jeg har brukt Censys, og vet ikke hvordan utviklingen har vært. Når det gjelder Skodan og den vanlige indeksen, så vil det jo ikke være sanntidsinformasjon. Hvor ofte Skodan "kjører forbi" har jeg ikke sjekket - mulig de oppgir hvor ofte de sveiper gjennom hele IPv4-adresseområdet og potensielt gjør de det vel oftere på noen porter enn andre.

Ulovlig er det heller ikke... tar man en titt i loggene, vil man gjerne finne en rekke tjenester som identifiserer direkte at det er de de gjør. For noen minutter siden her, så hadde en tjeneste jeg har oppe å gå besøk av Palo Alto Networks sin tjeneste:

Quote

/var/log/apache2# grep -i ipv4 access.log.1

205.210.31.17 - - [27/Jan/2023:23:29:54 +0100] "GET / HTTP/1.0" 200 40763 "-" "Expanse, a Palo Alto Networks company, searches across the global IPv4 space multiple times per day to identify customers&#39; presences on the Internet. If you would like to be excluded from our scans, please send IP addresses/domains to: [email protected]"

Finnes sikkert flere slike tjenester som jeg ikke kjenner til. Og noen er kanskje mer "undergrunn" eller interne.

Lenke til kommentar

Betalkonto hos Shodan gir en del ekstra muligheter med filter etc. Ikke sjekket hva det koster nå, men tenker at "Life-time"-aboet jeg vel kjøpte for 5 dollar eller hva det nå var i 2012 eller noe slikt var en god investering. 😉. Tror det har blitt en del dyrere etter hvert.

Lenke til kommentar
3 minutes ago, NULL said:

Ulovlig er det heller ikke..

I Norge så finnes det jo en Høyestrettsdom på dette fra tidenes morgen, da en ansatt hos Normann Data Defence Systems AS satt og tastet inn ip-addresser og portnummer manuelt, ett og ett mot UiO. Han ble jo frikjent for denne "scanningen", så i Norge er det jo egentlig lov ja. Litt usikker på enkelte utland. Regner imidlertid alt som kan være til irritasjon eller sjenanse som "ulovlig", selv om det kanskje ikke er det.    

Lenke til kommentar
8 hours ago, arne22 said:

Default Gateway. Denne adressen er jo "veien ut til Internett" for PC'ene inne på LAN. Adressen begynner jo på "fe80" likt med en "link local adresse, og hvorfor det er slik, er foreløpig ukjent.

Det er vel ganske opplagt?  Om ikke default gateway var tilgjengelig ditt lokale nett, ville du jo trenge en gateway for å nå den...   - og at man bruker fe80:: er en ganske opplagt løsning siden alle enheter på et IPv6-nett vil få en slik adresse. 

Lenke til kommentar
23 hours ago, HawP said:

Tror dette er sånn noenlunde korrekt 🤓

HawP. Gidder du å ta en kikk på det jeg har notert over? Tilsynelatende så kan det se ut som at vi forklarer forskjellig, men når jeg går inn på linker og slikt som jeg selv har lagt ut, så synes jeg at jeg finner mye av det du skriver om. Forskjellen ser ut til å bestå i "pedagogiseringen" og hva vi har trukket ut som "det viktigste" ut i fra et stort tema. Grunnen til denne tråden er jo ikke at jeg kan dette temaet veldig godt, det er vel heller den at jeg forsøker å summere opp forklaringer som er så enkle at selv jeg forstår dem. Er det feil så må man jo eventuelt kikke på tingene en gang til og korrigere. IPv6 har nok blitt satt på på vent litt for lenge, for min del, slik at det liksom er litt å ta igjen.

Endret av arne22
Lenke til kommentar
15 minutes ago, arne22 said:

IPv6 har nok blitt satt på på vent litt for lenge, for min del, slik at det liksom er litt å ta igjen.

Der går formentlig minst 10 år til før alle kan bruke IPv6, og lappeløsningene for IPv4 har på et vis fungert veldig bra, men samtidig vært til skade for IPv6 utrullingen.  Tror ikke IPv4 forsvinner i vår levetid, så har man ikke lyst å rote med IPv6, så trenger man det neppe heller. 

Lenke til kommentar
12 hours ago, tigerdyr said:

Det er vel ganske opplagt?  Om ikke default gateway var tilgjengelig ditt lokale nett, ville du jo trenge en gateway for å nå den...   - og at man bruker fe80:: er en ganske opplagt løsning siden alle enheter på et IPv6-nett vil få en slik adresse. 

Nei, synes ikke det var helt opplagt at man bruker en link-local addresse som gateway adresse, når man ikke bruker NAT. Ville heller forvente en global routbar addresse som gatawayadresse. Foreløpig så har jeg bare vurderingen til OpenAI chat å støtte meg på, som ikke alltid er å stole på, men den sier: 

Quote

A gateway device in an IPv6 network can be configured with both a link-local address and one or more globally routable addresses. In some cases, the gateway device may only have a link-local address, and in other cases, it may have only globally routable addresses.

The use of a link-local address for a gateway is not required, but it can be useful in certain situations. For example, a link-local address can be used for communication between the gateway and other devices on the local network, such as for network configuration or troubleshooting.

In general, it's more common to have a globally routable address for the gateway, as it's used for routing traffic to other networks. Additionally, link-local addresses are not intended to be used as the source or destination addresses in packets that are forwarded outside the local network.

Jeg har ellers spurt OpenAI Chat den om den svarer annerledes på engelsk enn på norsk, og den sier at den engelske språkmodellen den er trent på er mye større enn den norske, slik at svarene kan bli forskjellige. Derfor engelsk.

Ut i fra disse to kildene så kan det se ut som at link-local adresser er mest vanlig som gateway adresser:

https://blogs.infoblox.com/ipv6-coe/fe80-1-is-a-perfectly-valid-ipv6-default-gateway-address/

https://www.ciscopress.com/articles/article.asp?p=2803866&seqNum=4

Etter å ha googlet litt rundt forbi så sitter jeg med et inntrykk av at OpenAI har rett i at begge addressetyper kan brukes kan brukes som gateway adresse, men at det faktisk er link-local som er mest vanlig. I mitt (automatisk konfigurerte) testnettverk så er det jo en link-local adresse som brukes som gateway addresse.

Hensikten med tråden er å få avdekket/dokumentert hvordan IPv4 og IPv6 fungerer, rent teknisk og praktisk ute hos sluttbruker, likheter, forskjeller, eventuell sikkerhetsrisiko, osv.

Endret av arne22
Lenke til kommentar
1 hour ago, arne22 said:

Jeg har ellers spurt OpenAI Chat

Jeg syns det er fint at du tilsynelatende er interessert i å lære mer om emnet, men jeg vil anbefale du starter med å lese en bok istedet for å forsøke å lære et stort og relativt kompleks emne på "twitter-maner". 

Den første IPv6-boken jeg leste var "IPv6 Essentials" for over 10 år siden.  Der finnes sikkert flere bedre bøker i dag, men jeg mener å huske at jeg syntes den ga en helt grei introduksjon i emnet. 

  • Liker 1
Lenke til kommentar

Ingeniørutdanningen og og diverse videreutdanning handlet jo mye om bøker, men jeg synes nok at man lærer best om teknologi gjennom praksis. Har brukt portscanner og packetsniffer som arbeidsredkap i ca 25 år, og det var sånn sett meningen at denne tråden ikke skulle handle om personer i det hele tatt, bare om faglig innhold og teknologi.

I gamle dager så handlet det jo bare om bøker, og når man skulle sette opp testlab og teste ut så var det utrolig tungvint å skulle forholde seg til stabler av lærebøker. Så kom Internett og e-bøker, og så gikk det mye kjappere å finne fram til info.

Det som jeg prøver ut nå, der er en arbeidsform som jeg synes er ganske spennende. Man setter opp en testlab. I dette tilfellet en dual stack modem/router og 4 stk PC med henholdvis WIN 10, WIn 11 og Ubuntu og Linux mint. Når man så bruker portscanner/packetsniffer og ser hvordan tingene kjører, så kan man også og samtidig føre dialog med OpenAI om hvordan observasjonene eventuelt kan tolkes. Det har jeg aldri prøvd før. Etter testlab med OpenAI, så sjekker man så videre med for eksempel Internett, kursinnhold og lærebøker.   

Tråden er ment å skulle handle bare om teknologi og hvordan tingene fungerer og ikke om personer. Har man link til en god lærebok som kan kaste et videre lys over saken, så er det utmerket. I dag så kan man handle nye lærebøker i løpet av et par minutter ved behov, og man kan ha dem umiddelbart tilgjengelig som e-bok.

Som sagt. Teknisk fag og ikke personer, det ville være bra. Spiller ingen rolle hvor opplysningene kommer fra, hvis de kan etterprøves ut i fra testlab og eksterne kilder.

 

Endret av arne22
Lenke til kommentar
arne22 skrev (53 minutter siden):

Når man så bruker portscanner/packetsniffer og ser hvordan tingene kjører, så kan man også og samtidig føre dialog med OpenAI om hvordan observasjonene eventuelt kan tolkes. Det har jeg aldri prøvd før. Etter testlab med OpenAI, så sjekker man så videre med for eksempel Internett, kursinnhold og lærebøker.   

Tråden er ment å skulle handle bare om teknologi og hvordan tingene fungerer og ikke om personer. Har man link til en god lærebok som kan kaste et videre lys over saken, så er det utmerket. I dag så kan man handle nye lærebøker i løpet av et par minutter ved behov, og man kan ha dem umiddelbart tilgjengelig som e-bok.

Som sagt. Teknisk fag og ikke personer, det ville være bra. Spiller ingen rolle hvor opplysningene kommer fra, hvis de kan etterprøves ut i fra testlab og eksterne kilder.

 

Tja. Dette er litt misvisende og kan være en risikabel holdning til OpenAI slik den er pr dags dato.

OpenAI kan svare deg på en veldig overbevisende måte som gjør det til tider vanskelig å forstå eller vite om svaret du får er feil eller misvisende. OpenAI selv skriver dette på sine sider under begrensninger:

Sitat

ChatGPT sometimes writes plausible-sounding but incorrect or nonsensical answers.

Så kan man selvfølgelig ta svaret man får men en viss skepsis og etterprøve det selv i en labb som du sier. Problemet der er at selv om det kanskje virker så vet du ikke nødvendigvis hvorfor.

Mange forum begynner nå å ilegge forbud mot å poste svar fra ChatGPT fordi en ser en gjennomgående trend at svarene ikke nødvendigvis er korrekt.

Så jo, det spiller en rolle hvor opplysningene kommer fra. Kildekritikk er viktigere nå enn noensinne.

Lenke til kommentar
54 minutes ago, arne22 said:

Tråden er ment å skulle handle bare om teknologi og hvordan tingene fungerer og ikke om personer.

Min kommentar var ikke ment som nogen personkritikk, men heller at man bør starte i riktig ende og få inn basiskunnskap før man går løs på emner som bygger på den basiskunnskapen - litt som at man bygger et hus fra fundamentet og opp, ikke omvendt. 

  • Liker 2
Lenke til kommentar

Her er et enkelt eksperiment som "alle" med interesse for problematikken rundt IPv4 og IPv6 kan gjennomføre: hvis man har "dual stack" og kjører Windows, så kan man i alle enkelhet deaktivisere IPv4 og IPv6 i Windows og så prøve ut "bare IPv4" og "bare IPv6" hver for seg, og så se hvordan dette fungerer. (Man kan for eksempel observere av noen kjente aviser blir reklamefrie.)

Framgangsmåte: Kontrollpanel ->   Nettverks og delingsenter ->  Endre adaptersetting -> Høyreklikk -> Egenskaper.

(Min Windows er engelsk. Håper oversettelsen ble noenlunde rett.)

Ellers anonymiserte konfigureringdata, hver for seg (Med automatisk konfigurering fra ISP.)

Først IPv4:

IPv4:
ipconfig /all
Wireless LAN adapter Wi-Fi:
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek RTL8294EU Wireless LAN 802.11n USB 2.0 Network Adapter
   Physical Address. . . . . . . . . : 00-E0-4C-53-DB-44
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.1.119(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Wednesday, January 15, 2023 9:07:52 AM
   Lease Expires . . . . . . . . . . : Wednesday, January 15, 2023 11:07:52 AM
   Default Gateway . . . . . . . . . : 192.168.1.1
   DHCP Server . . . . . . . . . . . : 192.168.1.1
   DNS Servers . . . . . . . . . . . : 192.168.1.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

 Så IPv6:

IPv6:
ipconfig /all
Wireless LAN adapter Wi-Fi:
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek RTL8294EU Wireless LAN 802.11n USB 2.0 Network Adapter
   Physical Address. . . . . . . . . : E2-C1-68-19-74-3B
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2a05:9cc3:57:6f2f:2e24:e4ee:ca04:fce5(Preferred)
   Temporary IPv6 Address. . . . . . : 2a05:9cc3:57:6f2f:bcd3:f43a:de4b:4fd(Preferred)
   Link-local IPv6 Address . . . . . : fe80::7912:ed12:c8ce:4a89%18(Preferred)
   Default Gateway . . . . . . . . . : fe80::9482:88ff:fea9:1b4d%8
   DHCPv6 IAID . . . . . . . . . . . : 721477601
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-27-74-DA-C6-EC-8E-A5-4D-3D-64
   DNS Servers . . . . . . . . . . . : 2a05:9cc3:f000:1::4
                                       2a05:9cc4:f000:1::4
   NetBIOS over Tcpip. . . . . . . . : Disabled

Hvis man ønsker å teste med serverfunksjoner for å se om disse blir tilgjengelig gjennom globale IPv6 adresser fra Internett, så kan man for eksempel sette opp en webserver vha XAMPP (Serverfunksjoner på TCP port 80 og TCP port 443. Det vil også være en "service" som kjører på port 3306, men den skal være "lukket".) På mitt nettverk så kom XAMPP rett ut på nett når man enabler IPv6.

https://www.apachefriends.org/ 

Man kan scanne for åpen port vha denne portscanneren, men kan bare scannes en port av gangen.

https://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-port-scanner.php

Hvis man ønsker "å se på" hvordan IPv4 og IPv6 trafikken "ser ut" så kan man installere Wirehark.

https://www.wireshark.org/

Ønsker man et lite kurs i "packet sniffing", så har vi et her. (Første måned gratis.)

Wireshark Essential Training Online Class | LinkedIn Learning, formerly Lynda.com

Her er det mye gøyalt stoff for den som er interessert.

Endret av arne22
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...