> V dnešním světě IoT přibývá různých zařízení, která se mají
> propojovat mezi sebou, ale současný internet to neumožňuje.
> (...)
> Internet chytrých věcí by měl využívat princip end-to-end,
> který je základem internetové sítě. Můžete se přímo připojit
> z mobilu k chytré krabičce a ovládat ji přímo. Protože k tomu
> je internet určený. Obvykle to ale vyžaduje nějakou konfiguraci,
> takže je to odsouzeno ke komerčnímu neúspěchu.
Jenže i na IPv6 bude pravděpodobně po cestě nějaký firewall, takže ani s ním to nebude plug-and-play.
Přesně tak. Uživatel bude muset zjistit IP adresu toho zařízení, otevřít přístup ve firewallu, a pak při připojování zadávat ten šílený řetězec IPv6 (vlastní doménu skoro nikdo nemá). Nebo zařízení bude používat centrální server, což bude fungovat out-of-the-box.
A umíte si představit, že výše uvedený postup dělá třeba vaše matka, aby zprovoznila nějakou "chytrou" zásuvku?
Poznam aj lahsie cesty.
Cez UPnP sa da nastavit firewall alebo broadcastovat klientom, kde je to zariadenie v sieti na prve nastavenie. Vo Windows to maju integrovane v GUI a system zariadenie najde ako sietove zariadenie - staci dvojklik a ste na jeho webe.
V dnesnej dobe sa to riesi vacsinou aplikaciou na smartfon, ktora najde to svoje zariadenie a potom si zapamata jeho IP. Tu by to automaticky fungovalo aj z inej siete.
Pri firewalle je samozrejme treba urcit, kto ho spravuje. Ked lubovolne aplikacie, tak netreba potvrdenie. Technicky je lahke vypytat si vo Web UI potvrdenie na to, co chcela aplikacia spristupnit cez UPnP.
A umíte si představit, že výše uvedený postup dělá třeba vaše matka, aby zprovoznila nějakou "chytrou" zásuvku?
Ano, u své mamky si to představit dovedu. Je jí sice 66 let a nejvyšší vzdělání má střední školu, ale nemá problém se učit a když něco neví, tak se zeptat.
Jakákoliv technologie se stává nebezpečnou, když člověk neví co dělá a je líný se naučit ji používat a znát alespoň v obrysech její výhody a úskalí.
Pokud někdo není schopen/ochoten naučit se, co je to "adresa", nechť chytré zásuvky nepoužívá. IPv6 pro potřeby uživatele není o nic složitější záležitost, než telefonní čísla nebo poštovní adresy... Dělat "chytré technologie" pro blbé uživatele je největší chyba současné společnosti.
16. 6. 2020, 10:11 editováno autorem komentáře
Vidím to úplně stejně, hlavně pod tu poslední větu bych se podepsal. Teda tím nechci říct, že by každý musel být odborníkem na všechno, to nejde, ale aspoň nějakou míru znalosti o tom, co dělám/s čím pracuju je potřeba mít.
Bohužel mi ale přijde, že pro lidi (rozuměj BFU) je důležité, aby všechno bylo co nejpohodlnější, aby to "myslelo" za ně a aby všechno bylo nejlíp hned. Že tím přichází o soukromí nebo tam mají bezpečnostní díru jako vrata, to nikoho moc nevzrušuje.
Jste v zajetí současných síťových stereotypů. Co kdyby to fungovalo tak, že si zákazník donese domů zařízení, do telefonu nacpe dodanou aplikaci, oboje se při prvním zapnutí napojí na server a vyřeší si nastavení? Od té doby se zařízení spojují napřímo BEZ serveru. TEPRVE AŽ nezafunguje automatické nastavení (server nejede, nebo rovnou výrobce zkape), bude holt uživatel muset zvednout p*del a nastavit to ručně, ale nebude muset zařízení VYHODIT! Co je na tom tak nepochopitelného?
No nevím, znáte nějaké zařízení, aspoň jedno, které by takhle fungovalo?
Já se zatím setkal jen se 2 možnostmi:
1) zařízení se stabilně připojuje někam do cloudu a odesílá tam cokoliv chce na nějakých vysokých portech nebo naopak na :80 či jiných běžně otevřených portech, předpokládá se, že kdo neumí nastavovat jednotlivá zařízení, neuměl ani nastavit firewall na routeru
2) zařízení používá nějakou řídící krabičku v LAN, samotné dílčí zařízení pak broadcastuje do LAN nebo používá nějakou metodu aktivního párování na HW, čili třeba posílání identifikace po stisknutí tlačítka. Krabička samotná se pak buď ovládá zase z cloudu nebo "je určena pro profesionály", takže používá webové rozhraní na lokální IP.
Varianta 1) je velice oblíbená výrobci, protože jim přináší krom samotných zajímavých dat naprostou kontrolu nad tím, kdy donutí uživatele koupit si nové zařízení. Stačí po uplynutí záruky přestat to zařízení v cloudu podporovat. Varianta 2) je přijatelně levné řešení, které se tváří "profesionálně". Zařízení řízená nějakou aplikací v mobilu jsou vždycky připojená na cloud, protože je tím zajištěný krom telemetrie problém s nastavením a jednotný přístup odkudkoliv.
Variantu 1) jsme dělali taky, ale proto, že jediná jistota byla, že pojede IPv4. Co jsme dělali IoT bazmeky, tak nebyl s mirror serverem problím strhat 10Gbps linku a cena za servery a jejich provoz na pět let byla asi 1/3 ceny výrobku.
S tímhle, pokud by byla možnost jet jenom na IPv6, by se výrobek stal (cenově) hodně konkurence schopný. Jenomže to by museli ISPíci taky začít to IPv6 podporovat...
Momentálně největší problém s IoT a IPv6 je fakt, že se z LTE člověk nepřipojí, kdyby se na ptáka stavěl. Aspoň ne u nás. Kdyby tak aspoň to 5G udělali na IPV6, jinak je to na dalších 15 let beznadějný...
Ten firewall bude jako kde? Uvnitř jednosegmentové sítě s čínskou krabičkou (případ garáže) asi ne. U uživatelů, kteří upřednostňují pohodlí před bezpečností, může být firewall vypnutý (jejich věc). A u těch, kteří chtějí bezpečnost, jej holt budou muset nastavit, ale to je jaksi podstata sítí, o tom nemá smysl polemizovat.
@L: Nevím, v čem je problém. IoT většinou stejně jede jenom na MQTT, ZMQ a pár daších standardech, nechat přslušný porty otevřený není problém a když na ně někdo poleze na jiným zařízení, tak to prostě dropne. Pokud to zařízení podporuje, autorizuje se nějakým klíčem (ECDSA apod.). Není to o nic nebezpečnější, než nechat povolenou 22ku. Hotovo.
A pokud jde o spárování, tak třeba Bluetooth má unikátní ID, něco jako MAC adresu. I když dělám vývoj a něco s BT tam bylo a dokonce občas BT i používám, nedal bych ruku do ohně za to, kolik to ID má bitů. Prostě jsem ho nikdy ručně neopisoval a jenom jednou v životě jsem v nějaké zprávě deklaroval pro tohle číslo pole. Myslíš, že pokud se chc, tak se zadávání adresy nevyřeší?
A víš, že používám Syncthing po IPv6 bez toho, že bych konfiguroval cokoliv na firewallu, nebo nastavoval adresy? A funguje to dokonce i mezi mobilama (SLAAC + Private Extension). A synchronizovalo se to i předminulý víkend, když jsem si hrál se sítí a nechal omylem pět dní zakázaný DHCPv4 v LANce a nemělo to IPv4 přes WiFi (LTE doma vypínám). Prostě si přes server vymění adresy a jede se napřímo... A server si můžu spustit i doma v LAN.
Bluetooth má standardní MAC adresu (v tuto chvíli 48 bitů/6 byte), ale jestli mluvíte o UUID služby v rámci Service Discovery Protokolu, to má historicky 16/32 bitů, ale dnes se používá prakticky výlučně 128 bit UUID, na která jsou tato mapována (vložením do prvních 32 bitů hodnoty XXXXYYYY-0000-1000-8000-00805F9B34FB, kde 00000000-0000-1000-8000-00805F9B34FB je Bluetooth Base UUID).
Ta posedlost hodit každé zařízení na internet mě docela děsí. Je to obrovské bezpečnostní riziko ...
Za rozumné minimum bych považoval, že všechny tyhle pračky, teploměry a podobné nesmysly uzavřu do samostatné vlan a před to strčím velmi restriktivní firewall - protože ta zařízení prostě nejsou a nebudou bezpečná. Jenže takhle si to zapojí možná trošku paranoidní IŤák, co má doma i chytřejší switch a trošku ponětí o tom jak ty věci fungují. BFU to strčí všechno do jedné sítě a pak se bude strašně divit, že mu domácí NASku nebo notebook někdo hackne zkrz pračku, která je permanentně připojená do nějakého podivného cloudu.
IPv6 tomu moc nepomůže, protože kolik operátorů domácímu uživateli dá takový rozsah, aby si ho mohl rozdělit na víc /64 do různých vlan ? To samozřejmě neni problém samotné technologie ale toho jak se to implementuje.
Jenze zamostatna VLAN se da smysluplne udelat jen tak, ze jsou site oddelene i na L3. A taky nastava potiz, kdyz provider prideli jen IPv6 segment /64 (jak je bezne, kdyz uz nekdo IPv6 adresu dostane. To umoznu je provozovat jen jedinou L3 sit, protoze prestoze 2^64 adres je dost, tak /64 sit je dale nedelitelna (z vice duvodu, i kdyz se to muze podarit rozdelit, je to mimo standart a casem se najde nejake nechtene prekvapeni).
Už im to funguje? Super. Teraz trocha posuniem bránku: dá sa použiť ich modem v bridge mode s vlastným routerom? A aj annoncujú AFTR cez DHCPv6? (Vážne neviem, preto sa pýtam).
Ja som v tej situácii, že mám k dispozícií UPC, pomalé DSL (lebo stred mesta) alebo LTE (merané dáta a stred mesta). Takže mám UPC, s modemom Hitron v bridge mode, teda napevno v IPv4 sieti a so statickou IPv4 adresou.
Keďže výber v rámci UPC v čase keď som robil prípojku bol statická IPv4 + router aký chcem, alebo DS Lite + povinne Compal v router mode, tak výber bol ľahký, aj keď to znamená žiadne IPv6.
Na Compalu jim to funguje už nejmíň od roku 2017 (ale už jsem zažil i takový kus, který bylo pro rozfungování prefix delegation resetovat do defaultu). Tenhle router je ale taková hrůza, že nepomůže ani mít ho v bridge. Např. to, že v IPv4-only režimu (i v bridge) shapuje 6in4 provoz, takže všechny tunely s IP protokolem 41 jedou max. 20 Mbps.
Ve středu města mám na PPPoE DSL lepší latenci, jitter a plnohodnotný dual-stack. Jen tu rychlost nedoženu (100/10 vs. 500/30).
Ad adresa pomocí DHCPv6 a DHCPv6 option s AFTR - technicky jim to funguje, ovšem někdo moudrý rozhodl, že ten Compal ani jiný modem s podporou IPv6, který nabízejí, nebude možné přepnout do bridge. Asi proto, že jsme podle Liberty Global všichni příliš neschopní pořídit si vlastní CPE s podporou DS-Lite. Takže je to prostě "jen" zakázané. :-(
Zdroj. :-)
Jediný zdroj, který k tomu mám, je můj blogpost, ve kterém jsem tohle chování (poprvé pozorováno v letech 2016-2017, když jsem na Compal přešel, a naposledy viděno před pár dny na úplně jiném Compalu s jiným firmwarem) zadokumentoval:
https://zajic.v.pytli.cz/2020/06/15/pomale-ipv6-tunely-s-modemem-compal-od-upc-vodafone/
Jde o pozorování na vícero nezávislých linkách a kusech modemů, tzn. nejde o problém jednoho kusu.
Je to spíš bug než featura a podle všeho už to někdo řeší. Jestli to vyřeší, to je jiná otázka.
Radek Zajíc na nějakém IPv6 dni zmiňoval, že tohle řeší přes Hetznera, kde se dá o dodatečné /64 požádat nebo si je nějak naklikat snad. Jestli Vám stačí 20 TB za měsíc (většině tohle asi stačit bude) tak to je asi docela dobrá volba. Za ca. 3 € na měsíc to myslím je dost ok. Hlavně tam můžete dobře rozchodit např. Wireguard.
https://www.hetzner.com/cloud?country=cz
Jinak existuje např. tunel od VPSfree v režiji Ondřeje Caletky: https://kb.vpsfree.cz/informace/projekty/ipv6tunel
https://www.linuxdays.cz/2017/video/Ondrej_Caletka-IPv6_tunely_pomoci_OpenVPN.pdf
Jinak asi Hurricane Electric Free IPv6 Tunnel Broker
https://tunnelbroker.net/
16. 6. 2020, 15:05 editováno autorem komentáře
Žádal je o to kolega, jde o /48 a platí se za to nějaký ne úplně malý poplatek (bohužel to teĎ nemůžu dohledat a na webu o tom nepíšou). Prakticky bude lepší použít vpsfree (výhodou je geolokace do CZ) nebo IPv6 VPN od švýcarského serverhostingu Ungleich (https://ungleich.ch/ipv6/vpn/).
Problém bude mnohem víc to, že BFU neví že něco takového má vůbec řešit. To že lidi jako my tu situaci nějak vyřeší, považuji za samozřejmé. Jestli vytáhneme od operátora alespoň /56 pro IPv6, použijeme pouze lokální IPv4 a NAT, nebo to vyřešíme nějak jinak ... to je pouze technická věc.
Ale případů, kdy nějaké IOT zařízení se stane prostředníkem pro útok na zařízení v interní síti bude prostě čím dál víc. Osvěta je kolem toho nulová a každý výrobce tlačí svoje ultra chytré zařízení ovládané přes aplikaci zkrz cloud. Možná jsem paranoidní ... ale ja takových věcí prostě fanouškem nejsem a zařízení ve své síti chci mít co nejvíce pod kontrolou.
V tom se shodneme. Jako vývojář HW + embedded to vidím takto:
1) Konektivita stojí peníze. Za HW, SW a testování. Pokud nepřinese bonus pro zákazníka, který je ochotný zaplatit, tak je nesmysl se připravit o zisk, nebo být dražší než konkurence.
2) Pokud tam už nějaká komunikace musí být, je lepší volit dráty. Protože rušení, odposlech, vysoký vysílací výkon (nejlešpí přítel akumulátorů a baterií) a cena (když připočítám homologace atd.)
3) Pokud jde o interní komunikaci systému, je lepší volit jednodušší a levnější řešení ( jako Modbus po RS-485 nebo CAN ), než se drbat s TCP/IP, web serverem a zabezpečením.
4) Pokud chci ze systému ven, je lepší udělat gateway (nebo komunikační kartu). Uživatel získá jedno rozhraní (ne 20 webů na 20 krabičkách), já jako dodavatel chybu v komunikaci ven opravuju na jednom místě v jednom produktu (ne zvlášť vypínač, zvlášť zásuvku, zvlášť lustr,...) a gateway si koupí jenom ten, kdo o ni stojí. A mám tam dost výkonu (ty nářky, že teploměr nedá ani AES a MD5 jsou na kopanec špičatou botou).
5) Pokud si povolím přístup z veřejné sítě, zodpovídám za průšvihy a musím řešit záplaty. Ať si zákoš připlatí za podporu. A pokud mám tunelovat NATy a řešit podobný kulišárny, ať si to taky zaplatí.
Je, ale ve světě IPv6 to znamená /64 pro každou VLANu. A když nějakým zázrakem ISP přidělí jenom /64, je vymalováno. Všechno na jedné hromadě (špatně), nebo ULA prefix a NATování (ještě horší, pak IPv6 ztratí smysl).
Momentálně doma jedu na šesti sítích:
0. WAN mezi routerem a modemem
1. LAN (klasicky komply s Linuxem, záplatovaný a relativně bezpečný)
2. "Špinavá" síť pro mobily, telku s HBB, WiFi,...
3. IPTV pro set top boxy + pronajatý stroje, o kterých vím jenom to, že mají víc než dva roky starý FW
4. WiFi pro hosty
5. IoT síť, kde je třeba tiskárna apod., do které se dá dostat jenom z LAN a špinavé sítě
6. Síť pro management, kde můžu konfigutrovat APčka, switche, router,... a je přístupná jenom z LANky
7. Ani to nepočítám jako síť, ale servisní rozhraní z modemu mám trunkem přihozený jako VLANu na switch v pracovně, kdybych něco musel řešit.
Je super, že mám /56 prefix. Jinak by to byl docela problém...
Nikdo to nechce, nikdo to nepotrebuje, end-to-end komunikace predstavuje zejmena pro IoT neskutecne riziko.
Pulka tech kramu ani nema moznost sifrovani, spousta z nich nema autentizaci, nebo se neumi aktualizovat. Implementace tcp/ip je zhusta zalostna.
Raspberry pi fakt NENI typicke produkcni IoT zarizeni, uz kvuli jeho spotrebe, velikosti a narocnosti na napajeni.
Typicky je spis china made singlechip, jaky se treba strka do pracek Candy, nebo ty "chytre" krabicky na radiatorech.
Dokonce i arduino je na hranici pouzitelnosti se svou proudovou spotrebou.
Vstup do domu pres internet je diagnoza hodna odborneho zajmu docenta Chocholouska.
A posledni poznamka, jediny prinos IDN je snazsi oklamani uzivatele utocnikem.
> Vendor lock není přeci daní verzí protokolu. Pokud IoT bude svázané se službou výrobce tak bude prostě svázané a 4 vs 6 na tom nic nemění.
Presne. Niektorí si len mýlia príčinu a zdôvodnenie. Poväčšinou vendori chcú, aby dané zariadenie bolo zviazané s ich službou, NAT alebo ne-NAT, firewally a ne-firewally.
To není vždy pravda. Byl jsem u zrodu jedné cloudové IoT služby a první verze se snažily připojovovat z cloudu přímo na zařízení uživatele v jeho síti. Hodně úsilí se věnovalo nápovědě a nástrojům, které uživateli usnadňovali nastavení portforwardingu, ale stejně drtivá většina uživatelů to nezvládla.
Pak jsme začali dodávat krabičku, která tunelovala spojení ze sítě zákazníka na naše servery a byl to úspěch. Hlavně v USA je cena v řádu desítek dolarů naprosto zanedbatelná proti tomu, když se technik může při zprovozňování služby na několik hodin nečekaně zaseknout u zákazníka a řešit port forwarding.
Kdyby existovalo technické řešení, které jednoduše umožní zákazníkovi nastavit přístup na zařízení v jeho síti z našich serverů, rozhodně bychom ho použili a nebabrali se s vývojem vlastního HW, jeho distribucí, reklamacemi atd.
No ja som videl všeličo, aj hard-coded DNS (napr. aj Chromecast má napevno 8.8.8.8), pretože podľa daného výrobcu mnohí zákazníci mali rozbité DNS.
Pripájanie sa zvnútra siete von bude vždy jednoduchšie, ako naopak. Je jedno, či je tam NAT alebo nie je, či tam je IPv4 alebo IPv6. Vy ako vendor si to na svojej strane ošetríte, a na strane zákazníka to má väčšiu pravdepodobnosť fungovať, pretože by default to firewally v CPE umožňujú.
Od telemetrie ktorá sa dá predávať ďalej po umelé ukončenie podpory
Když píšete, že to je oproti provozu serverů podstatný přínos, asi znáte alespoň rámcově cenu takových dat. Bylo by logické, kdybyste ji ve svém komentáři uvedl.
po umelé ukončenie podpory a donútenie zákazníka kúpiť si novšie modely
Jasně, pokud výrobce uměle ukončí podporu, budou zákazníci celí žhaví koupit si od něj něco dalšího.
> Když píšete, že to je oproti provozu serverů podstatný přínos, asi znáte alespoň rámcově cenu takových dat. Bylo by logické, kdybyste ji ve svém komentáři uvedl.
Ono to závisí prípad od prípadu, ako každá cena v enterprise. Čo by Vás mohlo nasmerovať je to, že cena smart TV je nižšia ako cena hlúpych TV panelov (resp. tie už nie sú ani dostať). Je to práve kvôli post-sale monetizácií (<= kľúčové slovo pre Google). Je k tomu aj vyjadrenie CEO jednej firmy vyrábajúcej TV, ale to už nechám na Vaše google-fu.
> Jasně, pokud výrobce uměle ukončí podporu, budou zákazníci celí žhaví koupit si od něj něco dalšího.
A predsa to funguje. Všimnite si príklad vyššie - "a čo si mám kúpiť, keď na trhu nič iné nie je?". Dôvod, prečo na trhu nič iné nie je, pretože by to bolo drahšie, a všetci by aj tak kupovali lacnejší produkt so všetkými jeho nevýhodami. Ukážkový príklad pre race to the bottom.
Mňa osobne to tiež neteší, či už preto, že niektorí výrobcovia sa snažia vytriasť doslovne poslednú korunu zo zákazníka, z dopadu na životné prostredie, a aj z dopadu na spoločnosť ktorá prepadá konzumu. Tiež by som mal radšej zariadenia z Vášho imaginárneho sveta. Bohužiaľ, také v našom reálnom svete nie sú.
Televize se řadí mezi IoT krabičky? A je závislá na serverech výrobce? Která značka?
Všimnite si príklad vyššie - "a čo si mám kúpiť, keď na trhu nič iné nie je?".
Ten se týká volby ISP. Nebo jste myslel jiný příklad?
Bohužiaľ, také v našom reálnom svete nie sú.
Protože je u nás nedostatečná podpora IPv6.
> Televize se řadí mezi IoT krabičky? A je závislá na serverech výrobce? Která značka?
Medzi IoT sa radí všeličo. SmartTV sú jedny zo zariadení, ktoré tak rady komunikujú s materskou loďou a zbaviť ich konektivity keď ju už raz mali môže byť problém. Niektoré dokonca vyhľadávajú nezamknuté wifi v okolí a skúšajú to cez ne, keď im nedáte heslo ku svojej. Je len otázka času, kedy budú obsahovať SIM kartu a riešiť si konektivitu vo svojej réžii. Áno, aj to sa stále oplatí.
> Ten se týká volby ISP. Nebo jste myslel jiný příklad?
Ten istý prístup môžete aplikovať na ľubovoľný segment, nemusí to byť len práve ISP. Postoj zákazníkov je v tomto konzistentný.
> Protože je u nás nedostatečná podpora IPv6.
Aj taký Chromecast spomenutý vyššie závisí od serverov Googlu, bez nich na ňom nezafunguje ani DNS (lebo 8.8.8.8 je napevno). Rovnako nepodporuje IPv6, iba IPv4 - a nie, nie je to nedostatočnou podporou IPv6 v Českej republike. Na to Google zvysoka kašle.
Medzi IoT sa radí všeličo. SmartTV sú jedny zo zariadení, ktoré tak rady komunikujú s materskou loďou a zbaviť ich konektivity keď ju už raz mali môže byť problém. Niektoré dokonca vyhľadávajú nezamknuté wifi v okolí a skúšajú to cez ne, keď im nedáte heslo ku svojej. Je len otázka času, kedy budú obsahovať SIM kartu a riešiť si konektivitu vo svojej réžii. Áno, aj to sa stále oplatí.
Asi o něco přicházím tím, že SmartTV nemám, ale moc mne nenapadá, proč bych se ke SmartTV připojoval (tj. byla by v roli serveru) přes síť, snad leda bych chtěl programy přepínat mobilem. Stejně tak si nedovedu představit, že existují SmartTV, jejichž hlavní funkce je závislá na nějakém serveru výrobce.
Ten istý prístup môžete aplikovať na ľubovoľný segment, nemusí to byť len práve ISP. Postoj zákazníkov je v tomto konzistentný.
Aha, takže ISP schválně omezí funkčnost nějakého serveru, aby si u něj zákazník koupil novou službu. A zákazník má na výběr v jedné lokalitě z tisíců ISP. Ne, neřekl bych, že se utility chovají stejně jako spotřební zboží.
Na to Google zvysoka kašle.
Chromecast je jeden příklad. Podle mne má tedy Google nemalý podíl na tom, že se v ČR začalo IPv6 reálně řešit.
moc mne nenapadá, proč bych se ke SmartTV připojoval (tj. byla by v roli serveru) přes síť, snad leda bych chtěl programy přepínat mobilem.
Třeba si můžete nechat přeposlat TV kanál na mobil/tablet. Tj. rodina se dívá na velkou televizi, jeden člen se dívá v pokoji na jiný kanál. Nebo naopak. Máte v mobilu nějaké video a "vhodite" ho na velkou televizi.
@bez přezdívky:
Ony existují tři možnosti placení:
1) Někdo cenu dotuje. Typicky reklamou, kterou musí být kde zobrazit. Nějak si nedokážu představit, že by třeba domácí zabezpečovačka na textovým displeji 2x20 znaků zobrazovala reklamy a upoutala tím pozornost, takže tohle úplně doména IoT nebude.
2) Objednám si službu (např. připojení k internetu) a techniku k tomu mám v pronájmu, nebo je zápujčka v ceně služby. Jako zákazník o pravidelně platím. To se u IoT dá jenom v případě, že neprodám zařízení, ale službu (střežení objektu apod.) s tím, že je na faktuře nějaká cena podle kapacity DVR, počtu kamer,...
3) Koupím si zařízení a očekávám jako platící zákazník, že bude fungovat. Za to zařízení od okamžiku prodeje výrobce neuvidí ani korunu. Ale musí si koupit server, krmit ho, záplatovat ho, platit konektivitu,... Nebo si za paušál pronajmou kus čmoudu. A co za to dostane? IP adresu ( = geolokace?), kterou by dostal i při stahování update s menším trafficem a aplikační data ( = třeba teplota a směr větru z meteostanice na přesně neznámým místě), za který nikdo nezaplatí ani vindru. Jenomže napřímo to nejde, protože NAT v mobilní síti, CGNAT a NAT na domácím routeru.
To je ale z pohledu zákazníka.
Vycházejte z toho že nejsme v první polovině minulého století a firma nemusí být v defenzivě proti zákazníku. Náš zákazník náš pán neplatí. Měl by to byt rovný postoj obou tedy ani jeden nechce nemá s tím druhý vyj..bat.
Pro výrobce \ poskytovatele není důvod proč by zařízení s podporou iPv6 mělo automaticky být nezávislé na jeho nebo jiné službě. stejně to není důvod proč by tu službu neměl ukončit po x - xx letech provozu. Není to důvod proč by to měl uvolnit pod jednou z mnoha "open" licencí....
Z pohledu výrobce není důvod, proč by
- měl kromě aplikace na mobil, webovýho portálu a zařízení vyvíjet ještě nějakou internetovou službu, která zajistí propojení jejich zařízení se zákazníkem
- chtěl zbytečně platit nějakou infrastrukturu, kde do DB bude co 2s sypat 0.5M klientských zařízení aktuální stav, aby se k tomu mohli připojovat zákazníci a měli data prakticky v reálným čase, když kromě prodeje zařízení na to nedostane ani vindru
- toužil po reklamě "po útoku na datacentrum firmy X vypadly systémy 100 000 jejich zákazníků"
Jenomže to musí strpět, protože NAT v mobilní cíti, CGNAT u ISP a NAT na zákazníkově routeru. Jinak mu to nebude chodit.
Poskytovatel služby nemá ekonomický zájem dělat cokoliv, co mu nepřinese kačáky. Tlumočení mezi zařízením a mobilem mu prachy nepřináší, ale odčerpává (infrastruktura navíc). Ale NAT, NAT, NAT,...
Martin Prokop: Ne, je to z pohledu prodejce zařízení. K tomu, aby bylo zařízení na provozovateli dostatečně závislé, nemusí téct veškerý provoz toho zařízení přes infrastrukturu výrobce. Jak píše Petr M., výrobce dostane peníze od zákazníka jenom při nákupu, a pak už má jen náklady na provoz infrastruktury,kterou musí provozovat aspoň tak dlouho, aby nepřišel do řečí, že si od něj něco koupíte a za chvíli to přestane fungovat. Monetizovat ten provoz možná dokážou výrobci černé elektroniky, ale na anonymizovaných datech o otevírání a zavírání ventilů topení asi nezbohatnete.
Internet Info Root.cz (www.root.cz)
Informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2021 Internet Info, s.r.o. Všechna práva vyhrazena.