Vilka operatörer erbjuder IPv6?

Du har ju helt rätt. Pöben får stå ut med bara 256 nät.

Det var rätt så enkelt att få till det. tack för tipsen!

Tips för de som har tid och möjlighet den 11/9

https://pts.se/om-oss/evenemang/ipv6-forum-med-tema-anslutnin...

Jag anmälde mig, tack för tipset. Får se om jag hinner gå också

Testade dra iväg en fråga om ifall presentationerna kommer vara tillgängliga i efterhand. Hinner tyvärr inte deltaga live.

Provade bocka i dessa två men ingen skillnad

Du behöver ställa in Prefix Delegation till /56

Det är valt 56 i dropdownen, blev lite dolt bakom röda ringen.

Vet inte varför jag skulle kontakta Telia, har Bahnhof via Servanet
Menar du att det är nödvändigt att lägga till regler bara för att WAN-ska kunna bli tilldelad en IPv6-adress?

Var det nån som var på plats?

Presentationerna finns på https://www.pts.se/internet-och-telefoni/ipv6/ även om det var väldigt lite ipv6 denna gång.

Telenor verkade ju inte ha en jättekul inställning om man bara läser deras slides, men till skillnad från med Telia har jag IPv6 i telefonen med dem.
Att IoT-enheter "inte lämpar sig" för att presenteras mot Internet är snarast ett problem för lagstiftare: Inför stränga böter/sanktioner för dem som säljer grejer med dålig säkerhet och som inte underhåller grejer de sålt under rimlig tid. (Men visst: Svaret på det är att gå i konkurs och starta nytt...)

Man får tänka på att Telenor Connexion inte är Telenor.

Även med säkrare IoT enheter skulle jag nog inte vilja att de gick att nå direkt från internet av alla. Dels pga batteri förbrukning, kostnaden att ta emot trafik, enkel dos pga låg bandbredd och säkert en helt rad till med problem. Modellen att iot ansluter till en server. Och att användaren ansluter till servern kommer nog vara kvar. I mobilnät för iot blockar man ofta kommunikation mellan enheter för att förhindra dessa problem, liknade vad man gör på publika wifi.

Iofs: Med tanke på hur låg beräkningskapacitet en del microcontrollers har är det klart att man inte vill att de ska slösa tid på att droppa connections. Men möjligheten för en giltig kontroller att inte bara få anslutningar från utan också skapa anslutningar till IoT-enheter öppnar för en del förbättringar jämfört med idag.

Det finns i dag i deras usecase, där de listar ipsec över internet eller liknade. Och med IPv6 kommer det nog inte markant ändras hur detta ser ut.

Varför skulle man ansluta IoT-enheter rakt till internet bara för att man kör IPv6? Som standard har ju de allra flesta routrar en brandvägg som blockerar alla inkommande IPv6-trafik som inte är anslutningar initierade av någon enhet på insidan. På det sättet skiljer det sig inte från IPv4 + NAT (där man förövrigt också normalt har en brandvägg utöver NAT).

De routrar som inte har det är sådana riktade mot enterprise-marknaden där enheter bakom den inte ens kan nå internet innan man konfigurerat den. De som använder sådana har rimligen något slags hum om vad de håller på med.

Principiellt skulle jag vilja gå så långt som att säga att även perimeterbrandväggar är ett fulhack som vi har på grund av att majoriteten människor som skriver program inte är bra nog på att tänka i termer av säkerhet, och på grund av att en jobbig minoritet är aktivt engagerade i att tjäna pengar och/eller makt på andras bristande säkerhet. Men eftersom verkligheten ser ut som den gör så har vi naturligtvis perimeterbrandväggar, och jag använder dem själv för att stoppa trafik till/från andras IoT-utrustning. Både in- och utgående trafik är ofta ett otyg i det här sammanhanget, och jag är helt medveten om det.

Jag tror en del av missförståndet mellan oss kan bottna i att vi ser begreppet IoT på olika sätt: IoT är inte bara "en pryl du köper av någon" utan kan bokstavligen vara en liten dator du själv kopplat upp och som kör programvara du själv skrivit.

I många fall ser jag antingen inga nackdelar, eller åtminstone väldigt få fördelar med att ha en hub-and-spoke-arkitektur istället för en decentraliserad arkitektur för detta, om vi inte explicit pratar om tillämpningar där du har multipla identiska enheter du vill hålla koll på. Och även om du har en central kontrollpanel någonstans, varför inte låta (korrekt autentiserade och auktoriserade) styrkommandon gå rakt från en app på din telefon till enheten du vill styra istället för att ta ett extra hopp via någon helt annan server? P2P eliminerar (minst) en felkälla, helt enkelt. Och P2P minskar också trafikens omvägar om du exempelvis kan prata direkt med en kameras webbserver istället för att servern som ger dig materialet ligger i AWS. Igen: Förutsatt att du litar på kamerans webbserver.
P2P öppnar också möjligheter att utveckla lösningar liknande vad Matter-standarden gör, men med Internet som bärande länk, återigen utan behov av extra "nav", om man har en tillämpning där detta skulle vara lämpligt.

Allt detta görs möjligt av IPv6 om man också tänker på säkerheten ute på ändpunkterna. Jag skulle definitivt inte ha något problem med att öppna för någon form av API-trafik generellt till alla enheter på ett givet VLAN om jag styrde vilka enheter som hamnade där och kände mig tillräckligt trygg med programvaran som lyssnade på enheterna.

Tillägg till ovanstående:
Om du inte litar på dem som skriver IoT-programvaran, varför litar du på att samma utvecklare ska vara mer kompetenta i utvecklingen av det centrala navet? 🙂

Det centrala navet är naturligtvis Open Source och granskat av kompetent folk, samt minde kompetent folk (mig). Alltså inte mjukvara från anonyma kineser.

Diskussionen är intressant. Om man har IPv6 som privat- eller företagskund, tilldelas man ens fler än en IPv6-adress? Att man får ett /56 delegerat prefix är ju uppenbart, men prefixet ska ju routas via en viss adress.

En ISP skulle väl relativt enkelt kunna implementera att en privatkund får just en enda IPv6 + DP och därmed tvinga fram användandet av en router? I det läget är det en icke-diskussion att IoT-enheter hamnar på internet eftersom router i praktiken innebär brandvägg som hindrar all inkommande trafik, ifall man inte själv öppnar.

Du får gärna tycka att perimeterbrandväggar är fulhack, jag tänker nog mer på det som ”defense in depth”.

Jag har IPv6 från Bahnhof. Jag kanske får åka och köpa en switch för att se hur många parallella /56-nät eller enskilda enheter jag kan exponera ut på internet…

Men både du och jag vet att det inte är vad som händer i praktiken för kommersiella produkter.

Håller med om defense in depth, och det är vad jag i praktiken gör också, men jag ser ingen principiell skillnad mellan att ha en välkonfigurerad webbtjänst bakom en perimeterbrandvägg som öppnat för port 443 (i en ren stateful brandvägg) eller för https (i en applikationsbrandvägg) och att ha samma välkonfigurerade webbtjänst presenterad rakt mot Internet bakom serverns egen brandvägg. Routers på vägen har du ju ändå, bara att de (om du inte bor i Kina) är öppna för de flesta sorters trafik och bara berättar för klienten hur den kommer till nästa hopp. I en IPv6-situation kan jag i teorin sätta min router öppen för all inkommande trafik för alla protokoll till och från mitt segment, och lita till brandväggarna i mina olika datorer att bara släppa igenom trafik jag vill se på dem. I verkligheten, eftersom vissa människor är som de är, skulle jag troligen ändå sätta någon form av rate limiting i min centrala router för att inte slutpunkterna skulle behöva filtrera absolut all trafik som försöker nå dem, men med mindre än att det finns uppenbara brister i protokollen bör ju i princip vad som helst som du kan skaka fram som använder teknik från de senaste fem-tio åren klara av att hantera åtminstone upp till gigabithastigheter av trafik utifrån.

En perimeterbrandvägg minskar attackytan, vilket knappast skadar. Så länge man sedan kan släppa igenom trafik rakt till/från en enhet (via IPv6) så ser jag inte vad nackdelen skulle vara. Du får fortfarande alla fördelar.

Detta är irrelevent dock eftersom min kommentar var en reaktion på det implicita påståendet att IPv4 + NAT är bättre för att vi minskar risken med IoT-prylar direkt anslutna till internet då. Min poäng var att praktiskt taget alla uppsättningar av IPv6 har en brandvägg mellan så i praktiken är vi lika skyddade med "IPv6 + brandvägg" som av "IPv4 + NAT".

För att "det centrala navet" (routern) uppdateras regelbundet medan IoT-prylen i många fall inte uppdateras alls eller enbart några enstaka gånger. Många av IoT-enheterna kommer ju redan från början med sårbar mjukvara och resurserna som läggs på den mjukvaran tenderar att vara väldigt begränsade, vilket troligen är själva grundorsaken.

Pratar man om egna servrar eller liknande är det ju en annan sak, men när man diskuterar IoT-prylar med dålig säkerhet är det oftast inte dessa man syftar på, vilket gör dem ganska ointressanta i sammanhanget.

En del ISP:er ger dig en IPv6-adress för din routers WAN-interface (tror att det handlar om enbart en eller ett fåtal), men detta är egentligen onödigt då det går utmärkt att din router och nästa hopp i kedjan kommunicerar med varandra via deras Link-Local-adresser. Eftersom man med IPv6 får nät tilldelade och routade till sig istället för enskilda IP-adresser så kommer man behöva någon enhet som agerar router. Min routers WAN-interface har ingen IPv6-adress annat än sin Link-Local.

Man tilldelas normalt ett /56 som privatkund via prefix delegation, dvs. 256 st /64-nät. En switch bör inte göra att du får fler /56-nät, men det vore ju faktiskt lite intressant att testa. Det finns ju dock någon stor ISP i USA som enbart tilldelar dig ett /64 istället för ett /56 (eller ett /60 som jag tror Comcast kör med), men det går att begära ut flera separata /64 så pfSense/OPNsense har ett fulhack inbyggt för att göra detta.

Tekniskt sett behöver ju en router inte nödvändigtvis också agera brandvägg, även om den rimligen gör det för i princip alla användarna i praktiken. Det är som du säger därför en närmast obefintlig risk som inte på något sätt borde tillåtas hämma utrullningen av IPv6.

Jag tror vi håller med varandra i stort - min egen reaktion var en spark mot tanken på att fortsätta tänka IoT i samma gamla termer som man varit tvungen att göra hittills på grund av brist på publika IP-adresser.

Här, däremot, pratade vi förbi varandra. Det "centrala navet" jag pratade om var inte något i ditt eget nätverk, utan den ofta molnhostade serverlösning IoT-leverantören erbjuder för hantering av IoT-enheter. Poängen är att om leverantören har usel säkerhet på sina IoT-enheter, vad har du som kund för orsak att tro att inte deras managementlösning också läcker som ett såll så fort någon petar på den?

Tyvärr är väl IoT-prylar förmodligen de som riskerar att sakna IPv6-stöd.

Det är ju definitivt en risk, ja. Rent generellt behöver man göra sin research innan man köper IoT-prylar.

Ja, det rör sig åt rätt håll. Många IoT-prylar är dock inte så moderna tyvärr.