arne22

Liten bagatell, men de var der nå sist jeg kikket etter dem. I tillegg så husker brannmuren trafikken. I følge noe info jeg fant på nett så er dette et problem for IPv6 at datatabellene for IPv6 statefull inspection blir mye større enn for Ipv6. https://www.checkpoint.com/cyber-hub/network-security/what-is-firewall/what-is-a-stateful-firewall/ Se også her: https://www.imperva.com/learn/ddos/syn-flood/ I følge dokmentet "NSA Security Guide" så kan IPv6 gi hackeren bedre oversikt over trafikken, dvs i visse situasjoner bedre oversikt over hva som befinner seg bak en brannmur. Med "bedre oversikt" så mener jeg rett og slett hvordan det fungerer rent praktisk med å bruke redskaper som NMAP, TCP-view og Wireskark. Da har man mye bedre oversikt over trafikken med IPv4. Med IPv4 så gikk det bra å få til å resolve alle adressene automatisk, slik at jeg kunne se hvor alle ip pakkene hørte hjemme. For IPv6 fikk jeg bare fram disse ganske lange og nokså uleselige adressene. Synes vi bør fokusere mer på "fag" og "sak" enn på person. Det er jo det som er å være saklig. Har jobbet og lekt litt med maskinbygging i 25 år, og når jeg får beskjed om at all den informasjonen jeg har fått fra Direktoratet for sikkerhet og beredskap, Nasjonal Kommunikasjonsmyndighet og Nasjonal sikkerhetsmyndighet, pluss divese private firma er feil, da vet jeg jo at det ikke stemmer helt. Det vil være bedre å diskutere regelverk og teknologi litt i dybden, i stedet for å diskutere person.

Dagen har blitt brukt til litt "laboppsett" og litt testing stort sett så har jeg bare brukt en vanlig Windows PC, Wireshark, NMAP, TCP-Wiew, Process explorer, pluss noen dos shell kommandoer, og et 4G modem som kan konfigureres til å kjøre "bare IPv4", bare IPv6 og "dual stack". Dette ga litt "innledende innblikk" i hvordan denne trafikken fungerer. Så vidt som jeg kan bedømme så medfører bruken av dual stack nye sikkerhetsmessige problemstillinger, slik som beskrevet i dokumentet fra NSA over, pluss også en del problemstillinger som gjelder spesielt for industrielle kontrollnettverk, slik at det etter mitt syn vil være fordelaktig å unngå å bruke "dual stack". Slik somjeg ser det så vil det være fornuftig å holde fast ved "ren IPv4", så lenge som det kan fungere, og så når den tid eventuelt kommer, å skifte over til ren IPv6. Slik som jeg ser det så gir "dual stack" et trafikkbilde som er ganske "messy", altså mye mer uoversiktelig. Hvs man har å gjøre med et teknisk anlegg der det stiller store krav til "maskinsikkerhet" herunder også "Cyber Security", så vil alle arbeidsopereasjoner relatert til "Cyber security" bli mer arbeidskrevende, kompliserte og kostbare. Ved bruk av "dual stack" så bygger man inn økt risiko og kostnader, som ikke gir noen gevinst tilbake. Derfor så blir "dual stack" en forholdsvis lite aktuell løsning for indsustrielle kontrollsystemer. Når man jobber med arbeidsredskaper som de som er nevnt over, så blir arbeidsmengden mangedoblet, når man jobber med "dualstack", i forhold til "rein IPv4" eller "rein IPv6". Når man kjører rein IPv4 så har man den aller enkleste og beste oversikten over trafikken. Nå gjelder det jo et prisnipp, at nr man skal "spå for framtiden", så er det bare framtiden som kan gi et sikkert svar. Jeg ville tro at "dual stack" i forbindelse med industrielle kontrollnettverk, det er noe som vi ikke vil se så veldig myer til. IPv4 vil bli brukt i mange år framover og så vil det en gang i framtiden skje en overgang til IPv6, uten noen mellomperidode med "dualstack", slik som vi ellers har det i "generelle nettverk". En problemstilling som jeg så langt ikke har fått testet ut er det som går på lagring i sikekrhets og access logger, og bearbeidelse av data fra disse, men det ligger jo også i sakens natur at også dette arbeidet må bli mer komplisert. En ting som jeg ellers legger merke til, det er at når man kjører "dual stack" så er det utrolig mye av nettrafikken fra "IPv6 sites" (for eksmepel vg.no) som fortsatt kjører i IPv4.

Statefull inspection. Har testet litt i dag og ser at det fungerer likt. Ellers ut over det, så er det nok litt lenge siden. Nei har helt ikke funnet på dette selv. Forsøker å videreformidle det jeg har oppfattet som budskapet fra norsk Nasjonal Sikkerhetsmyndighet og DSB, som er vår overornede myndighet for maskinsikkerhet. (Som i følge DSB også omfatter de fleste automatiserte anlegg.) Gikk et kurs i "Cyber Security" der Nasjonal Sikkerhetsmyndighet var foredragsholder, nå siste år, og så har så har denne problemstillingen blitt diskutert med DSB pluss også noen av de litt større private firmaene gjennom en del år. Maskinforskriften og EU sitt Maskindirektiv gjelder på overordnet lov eller forskriftsnivå, altså "de lovgitte kravene som man må følge" mens IEC62443 gjelder på "norm-nivå" altså som en praktisk og anbefalt løsning for hvordan man kan infri de overordnede kravene som er gitt på forskriftsnivå. Det er jo sånn sett ikke et spørsmål om å enten følge lovgitte krav eller normkrav. Man må oppfylle de lovgitte kravene, og så kan man bruke "normer" eller "standarder" som en praktisk måte å oppfylle de lovgitte kravene på. Fra DSB sin side så har de pleid å henvise til de prinsippene som framgår av denne presentasjonen. som en slags "grunnstruktur" for regelverket rundt maskinsikkerhet. (Og så definerer man de fleste automatiserte anlegg som "maskiner".) Det var grunnen til at tråden ble opprettet. Jeg kunne for lite om IPv6. Men nå har jeg fått lært meg litt, og jeg har også fått kjørt litt testlab og sett litt mer detaljert på dette "fenomenet" IPv6 og ikke minst dette med "dual stack". Denne beskrivelsen fra NSA ser ut til å treffe litt i konklusjon, av det som jeg selv ville konkludert med, når det gjelder dual stack og "generell nettverkssikkerhet". https://media.defense.gov/2023/Jan/18/2003145994/-1/-1/0/CSI_IPV6_SECURITY_GUIDANCE.PDF Det er mitt foreløpige inntrykk at "NSA IPV6 Security Guidiance" beskriver situasjonen stort sett rett for "generelle nettverk" og så kommer da i tillegg det som gjelder spesielt for Industrielle kontrollsystemer, hernunder det som går på maskinsikkerhet og "Cyber Security".

Ville nok heller ha sagt at TCP/IP er en 4-lags modell som har sin parallell i en 7 lags OSI modell, slik som beskrevet her: https://www.geeksforgeeks.org/tcp-ip-model/ Når man skifter ut IPv4 med IPv6 så skifter man ut hele layer 2 i TCP/IP modellen fra IPv4 til IPv6. Når man kjører "dual stack" så kjører man med dobbelt sett med protokoller på layer 2 i TCP/IP modelen. Oppbyggingen av IPv4 og IPv6 datapakkene er noe forskjellig på grunn av at dette dreier seg om to forskjellige protokoller: https://en.wikipedia.org/wiki/Internet_Protocol_version_4 https://en.wikipedia.org/wiki/IPv6_packet Når oppbyggingen av pakkene er litt forskjellige, så gir det også en mulighet til at "firewalling" kan utføres litt forskjellig hvis man utnytter de forskjellene som er på detaljnivå. (Forutsatt at man har en firewall som har slike muligheter.) Når det gjelder lovgitte krav til "cyber security for maskiner ogautomatiserte systemer" i Norge og i Europa, så er det så vidt vites Maskinforkriften som gjelder som "det grunnleggende kravet til sikkehet", slik at man utleder "krav til Cyber Security" ut i fra de generelle kravene til "maskinsikkehet". https://lovdata.no/dokument/SF/forskrift/2009-05-20-544 For mer samfunnskritisk infrastruktur så gjelder også denne forskriften: https://lovdata.no/dokument/SF/forskrift/2021-05-11-1459 Nå er vel NMAP bare ett av ca 600 arbeidsredskaper for pen testing i Kali Linux. For flere av de forholdvis store og kjente angrepene mot industrielle tekniske anlegg, så ville "pen testing vha porscanner" ikke være i nærheten av å kunne forebygge eller å forhindre angrepet. Det ville kreve en type pen testing som går langt mer i dybden. https://www.hydro.com/no-NO/media/pa-dagsorden/cyberangrep-pa-hydro/ https://www.techtarget.com/whatis/feature/Colonial-Pipeline-hack-explained-Everything-you-need-to-know For angrepet mot Norsk Hydro så ville jo ingen av de 600 redskapene i Kali Linux hjelpe hverken fra eller til. Når man skal risikovurdere og gjennomføre tiltak for "Cyber Security" ut i fra de generelle kravene i Maskinforskriften, så vil det jo avhenge en del av hva slags "maskin" eller teknisk anlegg det gjelder, og hva slags risikonivå som finnes. For en enkel maskin eller et enkelt teknisk anlegg, så vil det kanskje være tilstrekkelig med en portscan fra utsiden. Når det er snakk om mer komplekse anlegg og forholdvis større risiko, så vil det jo kreves en helt annen type risikovurdering og en annen type pentesting. Når man skal implementere IPv6 så vil det ikke være tilstekkelig "å ha en generell oversikt". Man må også ha en oversikt over og kunne forstå og dokumentere alle detaljer reatert til sikkerhet, for eksempel slik som beskrevet her: https://www.linux-magazine.com/Online/Features/IPv6-Penetration-Testing http://ipv6now.com.au/security.php Man må hele tiden vite at det man gjør ikke kan ha noen "sideeffekter" som man ikke har tenkt på. Når det for eksempel gjelder bruken av de ca 600 arbeidsredskapene for pen testing som finnes hos Kali Linux, så er det vel slik at de fleste i større eller mindre grad støtter IPv6, samtidig som "den praktiske bruken" (kommandoer, etc) er forskjellig, for IPv4 og IPv6, slik at man på et vis må lære å bruke dem på nytt. Det kan vel være at en bil med høyreratt og venstreratt fungerer likt, men for sjåføren så blir jo kjøringen litt forskjellig. Man må på et vis lære seg å bruke arbeidsredskapet på nytt. Når det gjelder det som går på loggføring og "digital forensics" så vil jo systemer for loggføring og for bearbeiding av loggdata kunne være forskjellig i forhold til IPv4 og IPv6. En annen problemstilling det er jo hvilken praktisk mulighet man har for å følge opp situasjonen når man har mistanke om at man har hackere inne på anlegget, hvordan man rent praktisk går fram for å identifisere trafikken tilhørende hackere, og hvordan man identifiserer dem som "angripere" og stenger ned prosessene deres og tilhørende trafikk. Eller man lar den holde på, mens man overvåker situasjonen. For å kunne oppfylle de lovgitte kravene til Cyber Security for tekniske anlegg med en forholdvis høy grad av kompleksitet og høy risiko, så vil det kreves mye mer enn en grunnleggende forståelse av TCP/IP. Man må kunne gjennomføre en risikovurdering og påfølgende verifikasjon av Cyber Security (PEN Testing) som i prinsipp omfatter alle mulige og praktisk forekommende angrepsmåter, inklusive, men ikke begrenset til de allerede kjente angrepene som har skjedd mot industrielle anlegg nå i dag. Man må også ha klar en plan for hvordan man håndterer angrepene når de kommer.

.. Og så har vi jo også å gjøre med det som går på risikovurdering, verifikasjon, dokumentasjon og samsvareklæring, å gjøre også. Av og til kanskje også tryggest med litt "latskap" eller "teknisk konservatisme".

Penetration testing må vel være en nokså sentral problemstilling rundt vurdering av sikkerheten for et automatisert anlegg, ettersom det er lovgitte krav om at dette skal gjennomføres for utstyr koblet opp mot internett. Mener at det samme gjeder vel sannsynligvis for smarthus, intelligente bygninger og ulike typer samfunnskritisk infrastruktur. "Penertation testing" det er slik som jeg ser det mest av alt en måte å analysere eller vurdere og verifisere sikkerhet på. Det stemmer at for å gjennomføre en helhetlig risikovurdering for en "maskin" eller et "automatisert anlegg", ut i fra de kravene som gjelder ut i fra lovverket, så er det ganske mange ulike fagområder, som man må kunne se i sin sammenheng. Man kan ikke bare si at dette blir for omfattende, dette klarer jeg ikke å se i sin sammenheng. Skal man oppfylle kravene i lovverket, så må man se og forstå sammenhengen, og man må også kunne utarbeide dokumentasjon som viser hvordan risikovurderingen og jobben er gjort. Nå har jeg vel lekt meg med eller brukt en noen av disse redskapene som inngår i Kali Linux i litt over 20 år, og min konklusjon det er at selv om man kan bruke dem under IPv4, så betyr ikke det at man kan bruke dem under IPv6. Jeg kan det i alle fall ikke. Da blir det jo å legge ut konkret beskivelse av hvordan bruke "Kali Linux Tool" undet IPv6. Uten at man kan risikovurdere og verifisere sikkerheten til et teknisk anlegg, så oppfyller man ikke forskriftskravene, og man kan heller ikke skrive en samsvarserklæring eller overlevere det tekniske anlegget til en kunde. For så vidt enda ett nytt tema: "De lovgitte krav", men alt det andre henger jo sammen med og har sin grunn i dette siste nye temaet. Her behøves det nok litt godt humør, og gode konkrete tekniske løsninger 🙂

Det jeg jo egentlig mener, det er jo "hvordan gjennomfører man en penetrating testing i et IPv6 miljø". Med å "kunne" IPv6 så mener jeg ikke for eksempel "å forstå" prinsippene rundt adressering, men heller det å ha kompetanse og utstyr til å gjennomføre en penetration test i et IPv6 miljø. Man kunne vel egentlig formulere problemstillingen som så konkret som: Hvordan bruker man pen test redskapene i Kali LInux i et IPv6 miljø? (Slik at man kan ivareta sikkerheten i nettverket, enten det nå dreier seg om Industriell automasjon eller noe annet.) https://www.kali.org/tools/ De aller fleste av disse pen test redskapene er jo laget for IPv4, og de fleste kursene om Kali LInux og andre pen test redskaper handler jo enten bare eller alt vesentlig om bruk i IPv4 miljøer. Ja, det finnes generelle kurser og mer spesielle kurser for eksempel spesifikt rettet mot Kali Linux, gi meg litt tid, så skal jeg legge ut en del linker. Det kan ellers hende at det også skulle vært opprettet en ny tråd med en tittel av typen: "Hvordan gjennomfører man penetration testing i et IPv6 miljø?". Her blir det nok neppe helt likt i forhold til IPv4 og IPv6 protokoll. Edit: Her er da et folerøpig eksempel på et kurs som handler om penetrtation testing med Kali Linux. Det testmiljøet som brukes i kurset er IPv4 og de reskapene som brukes er basert på IPv4. Spørsmålet blir da: Hvordan gjennomfører man en tilsvaredne penetration testing innenfor et IPv6 miljø? (Slik at man oppnår en tilsvarende grad av sikkerhet.) Learning Kali Linux Online Class | LinkedIn Learning, formerly Lynda.com Ser det også finnes et Kali Linux tool kit, og spørsmålene blir jo da: Hvilke funksjoner der det som dekkes av dette tool kittet, og hvordan går man fram for å bruke disse? Hvilke funksjoner er bare tilgjengelig for IPv4? ipv6-toolkit | Kali Linux Tools Dette er jo ikke bare en problemstilling som gjelder bare industielle kontrollnettverk, men også det som generelt går på penetration testing i forhold til IPv6 nettverk.

Dette er nokså likt med kanskje litt egne erfaringer og eget syn på saken, bortsett fra opplysningen om at det er mye automasjonsutstyr som støtter IPv6. Har du noen opplysninger eller linker til produkter? Er ganske nyskjerrig på det..! 🙂 Ville trodd at det som ville sinke implementeringen av IPv6 i særlig grad er mangelen på egnet utstyr, men det behøver jo ikke å stemme.

Nei, det stemmer ikke i det hele tatt. Det finnes ekstremt mye innenfor IPv4 og generell Cyber Security. Kursleverandører er for eksempel Microsoft, Cisco, LinkedIn learning og hauger og lass med andre, pluss mye gratis på YouTube. Har nok passert noen hundre slike kurs, men bare to av dem har handlet om IPv6. Syntes jeg skjønte litt i øyeblikket, men når det går et par uker, så er jo det meste glemt, hvis man ikke "praktiserer". Nei, det er det rare. Læreplenene og lærebøkene inneholder nesten ingen ting om nettverk og nettverkssikkerhet, og IPv6 er ikke nevnt i det hele tatt. Det har kommet ett enkelt læreplanmål i læreplanen for VG3 automatiker, men det er i liten grad noe innhold i noen av lærebøkene som "matcher". Ett enkelt læreplanmål: https://www.udir.no/lk20/aut03-04/kompetansemaal-og-vurdering/kv717 Det er jo så lite og så vagt at det er nesten ingen ting. For elektriker, så er det så vidt at dette temaet er nevnt med et par ord, til tross for at man setter opp elektriske anlegg i smarte hus og intelligente bygninger. https://www.udir.no/lk20/ele03-03/kompetansemaal-og-vurdering/kv725

Utførte en test nå. Brukte en TP-link mobil 4G router. (TP-LInk M7350) Først så støttet det ikke IPv6. Gjennomførte så firmware oppgradering og så konfigurerte jeg til at det skal støtte IPv4 og IPv6 dual-stack. For IPv4 så støtter den NAT med mulighet for portforwarding. For IPv6 så står det ingen ting annet i menyen enn at IPv6 at den støtter IPv6 og at IPv6 fungerer. Så kjørte jeg i gang en webserver på min Windows(10)maskin. Brukte så en ekstern portscanner til å scanne den automatisk tildelte IPv6 adressen til Windows 10 maskinen. Denne portscanneren ble brukt: https://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-port-scanner.php (Har ikke brukt den før så jeg vet ikke om den er pålitelig.) Tilbakemeldingen fra portscanneren var at både port 80 og port 443 var synlige ute fra Internett og "klar for angrep" uten at det var noen IPv6 brannmur i 4G routeren som beskyttet de PC'ene som var koblet opp. Kan dette stemme? Hvis dette stemmer så fungerer jo dette noe annerledes enn for IPv4 på det samme modemet, som i praksis har en brannmurfunksjon. (I alle tilfeller så ligger den bak CGNAT, slik at den uansett er beskyttet.)

Se her er vi inne på noe. Grunnen til at jeg startet denne tråden, det var jo ikke at jeg visste svaret, men der i mot for å finne ut hva svaret var. Det er sånn sett egentlig ikke noe snakk om "påstander", men å "avdekke problemstillinger" og "å finne ut av". Hvis jeg skal oppsummere noen av problemstillingene så tror jeg det må bli omtrent slik: 1. Først og fremst, hvis man skal ta i bruk IPv6 i industrielle kontrollsystemer, så må det finnes utstyr som er kompatibelt, inklusive også alle funksjoner som har med funksjonalitet og sikkerhet å gjøre. Hvis mesteparten av det det nye automasjonsutstyret som selges nytt nå i dag ikke, og mesteparten av det utstyret som er ute i anleggene nå i dag ikke støtter IPv6, vil man da ta i bruk IPv6 i stort omfang? Første avklaring må vel bli: Hvilket automasjonsutstyr er det som støtter IPv6? HVis det er noen som har en link vedrørende dette, så legg den gjerne ut. Levetiden for typisk automasjonsutstyr er vel ellers ofte mye mer enn 5-10 år. Dette har jo til dels sammenheng med riskovurdering i forhold til ha som kan skje hvis utstyret feiler. Brann, oversvømmelse, eksplosjon, osv, kan vel også være en mulighet, slik at konsekvensene av feil kan bli annerledes enn i typiske IT systemer. 2. Hvis man har utstyr som er kompatibelt, så behøver man personell som kan dette med sikkerhet og funksjonalitet i forhold til bruk av IPv6 i industrielle kontrollanlegg, og hvor skaffer man den utdanningen? Tilbakemeldingene fra "bransjen" det er vel stort sett at den utdanningen finnes foreløpig i liten grad, og at det som finnes har karakter av bedriftintern opplæring hos noen av de store selskapene. Hvis det er noen som har en kjennskap til en slik utdanning, nasjonalt eller internasjonalt, så vil jeg være glad for en link vedrørende dette også. (Mener å vite at det er ting under utvikling, man har så langt ikke sett noe ferdig.) Nå er jeg vil klar over at man kan vurdere sikkerhet, forebyggelse av hacker angrep og risiko på forskjellig måte, men jeg for min del har inntrykk av at det er noen flere faktorer å ta med i betraktning. Globale IPv6 addresser kan tildeles utstyr og noder automatisk. Uten en lukket brannmur, så er disse tilgjengelig fra Internett. Automatisk tildeling av IPv6 adresser skjer på en annen måte enn ved bruk av IPv4. Porscanning for å sjekke for en sikker konfigurering av en IPv6 brannmur, må skje på en annen måte enn tilsvarende scanning av en IPv4 brannmur. (Og ved dual-stack så må man bruke flere metoder. Link local adresses i IPv4 og lokale IPv6 adresser er så vidt vites ikke helt det samme. (Må sette meg bedre inn i dette.) Ved bruk av globale IPv6 adresser på lokalt utstyr, så vil en hacker kunne få nye og andre muligheter til å finne ut av hva som befinner seg bak en brannmur eller rundt en hacket node. (PC eller noe annet.) IPv4 og IPv6 er ikke bare to forskjellige måter å adressere på, det er to forskjellige protokoller med hver sine egenskaper. IPv4 og IPv6 har forskjellig pakkeformat, slik at de vil se forskjellig ut når man ser på trafikken vha en packet sniffer. På grunn av at pakkeformatet er forskjellig, så vil detaljer innenfor "packet filtering" også kunne bli litt forskjellig. En del servere og annet utstyr har ikke IPv6 støtte for sikkerhetslogger og logging av driftsdata, slik at når man skifter over til IPv6, så kan man risikere å være uten sikkerhetslogg. (Påstand på nettside. må sjekkes nærmere.) Påstår fortsatt hverken det ene eller det andre, forsøker bare å skaffe litt oversikt over hva likheter og forskjeller består i, og hvilke nye utfordringer som eventuelt finnes. Jeg ville vel tro at den aller viktigste problemstillingen det er hvilket utstyr det er som støtter IPv6 og at mangelen på IPv6 kompatibelt utstyr vil være den faktor som medfører at IPv4 fortsatt vil bli mye brukt som protokoll innenfor industrielle kontrollsystemer. Når vi der i mot er over i "beslektede bransjer" som smarthus, intelligente bygninger og "Industrial Internet of Things", så ville jeg forvente at utviklingen over mot IPv6 skjer mye raskere. Hvis man skal forsøke å spå litt om framtiden så kan man ikke ha rett eller galt før man har kommet litt fram i tid. Tenkte å sette opp en IPv6 testserver for å teste ut IPv6 på server. Noen som har et tips?: Nytt spørsmål. Det ser ikke ut til å være noen enkel måte å sette opp en slik server på, og jeg lurer jo på om det kan ha noe å gjøre med eventuelle problemer med å få sikkerhetsloggene til å fungere.

Denne websiden er jo ikke en "formell rettskide", men man kan vel ikke utelukke at den inneholder noen riktige opplysninger allikevel: https://www.eiendomsrett.no/tvisteloven-6-13/ Har inntrykk av at det forholder seg slik at når en sak går for tingretten så kan man kreve godtgjøring for eget arbeid med sakforberedelse, men når saken går for forlikstådet, så kan man ikke det. Synes ikke at websiden gir noe helt godt svar på hvorfor det er slik, men den henviser jo til rettspraksis, og der finner man vel kanskje noen mer utdypende forklaringer. Noen av de som dikuterer under avsnitt "Juss" kan jo disse tingene godt, og det er da å håpe at det kommer en litt mer utdypende kommentar. Ville anta at den websiden som jeg linker til over forklarer tingene sånn oenlunde rett.

Det er jo det denne tråden handler om. Å finne fram til hva som er den praktiske forskjellen. Hvis man vet svaret, vil man da starte en tråd? Det er nok mitt intrykk at det finnes en del forskjeller, ja og at noen av disse forskjellene er beskrevet i presentasjonen til RIPE. https://www.ripe.net/support/training/material/ipv6-security/ipv6security-slides.pdf Så vidt som jeg kan se så har de problemstillingene som står nevnt i denne presentasjonen ikke brukbare eller tilstrekkelige fullstendige svar i denne tråden. Spørsmålet er jo: Hva består forskjellene i i, og hvordan håndterer man disse forskjellene på en sikker måte? Det er jo også et spørsmål om hvilke typer industriell automasjonsutstyr som faktisk støtter IPv4. Har ikke sett noen som nevner noe om det i tråden over. Det er jo ikke den som stiller spørsmål om i hvilken grad man kan bruke IPv4 vs IPv6, i industriell sammenheng, som skal besvare sitt eget spørsmål. Det må jo være den som eventulet vet noe om svareret, som kommer opp med svarene. Det aller første og viktigste spørsmålet i den sammenheng, det må vel være: Hvilket industrielt automasjonsutstyr er det som støtter IPv6? Kan man gjennomføre IPv6 som kommuniksjonsprotokoll for teknisk utstyr som bare støtter IPv4? Hvilket automasjonsutstyr er det som støtter IPv6 annet enn noen nyere modeller fra Siemens?

Når man kan det og har konfigurert riktig. Men det er nok litt mer å kunne enn før. Og så må man ha utstyr som er kompatibelt. At forskjellen mellom IPv4 og IPv6 er de lange adressene, eller at IPv6 er IPv4 med lange adresser, det stemmer vel ikke på noen måte som helst. Det er to forskjellige protokoller med ganske ulike egenskaper.

Dette er jo en veteranbil og det kan vel finnes noen litt slappere retningslinjer for slike. Det ser ikke ut som at det står noe om å fjerne seter, og det er kanskje et godt tegn. https://www.vegvesen.no/globalassets/kjoretoy/eie-og-vedlikeholde/skjema/retningslinjer-for-bruk-av-kontrollorens-skjonn-ved-ombygging-av-kjoretoy-30-ar-og-eldre.pdf

Fant en litt brukbar oversikt over de problemstillingene som man kanskje bør ha kontroll over før man tar i bruk IPv6: https://www.ripe.net/support/training/material/ipv6-security/ipv6security-slides.pdf

Tror det kan være lurt å ringe Biltilsynet vedrørende eventuelle grønne skilt. For nyere biler så skal det visst nok være et krav om at de skal være en skillevegg mellom bagasjerom og kabin for at man skal få godkjent den som varebil. Vet ikke hva som er reglene for eldre biler. Hadde en ganske stor 8 seter for en liten tid siden. Det var setene laget med hurtigkoblinger, slik at jeg tok ut setene og kjørte rundt med den som varebil, men med hvite skilter, og uten skillevegg. Det var merkelig nok lovlig. (Trodde jeg i alle fall, ble i alle fall aldri stanset.)

Ja, og den fristen skal vel stå i vedtaket. (I følge NAV sine nettsider.) https://www.nav.no/klagerettigheter

Det var det jeg trodde. Man skal vel vokte seg vel for å kalle dette for "redusert sikkerhet", for da er det vel noen IPv6 tilhengere som spretter opp, og så får man høre det ene og det ennet, men det er i alle fall en sikkerhetsmessig detalj som man så absolutt bør kjenne til og ta med i betrekning. Hvis lokale noder på LAN vanligvis har globale IPv6 adresser, så gir i alle fall dette hackerne et par nye "muligheter" eller "parametere" å jobbe med, og så gir det også vedig mange nye positive muligheter for den som ønsker å sette opp lokale servere av ymse slag. Har man en IPv6 brannmur som er feilkonfigurert så kan dette få ganske alvorlige konsekvenser ved at "lokale enheter" blir liggende "åpent ut" mot Internett. For en IPv4 router/brannmur, så kan man ganske enkelt finne ut om den er riktig konfigurert ved en portscan fra utsiden. For en IPv6 gataway, så fungerer det vel ikke med en slik portscan på grunn av at antallet tilgjengelige adresser blir for stort? Rettelse: For IPv4 så holder det med en ekstern portscan (mot gatewayens globale IP) for å se "alt på LAN", som er tigjengelig fra Internett. Har man for eksempel 5 "enheter" eller "noder" på et IPv6 LAN, så holder det med 6 portsvanninger, 1 for "utvendig ip" og en for hver av de "innvendige" men "globale" IPv6 adressene. Slik må det vel bli? - Ikke helt umulig, men litt mer omstendig. Man behøver vel ikke å scanne alle mulige adresser som ikke er i bruk?!

Jeg var intil for ganske nylig, det man kanskje kan kalle en "IPv6 analfabet", men jeg har forsøkt å lære meg litt. Jeg har forstått det slik at for et "standard hjemmenettverk", så vil det vanligvis og som default skje en tildeling av globale IP adresser, også for IPv6 enheter inne på på LAN. Det betyr jo i så fall at "sann klient IPv6 adresse vil være "synlig" i returtrafikken til server, og så betyr det vel også at dersom vi åpner opp for det i brannmuren, så kan vi kjøre flere forskjellige serverfunsjoner inne på LAN, som også kan gjøres tilgengelig fra Internett? Stemmer dette? (Hvis det ikke stemmer, så skal jeg nok sende en klage og stramme opp OpenAI Chat, som har fortalt meg dette.) Hva med spillekonsoller og slikt som har behov for "åpne porter inn", vil de (vanligvis) kunne åpne en brunnmur dynamisk når man kjører IPv6 på lokalnettet?

Vil nok mene at du har rett i det, og at trådstarter egentlig har "gjeldende rett" på sin side. Men så kommer det interessante spørsmålet: Hvis trådstarter har fått et vedtak om reduksjon i uføretrygd, som formelt sett er ulovlig, hva kan trådstarter da gjøre for å få gjort om dette vedtaket og å få erstattet det med et nytt? Man kan vel egentlig få prøvd lovligheten av slike vedtak uten at det behøver å koste noe?! Er den praktiske framgangsmåten først en formell klage til NAV og så, hvis man ikke får medhold, som eventuelt neste steg en formell klage til Trygderetten? https://klage.nav.no/nb/klage/uinnlogget/UFO/UFORETRYGD/begrunnelse https://trygderetten.no/nb/hvordan-anker-jeg-min-sak-til-trygderetten Hvis så er tilfellet, så er det vel bare å kjøre i gang en klagesak, og så forsøke å få omgjort vedtaket? En diskusjon på diskusjon.no gir vel i seg selv ingen endring, men en påfølgende formell klage til NAV og eventuelt Trygderetten, det skulle vel kunne "gjøre susen" ?

Tror det er et blindspor. Utviklingen blir nok ikke bestemt av oss eller en diskusjonen på diskusjonsforum. Hvis man skal få tak i hvordan tingene kan forventes å utvikle seg i framtiden, så må man nok snakke litt med de som er store i bransjen. Når det gjelder det automasjonsutstyret som jeg har vært borte i de siste 25 årene, så har jeg ikke sett at noe av det støtter IPv6. Det har bare vært støtte for IPv4. Men det kan tenkes at det er endringer på gang. Det gjelder utstyr for tradisjonell industriell automasjon. For et par "beslektede teknologier", så kan det være annerledes. Det gjelder for eksempel teknologi rundt "intelligente bygninger" og IIOT eller "Industrial Internet of Things" og teknologi rund "smarte byer". https://www.controleng.com/articles/wireless-protocol-supports-end-to-end-ipv6/

Står noe her. https://labs.ripe.net/author/philip_homburg/whats-the-deal-with-ipv6-link-local-addresses/

Det har jeg faktisk aldri prøvd, så det vet jeg ikke. Utsagn fra vår venn OpenAI. Jo hvis man definerer "tillatt" på den måten så blir det jo rett nok. Det er jo sant nok i forhold til sikkerhet. Men det er kankje ikke helt like sant i forhold til brukernes ønsker og behov. Det blir vel fort "mye styr" av å filtere utgående trafikk. Dessuten så kan man bypasse alle/de fleste forhindringer via 4G/5G. (Med mindre at bedriften har et opplegg som ruter all "trafikk fra hjemme PC" via VPN og bedriftens nettverk og brannmur.)

Ellers beskjed fra vår felles gode venn. * Are local link addresses in ipv4 the same as local addresses in ipv6? No, local link addresses in IPv4 are not the same as local addresses in IPv6. In IPv4, the local link addresses are in the range of 169.254.0.0/16 and are used for Automatic Private IP Addressing (APIPA) when a device is unable to obtain a valid IP address from a DHCP server. In IPv6, the local addresses are in the range of fe80::/10 and are used for link-local communication between devices on the same network segment, similar to the use of local link addresses in IPv4. However, in IPv6, these addresses are also used for stateless address autoconfiguration (SLAAC) when a device is unable to obtain a global address via DHCPv6. * Are you sure that local link addresses can not be used for communication between nodes? I apologize, I made a mistake in my previous answer. Local link addresses can be used for communication between nodes on the same network segment. In IPv4, the local link addresses (169.254.0.0/16) are used for Automatic Private IP Addressing (APIPA) when a device is unable to obtain a valid IP address from a DHCP server. These addresses allow the device to communicate with other devices on the same network segment, but they cannot be used to communicate with devices outside of the local network. In IPv6, the local link addresses (fe80::/10) are used for link-local communication between devices on the same network segment, and also for stateless address autoconfiguration (SLAAC) when a device is unable to obtain a global address via DHCPv6. These addresses allow the device to communicate with other devices on the same network segment, but they cannot be used to communicate with devices outside of the local network. So, in both cases, local link addresses are used for communication between nodes on the same network segment but not for communication with nodes on different network segments. ******** Vi kan alle sammen gjøre feil, og noen ganger så gjør vi til og med den samme feil 😀