Vlákno názorů k článku Získat IPv6 dnes není pro poskytovatele problém, stačí ji dovést k uživatelům od Peter - Ne, že bych IPv6 zavrhoval, ale tak dlouho...
-
Peter (neregistrovaný)
Ne, že bych IPv6 zavrhoval, ale tak dlouho ten vývoj probíhal, různéskupiny k tomu přibalili spoustu funkcní, které stejně nikdy pořádněfungovat nebudou. Co mne konkrétně na IPv6 vadí:
1. nefunguje DHCPv6 na mobilních zařízeních, konkrétně android Samsung.(možná novější už to podporují, nevím.) Mobily použivají jen nabídnutýprefix od routeru, a k tomu použijí privacy extension.
2. V případě připojení PC dvěma rozhraníma (jedno např. public, druhýv management segmentu), DHCP připojené přes relay nemá, jak přidělitoběma rozhraním různou IP adresu. DHCPv6 je postavené na DUID, jezdnoznačnýidentifikátor, který se ovšem posílá na všech net-ifacech stejný.
3. Síťové prvky moc často nepodporují RA guard. Tedy dostáváme se o20 let zpět, kdy fungovali ARP útoky, kdež to ARP inspekce už navíce řazeních existuje.
4. Privacy extension je noční můra pro dohled. Příve stačilo monitorovatARP a MAC tabulku, kde bylo X záznamů. S PE narostou dramaticky nárokyna dohled. Je nutné ukládat všechny vycucané IPv6 adresy klientů a párovatje s použitým portem klienta. U IPv4 je 1 záznam na 1 klienta u IPv6 jichje několik do hodiny. V případě velké sítě a skladování informace několikměsíců databáze pěkně naroste.
5. Nedostatečná podpora ze strany klientských routerů pokud dostanou přesDHCP PD. Ne každé klientské zařízení si s tím poradí.
6. Různorodost DUID typů. Aktuálně jsou 4 typy DUID identifikátorů.Potíže s přiřazením rezervované IPv6 adresy pro klienta, protožeDUID je spojeno s operačním systémem. Pokud někdo na stejném HW provozuje3 systémy, každý z těch systémů si vygeneruje jiné DUID a tedy na DHCPserver pošle 3 různé požadavky - tedy těžko se pak děla rezervace IPadresy - obvzlášť je potíž, pokud DHCP je za relayem...
7. HW nároky na router/switch. Nároky na držení IPv6 v paměti enorměvzrostly. Sice výrobci IPv6 podporují, ale už vám neřeknou, že jev HW místo jen pro X IPv6 adres a při jeho překročením zařízeníse přepíná do SW zpracování, protože HW má limitované místo. Nemluvímtady o zařízeních za Y mil, ale běžná zařízení. Ty nároky na vše v HWšíleně vzrostly - s privacy extension se problém násobí, protožeswitch/router musí držet info o mnoha adresách per klient.Je rozdíl mít v paměti routeru 100k IPv4 prefixů vs. 100k IPv6 prefixů.Nebo v případě access switche mít 2000 ARP (6bytových) záznamů vs.2000 * (16bytů) * X, kde X je počet adres vygenerovaných dle privacyextension měněných každou chvíli.
8. Potíže můžou dělat i rozšířené hlavičky. Případně použítí fragmentaces rozšířenýma hlavičkama. Další možný vektory útoku na síťový provoz.Opět, co se v počátku jevilo jako dobrý nápad je v reálu pěkný průšvih.Protože výzkum nepředpokládá, že ten návrh někdo zneužije, a všichni,že tu fci budou používat dle RFC. Realita je však jiná.
9. Osobně nechci, aby byly různa IoT zařízení vystavena do netu.(Mnohem rozumnější mi přijde, když je vystavena nějaká proxy, která tyzařízení zastřešuje).Některá zařízení co mám doma, měli podporu od výrobce cca 3 rokypo koupi. Tím, že jsou zařízení za NATem, a téměř s okolním světemnekomunikují, jsou alespoň +- uchráněna od útoku zvenčí. Protože budouděravá, jak řešeto. S IPv6 je rozhodně nezbytnost mít použitý stavový FW,což ovšem rozbíjí myšlenku volnosti v přístupu k zařízením z vnějšíhosvěta. Toto beru z pohledu "dědečka", který si jisto jistě nebudekonfiguovat FW a nastavovat, na které adresy se může komunikovat zInternetu a na které ne. S IPv6 vidím jako zásadní potíž vzniku megabotnetů s mil. napadených ledniček. Chápu, že někdo preferuje otevřenosta právě tu možnost přístupu z vnějšku, ale majorita společnostitoto není schopna bezpečně provozovat.
Tedy jak pro koho je 6tka dobra. Urcite nekomu se libi ale ... mouchy tam jsou a poradne.
-
m4ITqHKyewTsYIbBPoRX (neregistrovaný)
K bodu 4:
Proc bys mel zaznamenavat kazdou, i vycucanou z prstu, adresu? Proste vis, ze zakaznik X ma prefix 2001:db8:85a3:8d3::/64 a zakaznik Y ma prefix 2001:db8:85a3:abcd::/64. Tebe zajima jen hornich 64 bitu, co se deje s tema spodnima ti muze byt ukradene. Naopak ti to logovani znacne zjednodusi. -
Peter (neregistrovaný)
Zákazníci/uživatelé dostávají (mohou si brát) IPv6 ze sítě /64, tedy to /64 není unikátní per uživatel... Tedy v té IPv6 síti (/64) je cca 250 klientů, co má 250 IPv4 adres a cca 400 IPv6 adres, asi ne všichni klienti mají povolené IPv6. Monitoring musí dohlížet všechny, ne jen prefix,protože ten je pro všechny společný. Logování prefixu by fungovalo, pokudby ISP dávalkaždému uživateli jiný prefix, ale to nebývá ještě zvykem. Taky je otázka,jestli klient nemůže použít pak jinou IPv6 (z jiného prefixu)...
-
m4ITqHKyewTsYIbBPoRX (neregistrovaný)
Ja ti moc nerozumim. Ty jako ISP dostanes dejme tomu /29 a z toho rozdelujes prefixy na jednotlive pripojky.
Na jednu pripojku das /64 a zbytek neresis. Co si s tim prefixem udela spravce te pripojky je jeho vec, klidne si muze vsech 2^64 adres naaliasovat na jedno rozhrani.
Az za tebou dojdou policajti s tim, at jim identifikujes kdo pouziva adresu 2001:db8:85a3:abcd:0123:dead:beef:cafe, tak jen mrknes do databaze a podle hornich 64 bitu vidis, ze tu adresu mel nekdo z pripojky psane na Frantu Vomacku z Horni Dolni 26.
Pockej, ty chces rict, ze existuji ISP, kteri maji jednu /64 pro vsechny?
-
Petr M (neregistrovaný)
A proč musí být koncová síť monitorovaná par uživatel? Ze zákona nic takovýho neplyne. Tohle vymýšlí možná tak ocásci na pražským magistrátu do lamp, aby moli šmírovat lidi.
A i kdyby, jak podle DUID ztotožnit konkrétní osobu/zařízení, pokud je nemám v registru (čímž by se z DUID stal osobní údaj a museli by dávat souhlas)?
PE je navrženo proto, aby házelo klacky pod nohy šmírákům jako ty. A koukám, že se to celkem daří.
-
Peter (neregistrovaný)
Myslim ze jsi nepochopil k cemu PE je navrzeno. PE neanonymizuje adresu pred isp ale pred poskytovatelem sluzby. Isp ma moznosti jak zjistit komu dana ipv6 patri.
Koncova sit musi by monitorovana ze zakona. Kdyz prijdo cajti s papirem od soudu tak je nutne identifikovat majitele ipcka.
-
Petr M (neregistrovaný)
Tak ať nedává jednotlivý IP adresy, ale /56, jak si zákazník zaslouží. Pak ho taková drobnost, jako mobil s Androidem přes WiFi, nedokáže rozhodit.
Pokud je blbec a nechce se mu platit 27 tyček/rok za vlastní IP adresy, tak ať si platí 50 tyček/rok za standalone logování a dva lidi navíc na řešení problémů, který si nadělá nestandardním řešením. Je to jeho boj.
-
Petr M (neregistrovaný)
Blbost.
"Myslim ze jsi nepochopil k cemu PE je navrzeno. PE neanonymizuje adresu pred isp ale pred poskytovatelem sluzby."
Ne, PE anonymizuje od prvního routeru dál, takže i u ISPíka. Ten totiž nevidí neighbor discovery apod. v lokální sítiu zákazníka.
"Isp ma moznosti jak zjistit komu dana ipv6 patri."
Tak si nestěžuj, že to nejde.
"Koncova sit musi by monitorovana ze zakona."
Koncová síť je až za posledním NATem. Logovat musí poskytovatel připojení (ISP) a ten nemůže vidět z principu koncovou síť. Ani technicky (nat, firewall, rozdělení na routeru), ani legislativně (firma nesmí dát ISPíkovi seznam zaměstnanců a IP adresy jejich strojů).
"Kdyz prijdo cajti s papirem od soudu tak je nutne identifikovat majitele ipcka."
Ne. Ty můžeš maximálně identifikovat osobu, která má daný rozsah (ekvivalent IP adresy) přidělený v době, které se to týká. Nic víc. Takže ti stačí tabulka v CSV, kde je prefix a zákazník. Vyřešeno.
Představ si, že dáš hospodskýmu z putyky u cykostezky /56, on si jednu z 256 podsítí (nevíš kterou) vybere jako free WiFi pro hosty, někdo z druhýho konce republiky během výletu stahuje z mobilu skrz jeho free WiFi něco co nemá. A pak přijdou za měsíc švestky a budou tě mlátit pendrekem, dokud jim neřekneš jméno, adresu a rodný číslo toho výtečníka.
Nebo když někdo z práce hackne banku a má připojení dejme tomu od UPC, tak na základě IP adresy budou chtít identifikaci viníka od UPC? Těžko.
-
KateStříbrný podporovatel>Tím, že jsou zařízení za NATem, a téměř s okolním světemnekomunikují, jsou alespoň +- uchráněna od útoku zvenčí. Protože budouděravá, jak řešeto. S IPv6 je rozhodně nezbytnost mít použitý stavový FW,což ovšem rozbíjí myšlenku volnosti v přístupu k zařízením z vnějšíhosvěta.
A k tomu NATu firewall potřeba není? A myšlenku to nijak nerozbíjí. Myšlenka je, že z vnějším světa může uživatel komunikovat se vším u čeho to potřebuje, rozhodně ne že bude z internetu přístupná i lednička a televize.
-
KateStříbrný podporovatel
Eh, cože? Pokud má uživatel defaultně restriktivní firewall s IPv6, bude to stejně bezpečné jako teď s NAT a restriktivním firewallem, nic konfigurovat nemusí.
Pokud chce mít něco vystavené venku, má to s IPv6 snazsí a s IPv4 NAT občas nemožné.
-
Sten (neregistrovaný)
NAT bez firewallu není nijak bezpečný, je dost snadné jej obejít. Většina domácích routerů ale má NAT se stavovým firewallem, s IPv6 tak zahodí NAT a nechá firewall. Uživatel nemusí nastavovat vůbec nic. Zásadní rozdíl oproti IPv4 s NATem je ale v tom, že pokud uživatel chce, může nastavit některé IPv6 adresy do DMZ nebo povolit nějaké porty pro vnější přístup a ono to funguje. S NATem je to dost problém, třeba VoIP je bez proxy sázka do loterie.
-
Peter (neregistrovaný)
S vypnutym fw ne protoze je tam kvuli ipv4 a natu ale bezne dodavaji vyrobci toto zarizeni kde je k tomu ipv6 bridgovana... obavam se ze bez ipv4 zmizi stavovy fw nebo bude defaultne vypnuty. Vyrobce si umyje ruce protoze vse bude fungovat, tj klientovy projdou vsechna data ale bude to otevrene do celeho sveta...
-
KateStříbrný podporovatel
Načež ho pár průšvihů přinutí přehodnotit defaultní nastavení. Navíc, spousta routerů je už teď předkonfigurovaných od ISP a na tom se nejspíš moc nezmění. A provideři zřejmě na síti nebudou chtít bordel.
-
Peter (neregistrovaný)
Tady se motají dvě zařízení a fugování sítě mezi ISP -klientský router-klientská sít. Ja mluvil o chování klieského routeru. Už jsem viděl zařízení jistého výrobce, který IPv6 řešil tak, že ji bridgoval mezi porty. A IPv4 routoval. Vím není to pěkné, ale i takové výrobky jsou na trhu.
-
m4ITqHKyewTsYIbBPoRX (neregistrovaný)
Tak se mrkni na https://tools.ietf.org/html/rfc4389 a zjistis, ze NDP Proxy je prakticky bridge.... bavime se o tom stejnem, akorat ti rikam jak se to spravne jmenuje...
-
SB (neregistrovaný)
To je taky pravda - když budu třeba chtít povolit VoIP pro všechny počítače v podsíti, u IPv6 stačí JEDINÉ pravidlo na fireválu. Když to budu chtít pro 4ku pro x počítačů, tak to je x * pravidlo NATu s rozstrkáním po portech + 1 pravidlo ve fireválu, přičemž budu muset těm venku vysvětlit, na přes který port se komu dovolají. Obdobně u jiných služeb.
-
Petr M (neregistrovaný)
"nat pro ipv4 je pro klienta bezpracny."
Tak to ani náhodou. Musí si zvolit IP adresu NATované strany, navíc tak, aby nekolidoval s žádnou používanou VPNkou (v IPv6 mu přijde celosvětově unikátní prefix automaticky), musí nastavit počáteční adresu DHCP poolu a jeho velikost (v IPv6 je to celá síť /64). Musí nastavit pravidla na FW, aby rozsah NATu dropnul z WAN rozhraní, jinak se to dá snadno prostřelit (v IPv6 nemusí privátní adresní rozsah používat, tak ho neřeší). Musí nastavit maškarádu (v IPv6 neexistuje). Atd.
-
KateStříbrný podporovatel
verejná ipv4 s natem už rozhodně není nic běžného. Ale pokud ipv4 s natem mám, opravdu se můžu snadno připojit na kterékoliv zařízení v síti bez šachování s forwardingem portů?
Dvě věci s otevřeným portem 80 budu mít taky dost těžko… Teda, řešení to má, třeba pokud mám k oběma doménu, teď si to doma nastavuju, ale že by to byla stejná funkce jako s IPv6? To fakt ne, že?
-
Santiago (neregistrovaný)
> Ale ano potřebuje, ale pak už nedává smysl použítí ipv6, protoze se to stejne dostane na funkci ipv4 s NATem.
To je casty omyl, ale neni tomu tak. Skrz firewall bez NATu je mozne navazat ptp spojeni, pokud je navazovano z obou stran zaroven s pomoci verejneho zprostredkovatele (napr. VoIP nebo ptp hry).
-
ja (neregistrovaný)
Bod 1: to je feature, nie bug, a moze za to Google, urobili to naschval na vsetkych androidoch:
"Implementing stateless DHCPv6 does not provide much in the way of additional functionality above what Android 5.0 supports. ...Implementing stateful DHCPv6 would break planned use cases such as IPv6 tethering (which would require implementing IPv6 NAT in order to work with DHCPv6) and 464xlat on wifi (which requires that the device be able to use more than one IPv6 address). It also has greater privacy implications than stateless autoconfiguration and DHCPv4. Stateful DHCPv6 will provide the ability to connect to IPv6-only networks that don't use RDNSS, but because stateful DHCPv6 will in general not provide the two IPv6 addresses that are required to run native and 464xlat, such a network will not support IPv4-only applications; this will impact users, because they won't be able to use applications such as Skype, Hangouts, and many others."
-
Peter (neregistrovaný)
Protože nevíš, jestli v síti ti poběží jen mobilní zařízení. Může se stát, že v jedné síti chceš provozovat stanice i mobilní zařízení. To nebude asi přesně případ ISP a domácího připojení, ale třeba nějakého podnikového řešení. Příkladem třeba síť zaměstatnanců a jejich mobilních zařízení. Tam pak DHCPv6 dává smysl. Řešením, a neříkám, že špatným, je pro mibilní síť udělat separátní siť, kde nebude DHCP a pro zaměstnanecké PC udělat DHCP (s rezervací IPv6 adresy). Jen zmiňuji vlastnost, že DHCP nepodporují všechna zařízení a od některých zařízení bych to chtěl. Z mého pohledu IPv6 není dotažena.
-
Petr M (neregistrovaný)
No a co se stane, když v jedné síti jede RA + PE a DHCPv6? Stroje, který používají DHCPv6, dostanou nějaký adresy. Stroje s RA budou mít stejný prefix, ale vygenerují si náhodná 64b číslo. Pak se zeptají, jestli je někdo používá a pokud je obsazeno, zkusí další. Dokud se netrefí na volnou IP adresu. Takže pokud DHCPv6 nevnutíš dvěma strojům stejnou adresu, máš šanci n:2^64, že se připojením stroje s DHCPv6 trefíš na používanou adresu (n je počet zařízení s PE v síti).
-
Peter (neregistrovaný)
To by vcelku fungovalo. Ale dám příklad, v prostředí, kde to takto fungovat nebude. Potíž může být v tom, že někteří klienti nechtějí generované a nezapamatovatelné IPv6 adresy, ale nějaké kratší, které si zapamatují. Tedy nechtějí RA s nabízeným prefixem + PE, ale statickou IPv6 adresu (samozřejmě s tím správným prefixem pro danou síť). Problém má netadmin - při povolení statické adresy mu hrozí, že si klienti "ukradnou" adresu. Tedy v tomto případě je nutnost vyžadovat DHCP. OK, tak to nastaví pro běžná PC, kde to DHCPv6 +- funguje. Ale nastane potíž, pokud chceš v stejné síti provozovat i mobilní zařízení, protože ty zase DHCPv6 nepodporují. Prostě IPv6 má za léta vývoje jistou volnost v použití a tím, že zavedení trvalo leta, tak si každý z výrobců zvolil nějakou cestu. A nyní je z toho jeden guláš, s kterým se ne moc dobře pracuje - teda z pohledu netadmina. Z pohledu uživatele je to fajn, dám něco do sítě, ono to nějak bude fungovat a dostanu se na to odkudkoliv.
-
Petr M (neregistrovaný)
Ne, klient chce konektivitu. Jestli je to po čtyřce, šestce nebo kouřovýma signálama je mu buřt. IP adresy jsou přece pro stroje a těm je to jedno, hlavně že to chodí. Pokud klientovi někdo nakukal, že si potřebuje ručně měnit IPv6 adresu, dej po tlamě tomu, kdo šíří takový bludy a je to vyřešeno.
Pokud potřebuje navazovat spojení, ať použije DNS na nějaký server. Vzhledem k mobilitě, změnám konektivity, napájení z baterek (a tím i úsporným režimům), omezené kapacitě SD karty i paměti nedává server na mobilu/tabletu smysl. Naopak si živě dokážu představit tethering a podbný aplikace, který s DHCPv6 nebudou pracovat.
-
Petr M (neregistrovaný)
Přesněj, potřebuje tři věci.
První je , že obě zařízení mají IP adresu.
Druhá je, že na sebe zařízení vidí
Třetí, že zařízení, který inicializuje spojení, musí znát IP adresu protistranyPokud chceš z mobilu na web, potřebuješ IP adresu web serveru, web server nemusí tušit, že existuješ. A v rámci komunikace mu svou adresu předáš.
Otázka je, co je tak zásadního na mobilu, abys ty zvenčí inicializoval spojení s mobilem. A smysl toho počínání nějak nevidím. Teda vidím, ale to se uživateli nebude líbit - pokusit s vybrakovat maily, SMSky, kontakty a hesla.
-
Filip JirsákStříbrný podporovatelOtázka je, co je tak zásadního na mobilu, abys ty zvenčí inicializoval spojení s mobilem. A smysl toho počínání nějak nevidím.
Například všechny notifikace. O příchozím e-mailu, zprávě, zpoždění vlaku, blížící se bouřce, propadu akcií… Dále skryté notifikace, tedy takové, které uživateli nic nezobrazí, ale iniciují nějakou akci – aktualizace kalendáře, aktualizace kontaktu, nahrání souboru na sdílené úložiště, aktualizace jízdních řádů, map, aplikací, údajů o počasí… -
ja. (neregistrovaný)
Notifikacie su presne ten dovod, preco mobilne zariadenia drzia dlho otvoreny a idle connect na server Google/Apple/Amazon/Microsoft/Baidu/whatever. Tam by ale ani IPv6 nepomohlo, bolo by treba nejake dalsie discovery ako namapovat danu instanciu na IP adresu. Operatori pred nejakymi 15 rokmi uspesne zabili moznost, ako tento mechanizmus naviazat na SIM kartu (wap push).
-
Filip JirsákStříbrný podporovatel
Tam by ale ani IPv6 nepomohlo, bolo by treba nejake dalsie discovery ako namapovat danu instanciu na IP adresu.
Třeba DDNS? A nebo Mobile IPv6. -
Petr M (neregistrovaný)
No ale z praktickýho pohledu, pokud mám zařízení napájený z baterek, tak ho nemůžu držet online jenom kvůli notifikacím. Tohle by měl spíš, než stroj trvale udržovaný online, řešit mechanismus sítě s tím, že bude někde u operátora cache, do které ty notifikace dojdou a a okamžiku synchronizace se sítí se načtou i ty notifikace. Nevím jak teď, ale dřív se kvůli handoffu v GSM síti připojoval mobil co šest minut na BTSku a tam se to dá spojit s vyčtením dat. Pokud adresu cache zná protistrana, může do ní hodit notifikace a pokud ji zná mobil, může si je vyzvednout.
Poslouchání na nějaké IP adrese, když to není potřeba, jenom zbytečně vyžírá baterku.
Btw, pokud jde o doručení, tak snad jenom ten kalendář, když by nebylo dobrý čekat, až se někdo hodinu po události uráčí začít mobil používat. Třeba chybějící kontakt v telefonu nevadí do chvíle, než začneš listovat seznamem, takže zrovna tam notifikace moc nedávají smysl.
-
ja. (neregistrovaný)
Ano, zerie to baterku, ako velmi sa da jednoducho overit: ako dlho vydrzi mobil, ked sa mu vypnu data, v porovnani s rovnakym pouzivam, ale so zapnutymi datami?
Zacal s tym ActiveSync, ktory progresivne zvysoval interval medzi keep alive, az kym mu to naozaj netimeotovalo. Potom sa hodil o jeden krok spat. Postupom casu sa islo na hranu toho, co sa da zvladnut, napr. v casoch 3G radio potrebovalo az nejakych 30 minut idle, aby sa dalo do uplneho kludu, comu by posielanie keep alive paketov moc nepomohlo. Preto jedno z prvych opatreni bolo, ze to moze robit iba system, nie pouzivatelske aplikacie, pretoze ziadny developer by do toho nedal tolko optimalizacie (aj na strane serveru, aby tam nezahadzovali connecty ktore by normalne uz boli davno timeoutnute). Samozrejme medzitym aj operatori pochopili, ze spolupracovat chcu, pretoze notifikacie zostavaju a nikam neodidu, prve roky smartfonov bol pre ich infrastrukturu sok a ked nechcu dalsie soky, bolo by fajn spolupracovat a nerobit prekazky (ako vyssie spomenute pochovanie wap push, co by bol presne efektivny mechanizmus, kde by siet podla IMSI vyhladala mobil, zobudila ho a dorucila spravu, a navyse nefunkncy napr. na wifi. Ale chranili si trzby z SMS...).
V optimalizacii, ako a kedy sa drzi spojenie spociva aj kazdorocne oznamovanie Googlu pri uvedeni novej verzie Androidu, ze zase zapracovali na spotrebe. Tusim vo v7 zacali pouzivat akcelerometer, ze ked sa mobil nejakych 30 minut nepohol, tak ho ma pouzivatel niekde polozeny, spojenie sa zahodi a notifikacie nechodia. Obnovi sa, az ked sa telefon pohne.
-
Filip JirsákStříbrný podporovatel
Proč by zařízení mělo být on-line kvůli notifikacím? Když vám někdo volá, dokáže síť najít mobil a probudit ho za dobu, kterou je volající ochoten čekat, než mobil na druhé straně začne vyzvánět. Je nějaký důvod, proč by úplně stejně nemohlo fungovat navázání TCP/IP spojení?
Když začnu listovat seznamem kontaktů, chci ho mít aktuální, a ne aby mobil teprve začal zjišťovat, co se změnilo, a vzápětí zjistil, že nemá přístup na internet.
Ve skutečnosti je to úplně opačně. Existuje nějaký důvod, proč by si měl mobil složitě zjišťovat, jestli se něco nezměnilo, když může dostat zprávu v okamžiku, kdy ke změně dojde? To, že existovala nějaká technická omezení, a děláme to kvůli nim komplikovaně, neznamená, že si to musíme komplikovat navěky.
-
Filip JirsákStříbrný podporovatel
Spotřeba a omezení běhu rádia jsou důvody, proč používat spojení navazované v okamžiku změny. Když přidám nějaký kontakt jednou za týden, jednou za týden se naváže spojení a přenesou se data. To je mnohem efektivnější, než když se mobil bude každou hodinu ptát, jestli se něco nezměnilo, a pak jednou za týden se opravdu něco přenese.
-
neregistrovany (neregistrovaný)
To je jednoduche: server, ktory o danej notificii vie, sa nedokaze spojit s danym mobilnym zariadenim. Ono moze byt za 4 NATmi a 10 firewallmi a server to zo svojej strany jednoducho neda. Naopak to ide, zariadenie sa vie spojit s konkretnym serverom, akurat nevie, kedy moze prist notifikacia. Preto zariadenie drzi connect, tak dlho ako moze a co najefektivnejsie, ako moze.
Notifikacie nie su len kontakty, ale aj IM spravy, u ktorych sa akosi predpoklada, ze si ich adresat precita skor ako za tyzden. Predsa len, su "instant".
-
PetrM (neregistrovaný)
Nemusí být jenom za 10 NATy a 10 firewally, ale třeba v tunelu nebo v kapse turisty na dně Macochy. Prostě na to, že se k mobilu připojím, se nedá spolehnout.
Takže mobil musí spát a jednou za čas se pokusit spojit s okolním světem (a to "jednou za čas" může být v řádu minut).
IM je kapitola sama pro sebe. Pokud nemám nainstalovanou aplikaci, tak zpráva nedojde vůbec. A pokud necháš dotazování v režii aplikace, tak jasně, že ti vysaje nejenom soukromí, ale i baterku.
-
Filip JirsákStříbrný podporovatel
Takže mobil musí spát a jednou za čas se pokusit spojit s okolním světem
Tím, že to budete pořád opakovat dokola, z toho pravdu neuděláte. Proč by se měl mobil každou chvíli dotazovat, zda není něco nového, když může dostat zprávu v okamžiku, kdy opravdu něco nového je? Co je pro vás výhodnější – chodit se každý den zeptat na poštu, zda tam nemáte dopis, nebo v klidu sedět doma a počkat, až přijde pošťák s dopisem? -
Ondra Satai NekolaZlatý podporovatelRáno se vzbudit a brnknout na poštu. Lepší než když ve dvě v noci zazvoní pošťák s pohlednicí a dožaduje se podpisu.
-
PetrM (neregistrovaný)
Počítal sis to, jak to vyjde na spotřebu?
Pokud přijímač má spotřebu 10mW a vysílání 1W, navázání spojení 20ms a přenos notifikace 20ms, pak platí, že
- sám přenos je zanedbatelných 11.11e-6 Wh (1W * 0.04s = 0.04J = 11.11e-6Wh)
- pokud bude trvale poslouchat po dobu jednoho týdne, za tu dobu se přenese jedna notifikace: 10mW*168h = 1.68Wh, sama zpráva je zanedbatelná.
- pokud se bude dotazovat po pěti minutách, tak to je 12 dotazů za hodinu, tj. 12*168=2016 dotazů/týden. Marný dotaz je 0.02J, tedy 2015*0.02 + 1*0.04 = 40,34J = 11.2e-3 WhTakže řešení "trvale na příjmu" je v tomto případě 150x žravější (!!!), než se po pěti minutách probudit a zeptat se serveru. Dá se ospravedlnit, když s mobilem něco děláš a máš otevřenou tu aplikaci (ale pak může komunikaci s pevným serverem otevřít ta aplikace), ale ne když mobil spí.
-
Filip JirsákStříbrný podporovatel
Počítal jsem si to, 3×5 je 15, takže notifikace jsou 133,5× výhodnější.
Zkuste si to promyslet, pomalu. Mobilní telefon. Zaměřte se na to slovo telefon. Telefon je určený k volání. Volání funguje tak, že se vám někdo rozhodně zavolat, vytočí vaše číslo a za chvilinku začne váš telefon vyzvánět. Stop, teď se zastavte a projděte si to pomalu ještě jednou, dvakrát. Už to vidíte? Mobilní síť a mobilní telefonu spolu spolupracují tak, že během chvilinky od vytočení čísla dostane váš mobil notifikaci „někdo ti volá“, mobil se probudí a začne vyzvánět. Na LTE lze dokonce i ten hlas přenášet přes IP vrstvu, aby nebylo nutné udržovat zvláštní protokol – a do budoucna se počítá v mobilních sítích s přenosem hlasu jenom přes IP. Takže v tom případě mobil ani nedostane notifikaci „někdo ti volá“, ale „přišel ti nějaký paket“. Je vám to povědomé? Ano, „přišel ti paket“ je přesně ta zpráva, kterou potřebujeme mobilu doručit i při jakékoli jiné IP komunikaci, třeba při navazování TCP/IP spojení. Takže ten mobil už dnes takhle poslouchá, jenom kvůli tomu, aby bylo možné se na něj dovolat. Takže řešení „trvale na příjmu“ je přesně o 0,0000 Wh žravější oproti současnému stavu „trvale na příjmu“. Co žere baterku navíc je to, když se mobil musí úplně zbytečně probudit a navázat spojení aby se dozvěděl, že není nic nového a zase se uspal.
-
neregistrovany (neregistrovaný)
Pani, pri mobiloch oddelujte paketovu cast (packed switched, data) a prepojovany spoj (circuit switched, hlas).
Zariadenia s mobilnym systemom mozu byt v rozlicnych stavoch:
- moze to byt telefon, ktory ma sim a je vo svojej domovskej sieti,
- moze to byt telefon, ktory ma sim, je vo svojej domovskej sieti, ale nema z nejakeho dovodu data (napr. mimo dosah),
- moze to byt telefon, ktory ma sim a je momentalne na wifi (subscriber moze a nemusi mat datovy program),
- moze to byt telefon, ktory ma sim a roaminguje,
- moze to byt telefon, ktory ma sim a roaminguje, pricom nema povolene data v roamingu,
- moze to byt telefon, ktory teraz ziadnu sim nema a je teraz na wifi,
- moze to byt telefon, ktory nikdy ziadnu sim nemal a je teraz na wifi,
- moze to byt telefon, ktory ma vymenenu sim (napr. servisnu) a je vo svojej domovskej sieti,
- moze to byt telefon, ktory ma vymenenu sim (napr. servisnu), teraz je na wifi,
- moze to byt tablet, ktory ziadnu sim nema, mat nebude a je teraz na wifi,
- moze to byt telefon/tablet, ktory ma/nema sim, ale momentalne je uplne offline, ci uz dobrovolne alebo nie.1. Medzi tymito stavmi sa da plynulo prechadzat, a ked telefon takyto prechod zaregistruje, tak uz je neskoro niekam nieco posielat, napriklad aj preto, ze uz nie je ako.
2. Mobilna siet rozlisuje jednotlive terminaly pomocou IMSI. Serveru, ktory sa chce dohovorit s nejakym zariadenim, je IMSI nanic, pretoze a) ho nepozna, vie ho iba SIM karta a b) aj keby ho poznal, tak na neho nedosiahne standardnym TCP/IP, ale jeho prevadzkovatel by musel mat nejaku gateway v sieti operatora (a to znamena zmluvy a peniaze medzi prevadzkovatelom notifikacnej gateway a kazdym jednym operatorom, takze sa na to co? Spravne, vykaslu).
Takze mechanizmus, ktory sa pouziva na zostavenie hovoru alebo poslanie SMS, je nepouzitelny.
2b. Pouzival chce dostavat tie spravne notifikacie; ked ma aplikacia koncept pouzivatelskych uctov, napr. email, tak notifikacie maju chodit pre spravny ucet, bez ohladu na to, aka sim je vlozena a v akej sieti sa zariadenie nachadza.
2c. Bod 2. by neriesil zariadenia, ktore su na wifi alebo inu sietovu konektivitu, ktora nie je naviazana na sim kartu.
3. Ako to bolo x-krat povedane, klient zvycajne vie kontaktovat server, bez ohladu na to, v akej sieti sa nachadza, ci uz 2G/3G/LTE alebo wifi, ale naopak to byva problem a) kvoli routovatelnosti IP klienta zvonka, lebo neverejne adresy za NAT, b) kvoli dynamickosti danej IP, lebo roaming medzi rozlicnymi sietami c) kvoli zariadeniam dropujucim pakety smerom ku klientovi, lebo firewally po ceste.
4. To, ze zariadenie udrzuje connect, neznamena, ze stale vysiela. Moze otvorit connect a ked cez neho nic neprejde nejaky cas, tak fyzicka vrstva (radio) prejde do idle. Connect je stale otvoreny! Casom bud timeoutne (a vtedy ho zariadenie obnovi, zvycajne v nejaky prihodny cas, ked user aj tak nieco robi, alebo sa nazbiera viac dovodov, preco zapnut radio. Chvilu to trva, ale zase notifikaciam tie stovky ms nevadia), alebo pred timeoutom posle keep alive (ked sa so sietou dohodlo, ze aky dlhy cas treba na timeout a zariadenie uznalo za vhodne, ze je fajn drzat ho otvoreny). Pokial zariadenie preroamuje, tak pri inicializacii v novej sieti otvori novy connect s tym istym tokenom, co mal stary, aby server na opacnom konci zaregistroval zmenu. Ani Apple, ani Google nie su hlupaci a robia pomerne chytre optimalizacie, kedy a ako sa connect obnovuje.
-
Filip JirsákStříbrný podporovatel
Důležitý je akorát ten bod 4. A z něj je podstatné to, že dnes musí být kvůli NATům a dynamickým IP adresám to spojení navázané z mobilu a pak průběžně udržované při životě, když bude to zařízení mít stálou (alespoň tak, že je možné ji dát do DDNS) veřejnou IPv6 adresu, je možné to úvodní navázání spojení a jeho udržování při životě vynechat, čímž se trochu ušetří baterka. Ano, Apple i Google mají to udržování živého spojení optimalizované, ale pořád je to energeticky náročnější, než nedělat to vůbec.
To, že se mobil může nacházet v různých sítích, řeší např. Mobile IPv6.
-
me (neregistrovaný)
Pak je tady jeste jeden prakticky problem, operatori chteji za mobilni data platit, pripadne maji ruzne omezeni FUP. V momente, kdy ma mobil IPv6 adresu na kterou se muze kazdy pripojit, tak koncovy uzivatel nema vubec zadnou kontrolu nad tim, kolik dat na jeho mobil pritece... A je nepravdepodobne, ze by koncovy uzivatel mohl nejak konfigurovat firewall, ktery by jej ochranil. I kdyby tam nebyl zadny FUP a data byla zadarmo, prijem dat o ktera nezadal, bude mit dopad na vydrz baterie; DoS.
Je to podobny problem jako obsluha udalosti v programovani. Lze pouzit "interrupt", nebo "pull", tedy pravidelne overovani stavu. Kazdy pristup ma sve vyhody, takze se pouzivaji oba...
-
me (neregistrovaný)
Predpokladam, ze az bude na mobilu IPv6 konektivita, tak bezny uzivatel dostane subnet /127 a bude tam velmi omezujici firewall, ktery zablokuje prichozi pripojeni. S tim subnetem /127 se to taky muze stat, mam jeden takovy server v cloudu a zakladni veci funguji, lze mit WWW server na IPv6, lze se pripojit pres ssh pomoci IPv6.
-
Filip JirsákStříbrný podporovatel
Když je to praktický problém, kdy jste se s ním v praxi setkal? Protože FUP není záležitost jen mobilních operátorů, a spousta operátorů pořád přiděluje koncovým zařízením veřejné IP adresy, a dříve to bylo ještě mnohem častější.
Je zvláštní, jak jsou lidí NATem už tak zblblí, že hledají problémy tam, kde žádné problémy nejsou a nikdy nebyly. Internet bez všudypřítomných NATů fungoval, a z hlediska IP protokolu fungoval lépe než dnes.
Kazdy pristup ma sve vyhody, takze se pouzivaji oba...
Bez stabilních veřejných IP adres bohužel interrupt pro notifikace použít nejde. A oba přístupy se sice používají, ale dotazování se používá především tehdy, když přerušení není k dispozici. Jinak je dotazování výhodnější pouze ve výjimečných případech, zpravidla když je tak velký provoz, že při každém dotazu jsou k dispozici nějaká data. Což ale evidentně nebude případ mobilních notifikací. -
Ondra Satai NekolaZlatý podporovatel
Dotazování má tu výhodu, že si samo zařízení rozhodne, kdy být kvůli němu vzhůru...
-
Filip JirsákStříbrný podporovatel
Když se řekne „každý přístup má své výhody“, myslí se tím, že v některých případech převažují výhody jednoho přístupu, zatímco jindy převažují výhody jiného přístupu. To, že si zařízení samo rozhodne, kdy má být vzhůru, sice je výhoda, ale je dalece převážena nevýhodou, že (v případě notifikací o změnách nebo o příchozích zprávách) je to zařízení vzhůru v drtivé většině případů úplně zbytečně. Což u mobilních telefonů, kde se řeší výdrž baterky, docela vadí.
-
Petr M (neregistrovaný)
Jenomže z pohledu baterek je nejhorší udržet spojení TCP. Optimální by bylo použít protokol nad rádiovou vrstvou (GSM,...), který stejně jako SMS doručí informaci, že zařízení se má připojit na konkrétní server, mobil by se probudil a předal řízení aplikaci, která má spojení na ten server zaregistrovaný. A ta si stáhla data přímo ze serveru.
Tenhle přístup má ale pár problémů:
- Bezpečnostní - donutí mobil připojit se k nějakýmu serveru, ať chce nebo ne
- Bezpečnost komunikace se sererem leží na aplikaci
- Může se připojit jakkoliv, po LTE, WiFi,... I to, co by bylo standardně v síti, si může najít jinou cestu.Každopádně, pokud mobil nemusí být zapnutý, nemusí být dostupný, není známý ani prefix (výhodnější je aktuálně WiFi, nebo je v roamingu), je lepší, když spojení inicializuje mobil. A tam IPv6 s RA + PE ničemu nevadí a DHCPv6 je komplikace.
-
Filip JirsákStříbrný podporovatel
A nebo prostě když je potřeba mobilu něco doručit, navázat ze serveru spojení na jeho veřejnou IPv6 adresu získanou z DNS. A jestli to chce mobil doručovat po LTE nebo po WiFi si mobil určí buď změnou DNS záznamu nebo pomocí Mobile IPv6. Případně, pokud byste se chtěl vyhnout DNS i Mobile IPv6, je možné mobilu poslat mobilní sítí UDP paket, který ho probudí a řekne mu, kam se má připojit. Tahat do toho speciální protokol nad rádiovou vrstvou je nesmysl, když naopak vše směřuje k tomu, že i hlas a vše ostatní bude v mobilu přes IP.
Ale samozřejmě se to dá dělat i mnoha komplikovanějšími způsoby.
-
Filip JirsákStříbrný podporovatel
A zákazníci platí mnohem víc, než by museli, kdyby internet fungoval normálně – tedy jako síť, kde principiálně může každé zařízení komunikovat s kterýmkoli jiným. To je holt ta nevýhoda evolučních algoritmů (jako např. trh), že mají tendenci uváznout v lokálním minimu a musí přijít nějaký vnější zásah, aby se odsud dostaly. Doufejme, že vyhubit IPv4 bude snazší, než bylo vyhubit dinosaury.
-
Unknown (neregistrovaný)
"A zákazníci platí mnohem víc, než by museli, kdyby internet fungoval normálně "
Kdo presne urcuje "normalitu trhu"? ;-)
Zakaznici presne platit tolik, kolik chteji zaplatit za to co je na trhu. Znam minimalne dve domacnosti kde internet neni vubec pritomen (tedy v jedne z nich je na simm karte jednoho potomka), takze nejaka nevyhnutelnost to neni. Mohou platit 0,-
-
Filip JirsákStříbrný podporovatel
Řeč nebyla o normalitě trhu, ale o normalitě fungování internetu. Neurčuje to nikdo, je to dáno – tím, že se komunikuje nejefektivnějším možným způsobem. Když máte vedle sebe dvě varianty, v jedné variantě spolu dva počítače komunikují přímo po nejkratší možné cestě (v internetu), a ve druhé variantě musí někde běžet třetí počítač, přes který jde ta samá komunikace, tak ta první varianta je zjevně efektivnější, protože ušetříte náklady za ten server a v drtivé většině případů jdou pakety kratší cestou (takže zase úspora).
za to co je na trhu
A to je právě ten podstatný detail. Že to, co je na trhu, nemusí být to optimální.Do současného stavu IPv4 a IPv6 se došlo tržní cestou a je naprosto logické, že jsme ve stavu, v jakém jsem – protože zavádění IPv6 teď znamená pro ISP náklady, a výhoda je někdy v budoucnosti, až i ostatní ISP zavedou IPv6. Nebo-li v tomto případě nepůsobí konkurenční prostředí, reps. působí proti zavedení změny, která by znamenala větší efektivitu. Příroda má na to hledání optimálního řešení miliony let a klidně se počká, než přiletí nějaká planetka, aby vychýlila rovnováhu z lokálního minima. Lidé ovšem dokážou věci nahlédnout z odstupu, zjistit, že se současný internet s IPv4 nachází v lokálním minimu, a bylo by fajn to nějak pošťouchnout, aby se z toho lokálního minima dostal a pře sten hrbolek zavedení IPv6 se překulil co nejdřív.
-
null null (neregistrovaný)
@FIlip Jirsák
"Doufejme, že vyhubit IPv4 bude snazší, než bylo vyhubit dinosaury."
No, není stanovené měřítko kterým se to srovná, ale už se ukázalo že to snadné rozhodně není a nebude. Mámenástupce ipv4, tedy ipv6, a přes proklamovanou potřebu a výhodnost to stále jaksi drhne a skřípe. Abys mi rozuměl, já za ipv4 nebo ipv6 nebojuji, ale když se na to tak člověk podívá ...
-
Ondřej CaletkaZlatý podporovatelWrong on so many levels ;)
1. Implementace DHCPv6 není povinná. Android se rozhodl IPv6 neimplementovat. Hlavním důvodem je nedostatečné množství přidělených IPv6 adres. Dnešní Android potřebuje minimálně dvě, jednu pro sebe a druhou pro CLAT, pokud uživatel zapne tethering, potřebuje Android další adresy pro připojená zařízení. Z toho důvodu by na DHCPv6-only sítí fungoval jen velmi omezeně, i kdyby DHCPv6 podporoval.
2. DUID je unikátní identifikátor počítače. Pro každé rozhraní si počítač vytvoří ještě IAID, takže je vždy možné odlišit konkrétní rozhraní. DHCP server by měl umět přiřadit k jednomu DUID více IPv6 adres, přičemž se použije ta, která patří do sítě, ze které požadavek na konfiguraci přichází. Je pravda, že některé implementace DHCPv6 serverů nejsou v tomto ohledu dokonalé, ale to není problém protokolu.
3. Ta ARP inspekce taky nevznikla v zařízeních sama od sebe, musel ji někdo po dodavatelích chtít. Stejně je to i s RA guardem. Větší problém je, že kvůli možnostem řetězení hlaviček, fragmentace a třeba i přeuspořádávání jejich pořadí spojeném s nedokonalostí implementací IPv6 v koncových zařízeních nemusí RA guard vždy fungovat proti cílenému útoku.
4. Pokud monitorujete ARP a MAC tabulku, monitorujte stejným způsobem i tabulku sousedů. Princip je totožný, jen těch adres bude víc a budou delší.
5. Ano, podpora ve spoustě HW produktů stojí za starou bačkoru.
6. DUID je pro vás jako síťového spravce neprůhledné číslo, máte zakázáno zkoumat jeho vnitřní strukturu. Takže vám může být ukradené, kolik různých druhů DUID existuje. Že je DUID v současnosti implementován jako číslo uložené na disku při prvním startu, které se naklonuje při klonování počítače, je implementační nedokonalost, která měla dávno zmizet s obměnou hardware v posledních deseti letech.
7,8. Ano
9. Já zase na oplátku chci mít možnost otvírat garážová vrata mobilem tak, že se mobil připojí k těm vratům a pošle jim správný příkaz. Nechci být rukojmím výrobce, kterému se nebude líbit můj tón v hodnocení na Amazonu a za odměnu mě odstřihne od svého cloudu tak, že už si vrata neotevřu vůbec.
-
Peter (neregistrovaný)
Ad vrata. Toto taky osobne preferuji jen mam obavy ze vyrobce proda 100k vrat. Po 3letech bez supportu. A ve firmwaru vrat nejaky bug co otevre vrata. Nebo taky botnet 100k vrat by mohl byt zajimavy. Podle mne by vsechny tyhle hracky mely byt za jednim bezpecnym rohrnim a ne byt otevreny do celeho sveta. Jinak cloudova reseni taky nemam rad pac tam hrozi potize po padu cloudu nebo konci jeho sluzby.
-
KateStříbrný podporovatel
Jenže na to aby byly za jedním rozhraním prostě NAT nepotřebuju. Stačí mi firewall a VPN, ten NAT je tam opět navíc.
A sice tohle takhle jde i s IPv4, ale je k tomu jaksi potřeba ta veřejná adresa.
-
Peter (neregistrovaný)
Ten NAT tam je jen kvůli tomu, že ve vnitřní síti je kromě vrat ještě maminka, tatínek a dětičky, kteří chtějí na internet a protože od ISP dostali jednu IPv4 (v štastnějším případě - veřejnou) adresu. Ksakru já dnes nic v práci neudělám. Až mne vykopnou, tak budu to budu za vinnu dávat IPv6 :-)
-
KateStříbrný podporovatel
pardon, myslela jsem tím že NAT nepotřebuju pro „schování hraček pod jeden interface“ ani na té IPv6. Prostě, NAT je jen přebytečná komplikace která řeší problém co by vůbec nemusel existovat.
Všechny zmíněné bezpečnostní problémy řeší firewall a to s NAT i bez.
-
SB (neregistrovaný)
1. To je věc Samsungu, ne IPv6. V případě nefunkčního DHCPv4 si taky budete stěžovat na IPv4?
2. Ale každé rozhraní je v jiné síti s jiným prefixem, takže kde je problém?
3. Ano, toto je argumentem. Podpora v zařízeních je žádoucí.
4. Při DHCPv6 PE zapnuté nebudou. Každopádně evidence IP uživatele je obecně nesmyslem, dokonce ani MACu, oboje se může měnit. Smysl dává POUZE evidence linky/portu(?) k zákazníkovi, pak je buřt, zda jsou PE zapnuté či vypnuté, či jaký protokol tam jede. Jaké jsou k tomu prostředky, ale netuším.
5. To je ale pořád dokola problém typu „šyna za tšista a bes ipéféšesť, ale hlafně lefná!“.
6. Vizte 4. - když budete evidovat porty, můžete se na nějakou prcatůru s DHCPv6 vykakat.
7. Nejstarší záznamy se z cache vyhazují, každopádně to problémem může být (ale 100 000?, kde to máte?). Proč chcete místo MAC začít používat IPv6?
8. Na rozšířené hlavičky sere pes. Dokud nebudou prřepracovány, nikdo je zapracovávat nebude, a ani pak to nebude povinné.
9. Tohle se už řešilo - stavový firewall zůstává (tj. nic se nemění).
