Názory k článku Tak jsme na suchu!

V clanku je vysvetlenie.

necetl jsem clanek, ale mam cca poneti o cenach TCAMu do routeru; obchodovanim s adresama se rustu globalnich tabulek zrovna nepomuze

> Mohlo by to elegantněji řešit nedostatek IP adres.

Tím myslíte ještě více oddálit přechod na IPv6? Snažit se ještě déle udržovat při životě neudržitelný stav s IPv4. Čím dál více uživatelů za NAT. Spoustů webů pod jednou IPv4. Děkuji nechci. I když, chápu že by to byl dobrý byznys pro firmy, co kdysi získaly snadno velké množství IPv4 adres a teď by je začali draze prodávat. A kdo by to nakonec zaplatil. No přece zákazník. Jen se mrkněte jak už teď "obchodují" různí poskytovatelé internetu. Kolik od zákazníků chtějí za přidělení a pak za "pronájem" IPv4 adresy. Ať už je konečně IPv6 samozřejmostí.

Jen to plýtvání s IPv6 adresami mě děsí. Masku /64 pro každou pidisíťku, to je strašné. Ani s vývoje IPv4 se se nepoučili. Prý IPv6 adres je dost. Jenže dost neznamená nekonečně. Stejné řeči tady byly i na začátku IPv4. Pak se začaly sítě dělit s jemnější maskou než jen A, B, C. Pak už nestačilo ani to. NAT začaly být součástí života. Tak jako virtuální weby.

Virtualhosty webu bych do toho nepletl. Pouzivaly se davno pred tim nez nekoho vubec napadlo ze by ipv4 mohly nekdy dojit (1996).

NAT neni zas takove zlo, pokud poskytoval a hlavne domaci routery transparentne poskytuji forward portu pres upnp/NAT-PMP. Drtiva vetsina aplikaci co to potrebuje potrebny support ma.

Je to dano proste tim ze je zbytecne mit na jednom stroji nekolik virtualnich interfacu, pro kazdy web zvlast.

V pripade SSL se jednalo o chybny design protokolu, to uz je nejakou dobu napraveno (http://en.wikipedia.org/wiki/Server_Name_Indication).

NAT není internet a lidé za NATem nejsou připojeni do internetu.
IPv6 spoustě lidí přinese domů internet.

To by se rodice a manzelka divila, ze nejsou pripojeni k internetu ...

Znacna cast domacich uzivatelu za NATem je a to i kdyz jim jejich poskytovatel verejnou adresu na rozhrani poskytne... jednoduse proto, ze hromada lidi ma doma nejakou tu wifi, maly router. A to same se aplikuje i na velke korporaty... ale treba uz i dlouhe roky na mobilni pripojeni. Ano, je identifikovatelna domacnost ci organizace, ale podle tehle "definice" by nebyl pripojen dohromady nikdo. Opak je pravdou ;-)

Tohle je trosku extremni nazor. Jaky ma NAT prakticky dopad na 99% uzivatelu ?
Zadny .

Mozna se pohybujete ve skupine lidi , ktera to resi , ale to neznamena ze to tak maji vsichni spis naopak.

Hrani her, P2P, skype proste prakticky vse jde uz dnes nastavit polopaticky na routeru na nejaky ten FW a slusny poskytovatel to podporuje.

IPv6 spoustě lidí přinese domů problémy.

To mi pride trochu ako demagogia.

SSL = Secure Sockets Layer

>Je to dano proste tim ze je zbytecne mit na jednom stroji nekolik virtualnich interfacu, pro kazdy web zvlast.

Bezne mivam na serveru vice IP adres na jednom rozhrani. Kde je problem?
A navic mam pripady, kdy na pocitaci bezi nekolik serveru (virtualnich stroju) a kazdy z nich ma nekolik IP adres.

> V pripade SSL se jednalo o chybny design protokolu, to uz je nejakou dobu napraveno (http://en.wikipedia.org/wiki/Server_Name_Indication).

SNI znam a pouzivam. Rozhodne ho nepovazuji za opravu chybneho designu protokolu, ale za berlicku jak provozovat neco, co bylo puvodne urceno pro jine podminky.

Predevsim je chyba to, ze vice webu sdili stejnou IP. Vsechno ostatni jsou jen berle jak to obejit.

To o cem mluvis je DNS. Jsem velmi rad ze se IP4 nedostalo do rukou domenovym paznechtum z ICANN ale LIRum, protoze pak by na IPv6 nedoslo asi nikdy - marketingovy kouzelnici si se substituty umi velice sikovne poradit, je to cele o pricingu a medovych slovickach o ROI.

"Jestli by to prodloužilo pro IPv4 život (majitelé zbytečně velkého množství IPv4 adres by je uvolnili), nebo naopak zkrátilo (zákazníci by rychle přeběhli k IPv6 only), je celkem nepodstatné."

To je prave imo velmi podstatne a LIRove se zachovali jak jen to nejlepe ekonomicky slo. Davat po hrstich vsem a (skoro) zdarma, a pak tvrdej konec.
Nove vznikajici trh ma pred sebou 2 volby: bud kupceni s alokacema, nebo IPv6.

Postupna price discovery jako je tomu u ropy by trh zafixovala na IPv4 na podstatne delsi dobu, jeste pred tim nez by o ipv6 nekdo vubec uvazoval.

>Možná se vám zdá 64b na jednu síť příliš mnoho, 64b na počet sítí příliš málo, ale uvědomte si, o jak velká čísla se jedná

Ano jsou to obrovská čísla a dnes si většinou lidi neumí představit že dojdou.
Ale právě proto, že vím o jak velká čísla se jedná, mi připadá 64b na jednu síť příliš mnoho. A na počet sítí zdaleka pak nezbývá 64b. Už jen proto, že pro danou alokaci, jak píšete, se přiděluje jen kousek prostoru.
A dále, když zákazník bude potřebovat více sítí tak co? No nic se neděje, prostě mu přidělíme rovnou masku /48. No jo a jakou masku bude mít tedy poskytovatel, který bude schopen zákazníkům přidělovat rozsahy /48. Zřejmě ještě kratší že. Prostě to, že mi zbývá 64b jak píšete zdaleka neznamená 2^64 sítí. Díky alokacím po šílených maskách bude většina IPv6 adres nevyužita. Takže jsme slavnostně zavedli 128 bitovou adresaci, aby jsme následně o cca 80 bitů přišlli díky nevhodně nastaveným pravidlům, jak tyto adresy dělit do sítí.

No nic tak zákazníkům bydeme raději místo /48 přidělovat /56 a nebo možná míň. Třeba jen /64. A zákazník bude mít smůlu. Bude moct mít jen jednu síť. A nakonec mu nezbude nic jiného než obcházet pravidlo, že síť má /64 masku. Tím mu zase nebude fungovat standardní bezstavové přidělování IPv6 adres, protože hold je určeno pro sítě z maskou /64. Tak co zavede DHCPv6. Nakonec bude IPv6 používat jako starou donrou IPv4. Ale alespoň to hlavní bude vyřešeno. Nebude potřeba NATu. Hurá

Nejmensi prideleny rozsah providerovi je /32, mensi se neprideluji, muze si jich vyzadat vice => muze pridelit (minimalne) 65k /48 subnetu (kolik je trebas v CR provideru, kteri maji vice nez 65 000 zakazniku?).

Prumerne inteligentni clovek pak aspon tusi, jak probiha routovani, a proto vi, ze routy se sdruzuji a tudiz je treba aby byl dostatek prostoru, a ne jako u IPv4, kde jsou routovaci tabulky obri.

IPv6 adres je vice, nez castic ve vesmiru, takze to, ze jich vetsina bude nevyuzita tak nejak nikoho nepali.

Takze nez zacnes psat hovadiny, neco si o tom zjisti.

Pod timto honosnym nazvem skryva jedine. Cisco prelepujici nalepkama linuxove masinky kterezto dokazou NATovat az 1Mpps/1M spojeni.

"Těžko si lze představit celoplošného operátora v libovolné středně veliké evropské zemi, který by vystačil pouze s 1024 adresami."

Ale to je kec.

Znate preci gprs/3G NAT vodafonu/tmobilu.

A z ceho tak prakticky soudim? V celku obycejne moderni PC zvlada 500kpps/500k spojeni, vcetne presmerovani tech co nemaji zaplaceno, pro segment Pilsfree kde je 3000 uzivatelu (operator o 15k uzivatelich, 3gb NIX, zhruba stejne zahranici). Neni problem takto na tom stroji protahnout 4gbps, ale to neni zrovna v tomto kontextu relevantni udaj.

Full-cone NAT omezuje pocet spojeni od vsech uzivatelu za natem na zhruba 64k (dolnich 1024 nepocitam) na jednu cilovou ip:port. Rekneme ze tato IP bude seznamu.cz:80, je realisticke predpokladat ze 5k uzivatelu na 1 NAT IP umozni minimalne 10 spojeni per user, v praxi az 100, mozna 500 diky agregaci klientely.

Aby jeden uzivatel neblokoval ostatni se da snadno zaridit (hashlimit na srcip:dstip:d­stport=100).

Z teto spekulace lze dojit ze s 4mi ccky lze stabilne obslouzit alespon 5 milionu uzivatelu.

V pripade pilsfree to znamena ze drtiva vetsina z 15k lidi se schovava za jednim Cckem/10 IP adresami. A zdaleka v cechah nejsou jedini, czfree-like operatori maji v oblibe takto "prasit".

Nevidim problem v tom aby i "profi" operator mel takovych masin plne 2 rackove stojany pro svych 100k uzivatelu.

To je hezké, ale vzhledem k tomu, že prvděpodobně sami velcí telko operátoři tlačí do Rady Evropy návrh legislativy pro nový regulační rámec, který krom jiného bude navrhovat zákaz používání CGN, tak levný hardware schopný unatovat půlku vlasti je řešení cca na 4 roky, než to uplatí, ehm, protlačí do platnosti. Bylo to teda definováno trošku vzletněji, ale důsledek je zákaz NATu pro veřčejné telko operátory (operátor veřejné telko sítě nesmí pouížvat techniku a prostředky, které ukrývají jendoznačný komunikační identifikátor koncového uživatele sítě nebo mění na identifikátor jiného subjektu). Celé je to primárně mířeno na stížení života nejrůznější hlasových agilních služeb (typu VoIP, kde vás VoIP operátor identifikuje vašim mobilním číslem místo daného VoIP operátora a podobné), ale vlastní IP se s tím sveze také.
Nu, aspoň to urychlí nástuop IPv6 u těch, co nemají nasysleno dostatek IPv4 adres.:-)

To zni celkem drsne. Lidi za NATem nejsou ani zbla anonymni, stejne jako ti co maji od UPC/O2 dynamickou IP. Logovani DHCP, stejne jako vytvarena spojeni za NATem po nejakou snesitelnou dobu (rekneme 3 mesice) mi prijde jako naopak korektni reseni ktere by melo byt na legislativni urovni (aby to nikdo nelogoval dele nez je treba :).

Pokud mi neco fizlove fakt chtej (vrazda), pomuze jim to, pokud je to naka blbost, po 3 mesicich promlceno.

To s tema VOIPama tezko rict. Snad jen legendarni:

"The more you tighten your grip, Tarkin, the more star systems will slip through your fingers." ―Princess Leia

Aneb pokud se budou do volny souteze srat na takto nizkem levelu a nebudou mit korektni support pro SIP, uvolni tim prostor Microsoftu s lumii ktera bude mit wifi a Skype za super duper lechce monopolni, ale stale levnejsi ceny.

U NATu zalezi na providerovi a jeho nastaveni. V jednom mensom meste ma 1 garazovy provider wifi sice s WPA2, ale preshared key, takze nikto nema problem sa pripojit ako chce a kde chce v ramci mesta. Formalne funguje logovanie tak, ze je v zmluve povinnost nahlasovat "providerovi" MAC adresu kazdeho pripajaneho zariadenia, ale to nerobi nikto, koho poznam. A u takehoto NATu ma jednoducho nikto lahko nenajde, lebo aj bez zmeny MAC adresy je problem zistit, komu ta MAC adresa vlastne patri.

Problém je v tom, že lidé za NATem nejsou připojeni do internetu a to je poměrně vážná závada.

Vsechna ta spojeni jsou na jeden cilovy stroj? Jste si jist ze nejste v nejakem zombie botnetu :)

Dokonce i ten torrent kontaktuje kazdeho peera pouze jednim spojenim.

Prosim vysvetleni jak vas priklad "bezneho uzivatele" ovlivnuje cone nat. Jediny priklad kdy jsem na limit narazil byl apache benchmark co vytvori vice jak 100 spojeni na server :)

Hash tabulky jsou velke, procesory rychle, hardware levny :)

Pisal som vyssie - problem NATu. Hraci napriklad nemozu hostovat hry, co je pre cast ludi velky problem

Problem je ze tvuj server nepodporuje nat-pmp ci upnp co interakci s NATem resi. Pokud s tim ma server problem (proc? utorrent to umi :), lze si pomoci berlickou. Napriklad v linuxu pro minecraft server:

$ natpmpc -a 25565 25565 tcp 3600

Mi otevre port pro 25565. Samozrejme to neni idealni, protoze kdokoliv z okolnich uzivatelu si ten port muze zabrat taky. Velmi podobna situace jako dynamicka IP na modemu. Na casual hrani vic nez dostatecne, velke servery beztak potrebuji hosting.

Pokud provider neposkytuje alespon dynamickou verejnou IP, nebo portforward pres pmp/upnp (a nebo alespon pres telefon/web xycht), rychle od nej pryc, protoze na lidi sere a zajimaj ho jenom babicky na facebooku :)

Abych jen doplnil - rozdeleni netreba. Vsechny NAT GW mohou klido prdo sedet v jednom sdilenem /22 segmentu a vesele si povidat po BGP s core routerem kde sou spojovacky. Vim to protoze to tady tak je.

Jedine misto kde je potreba plytvat adresami je spojovacka mezi AS, coz je tradicne /30 (4 IP). Jejich pocet spoctete na prstech ruky i pro hodne velke operatory.

Na co narazim s cilovym strojem. Vsichni co machrujou s netstatem si neuvedomuji ze jeden zaznam NATu je kombinace:

srcip:srcport:dstip:dstp­ort. Z toho plyne ze limit je na *zdrojove* strane, tam dojdou porty pro cilovou kombinaci ip:port. Vice jak 100 spojeni na jeden cil je ve vetsine pripadu beztak na hranici DOS utoku.

A mimochodem, vsechny prohlizece limituji pocet ESTABLISHED spojeni (FIN-WAIT se do limitu nepocitaji) na kazdou cilovou IP. Chrome 6 (https://code.google.com/p/chromium/issues/detail?id=85323), Firefox tusim 3. Na limit cone natu proste nemate sanci narazit.

Ano, mate pravdu, jedna se o symmetric NAT. Poucuju tady a sam v tom mam bordel - ty terminy v anglictine mi nejak v hlave evokuji presny opak (u nas cesky rikame 1:1 nat a 1:N nat).

Sub-alokace v ramci NFX maji ale podobna pravidla jako RIPE. Tzn ti velci s vetsi siti, co plati vice si vyhadaj vic. Ale i tak je adres celkove zalostne malo. Neexistuje neco jako spolecny pool, jednou se to prideli nejakemu sdruzeni a basta.

Adres ma pilsfree asi tak petkrat min nez by bylo treba pro verejnou IP pro kazdeho uzivatele. Coz kupodivu prilis nevadi, protoze v prumeru to bude tak paty az desaty uzivatel co ma vubec tuseni co to nejaka verejna adresa je.

mohly adresy v Severní Americe dojít někdy v období příštích letních prázdnin.

To je tzv. předbudoucí čas.

Bude vytvořena nová síť, tvz. Euronet. Stávající Internet bude jako přebytečný zrušen a zakázán a jakékoliv jeho použití bude zakázáno.
Na Euronetu budou kvůli ochraně dětí před dětskou pornografií povoleny pouze přínostné a užitečné služby jako jízdní řády, stránky ministerstev a certifikovaných obchodů.
Stránky eurosocialistických organizací (bývalých právnických osob) budou až na výjimky přístupné pouze eurosocialistkým organizacím, protože by normální řádné občany mátly.
Každý občan obdrží od státu řádnou a certifikovanou emailovou adresu. Použití jakýkochkoliv jiných adres, ať už komerčně poskytovaných nebo tzv. free, by bylo zbytečné a proto bude přísně zakázáno a trestáno.
Dále bude mít každý občan právo na jednu osobní webovou stránku a na jeji pravidelnou aktualizaci 1x měsíčně, po schválení příslušnými orgány.
Protože je na Euronetu přístupné vše potřebné, bude propojení s ostatními sítěmi zrušeno jakožto zbytečné a nebezpečné.

Začal jsems se zajímat, jestli u O2 můžu dostat IPv6 adresu a našel jsme na jejich webu tohle:

(http://www.o2.cz/osobni/techzona-sluzby/IPv6.html):

Internet zřízený po 1. červenci 2012: ...IPv6 adresu jste získali automaticky při pořízení internetu. IPv4 adresu máte přidělenou také...

Internet zřízený před 1. červencem 2012: ...Objednat si fixní IPv6 adresu v některé z O2 Prodejen nebo na telefonní lince 800 33 00 76 (podnikatelé a firmy na lince 800 203 203). Služba je zpoplatněna dle aktuálního ceníku...

WTF?! Takže, protože jsem dlouholetý zákazník, tak si musím IPv6 adresu zaplatit a nový zákazník ji dostane zadarmo? FML.

Copak že musíš zaplatit za IPv6 - ono je to ještě daleko horší. Když si to /64 objednáš, tak si k tomu ještě jako bonus připlatíš za (fixní) veřejnou IPv4, protože bez ní ti to nezřídí. Takže to máš suma sumárum za 200.- měsíčně plus DPH. A je jim hrozně divné, že o tuhle "službu" je minimální zájem :-)))

Bohužel mi to bylo opakovaně potvrzeno různými lidmi sděleno na zákaznické lince. Ostatně když si přečtete odkazovanou zprávičku z Lupy, totéž sděluje i mluvčí Telefóniky. Bez pevné IPv4 vám tu službu prostě nezřídí a chtějí za to platit - za každé zvlášť. (Ne)schopnost operátora komunikovat a zveřejnit srozumitelné informace je ostatně dlouhodobě tragická.

Buď rád, že jsi rád. Zmrdi z O2 ti totiž zamplčují jednu věc. Ta IPv4 kterou dávají stávajícím a kterou bys dostal, když si objednáš IPv6 je totiž privátní.

No teda píšu jak blb :-) Tak radši znova: Ta IPv4 kterou dávají novým k té IPv6 a kterou bys dostal i ty, když si objednáš IPv6 je totiž privátní.

Dobře. Takže platíte 99 Kč za veřejnou IPv4 kterou jste předtím měl zdarma a dočasně nic za IPv6 prefix.

Kdyby velké společnosti a univerzity pustili do světa své A class bloky IP adres, tak by žádné přecházení na ipv6 nemuselo být a nebo ne teď a zbrkle než by se vymyslel jiný standard.
Je to jen uměle vyvolaná a přiživovaná "nutnost", aby každý čip měl svou IP.

"Jiný standard" byl vymyšlen už v půlce devadesátých let. Jmenuje se IPv6... :-)

Přes 13 let příprav na IPv6 dodává slovu zbrkle zcela nový význam.

Prohlásili tmu za standard a 13 let čekají, až na to lidé přistoupí. Osobně to považuji spíše za "necháme to vyhnít" než za "lety prověřený standard". Ale neberte to zle, ten "druhý tábor" má přístup obdobný. Snad už se blíží doba, kdy někomu dojde trpělivost s náboženskými debatami typu "NAT je zlo" a "IPv6 je zlo" a s něčím kloudným přijde.

A komu by jako měla dojít trpělivost? Ti co mají moc měnit už dávno rozhodli. A zvolili IPv6.

Vazne si jako myslite, ze se cisco, microsoft, hp a nemala komunita open-source vyvojaru jen tak rozhodne, ze stavajici reseni "jsou zlo", zahodi miliony dolaru investovanych do vyvoje a testovani, zapomenou na statisice clovekohodin stravenych navrhem a implementacemi a spolecne prijdou "s necim kloudnym"?

Mozna by si konecne mohl CEZ uvedomit, ze okradat lidi a stat "je zlo" a "s necim kloudnym prijit"...

V systemu, kde rozhoduji pseudovzdelani kravataci, neni mezi "nabozenskymi debatami" a jakoukoli technicky relevantni informaci absolutne zadny rozdil. Podivejte se do tech RFC, ze kterych firem je lide pisi. A projdete si archivy prislusnych mailing listu. Jak by rekl nekdo, kdo chce vypadat chytre, kostky jsou vrzeny.

Neni jednodussi, kdyby se konecne lidi naucili jak vlastne to IPv6 funguje a zacal ho pouzivat? Vymlouvat se, ze neco "je zlo" umi fakt kazdy.

To nejsou žádné výmluvy, před pár měsíci vyšel na Lupě seriál, kde byly problémy a nedotaženosti IPv6 konkrétně probrány.

+1

IPv6 řeší problémy jen nedostatku adres, ale pak už přináší jen samé problémy, nehledě na možnosti bezpečnostních skulinek... Kdo to prosadil proboha? :-)

Som zvedavy kolko % (neupdatovanych windows) PC bude napadnutych preto lebo sa vystrcia spoza (zleho) IPv4 NATu na bezNATove IPv6...
Botnety zas nabobtnaju...

Ja si myslim , ze typicky uzivatel ma pred temi zarizenimi nejaky router, ktery ma nejakou bezpecnostni politiku ne ?

TAkze pro internet budu zase jedno zarizeni a kam jake porty forwardovat si nastavi sam uzivatel ?

To by byl dobrej banglades kdyby uzivatelum vylezly do internetu vsechny zavirovane PC , telefony a tak :)))

Tohle teda zatim nechapu jak to bude teda, ale kazdopadne to bude sranda , kazdemu budu defaultne instalovat vnc :))))

Typicky uzivatel se strasne divi, ze pokud potrebuje pripojit druhe PC, televizi, ntb, mobil, pda, .... potrebuje krabku za "litr" a nestaci mu krabka za kilo. S IPv6 mu stacit bude.

Informovany uzivatel pak bude vedet, ze by bylo mozna zahodno mit nejaky domaci firewall, ktery pripadne muze poskytnout i dalsi sluzby (trebas mobilitu), jenze to mu zase znemoznuji debilni ISP, kteri mu na to nedaji IPcka (kterych sice mame bambiliony, ale proc nekomu dat co potrebuje, ze...).

To ze stroj je pristupny ze site je !normalni! stav, naopak zcela nenormalni stav je cokoli jineho. Normalni stav je taktez, to, ze na normalne nakonfigurovanem stroji by default nebezi zadne sluzby => odpovi na ping a to je vse.

Vazne se dycky smeju tomu, ze nekdo ma prece ten NAT, tak je to OK, a ja mu pak behem minuty browsam po disku - trebas pres jeho wifi.

Edit: Jop, v "normalni" situaci by se dalo cekat, ze ten firewal bude schopen dodat ISP (nalezite nakonfigurovany) a ze zakaznika alespon pouci.

Ok, mam za NATom nejake SSH-cka, NAT-PMP mi nefunguje a som ochotny nasadit lubovolne riesenie, ktore mi SSH spristupni zvonka (co je ovela jednoduchsie ako spominane browsovanie po disku cudzieho, kedze je tu mozna kooperacia pri nastavovani).

Existuje nieco ine ako IPv6, co naozaj funguje a pokial mozno to nevyzaduje vela prostriedkov? Pod prostriedkami myslim, ze pripajat sa do VPN asi nie je to prave (treba na to server) a zaroven lubovolna nutna interakcia z opacnej strany pri kazdom pripojeni sa mi zda az vela.
Ak to existuje, tak prosim napis aj presny nazov a popis takeho programu.

IPv6 je momentalne riesenie, ale chcel by som, aby bolo mozne pripojit sa tam z lubovolnej internetovej kaviarne, maximalne s nejakymi programami na USB kluci.

Pokud hledáš řešení pro sociální případy (tedy zadarmo), zkus SocialVPN http://socialvpn.wordpress.com/
a doufej že ti někdo poslouží jako relay ;)

Ano, proč to nenapsat rovnou - to co je potřeba je zpřístupnění obsahu na počítačích za NATem zadarmo a pokud možno bez složitých zásahů uživatele, a aby to pokud možno jelo rychle včetně streamování videaa a přenosů gigabajtů dat denně.

Kdokoliv tu něco píše o tom že pořídit si VPS nebo VPN je těžce mimo, protože pouze minorita uživatelů bude ochotna za to platit. Samozřejmě že VPN s pevnou veřejnou IP adresou bude řešením, ale opět se dostáváme do stavu - někdo musí mít veřejnou IP adresu.

Už aby bylo dobře rozšířené a funkční IPv6, to je podporováno i v boost::asio a dalších relativně standardních knihovnách, a programátoři se nebudou muset zabývat tím jak vlastně používat chujoviny jako je libnice nebo pjnath, které toto částečně řeší. A ty knihovny jsou (ne)dokumentované tak, že bez znalosti STUN a TURN protokolu se nedají použít, přitom ne každého to zajmá jak to funguje, protože chce jenom poslat data z jednoho uzlu na druhý, a pokud možno bez prostředníka aby to jelo rychle. Navíc pokud chcete stoprocentní konektivitu, tak se TURN relay stejně nevyhnete, protože to pro změnu neumí multi hole punching. Pjnath má navíc lepší podporu ALG, ale zase vůbec nepodporuje IPv6 pokud je dostupné, což je deviza libnice, takže pokud budete chtít maximalizovat pravděpodobnost přímého spojení dvou uživatelů, musíte použít obě knihovny a nebo pjnath + ipv6 a nad tím ještě nějakou další vrstvu co to posílání dat skryje a nějakou logikou rozhodne, co se tedy laskavě použije...

Widle za NATem jsou uplne stejne zabezpeceny jako widle s verejnou adresou, ale to by nekdo musel tusit co plka.

Drtivá většina útoků co jsem na MS Windows viděl bylo buď přímo přes malware, nebo přes webové stránky (respektive webový server, který využil toho, že už se vzdáleným PC spojení má - proč oběti vyhledávat, když se vesele hlásí samy).

Old school hackování už se moc nenosí, tím byste velký botnet nepostavil. Takže to, zda je počítač vystrčený nebo ne, nemá na růst botnetů v dnešní době moc vliv. Jó byly doby, kdy se opravdu hromadně očuchávaly porty a nabourávaly se chronicky známé slabé služby (jako port 135 nebo 139), ale to je dnes zaprvé těžší (MS na svých OS mírně zapracoval) a zadruhé jsou zde řádově jednodušší metody (lidé si malware instalují sami, nebo to za ně obstará jejich prohlížeč).

Ne, že by nebyly řešitelné, ale nikdy to není ono. Zvláště pak brzdí malé startupy a jiné oss projekty, kde autoři nejsou schopni zajistit kvalitní infrastrukturu ve formě množství relay serverů.

Jinak od té doby co Microsoft přebral Skype, tak uživatelé z veřejnou IP už nefungují jako supernody, tuto funkci plně převzaly vlastní servery Microsoftu. Nějaký OSS projekt jim v tomto nemůže konkurovat, protože nemá takové příjmy na provoz této infrastruktury, a proto musí spoléhat na konektivitu svých uživatelů.

Jinak pěkně vysvětlené formy NATu včetně metod jejich obcházení je zde (anglicky):
http://www.goto.info.waseda.ac.jp/~wei/file/wei-apan-v10.pdf

Když by někdo chtěl rozjet novou sociální síť a využít p2p konektivitu uživatelů, tak nemůže, protože NAT. NAT zvýhodňuje aplikace typu klient-server, čímž deformuje tržní prostředí, protože tento typ aplikace představuje dodatečné náklady a povinnosti pro provozovatele (jako je logování) a navíc uživatelé ztrácí jistou míru soukromí a anonymity. Navíc vede k tomu, že data nejsou uložena na nosiči fyzicky vlastněném uživatelem, takže poskytovatel hostingu také částečně nese odpovědnost za jejich obsah či je může zneužít za účelem cílené reklamy. Třeba taková Diaspora byl zajímavý startup, který bohužel úplně nevyšel. Ale představme si facebook, kde by si lidi sami spravovali svoji infrastruktru, něco co není pod kontrolou jedné firmy a jejich hloupých podmínek (zákaz fotek kojících matek, protože obsahují vyobrazení bradavky...).

Ale pod pojmem startup nemusíme nutně vidět jenom IT záležitost, je to jenom buzzword pro začínající firmu. Kdejaký živnostník by ušetřil, kdyby si mohl z domu rozjet svůj malý servřík se svými stánkami nabízející jeho produkty. A mnohým by to bohatě postačovalo.

Ale teď je čas dát si menší visual novel o sociálních sítích:
http://my.pages.de/dsn-vn/
;)

On je spíš problém pro případné tvůrce softwaru který by toto zjednodušil. Ideální by bylo, kdyby šlo vytváře software, který by umožňoval vynutit aby uživatelé sdíleli svá data (třeba veřejné stránky) a přitom sami nemuseli řešit technické detaily. Samozřejmě že relativně malý poplatek si může každý pořídit VPS, ale jak donutíte lidi aby si to zařídili všichni jenom proto, že vaše aplikace toto potřebuje ke správnému fungování?

Předpokládejme že BFU nahodí vygenerované stránky do adresáře který pojede u něho z komput, ty se někam párkát replikují a něčím se to bude směrovat na právě běžící instanci. Všechny IP musí být veřejné, nebo lépe řečeno, musí mít přidělenu kombinaci IP a port které budou neměnné a poběží na nich daná služba.

Ano, je pravda, že prakticky by běžnému uživateli stačilo řekněme že tak maximálně 16 portů, ale i tak vyhradit je pro 4096 uživatelů bude činit problémy. Navíc konzumní zboží jako herní konzole nabízí dodatečnou funkcionalitu plnohodnotného online hraní pouze tehdy, pokud si nějak zajistí port a adresu. Tento stav je dlouhodobě neudržitelný, protože takových zařízení bude jen přibývat.

Takže pokud dnes chci POUZE webové rozhraní pro bittorrent klienta, ssh a abych si to mohl ovládat z práce, vzdálenou plochu a nějaké to VoIP, tak později budu třeba chtít aby mi mikrovlná trouba ohřála večeři když jí aktivuji mobilem při odemykání vhochodových dveří, abych nemusel čekat ty dvě minuty. To je samozřejmě hloupý případ, ale právě takovýchto chujovin bude přibývat.

Opět se to samozřejmě dá řešit protokolem který poběží na jednom portu, ale to bude fungovat pouze tehdy, pokud se NAT bude chovat slušně, což u symetrického NATu nehrozí. Full cone NAT se samozřejmě bude chovat ještě dobře a dokud takových magorů nebude hodně, tak to fungovat bude. JENOM to přidává další starosti programátorům, protože neexistuje jednoduché řešení daného problému.

Navíc ono řešení viz. pdf výše bude fungovat i pro symetrické NATy, pokud si tedy seženete dva servery co prostřelí ty díry a váš ISP nebude mít velmi exotický hardware. Ale opět - knihovna proto neexistuje, a já nechci programovat vlastní bastl jenom proto, že neexistuje standardní neplacené řešení které by pokrylo i tuto metodu jak se dostat přes NAT. Vím sice o placené NAT traversal knihovně která toto nejspíše dělá a kde ta firma nabízí i možnost pronájmu TURN relay serverů pro těch pár uživateků u kterých nepomáha ani multi hole punching protože symetrický NAT generuje přidělené porty náhodně, ale to není řešení třeba pro open source projekty.

Uzivatele jako supernody fungujou furt, M$ jen zprovoznil navrch vlastni, pres ktery jede placenej provoz, nebot si platici zakaznici stezovali, ze je kvalita hovoru velmi promenliva (prave na zaklade toho, jaky node prave pouzivaji).

Není tak úplně jisté, minimálně pro nové uživatele je prý poměrné těžké získat status supernode uzlu, viz. článek na Ars Technica

http://arstechnica.com/business/2012/05/skype-replaces-p2p-supernodes-with-linux-boxes-hosted-by-microsoft/

Zdar a sílu,

nemám zájem rozpoutávat flame, nicméně, jako člověk, kterej implementoval v4 a v6 stacky mám silnej pocit, že IPv6 je fail právě pro překombinovanost a složitost implementace. Kdyby pánové a organizace, co to tvořili, nebyly zhulení a nesnažili se každej prosadit "něco svého" (často i snad jen proto aby tam od nich něco bylo), věřím, že by v6ka už dávno okolo byla. V embeded oblasti, kde neběží "kernel" (bsd,linux, ...) a počítá se každej Kb RAM nebo fleše, je to neuvěřitelnej rozdíl. A tím nemyslím to, že je adresa o něco málo větší. Množství "věcí" ktere se musí implementovat a nakolik jsou sami rozsáhlé, aby to jelo.

Nemám nic proti změnám a novím věcem :) Jen musí mít hlavu a patu. IPV6ka je někde na úrovni snahy ekologů vyřešit spotřebu a ruť tím, že zakážou klasické žárovky.... To tu ale každej určitě ví, jak totok funguje.

To je myslím zcela základní důvod failu ipV6ky, jíž jsme svědky. A že to fail je, je zjevné. Kolik by asi bylo procent domén, kdyby se nepředělali na základě automatizovaného robota a web hostingů ?

Časem nezbude nic jiného, to je bohužel pravda. A tak nám nezbyde, než kočkopsa ipV6 mít všude...

Chápu, že lidi z NICu a podobní, jejiž rozlišovací schopnost v6ky končí na úrovni kabelu (nemysleno špatně, pouze kosntatování, že na věci koukají z jiného úhlu) určitě nebudou souhlasit. Přece to tak krásně funguje. Jenže za tím funguje, je nechutně překombinovanej kočkopes.

Ale ty množsštví energie navíc, ve formně instrukcí, tepla a flesh buňěk, která se kvůlu 6ce bude muset vyzářit a posléze ochadit, se někde vyrobit musí. A nějaka elektrárna navíc to bude :)

Škoda, že místo jednoduché věci, jakou v4ka je, udělali překombinovaného kočkopsa, který "umí věchno" a tím z velké části zabili jeho nástup... Ne každej je happu s tím, že "linux kernel to umí".

Proto nemám rád IPV6. A nikdy nebudu.

Vývoj jde od věcí primitivních přez složité k jednoduchým. 6ka bohužel tto rčení přesně reflektuje...

Můj názor, nic víc :) A nechci rozpoutávat flame a dohadovat se, která featura je taková nebo maková a že je vlastně skvělá. Protože vždy záleřží "jak pro koho". Pro správce sítaře to bude rozhodně něco jiného, než pro někoho, kdo počítá spotřebu na desetiny watu.

R.

Nejake konkretnejsi argumenty by nebyly? (Napr. ktera featura konkretne zvysuje naklady co do prikonu ci narocnosti implementace.) AFAIK je tam naopak docela dost veci, ktere to zjednodusuji (zruseni fragmentace na routerech ci zruseni potreby prepocitavat konktrolni soucet pri forwardingu).

Co do narocnosti implementace jednoznacne zvysuje naklady nutnost znovu implementovat ARP, ktery se jen jmenuje NDP, ma nekolikanasobne vic podminek a okrajovych pripadu, se kterymi se MUSI pocitat (RFC4861) a oproti ARP neprinasi nic noveho. ICMPv6 jako "formalizace nekolika starych protokolu do jednoho" je teoreticky pekny napad, ale sam jiste vis, ze implementace rozhodne stejne slozite nejsou.
Na co potrebujeme 24 strankove RFC 3484 (default address selection)? Na co potrebujeme vynucovat v krajnich pripadech link-local adresy, takze kdyz je nepouziju jako gateway, nektere nahodne featury (napr. ICMPv6 Redirect) prestanou fungovat? Na co potrebujeme svetu diktovat jakym zpusobem si ma generovat adresy? Proc vlastne DHCPv6 a RA nemaji od zacatku stejne opsny pro zjednoduseni implementace? A proc vlastne nemuze RA podporovat generovani mensich adres nez 64 bitu? (ne, alignment tady fakt nehraje roli, adresu generujeme jednou za pet minut a zamaskovat pul adresy nas fakt nezabije, navic mame DAD a ani trefit se dvakrat stejne do 2^32 neni tak lehke)

Proc je SeND patentovane a neni to volitelna soucast IPsec? Proc se vubec nekolik let resilo jestli AAAA nebo A6? Proc je tolik prechodovych mechanismu a NAT64 implementace pokud vim jen jedna?

Prepocitavani checksumu, "variabilni" hlavicky co nejsou zase tak variabilni, konecne reseni fragmentace, anycast "v zakladu" -- tyhle featury jsou sice fajn (s tou fragmentaci jim to teda trvalo, diky F. Gonte!), ale zdaleka to nevyvazi ten bordel, ktery vznikl praci ve stylu "jenom to prepiseme do uhledne formy... a tohle by chtelo zmenit". IPsec se taky docela povedl, ale je malo jednoduchych implementaci, takze se nerozsiril. Hlavni problemy do budoucnosti, mobilita a rust routovacich tabulek, jsou ponechany "for further study". Takhle se da pokracovat dal a dal...

IPv6 je "fail" hlavne proto, ze blbci jsou dvou typu. Jedni {neumi|nechte­ji|odmitaji racionalne} navrhnout protokol a druzi se vymlouvaji, ze se jim neco nelibi a tedy to nebudou pouzivat. Takze na jedne strane mame desitky naprosto zbytecnych, komplikovanych a casto nedostatecne otestovanych RFC, ktere tu druhou stranu absolutne nezajimaji, protoze to pro ni "je zlo" ;-)

Jen dopním pár věcí, co řekl kolega, protože se nezbvývá, než pod to podepsat... Další ztěžující věc jsou různá rozhraní (z hlediska adres), které jsou navěšené na jedno (třebas místní linky při autokonfiguraci). 1 rozhraní tak nakonec může komunikovat s větším množstvím měnících se adres (rostou nároky na pamět, ARP tabulky, ...).

Fragmentování ? To jsem ještě nikdy neřešil, pakety s fragmentem zásadně zahazuju (není RAM kam si to uložit a čekat) a zatím jsem nikdy nenarazil na situaci, kdy by to zpusobovalo problém. Ona většina zařízení s fragmentovanejma paketama stejně dělat neumí a na směrovaších ISP se obvykle zahazujou. Takže opět něco, co se vyřešilo samo historicky tím, že HW překonal nutnost cokoliv fragmentovat. Zkus si poslat fragmentovanej paket z jednoho konce světa na druhej... Došel ? :)

Nepřítomnost součtu, že něco zjednodušuje ? Přepočítat kontrolni součet neni problém a to, že ho odebrali, je dle mého názoru, taky chybou. Ne všude pakety jedou po ETH, ne každý protokol, kterým se tuneluje je málochybový. Ne všechny kabely jsou duělné jak by měli, sem tam se vyskytují i v provoze a zarušených oblastech... A tam fakt chyba není něco, na co by se muselo čekat dlouho... Stačilo ho definovat rozumně, nikoliv jako ve V4, kde se vytváří virtuální hlavičky, je jich tam několik atp.... Tak či tak, tohle v podstatě není zjednodušení, protože při tunelování se musí přidat "vrstva" navíc. To teď stačilo prohnat paket kudy člověk potřeboval a nemusel řešit nějak spešl CRC. Určitej význam to má když se implementují věci na úrovni FPGA, což se týká lepších swtichů. Tam pro změnu ale mají FPGA takovej hrubej výkon, že to CRC už zase moc nemění. Stejně tam CRC jednotka pro V4 být musí, leda že by to byl V6 only HW.

Potom fine věci, jako že do stejné skupiny patří 2 rozhraní, jedno WAN a druhé LAN. To všechno zesložiťuje logiku "routování" paketů. Je sice krásné, že zákazníkovi přidělí operátor 1 subnetu a on pro WAN použije rovnou tu subnetu stejně jako pro LAN, nicméně... Proč ? Pak s takovo hovadinou musí počítat každé zařízení. Notabene, operátor stejně musí vědět kam naroutovat daný rozsah, takže se ani nakonec neuštetří ani záznam v routovacích tabulkách. Pouze nebude "transportní" subneta.

Pak namátkou zónové rejstříky, nejednoznačnost routování dle samotných RFC, kvůli kterým se pak píšou další RFC (2462 a 4007). Ono celkově ta autokonfigurace je lahůdka.

Nebo další drobnůstka, routing hlavičky. Ve V4 se fakt neosvědčili a sloužili akorát k útokům, takže ve V6 se udělali také aby je pak s velkou slávou zrušili (5095). Tak at mi nikdo neříká, že nebyli zhulení :)

Identifikace toku (flow label). Krásná myšlenka, která by fungovala v dokonalém světě... Jenže, realita je jiná. Dodnes je to nevyužívaná položka a nejspíše zůstatne, protože jak by mol hraniční směrovač věřit této položce, když útočník tam může strčit co bude chtít a dostat se tam kam nemá? Do sitě bych si nedal zařízení, které by této položce důvěřovaloa nedalo se to vypnout. Radší ať si udělá lokální cache, když už nemá výkon na to, aby při každém paketu prozkoumala "kam s ním".

Jak říkám, pro někoho to můžou být úžasný featury, pro mně jsou tyto věci V6 killery.

Kdyby se z V6ky nesnažili udělat kočkopsa co má v sobě všechno, definovaly rozumej základ funkčnosti a zbytek nechali na "protokolech" (v obecné rovině), věřím tomu, že by dneska V6 adresu měl kde kdo. IpSec je součástí hlaviček, bla bla bla...

Náklady, které stoji implementace V6 zabíjí jeji rozšiření a ještě pěkných pár let bude. Náklady zbytečné... Bude jednodušší (čti: levnější) obchodovat s adresama, kterých je více než dostatek alokován mezi členy RIPE... Až skutečně někomu začnou odebírat nevyužívaný vě větší míře, pak můžeme teprve začít říkat, že nám dochází adresy. Do té doby je to čistě akademická debata.... Nám se také vyplatí stavět V4kovou síť a tunelovat, než překopávat tisíce zařízení na V6ku...

Je to jak poměřování pindíků u piva... Dřív se poměřovali pindíci, potom mobili a dneska délka IP adresy :)

R.

> Další ztěžující věc jsou různá rozhraní (z hlediska adres), které jsou navěšené na jedno (třebas místní linky při autokonfiguraci). 1 rozhraní tak nakonec může komunikovat s větším množstvím měnících se adres (rostou nároky na pamět, ARP tabulky, ...).

Nejsem si jist, ze rozumim co mas na mysli, ale pokud tim myslis proste vic IP prefixu na jednom sitovem rozhrani, tak to je featura, ktera puvodne v IPv4 nebyla, ale je natolik potrebna, ze ji dneska (pro IPv4) stejne umeji skoro vsichni, ale proto, ze puvodne nebyla ve standardu, tak mohou byt potize s kompatibilitou (napr. v OSPFv2, kde rozumne chovani pri vice IP na rozhrani snad nikdo nedefinuje). Proto je vcelku rozumne, ze pri navrhu IPv6 to tam rovnou dali.

> Fragmentování ? To jsem ještě nikdy neřešil, pakety s fragmentem zásadně zahazuju. .. Takže opět něco, co se vyřešilo samo historicky tím, že HW překonal nutnost cokoliv fragmentovat.

Problem s fragmenty v IPv4 neni ani v tom, ze bys je musel spojovat (to stejne dela koncovy stroj), ale ze je musis po ceste rozdelovat, kdyz je predavas na linku s mensim MTU.

Ono to je trochu jinak - prave proto, ze v IPv4 je fragmentace docela dost rozbita, tak se lide moc neodvazuji pouzivat jine (vetsi) MTU nez 1500, i kdyz pro moderni hardware a rychlosti by to bylo vhodnejsi.

Problem s fragmenty v IPv4 neni ani v tom, ze bys je musel spojovat (to stejne dela koncovy stroj), ale ze je musis po ceste rozdelovat, kdyz je predavas na linku s mensim MTU. Jak je to s pruchodnosti fragmentu Internetem nevim, nicmene problem byva spis na opacne strane - router predavajici pakety, ktere maji zakazanou fragmentaci po ceste (typicky TCP), vygeneruje ICMP zpravu, kterou nekde sezere pitome nastaveny firewall.

> Nepřítomnost součtu, že něco zjednodušuje ? Přepočítat kontrolni součet neni problém a to, že ho odebrali, je dle mého názoru, taky chybou. Ne všude pakety jedou po ETH, ne každý protokol, kterým se tuneluje je málochybový.

Kontrolni soucet samozrejme neodbrali, pouze z nej vyjmuli TTL, takze ho neni treba pregenerovat pri kazdem forwardovani paketu.

> Potom fine věci, jako že do stejné skupiny patří 2 rozhraní, jedno WAN a druhé LAN. To všechno zesložiťuje logiku "routování" paketů. Je sice krásné, že zákazníkovi přidělí operátor 1 subnetu a on pro WAN použije rovnou tu subnetu stejně jako pro LAN, nicméně... Proč ?

To, zda mezi LAN a WAN se routuje (a pouzivaji odlisne prefixy) nebo bridguje/proxy­arpuje (a pouzije se stejny), preci vubec nesouvisi s IPv6 - obe varianty se pouzivaji jak na IPv4 tak na IPv6 (nicmene bridging jako optional). A fakt nevim, ze by nejaky IPv6 RFC specifikoval, ze to IPv6 implementace musi umet. Odkaz?

Logika routovani/for­wardovani je vicemene stejna - vyberu best-matching routu a pouziji interface a next-hop, ktery ta routa specifikuje.

Ad více rozhraní: nejde o to, jesli existuje více IP adres na jednom rozhraní, ale způsob, jakým IPv6 k tomu přistupuje. Minimálně bych měl rozpoznat link local, nějakej muj unicast, loopback a páš dalších (nodes na ifacu, linku, ...). A to pomíjím privacy extensions, kde se mi buduo měnit IPčka klientlů nazdařbůh. Další věc nutná k ošetření. A minimálně jeden nejmenovaný OS to má ve výchozím stavu zaplé...

Ad fragmenotování: přesně jak říkáš, 1536 batů "musí stačit každému"... Ono to souvisí ještě z dob 10base a sdíleným médiem... Těch 1500 se tak nějak vžilo jako standard, že s tím tak nějak všici počítají. A když ne, máme jumbo framy. A vzheldem k tomu, že já jsem koncovej stroj, je spojování na mně.

Ad CRC: vyjmuly kompletní hlavičku, to znamená, že část paketu prostě *nemá* CRC. Čili, je na mně si to ověřit, protože pokud chybuje médium, tak můžu posílat pakety na nějakou rand() adresu danou chybou.

Ad LAN/WAN: na IPV4 nejde jednouše mít směrovač, kterej dostane od operátora 192.168.1.1/24 tak, že on sám bude mít ".1" a klienti (na jiném rozhraní) 2-254. U IPV4 se používaj tansportní subnety /30, nebo přislušnost k vetší tansportní subnetě. U IPV6 je možné mít přesně tuhle konfiguraci (analogicky). A to u IPV4 není možné.

A best match ? Když je víc rozhraní, tak už nemusí být jednoduché určit, kam paket poslat (vic RFC4007).

IPv6, co se týče kódu, je minimálně 2x tak náročná než IPV4 a to režie 32->128 (zvětšení IP) je znedbatelná.

R.

Diky za zajimavy pohled na vec z jineho uhlu. Muzete se mi prosim ozvat tpoder@cis.vut­br.cz. Predem diky.

Carrier Grade NAT a UDP multihole punching

Mezitím co my se tu hádáme, tak asiati již pracují na řešení jak se dostat i přes to. Protože někde se to bude určitě používat, tak se hold nedá nic dělat a budoucí aplikace se budou muset přizpůsobit...

Nějaké slajdy zde:
http://www.apan.net/meetings/Hanoi2010/Session/Slides/NetworkResearch/2.1.pdf

A ještě paper: http://www.apan.net/meetings/Hanoi2010/Session/Slides/NetworkResearch/paper/Protocol_ExtendedUDPMultipleHolePunchingMethod.pdf

a iPath zdrojáky: http://i-path.goto.info.waseda.ac.jp/trac/i-Path

Prostrelovani NATu je celkove dost velka alchymie. Momentalne nejlepsi metoda se zda byt:

http://en.wikipedia.org/wiki/ICMP_hole_punching

Problem je v tom kdyz se 2 uzivatele za velkymi 1:N naty (rekneme 5000 lidi za 1 IP) snazi neco prostrelit. GW na obouch stranach budou mit velky problem zachovat zdrojovy port, protoze bude uz pravdepodobne pouzit jinym parem uzivatelu. A to ani nemluvim o pripadech kdy tam je neco prechytraleho (OpenBSD, PIX) co randomizuje zdrojove porty po pruchodu natem.

Spravne reseni je nativni support pro port forward (nejrozumejsi se zda byt NAT-PMP).

Z mého pohledu je pro trošku zkušeného uživatele jednoduché nastavit na IPv4 routru pevné(nebo pevně přidělované) adresy a následně upravit Firewall a NAT.
Pro IPv6 s dynamickými adresami přidělovanými od poskytovatele nebo s privaci extension si to neumím moc dobře představit.Nejspíše bude nutností používat něco jako UPnP či jak se to jmenuje.

Což mě vede k otázkám:
Máte někdo zkušenosti s používáním UPnP(nebo podobně) pro IPv4 ve svých aplikacích?
Funguje toto(nebo něco jiného) i pro otevření firewalu na IPv6?

něco ajko ipv4.5 kde se jn rozšíří adresní prostor na 64 bitový by bylo myslím ideální. Jk z hlediska kompatibility i implementace. I lidé by na takovýto systém přecházeli ochotněji, když by to byl jen stupínek nahoru, ne sprominutím celý žebř , jak je to při přechodu v4 na v6..