Vlákno názorů k článku IPv6 v roce 2013: pokrok je malý, ale je od Ray - Jak je IPv6 skvela, vzjemne jsme se ujistili,...

Co je to IPv6?

Pár "Akademiků" navrhlo něco, za čímž si stojí, protože nemůžou uznat, že to je šmejd. Bojí se toho, že by je příště už nikdo nenechal navrhnout ani dezén na toaleťák. Pak tu je další skupina, to jsou tzn. evangelisté, kteří budou kázat cokoliv, co je podle jejich fanatických kebulek dobré.

No a pak tu jsou admini a programátoři, kteří s tím svinstvem budou jako jediní skutečně pracovat. Ti samozřejmě vědí, že IPv6 je hnůj, ale když se ozvou, jsou "těmi druhými" označeni za blbce.

Podívejme se na EURO, to je podobný bastl. Představme si, že by se Japonci vykašlali na svůj jen a udělali společnou měnu s Čínou, KLDR a Afgánistánem.
Dobrá kravina co? No a přesto nám tu někdo tvrdí, že Euro je dobré.
No a to jsou ti stejní evangelisté, kteří jsou schopní tvrdit, že IPv6 je dobrá a ti stejní, kteří tvrdili, že Hitler je dobrý atd, atd, atd.

Ale zpět k IPv6.
Pokud vynechám přenatovaná prostředí, kde se schovává nat za natem a ještě dalším natem, je to poměrně fungující technologie. IPv6 tak řeší jedinou věc a sice je tu pro SW piráty, kteří používají Bittorent. Ano, těm skutečně IPv6 pomůže, na druhou stranu už je jasné, že používání Bittorentových sítí bude postaveno EU mimo zákon.

SIP se nijak zvlášť neprosadil, jako pár ustředen tu je, občas to někdo provozuje, ale co tak sleduji, jsou to spíš jednotlivé výkřiky do tmy.
Pokud srovnám SIP a SKYPE, pak je SIP ubohý přizdisráč, lidé chtějí Skype a ne SIP, kdyby chtěli SIP, tak mají SIP. Tedy zůstává tu jen ten Bittorent.

Například ten argument těch šílených evangelistů, kteří jednou hlásají Korán, pak Křesťanství a pak IPv6, obvykle s rukama od krve a hovnem v hlavě.
"Že když bude IPv6, tak že bude internet internetem, protože bude moct komunikovat každý s každým!"
Problém je v tom, že tihle lidé nerozumí rozdílu mezi Firewallem a NATem.

NAT provádí překlad adres, ale Firewall rozhoduje o tom, jestli půjde relace inicializovat. No a pokud bude na domácích krabičkách pro rozvádění Internetu pořád nastavené defaultní pravidlo "Dovnitř nic, dokud se nebude komunikovat ven, tak se vůbec nic nezmění!"
Na to začnou obvykle ječet, vydávat svoje dementní zvuky a přijdou s argumentem, že na rozvádění internetu bude stačit switch.
Hm, jak switch přiděláte k ADSL lince, to je mi záhada.
Opět se tu ukazuje jejich neschopnost, neznalost a hloupost.
Pořád zde bude nějaký Firewall, který stejně zamezí komunikaci z vnějšku dovnitř, pokud už předtím nebylo spojení navázáno a 99% BFU nic na tom nastavovat nebude, protože prostě ani nezvládnou se připojit na webové rozhraní.

No a teď do mě vy evangelistický zmrdi ;-)

Pár akademiků, mimo jiné AT&T, Boeing, CERN, Cisco, DEC, Microsoft, Novell a Xerox. Samé nevýznamné firmy nesahající Rumovi ani po kolena :-)

Zbytek je akorát ječení a vydávání dementních zvuků, na kterou nestojí reagovat. Snad jen, že takové poznávací znamení lidí, co mají hovno v hlavě, je zatažení Hitlera do technické diskuze.

Od tebe jsem vážně žádný rozumný argument nečekal, tak buď v klidu, nezklamal jsi mě ;-)

Ale abych ti vysvětlil ten tvůj Boeing s Microsoftem.
Pejsek s kočičkou taky vařili dort jen z toho nejlepšího, dali do toho buřty, čokoládu, mlíčko a další samé dobré věci. To ovšem neznamená, že se jim povedl víš ;-)

Současný argument tvých soukmenovců je ten, že "je to za XY NATy".
A to je přece pitomost, ta služba je a vždy bude za XY firewally!

Průměrná domácnost:
ADSL modem: 1. firewall, který pořád bude blokovat spojení z venku
WIFI AP: opět tu bude firewall, který bude blokovat spojení z venku
Zařízení: SW firewall od výrobce OS + další firewall jako součást antivirového řešení opět bude blokovat spojení z venku
BFU to nakrásně stejně nenastaví, aby mohlo něco chodit napřímo.
Ale můžete přijít třeba s tím, že výrobci přestanou firewall do svých zařízení dávat, že :-D a konfigurace se bude dělat pomocí jumperů ;-)

Ale to bych toho po tobě chtěl asi moc ;-)

Obvious troll is obvious

Nevím, jestli správně chápu tvůj post, chtěl jsi říct: "Jsem dežon, nemám žádné agrumenty, ale chci mu to nandat!" ??
Nebo něco jiného?

Já abych to chápal správně ;-)

Ne, chtěl jsem tím odkázat na:
Forma a obsah musí jít ruku v ruce. Sebelepší argument vyžblekotaný na úrovni vesnického idiota je bezcenný.

Je to totiž docela úsměvné ve spojení s tvými příspěvky.

Pejsek a kocicka - dost z toho nejlepsiho - to je naprosto trefne prirovnani. U IPV6 neni vsechno spatne, v zasade je tam i par dobrych myslenek (jako identifikace toku a dalsi). Otazkou ale zustava, nakolik tyhle veci budou fungovat v realu a jak moc ten dobrej dort bude, protoze, jak CptRum napsal, to ze je neco slozeho z dobrych veci neznamena, ze to bude dobre. A to se presne stalo. Kazdej si prihodil neco (mnohdy i dobreho) a je z toho to co z toho je...

R.

Současný argument tvých soukmenovců je ten, že "je to za XY NATy".
A to je přece pitomost, ta služba je a vždy bude za XY firewally!

BFU to nakrásně stejně nenastaví, aby mohlo něco chodit napřímo.

Hmm, expert na P2P jak poleno.

Pokud jsem za firewallem, přes někoho (klidně dalšího klienta, se kterým už mám sestavené spojení) si vyměním IP adresy, pošlu jeden UDP paket a už komunikuju.

Pokud jsem za NATem, napřed si zjistím, jakou mám vlastně veřejnou IP adresu a na jaký port mi to NAT přeloží (můžu zjistit jen přes někoho, kdo může naslouchat na všech UDP portech, má kompletně otevřený firewall a není za NATem), pošlu jeden UDP paket a doufám, že nejsem za stále častějším symetrickým NATem ani že nejsem za stejným vnějším NATem a zároveň za rozdílným vnitřním NATem, protože to jsem jinak v prdeli.

Máš na mysli tenhle rozdíl mezi NATem a firewallem?

Kde chybí věcné argumenty (pokud možno bez badge hooles)... Opakuji, že prvotních veřejných adres pro v4 je dost, z toho ještě třetina přidělených je v různém stupni smrti. NATy jsou právě tím, co řeší všechny LAN, pokud jsou síťaři soudní a zkušení. Jaká úroveň textu, taková úroveň jeho autora...

Kde chybí věcné argumenty, co mělo být na Ruma, ne?

NATy jsou svinstvo.

Prosím rozveď, proč je IPv6 šmejd/hnůj/svin­stvo. Jsem admin a i když píšeš, že bych to měl vědět, nevšiml jsem si.

„SIP se nijak zvlášť neprosadil, jako pár ustředen tu je, občas to někdo provozuje, ale co tak sleduji, jsou to spíš jednotlivé výkřiky do tmy.“

A nemohl se neprosadit právě kvůli tomu, že lidé nejsou připojeni do jedné sítě?

„lidé chtějí Skype a ne SIP“

Lidé chtějí telefonovat. Skype jim to pomocí botnetu umožňuje i když nejsou připojeni do Internetu.

„kdyby chtěli SIP, tak mají SIP“

Nemají, nemají připojení do netu, nemůžou mít SIP.

„Problém je v tom, že tihle lidé nerozumí rozdílu mezi Firewallem a NATem.“

(zdá se mi, že tomu nerozumí většinou hlavně lamy, co se snaží IPv6 umlátit „argumentem“ o nebezpečnosti)

„NAT provádí překlad adres, ale Firewall rozhoduje o tom, jestli půjde relace inicializovat. No a pokud bude na domácích krabičkách pro rozvádění Internetu pořád nastavené defaultní pravidlo "Dovnitř nic, dokud se nebude komunikovat ven, tak se vůbec nic nezmění!"“

Rozdíl je v tom, že FW si můžu nastavit, aby propouštěl. NAT ne.

„Na to začnou obvykle ječet, vydávat svoje dementní zvuky a přijdou s argumentem, že na rozvádění internetu bude stačit switch.
Hm, jak switch přiděláte k ADSL lince, to je mi záhada.
Opět se tu ukazuje jejich neschopnost, neznalost a hloupost.“

Strawman.

„Pořád zde bude nějaký Firewall, který stejně zamezí komunikaci z vnějšku dovnitř, pokud už předtím nebylo spojení navázáno a 99% BFU nic na tom nastavovat nebude, protože prostě ani nezvládnou se připojit na webové rozhraní.“

Co když takový firewall nebude a bude třeba SIP povolovat?

Rume ... asis hodne chlastal ... poslednich 20let ... protoze to je kupodivu doba, kdy tu je IPv6.

Jop ... a mimochodem, SIP pouziva kazdej VoIP provider ... kupodivu.

KapitanRUM: IPv6 tak řeší jedinou věc a sice je tu pro SW piráty, kteří používají Bittorent.

Ne, IPv6 resi hlavne uplne jiny problem. To, jesti domaci uzivatele budou mit verejne nebo privatni adresy je okrajova zalezitost. Skutecny problem je v tom, ze v soucasnosti dosli verejne IP adresy regionalnim organizacim jako RIPE, coz znamena, ze zaprve prakticky nemohou vznikat novi ISP (protoze neziskaji nove adresy, resp. ziskaji jen jednu /22 z posledniho volneho /16 bloku, coz pro seriozni praci moc neni), zadruhe vetsi firmy mohou mit problem zmenit ISP (protoze pokud napr. pouzivaji /24 verejnych IPv4 adres od stareho ISP, tak novy ISP uz nemusi mit po ruce volny blok /24.

Takze to, ze dosly IPv4 adresy, v prve rade znamena omezeni konkurence na trhu ISP.

KapitanRUM: NAT provádí překlad adres, ale Firewall rozhoduje o tom, jestli půjde relace inicializovat. No a pokud bude na domácích krabičkách pro rozvádění Internetu pořád nastavené defaultní pravidlo "Dovnitř nic, dokud se nebude komunikovat ven, tak se vůbec nic nezmění.

Navazat session pres standardni stavovy firewall (kdy obe strany jsou za firewallem a maji nejakeho prostrednika venku, od ktereho se dozvi, ze jedna strana chce s druhou navazat session) je jednoduche - staci, aby kazda strana aktivna zacla se snazit komunikovat s druhou stranou, tim otevre diru ve firewallu i pro prichozi provoz druhe strany.

U nekterych typu NATu to jde taky tak udelat, ale AFAIK se casteji pouzivaji typy NATu, kde to spolehlive udelat nejde (a v okamziku, kdy je pocitac za nekolika urovnema NATu je naivni zkouset jakykoliv NAT traversal).

Ono jde i o ty domaci usery ... nejde jim totiz nabizet sluzby a produkty, ktery jsou primo spojneny s tim, ze koncak ma internet. Jak chces trebas nekomu prodat krabku na ovladani topeni ... kdyz se na ni zvenku nijak nepripoji. Jak chces nekomu prodat ... lednici, ktera bude vedet co je vevnitr, kdyz to zvenku dotycny nijak nezjisti (trebas pomoci appky v telefonu, ktera si hrabne do lednice ... a rekne mu, co ma koupit).

Takhle by se dalo pokracovat - sam si dovedu predstavit desitky vyuziti, ktery sou s NATem realizovatelny velmi obtizne/vubec a vzdy pouze zasahem nekoho, kdo vi co dela. A urcite existujou miliony jinych, ktery si ani predstavit nedovedu.

A co se tyce firewallu ... tak predevsim plati, ze ISP nikde zadny firewally delat nebude (narozdil od NATu), a nastavit na domacim firewallu "povolit lednici" je i pro BFU uloha zvladnutelna, narozdil od "nastavit forward nejakyho podivnyho cehosi ...". Vubec nemluve o tom, ze vetsina zarizeni se uz dneska umi firewallu ohlasit a ten jim muze komunikaci povolit.

NAT není internet, internet je přímá komunikace mezi všemi uzly internetu pomocí protokolu IP. A zkus to vyvrátit :-)
SIP se nerozšířil protože existují NATy. Skype funguje a má úspěch jen a pouze proto, že šíleným úsilím obchází NATy.
Na rozvádění opravdického internetu v domácnostech bude stačit levný gigabitový switch.
K ADSL lince se switch přidá úplně stejně jako se dneska přidává krabice s NATem, prostě bude nová krabička na IPv6 co do ní leze telefonní kabel z druhé strany bude mít čtyři J-45 porty.
Firewall se bude dělat v rámci OS, nebude žádná firewallová krabice. V majoritním OS je firewall nastaven defaultně, BFU ho tedy nastavovat nebude, BFU pouze občas odklepne výjimku jako třeba pro SIP nebo Torrenty.
Teprve lidé co si chtějí doma zřídit malou LAN, tak si pořídí switch s firewallem a porty budou otevírat přes uPNP, ale těch je málo.

Pro SIP ani Torrenty dokonce BFU firewall vůbec nemusí otevírat či jinak nastavovat, ty aplikace si jej otevřou samy pomocí hole punching. Na firewallu je potřeba otevírat příchozí spojení jen pro lokální servery.

Vidis, my neco podobneho mame a je jedno za kolika si firewalama, protoze principielne, pripojvoat se na krabicku je, prinejmensim, hovadima. Krabka se nekam sama hlasi (oblibeny cloud) a user si tam leze prez mobil, cokoliv chce mit u sebe. Cili, za mne, ikdyz presne tyhle krabky taky delame, nevidim NAT jako jakykoliv problem. Naopak, kdyz jsou tam dalsi redundatni kanaly (GSM, druha dira do netu, ...) tak to ani jinak *nejde*.

R.

Sbery dat, EZS systemy, ... aplikaci je hafo. Nekdy jde o cenu ($1 uz udela doce hodne), jindy o spolehlivost - aby byl SW napsany co nejmensi, jindy zase o vydrz - mensi CPU byvaji vyrobene sirsi technologii a z tohoto pohledu maji daleko vetsi vydrz. Krom toho, uLinux, na CPU co nema MMU, pusti jen sebeverah :) A ty co maji MMU jsou oz obvykle "vetsi". No a kdyz mas k dispozici na celej system ~20 mA, tak uz vyber CPU hodne osekanej...

A co z toho opravdu potřebuje komunikovat přes internet? Pro lokální síť úplně stačí IPv4 (i když IPv6 je prakticky stejně složité, viz dále) nebo něco ještě primitivnějšího (IPX, raw pakety).

Melo by to byt jejich nedilnou soucasti - protoze vyvoj jde od veci primitivnich, prez slozite k jednoduchym. IPv6 je ve fazi slozitych :) Ale je to samo jen vec nazoru.

IPv6 je pro nody (RFC 4294) prakticky stejně jednoduchý jako IPv4;hlavičky jsou jednodušší, adresy zase delší). Všechny ty složité vlastnosti jsou nepovinná rozšíření.

Ale za jakou dobu ? Krom toho, V4 adres je porad 'dost', na to, jak se s nima plytva. Krom toho, hodne techto problemu je 'akademickych' (tim nerikam, ze neexistuji) a snad jeste vic neni otazkou zakladni implementace, kdyz clovek nepotrebuje vic nez 'komunikovat'.

IPv4: 30 let
IPv6: 20 let
Kde je ten podstatný rozdíl?

Tu spoustu problémů také nemusíš řešit, pokud pro tvoji implementaci nejsou zajímavé.

Pak uz zustava otazkou, jesli to je dobre, nebo spatne (:

Pokud bych měl jmenovat jedno jediné RFC, které IMO stálo za masivním rozšířením internetu, bylo by to 2131. IPv6 jde v tomhle ještě dál.

Pane kolego, vy tomu asi nerozumíte. Vy si asi představujete aplikaci jako krabičku, kterou strčíte do switche (s PoE) a pak si kdekoliv na světě můžete komunikovat s vaším zařízením. Ve skutečnosti je tento případ asi tak 0.1% četný. Mnohem četnější jsou krabičky komunikující mezi sebou (typicky krabička s tlačítkem jako zapínač a druhá krabička s ovládanou zásuvkou na 230V). Takže jde o hromadně nasazované krabičky ve velkém počtu. Tam záleží na každé koruně. Když udělám krabičku s Cortex M0 + ENC28J60, tak na BOM mě stojí cca 150 Kč+cena krabičky. To trh unese. Ale na zařízení s linuxem bych musel nasadit třeba Cortex M3 se správou paměti, což je proti STM32F050 zdražení nejméně 300 Kč a pravděpodobně budu muset dát k mcu ještě nějakou další paměť, což aplikaci prodraží. Takže budu na ceně nejméně 400 (spíše však 450)+cena krabičky. Tedy stejnou funkcionalitu dostanu za cenu 3x větší, což je ekonomický nesmysl. To je jeden aspekt. Druhý je spotřeba. Pokud mám zařízení s bateriovým napájením a wifi připojením, tak první řešení bude mít spotřebu cca 20-30 mA a druhé cca 50mA, což znamená poloviční výdrž.

Ne, pane kolego, zřejmě nerozumíte vy. Píšu přeci, že takové krabičky nejspíš nepotřebují komunikovat přes internet (tedy to samé, co vy), a aby komunikovali mezi sebou (či v lokální síti, to je jedno), tak na to IPv6 nepotřebují (tedy vyvracím Rayovo tvrzení, že IPv6 je špatné, protože do takových krabiček je složité dostat IPv6 stack).

Ty už to FAKT NEHUL ;-)

To tvoje "IPv6 je super, ale na lokální síť raději použij IPX/SPX nebo NetBEUI" je vážně kokotina.

Vím, že to asi nepochopíš, protože to je na dítě hodně složité, ale jsou fabriky, kde zařízení leží například u vodojemu a server na sběr dat v serverovně. Často od sebe oddělené další sítí. Další, co se bojím, že nepochopíš, je to, že je nesmysl dělat deset verzí krabiček, jednu pro použití na internetu, další pokud to pojede jen po lokále, další pro použití přes MPLS...atd...

Zase jsi nic nepochopil. Ale už se tomu ani nedivím.

Jiste, pri cene vodojemu miliarda ... budu resit jestli krabka stoji 150 nebo 500Kc ... lol

Ten matros bych vazne chtel, mas ho predpokladam na tuny?

Jistě, krabička řídící vodojem nemající dost paměti ani na implementaci IPv6 bude připojena od nějaké složitější sítě nebo přímo do internetu, aby ho mohl ovládat kdokoliv, protože když nemá těch pár bajtů navíc, co sežere implementace IPv6, určitě už nebude mít ani na nějakou autorizaci.

Krabička řídící vodojem má běžně minimum paměti a je běžně připojena do internetu (někdy přímo, někdy přes nějakou síť).
Nějakou autorizaci to má vždy, ale nebývá to vždy valné. A obecně rozhodně platí, že tohle je slabé místo krabiček, co řídí fyzické technologie.
Běžně spočívá velká část zabezpečení v tom, že na nějakém FW před tou krabičkou se propouští pouze requesty z nějaké konkrétní podsítě a hotovo.

Pak je otázka, jestli by ten FW před tou krabičkou neměl spíš spouštět VPNku. Tím se totiž vyřeší jak problém IP stacku (krabička nemusí komunikovat přes internet -> nepotřebuje IPv6), tak problém zabezpečení.

V "lepších rodinách" se to tak dělá. Ale je to další komplikace navíc - kterou dneska používá ten, kdo chce. Kdo má pocit, že (například) HTTP auth není pro jeho zařízení dost dobré, tak použije VPN.
IPv6 bude znamenat, že VPN bude fakticky nutnost.

A co zas resite za ptakoviny?
Obvykly design je ten ze se hloupe krabicky pripoji pres jednoduche sbernice jako 1Wire,CAN,Meter BUS,KNX,RS485 a jine kyho slaka BUS. A cele se to ridi pres nejaky chytrejsi ridici pocitac ktery uz ma dost vykonu na cely operacni system s kompletnim stackem.
Od nejjednodussiho k nejslozitejsimu.
Argument ze IPv6 se spatne implementuje do digitalnich hodinek od vietnamcu je fakt lichy. IPv4 taky nebylo navrzeno pro jednoduchou implementaci. Pouze se podarilo po urcitem case technologickeho pokroku ho doimplementovat i do lepsich jednocipu. Jednoducha implementace pro jednocipy nebo prumysl nebyla cilem ani jednoho z IP protokolu.

Dobře, ale furt je tady segment zákazníků, který ocení stejnou funkcionalitu zařízení jako na lokále, ale jako GUI vlastní tablet, se kterým můžou cestovat po světě a nebude se mu třetí strana vrtat v datech na cloudu...

Základ je v principu stejný pro IP4 i pro IP6. Liší se jenom drobnosti jako hlavička atd. Co jsem viděl, tak systém řetězených hlaviček je jednodušší a logičtější na implementaci. A třeba u PLC natvrdo vraženýho ve skříni, která je přišroubovaná k betonové zdi v baráku, asi nebude moc potřeba podpora mobility a hledání zprostředkovatele do domácí sítě a podobných rozšíření.

Netuším jediný důvod, proč by se to nedalo rozchodit třeba na stará AT91SAM7X512 s PHY připojenou po MII. Tam je taky odběr 00nic...

A co z toho opravdu potřebuje komunikovat přes internet? Pro lokální síť úplně stačí IPv4 (i když IPv6 je prakticky stejně složité, viz dále) nebo něco ještě primitivnějšího (IPX, raw pakety).

No, kdyz je to heterogeni sit, kde jsou krabicky rozesete vsude mozne, neco je na WiFi, neco na optice, neco na RS485ce, ... proste abslutne nestrukturovana vec (protoze principielne to nejde), tak opravdu *jedinym* rozumnym spolecnym jmenovatelem je GPRS, nebo Internet, nebo spoplecnosti (kazdy si jiste najde svou ne/oblibenou) co provozuji privatni site treba na 3.5Ghz pasmu a podobne. Cili, clovke musi vyuzit toho co je v miste k dispozici. Dokupy to spolu musi nejak komunikovat a co vic, uzivatel (v obecne podobe) to chce mit nekde v mobilu. Cili, nakonec to na siti skonci. Neco jako likalni sit je dobry tak na barak, ale na nic vic. Za komancu se nadavalo na centralizaci. Tak se udelala decentralizace a zjistilo se, jakej je to nemysl. Pak prisla EU a centralizace komancu se ukazala i 'jako fungujiici' proti tomu, co prislo. A nakonec se skoncilo u cloudu, co je to same jako centralizace, jen je to rozlozene na vic kompu. Historie se neustale opakuje, jen se zrychluje. Cili, ANO, potrebuje to komunikovat s cenrem (modni replace za cloud)...

IPv6 je pro nody (RFC 4294) prakticky stejně jednoduchý jako IPv4;hlavičky jsou jednodušší, adresy zase delší... To si delas srandu ? Nejde o par bitu v hlavicce, ale o vsechny ty sra... veci okolo. Staci se podivat na implementaci 'DHCP' like v obou svetech. Nejde o to ze je delsi adresa, ale kolk bajtu mi zabwere jen si ulozit vsechny adresy, co potrebuju k funkci, mnozstvi adres, na ktere musim reagovat, ... A zcela zbytecne. Funkcne to neprinasi v podstate nic, jen nekomu prilso dobry to udelat takle 'ciste' aby nahodou v ISO modelu DHCP nepreskakovalo jednu vrstvu (napr. kdyz prijde OFFER na IPcko, ktere jeste stanice nema, coz dle RFC mozne je). A muzem pokracovat....

Ja nejsem proti nahrade za IPV4. Nicmene, jako PRVNI a zcela ZASADNI vec mela byt koexistence OBOU protokolu zaroven. Staci se podivat na mnozstvi RFC co se tyce 4 over 6, 6 over 4, ... Samo tohle odsuzuje V6 do propadliste dejit - driv nebo pozdeji :) Nicmene, jen to jen vec nazoru.

A ad to plytvani - to je bohuzel presne pravda. Krom toho, hodne firem z 'bezpecnostnich' duvodu stejne bude NATovat i s V6kou (a uz tak cini). Jen je na to potreba vic RAM a vice CPU, vzhledem k existenci vetsiho mnozstvi IP adres na rozhrani :o)

Notabene, uz jsem zazil firmy, co to delaji i pro ochranu soukromi. Premisa, ze IPV6 = zadny NAT nebude potreba, je IMHO zcela chybna. A dokud si mainstream aplikace PORADI s NATama (nepolemizujme o cistote tohoto reseni), tak se to nezmeni. A oni si poradi :o)

R.

Cili, nakonec to na siti skonci.

Pokud taková krabička nemá dost paměti na IPv6, jak řeší zabezpečení a autorizaci?

Nejde o to ze je delsi adresa, ale kolk bajtu mi zabwere jen si ulozit vsechny adresy, co potrebuju k funkci, mnozstvi adres, na ktere musim reagovat, ...

V minimální implementaci stačí získat prefix sítě (což je IMO jednodušší než u DHCP) a EUI-64 odvozené z MAC adresy s prohozeným U/L bitem. Lokální adresy jsou potom právě dvě: fe80::EUI-64 a prefix:EUI-64. Oproti IPv4 to sežere 12 bajtů RAM navíc, pokud je opravdu potřeba RAM hodně šetřit, jde EUI-64 generovat z MAC adresy on-the-fly, což potom sežere oproti IPv4 o 5 bajtů RAM navíc (4 bajty pro delší prefix a 1 bajt pro prohození U/L bitu).

A ad to plytvani - to je bohuzel presne pravda. Krom toho, hodne firem z 'bezpecnostnich' duvodu stejne bude NATovat i s V6kou (a uz tak cini). Jen je na to potreba vic RAM a vice CPU, vzhledem k existenci vetsiho mnozstvi IP adres na rozhrani :o)

IPv6 NAT momentálně existuje pouze bezstavový. Z bezpečnostních důvodů se používá firewall.

Notabene, uz jsem zazil firmy, co to delaji i pro ochranu soukromi.

Na to jsou přeci privacy extensions.

"IPv6 NAT momentálně existuje pouze bezstavový." - kolikrát ještě se toto nepravdivé tvrzení bude objevovat? Klasický 1:N NAT pro IPv6 existuje už dávno, od verze kernelu 3.7 dokonce už i v Linuxu - IP6_NF_TARGET_MAS­QUERADE!

Auorizaci preshared klicema (pro kazdy kus jine) a dobrou kryptografickou vrstvou. Jako cipher napriklad AES128. Ja mam kompletni implementaci tohjo EASka cca na 950 bajtu flese a 32 bajtu RAM. Samotny veci okolo, jako MAC, etc etc. je dalsi cca 3/4 kila. A rychlost vice nez dostatecna, co tenhle typ krabicek potrebuje.

Na tu implementaci je potreba bohuzel vic, uvedom si, ze to neni jen o IP adrese, ale o branach, o vecech na ktery musi clovek reagovat, ... a proste musim predpokladat, ze se mi moje GW muze chovat 'podle ipv6' a nemuze si to clovek mco zjednodusit...

R.

Hmm, OK, autorizace tedy není problém.

Brána v IPv6 minimální implementaci je jednodušší než v IPv4, nepotřebuješ totiž vůbec znát IP adresu, protože MAC adresu získáš rovnou z RA (oproti IPv4 tedy ušetříš 4 bajty RAM). A pokud bys už nějakou IPv6 adresu pro bránu potřeboval, můžeš natvrdo používat fe02::2.

Další věci mi teď nejsou jasný, NDP je akorát jinak vypadající ARP, ICMPv6 jinak vypadající ICMP a na nic jinýho snad reagovat potřeba není.

Pokud se GW chová podle IPv6, tak by měla umožnit komunikaci zařízení chovajícího se podle minimální specifikace, od toho ta minimální specifikace je. Jediná problematická situace, co mě teď napadá, je, když brána nepodporuje SLAAC, ale to je stejná situace, jako když v IPv4 nejde DHCP, v takovém případě budeš nejspíš adresy vypalovat přímo do zařízení.

Jj, potreba je jen zaklad, jak rikas, NDP/ARP, ICMP. Nicmene, potreba je DHCP, protoze ty zarizeni musi komunikovat mezi sebou a nemusi byt nutne na 1 subnete. A SLAAC ? To byt nemusi. A hned tu jsou 2 moznosti. Proc ? Pak bych tedy zrusil DHCP a nechal funkcnost na SLAAC. Nebo opacne... Vysledek pro mne je 2jita implementace. Bohuzel sem tam ma krabka 2 porty, protoze (kvuly bezpecnosti a spolehlivite) se instalace kruhuji (nemusi nutne byt kruh pouze z ETH). Krasny je, kdyz vim, ze tam mam jen svoje krabky. Nojo, ale realnej svet neni tak krasnej. Takze zase zadne moc velke zjednodusti. Proc ty porty - nekdy se to propojuje na urovni portu (IN-OUT), protoze kdyz se crosne napr. AC230 na datovky, nebo nekdo sekne kabel, nebo ho sunda prepeti, ... da se postizena cast odpojit (autonomne) a kruh dale funuguje. SLAAC/DHCP jedna z veci, co na V6ce opravdu rad nemam. Pak se mi nelibi mnozstvi 'adres', kde se vyradili na velkem rozsahu IP adresy a vlozili do nej funkcionalitu jinych protokolu (IMHO) - proc ? Jenom protoze to jde ? Pomijim, ze treba IpSec je mandatory pro IPv6. A muzem takhle polemizovat dokola. Proto nemam rad IPv6. Je to jak systemd / linux. Filozofie *nixu sveta je to, ze jedna vec dela to co umi a dela to poradne. Podivej se, jake emoce rozdmichava systemd. A je to IMHO presna paralela V6ky.

To je jadro pudla...

Krom toho, od sameho zacatku ti, kdo to delali, NEMELI REALISTICKEJ transition plan. Proste to 'nejak' zpytlikovali a nekolikrat menili jak po dobu prechodu. Myslim jako od zacatku, kterymu se prozpusobi protokol jako takovej. Neni mozny u neceho, co ma takovou penetraci jako V4ka, se na to tak tragicky vys....

Nevidím důvod, proč by tam muselo být DHCP, resp. co DHCP pro takovou konfiguraci (interkomunikující zařízení na více subnetech) řeší lépe. SLAAC je povinné, protože se používá pro tvorbu lokálních adres.

To množství adres má svoje důvody, ale pro minimální implementaci stačí ty dvě, které lze na rozdíl od IPv4 získat velmi jednoduše (plus případně ta jedna pro router, která je na rozdíl od IPv4 pevná). Navíc jde velmi snadno udělat multicast adresu, třeba když chcete mít implementaci, která umí najít všechna vaše zařízení na lince.

Nechápu, jaký je rozdíl pro kruhové zapojení mezi IPv4 a IPv6.

Od RFC 6434 je IPSec nepovinné.

Ale vždyť IPv6 to dělá přesně jako Linux. Je tady nějaká minimální implementace, která je velmi primitivní a dělá to pořádně a IMO líp a jednodušeji než IPv4 (neobsahuje třeba fragmentaci po cestě), a pak je tu tuna nepovinných rozšíření, která dělají to, co je zrovna potřeba.

Původní transition plan pro IPv6 je dual stack. Je to úplně ten samý transition plan, který byl úspěšně proveden u IPv4.

To mi v tom RFC uteklo, mas recht (i IpSec jsem ani nikdy implementacne neuvazoval, do RAM bych sotva nacpal prislusny prime, natoz neco jineho :) Tak ci tak, jednoduchost/slo­zitost je dana implementaci. A ta je i V6 narocnejsi. A ne o malo (soude na zaklade zdrojaku - a ne jednech). Z casti to je dany platformou - na velkych CPU s neomezenyma moznostma se programuje "jinak" a slozitost ma jiny rozmer. O tech duvodech nekterych featur (vice IPecek, vice moznosti ziskat IPcka, ...) se da polemizovat, resp. ktere jsou pricina (feature) a ktere nasledek (nekomu doslo, ze to tak nemusi byt dobre). Prave ten cistej dualstack bez promysleni dalsiho tahu, je ten nejvetsi fail. Nejsem zastancem lepeni, ala intel (s porovnani s motorolou trebas, zvlaste u drivejsich modelu je to neuveritelne markatni :), nicmene, jsou veci, ktere se proste nevyplati jen tak 'rozbit'. Pohrbili tim IPv6 na dlouhou dobu dopredu. Coz je IMHO skoda (za predpokladu neceho lepe promysleneho). Zminene RFC je pomerne nove, s porovnanim s dobou vniku samotneho V6, ponekud opozdene. Pokud pri vniku neceho takoveho nemyslim na ruzna typy nasazeni (v okamziku PSANI) tak to je podle mne pruser, at na to koukam jak na to koukam. Nebo si fakt mysleli, ze uz budou existovat jen velka CPU s neomezenymi zdroji ? Je sice pekny, ze po ~16ti letech jim to dojde, ale neni to trochu pozde ? Stejne tak tunely, ... Tobe to opravdu prijde jako koncepcne dobre vymysleny ? Kdyz se podivat na 'nasazovani' a 'penetraci' od dob vniku az po dnesek ? Proc se mobilnim operatorum nechce do IPv6 ? Nebo nam ? A dalsim ? Je to otazka ma dati/dal. A tak jak to je nastavene, toho vlastne tolik nedava.

Nakonec je to stejne jen otazka nazoru/uhlu pohledu na vec. Kazdej mame pravdu. Tu svoji :o) A universalni pravda je jen chimera...

R.

Tak on ten protokol a jeho vlastnosti byly vymýšleny s tím, že nasazení bude nějakou dobu trvat — a ono to trvalo dokonce výrazně déle, třeba Windows se pořádně IPv6 naučily až po 15 letech a stejně dodnes neumí RDNSS. (Automatické IPv6 sítě nastavené pomocí prefix delegation? Pokud tam jsou klienti s Windows, tak zapomeňte. A s Windows Phone zapomeňte na IPv6 úplně.) Za tu dobu se některé podmínky nepředpokládaně změnily (IPSec vznikl šest let před TLS a nebýt tak pomalého rozšiřování IPv6, dost možná by TLS nevzniklo nikdy) a jiné naopak ne (koho by v devadesátých letech napadlo, že se jednočipy budou i za dvacet let připojovat do internetu?). Na to dopadlo IPv6 ještě docela dobře. Ostatně jakákoliv náhrada by velmi pravděpodobně během předpokládané doby nasazování v horizontu deset a více let začala trpět podobnými problémy.

Smysl dvou IPček je ve spojení se SLAAC patrný: vezmu dva počítače, spojím je kabelem a díky linkové IP adrese spojení mezi nimi funguje okamžitě (a díky mDNS ani nemusím ty IP adresy znát). Když tam potom časem připojím router, veškerá lokální spojení by měla fungovat dále a to moc jinak než další IP adresou vyřešit nejde. Stejně tak lokální spojení neovlivní to, když router odeberu nebo když se celá síť přečísluje. Pro mobilní sítě (mám teď na mysli sítě, které se pohybují) a multihoming poměrně zásadní věc.

Každý tunel je hack. A zrovna třeba 6to4 mi přijde jako poměrně geniální nápad — žádný broker, žádné zásahy do DNS, žádná registrace kdekoliv a funguje to (jen je potřeba dát pozor na MTU). Jako největší problém mi pak přijde chybějící podobný nápad pro tunelování IPv4 na IPv6-only sítích. Ale protože Windows mají dodnes problémy fungovat na IPv6-only sítích a MacOS X je plně podporuje až od Lionu, tak to zatím stejně není na pořadu dne.

Mobilním operátorům se nechce do IPv6, protože to znamená druhé PPP spojení. Ale to by znamenalo s jakýmkoliv protokolem.

"Mobilním operátorům se nechce do IPv6, protože to znamená druhé PPP spojení." - to není pravda. Telefonica už na svém ADSL/VDSL IPv6 provozuje IPv6 skoro rok, tam se taky používá PPP (PPPoE) a není to problém (RFC 5072 funguje dobře). Hlavní problém je vždy když máte podporovat hodně variant koncových zařízení - u ADSL si odzkoušíte a prodáváte několik málo modemů a je to. Ale u mobilního připojení je to velký problém - zákazníci mají spoustu různých mobilů, většina z nich IPv6 vůbec neumí, další část IPv6 umí s chybami, a téměř žádné mobily dneska neumí IPv6 přes 3G nebo LTE pořádně. :-(

Tady nejde ani tak o druhe PPP spojeni (to je takovy uzivatelsky viditelny artefakt a asi si lze predstavit ze by se to dalo implementovat s jednim), ale o druhy PDP kontext. Jednim paketovym pripojenim lze tlacit pouze jeden L3 protokol (tim protokolem muze byt fakticky PPP a v nem multiplexovano neco dal, ale to z pomerne dobrych duvodu neni rezim, ktery se obvykle pouziva pro "pripojeni k internetu"). To vytvari jeste dalsi rozmer ruzneho chovani zarizeni: jestli vubec funguje jako modem pro vice spojeni soucasne pripadne jako modem pro IPv6.

U ADSL/VDSL "modemu" nastavaji nejake zajimave otazky ohledne funkcnosti IPv6/koexistence s v4 jenom pokud se nakonfiguruje tak, aby zaroven delal nejake L3 funkce (tj. byl router/natator).

Pomoci jednoho PDP kontextu (EPS bearer) lze od 3GPP Rel8 (LTE) a Rel9 (GPRS) resit IPv4 i IPv6 soucasne, takze pocet kontextu zustava nezmenen. Jedna se o PDP/PDN Type IPv4v6. Jeho podpora v mobilnich zarizenich a mobilnich sitich se pomalu objevuje.

Jen pro upresneni PPP spojeni je mezi mobilnim terminalem a modemem, ktery soucasti mobilniho telefonu. V mobilnich sitich se PPP neuziva, na rozdil
od DSL siti, kde PPP terminuje BRAS.

Mozna je ten duvod to, kdy V6 vniklo a ze v tu dobu to nebylo zdaleka potreba. A pokud s nekdo myslel, ze za 20 let tu nebudou 'krabicky' tak dotycny nemel k psani takove veci prijit ani na vzdalenost dratu od kalvesnice (v tu dobu :o) Protoze to pak bl vizionar stylu my zirame, vy zirate, vyzir... Asi tohle je to jadro pudla. Popravde jsem ani nevedel, KDY vnikla V6 jako prvotni navrh. Mnohe to vysvetluje. Nicmene neomlouva.

R.

V propadlisti dejin skoncis leda ty ... IPv4 a IPv6 spolu kupodivu zcela vpohode koexistuji. A prave proto existuje tolik prechodovych mechanismu, aby si kazdy moh vybrat podle svyho vkusu.

Firmu ktera by natovala IPv6 sem jeste nevidel ... ano, ma na ni firewall - radove jednodussi, nez ten NATujici na IPv4.

Maly priklad
Ipv4 natujici firewall - 425 radku pravidel
Ipv6 firewall - 142 radku pravidel.

Copak se asi tak lip adminuje? Hmmm ....

A ano, davat na IPv6 NAT muze leda Blb(velke B protoze velky blb). Az vytahnes, ze kdesi cosi o cislovani stroju ... tak od toho tu sou linkovy adresy.

V propadlisti dejin nakonec skocime vsichni, tak si z toho nic nedelej :)

R.

„Krom toho, V4 adres je porad 'dost', na to, jak se s nima plytva.“

Fakt? Vždyť ten rozsah nepokryje ani IP na každého druhého obyvatele Země! (řekněme, že polovina lidí žije v podmínkách, kde je možno uvažovat o počítači - + „zápaďáci“ mají počítač, počítač v práci, mobil, notebook, APčko, IP telefon, chytrou televizi…) A to nepočítám servery.

Stejne tak jako kazdy obyvatel teto planety nemuze mit auto, tezko bude mit pocitat a nutne s nim IP adresu. Dokonce, kdyby v cine chteli mit tolk aut jako mamy na osobu v evrope, tak na to ani tahle koule, na ktery zijem, nema zdroje... Toz asi tak :)

R.

Jestli každý obyvatel této planety může nebo nemůže mít auto, to nevím, ale vím, že na této planetě příští rok bude víc aktivních mobilních telefonů, než kolik je lidí. A každý z nich je počítač a rád by měl IP adresu.

Pocitaci je to uplne jedno, jesli ma nekdo stejnou nebo ne. Krom toho, mobilni aplikace to je uplne jina liga. Nemyslim si, ze by v tomto pripade Ipv6 melo nejakej 'vliv'. Leda to, ze si nekdo pusti svuj server, coz by ho operatori jiste milovali. Tady je nejvetsi problem se zmenou geolokace a podobne. Coz mobilni IP stacky resi po svem. Nevim o tom, ze by sem mela v6 nejakej dopad, ale jesli se pletu sem s tim.

R.

NAT tam má velký dopad už teď. Třeba to hrozně ztěžuje SIP nebo posílání lolcats. Implementovat to bez NATu je totiž hračka, s NATem je to noční můra.

Nepopiram, ze NAT ma sve neduhy, to je zrejme, jen jsem narazel na to, jak IPv6 pomuze mobile IP stackum. Ja si jen myslim, ze z heldiska prakticnosti, neni NAT takovou prekazkou, jak nedomyslene IPv6, ktere uz davno mohlo mit penetraci radove vyssi, kdyby soudruzi mysleli vic prakticky, coz je skoda...

Cele tohle dobre/spatne neni az tak o konkretnostech (byt jich tu padlo a daji se dohled, protoze se to resi pod kazdym IPv6 oslavujicim clankem a nemam chut flamesit o tom, jak je skvele 'zruseni' ARP (zmixovani), menici se IP adresy na interfacech, ... ) jako o faktu, jak mizerna penetrace V6ky je navzdory snaham vyrobcu a akademicke sfery. To poukazuje na 'kvalitu' promysleni cele 6ky. A proto temer pod kazdym oslavnym clankem je podobna diskuze. Pointa neni to, ze to zere vic flese a ram v krabickach. Pointou je to, ze penetrace V6ky je mizerna a nemyslim si, ze se to nejak moc brzo zmeni. V celosvetovem meritku rozhodne ne. Podivejme se trba na USA. A je to je dusledek navrhu. Niceho jineho. Muj nazor :o) Howk

Cili ano, na kazdou technickou 'vytku' existuje rozhdone odpoved, proc je to tak nejlepsi. Ale stejne tak existuje minimalne 1, jak to muze byt lepsi.

A ten nejvetsi fail je naprosto mizerna koexistece V4 a V6. A dusledkem je mizerna penetrace a prakticky nulovy prinos pro EU (a ano, vim ze NAT je zlo a pujdu do pekla :o)

R.

Vysledky ceho ? Ja mam implementovanou jak V4 tak V6 a proste V6 nemam rad :)

R.

Problem "ruznych mobilnich PPP spojeni" je ten, ze to neni neco, co by normalni clovek pouzival. Technologie paketovych dat, ktere nejakym zpusobem vychazeji z GPRS (tj. tak jako cokoli co se dnes u nas pouziva) maji fakticky dva rezimy: tlaci se tim nejaky jeden konkretni L3 protokol (tj. typicky IPv4) nebo "PPP" (fakticky by asi mohlo fungovat cokoli co ma stejny framing), v tom druhem rezimu ovsem sit vcelku nezajima co v tom PPP je a ty ramce cele tlaci nejake jedne konkretni protistrane (coz je duvod, proc se to na normalni pristup k internetu nepouziva).

To ze uzivatel po AT+CGDCONT=1,IP,"AP­N"ATD*99 vidi neco co vypada jako PPP je o tom, ze je to jeden z mala rozumnych zpusobu jak po te nejake seriove lince IP tlacit a to PPP spojeni realne konci v MT, kde se z nej vyndavaji spravne packety a posilaji dale uplne jinym protokolem (fakticky HDLC u (E)GPRS a fakticky ATM AAL5 u UMTS, vsimete si, ze ani v jednom pripade vrstva pod neumoznuje primo oznacovat pouzity protokol vyssi vrstvy pro jednotlivy ramec).

Vtipne na celem tom mechanizmu je, ze na strane site (SGSN) se z toho "uplne jineho protokolu" vcelku zahy ty jednotlive packety zase demultiplexuji a prevedou na UDP datagramy ktere dale prochazi pomerne rozsahlou IP siti (je fakticky bezpredmetne jestli v4 nebo v6) na jejiz opacne strane (GGSN) se detuneluji a predaji tam kam patri, tj. u IP nekam odroutuji, u PPP poslou do neceho co alespon trochu pripomina seriovy port (ie. GGSN u nich nedela zadne smerovaci rozhodnuti). Smysl celeho tohohle mechanizmu je pouzit na backhaul existujici technologii pro site s prepinanim packetu (tj. IP, typicky po Ethernetu) a zaroven podporovat mobilitu koncovych zarizeni i pro protokoly, ktere to primo neumi (tj. IPv4 a teoreticky X.25). Clovek se svym zpusobem muze domnivat, ze to cele bylo puvodne myslene jako docasne reseni nez dojde k nasazeni IPv6, protoze tam neco takoveho diky Mobile IPv6 neni fakticky potreba, pripadne muze fungovat uplne jinak (to tunelovani/de­tunelovani se muze posunout na koncove zarizeni).

Pokud chcete zaroven prenaset IPv4 a IPv6 musi se tohle cele dit pro kazdy protokol zvlast. Navic je docela dobre predstavitelne ze GGSN pro IPv4 a GGSN pro IPv6 jsou/budou fyzicky rozdilna zarizeni (mam takovy dojem, ze je fakticky nutne aby minimalne mela ruznou adresu v te vnitrni IP siti, ale to je pouze muj matny dojem). Zaroven koncove zarizeni musi pouzivany protokol znat. Na druhou stranu si lze predstavit, ze zarizeni ktere umi IPv4 a IPv6 pred faktem, ze existuji dve spojeni muze uzivatele nejakym zpusobem odstinit, ale to je v situaci kdy velka cast zarizeni neumi IPv6 vubec a jina velka cast neumi vice aktivnich PDP kontextu zaroven je ponekud teoreticky problem.

Cele bych to zakoncil tim, ze jako duvod pouzivani PPPoE/PPPoA pro xDSL se obvykle prezentuje kompatibilita s AAA systemy pro normalni dialup, ale druha zasadni vyhoda je to, ze odpadaji problemy tohohle typu. Prenosovou siti proste existuje nejaka point-to-point cesta kterou se da tlacit fakticky cokoli zaroven (nevyhoda je pak to, ze prenosova sit "nevidi" multicast).

Jiste, je mu to jedno presne do okamziku, kdy se spolu ty dva stroje chtej zacit bavit... pak sou oba ve stejny prdeli. POtrebujou na to nejakyho prostrednika ... a prostrednici = zbytecna zatez site, zbytecny HW v siti, a zbytecne utracene miliardy.

a) Jenže zatímco na auta nemáme fyzické zdroje, ropu, ocel… IP adres je 2^128. Teda pokud by se nepoužíval protokol, který je uměle limituje.

b) Chápu správně, že jsi proti globálnímu Internetu? Proč?

Ad A: Fylozoficky vzato jsem proti nahrade reality jinym druhem reality :) Zdroje na vyuziti 'ip' adres predpokladaji hodne vzacych kovu, ktetre se v elektru pozivaji. Namatkou tantal, ktery je sem tam, potreba. Treba jen blbe kondiky z tantalu jsou v urcitych oblastech nenahraditelne. A doly na svete spocitac na prstech jedne ruky i po hratkach z motorovou pilou. Da se pkracovat. Jesli vic neco u vyrobe PCB, tak mas predstavu o mnozsti chemie a vsechno, co tehle prumysl potrebuje. A tak se da pokracovat. Jinymy slovy, nemame zdroje ani na to, aby kazdej na svete mel 'svuj mobil'. Rozhodne ne tempem obnovy a zalostnou recyklaci, kterou jako civilizace predvadime ted. Tohle je IMHO realne vetsi nebezpececi, nez ze se vyvrazdime driv sami. Jsme cim dal tim vic zavisli na ruznych krabickach a tune 'sracek' (pardon za ten vyraz, ale slusneji to napsat nejde). Nejde tedy u umelou limitace, ale limitaci veskrze fyzickou.

Ad B: Nejprve bysme si myseli ujasnit, co je to vlastne pojem globalni. Oni ty hranice jsou krehke, zvlaste kdyz jsme stejne na jedny velky skoro kouly. Kdyz posles lod ke dnu, je v konecnem dusledku jedno, jesli se plavis v prvni nebo treti tride. Myslim si, ze jakakoliv globalizace nakonec znici sama sebe. Sesype se zevnitr. Je to jen otazka casu. Cim vetsi ale dana globalnost je, tim vtsi pruser ono sesypani nakonec zpusobi. Takze ano, pokud bysme pojem globalni chapali jako 'vsudypritomny' tak to se mi nelibi. Ja sice navrhuju HW, delam systemovej SW a ani vlastne sam nevim poradne co, ale mobil... Ten nenosim :) Natoz pak jine vydobitky moderni civlizace. Ja jdu radsi na pivo, teda kdyz je s kym, protoze lidi blbnou. Globalne :)

R.

Proletěl jsem to a vidím tam pár věcí, ale myslím, že je nepotřebuje implementovat krabička v kontrolované síti ve vodárně - jako třeba víc způsobů přidělování adresy, SeND, mobilita…

Tot otazkou, co potrebuje a co ne. Nebit zde zmineneho RFC nekde vis, by kazda podobna krabka mela mit IpSec, coz je nemyslitelne. Principielne nerikam, ze to nejde, pouze se mi to zda 'zbytecne'. Zbytecne moc promrhane energie. To je asi jako Aero rozhrani aneb o kolik se zvedne spotreb aprumernyho krapu po instalaci tehle veci, jen proto, aby to bylo 'pekne' (subjektivni vec, jasan). Vezmi si pocet PC, na tkerych se to stane a spociej si, kolik elektraren zivi jen tuhle blbost. Ja vim, ze jde vypnout. Je poukazuju na trochu jinej rozmer vsech techle 'globalnich' veci. Nebo jinej priklad, GPON. Jako jedno z + je uvadena spotreba, ktera klesne. Nicmene, kdyz si proheldas net, najdes par studii, kde porovnavali nakaldy na elektriku v globale. Vzali GPON, beznej router co k tomu musi byt (a musi mit z principu relativne silne sifrovani). A potrebnej HW. Proti tomu postavili klasickou sit z CISCO a optiky. Svete div se - GPON usetril HODNE energie. Ale otazkou je komu, protoze v dusledku spotrebuje energie VIC. A to docela vyrazne. Pointou je, ze ji neplati provozovatel, ale rozmenil se to mezi koncaky, takze to nikoho nepali. Stejne tak to je s V6kou a dalsima vecma. Je tu proste jeste jeden dalsi rozmer. A protoze sedime na jedny velky kouly, je sumak, jesli usetri A a videla B ci opacne... Tenhle trend je patrnej ve vyvoji uz peknych par let a mne osobne docela desi. Veci se 'rozmelnuji' a jsou cim dal tim mene 'ucinne' ve smyslu vynalozene energie na provoz (ale i vyrobu) ve vztahu k tomu, co poskytuji. Aneb, nez najit progamatora, kterej pri praci trochu mysli, je levnejsi si koupit vykonejsi HW :) A a tom to cele je. Sorry za naprostej offtopic.

R.

IpSec slozity neni ? Takto je slovo do pranice :o) Slozitost je relativni a zalezi na zdrojich. Pro 'bezne' krabky je to naprosto nedosazitelne. Vis, jaka je ~minimalni implementace IpSecu, rekneme ve statisicich radku zdrojaku ? At mame rpedstavu o ~slozitosti. A neni to o -l na komandlajne, protoze ten kod nekde MUSI bezet. Neco tu RAM a CPU musi napajet. Nekdo musel vyrobit ty kusy kremiku. Ty se nekde museli natezit. Chemie k tomu vsemu potrebna se taky nevzala jen tak z niceho. Krom toho, IpSec je navazenej na radu dalsich RFC, bez kterych nema vyznam (IKE etc..). Proti IpSec nic nemam, sam ho pouzivam na radu veci, ale Ipv6 znej udelal 'vsespasu' a zaradilo ho jako povinou soucast protokolu (kterou pak posleze zase odebralo, kdyz se nekomu trochu rozsvitilo, jak uz jsem take zjistil :o) To je identicky jako to, kdyz jsem videl soft na krabky, ktere komunikovaly paradne prez JSON, ... bla bla. Same cool technologie. Ale kdyz se to hodilo nekam do praxe a spadlo to za GPRS (nebo nedej boze na pomalejsi RS485 linky) bylo to proste mrtve. Nepouzitelne. Protoze od urcite urovne technologii je potreba myslet a ne jem tam neco 'strcit' - a ono to proste pojede, protoze zdroju je ~nevycerpatelne.

R.

Oprav mne opkdu se pletu, ale IPv6 oznacilo IpSec (po 10letech nebo kolika to zrusili) jako manadtory. Dale vzaly jednoduche protokoly z V4ky, zmixovali dokupy a 'zjednodusili' komunikaci. A souvisi to s celym pojetim IPv6ky. Tj. neco co ja osobne nemam rad. Koneckoncu, jak jsem psal, to je hlavne o pojeti/nazoru. Neni to az tolik o technicke vrstve, protoze fungovat muze 'vsechno'. A dobre/spatne uz hodne zalezi na subjektivnim pojeti.

A cena krabky s IpSec je radove drazsi i vykonostne narocnejsi. A hlavne, uz je v v pozici, ze se nevyplati to delat, to uz je lepsi tam tak regulerni OS. Jinak uz je to mco prace. Cili, prehoune se to do 'velke' krabicky a jsou ze miliony radku kodu, ktery na sobe ruzne zavisi, etc etc... Pomijim to, ze nekdy je potreba delat audity a to ej dalsi problem keyz clovek pouzije OS. Ne kazdej OS ma prislusne certifikiace, ne kazda verze, ... Pakarna.

R.

No, pokud se budeme babrat v detailech co/kdo, nema vyznam pokracovat. Faktem je, ze povinotu soucasti IpV6 skrze AH/ESP extenze. Abych citoval:

IPsec is a mandatory component for IPv6, and therefore, the IPsec security model is required to be supported for all IPv6 implementations in near future. In IPv6, IPsec is implemented using the AH authentication header and the ESP extension header.

Ad cena krabicky: HCS08/HC16 procesor, generic ARM M3... se v dostatecne kvalite da poridit pod $5 vcetne PHY pro ETH. Dalsi cipy nepotrebujes. Odber *celeho* systemu je nekde na urovni 0.5W. Co se tyce PCB, 1 cip, mala plocha. Nic moc externiho nepotrebjes. Na implementaci linuxu potrebujes ARM trochu jiny tridy, ten koupis okolo $10, ale ma to porad malo flese a RAM na linux. Takze pripocti vrstvy na PCB, plochy pro dalsi cipy etc. A i pro uLinux potrebujes aspon nejaky to mega. A muzeme polemuzovat o spolehlicost pri bezhu bez MMU.

99% krabicek na linuxu ? Nenech se vysmat, krabicky nejsou jen (bez)dratovy blbosti s ciny. Popravde, pokud by si nekdo lajznul nejakou EZS nebo PLC s velkym OS, je to cistokrrevnej blazen. Takove zarizeni (mam na mysli to co sedi nizko) nemuze nikdy spolehlivost prekonat malej CPU s nejakym mikrokernelem.

Krabky co se tu resis, nekoupis v Tescu nebo na Alze :o)

R.

Tescem chtel basnik rici, ze to neni 'spotrebka' v pravem slova smyslu. Mas predstavu, kolik podobnych 'krabicek' je potrea, aby to doma tekla voda a sla elektrika ? Nebo by si nemusel do schodu pesky ? A tech, co maji pripojeni 'nekam pryc' (cti: net/cloud/....) pribejva...

R.