Mne sa tá IPv6 nezdá, má obrovský adresný rozsah a umožňuje defacto indektifikovať užívateľa, lebo mac adresa modemu sa jednoducho "zmestí" do IPv6 adresného rozsahu.
Okrem toho, na roote sa písalo o výskume jedného mladíka, ktorý napichol cisco routery a skúmal dáta z Internetu. Objavil aj bootnet v routrech, ktoré pre tento obrovský sken využíval.
A výsledok bolo, že vyše polovička IPv4 adresového priestoru sa nevyužíva! Inými slovami, mne sa zdá, že sa jedná o umelý nátlak. Nehovoriac o tom, ako Snowden načrtol bežnú prax na západe, kde tajné služby vyvíjajú nátlak na pracovné skupiny, ktoré sa snažia vyvíjať štandardy pre IPv6, všetko smeruje k tomu, aby sme mohli byť ľahšie sledovateľní.
Takže IPv6 Get in Hell! Nedostatok IPv4 je umelo vyvolaný. Vyše polovička IPv4 adries sa nevyužíva! A môžete tu prezentovať IPv6 ako len chcete.
Verím, že IPv4 bude existovať vždy a že nikdy nevymizne. Možno tam sídliť undeground, tak ako teraz sídli underground pod hladinou a potrebujete Tor ako ponorku pod túto hladinu.
I LOVE IPv4. Pretože tie sexi 4 čísla sú oveľa krajšie ako MAC adresa a oveľa jednoduchšia ako tá hnusná IPv6-ka. Bleee.
> Mne sa tá IPv6 nezdá, má obrovský adresný rozsah a umožňuje defacto indektifikovať užívateľa, lebo mac adresa modemu sa jednoducho "zmestí" do IPv6 adresného rozsahu.
A o Privacy Extensions jsi slyšel?
> A výsledok bolo, že vyše polovička IPv4 adresového priestoru sa nevyužíva!
Část lidí blokuje veškerou příchozí komunikaci, část jsou zařízení, která se zapínají jenom občas, a část se opravdu nevyužívá. Ono to ani jinak nejde, například protože se vždy alokuje po subnetech, které jsou velké mocniny dvojky (tj. očekávané využití by při rovnoměrné distribuci velikosti sítí bylo 0.75), navíc alokace subnetu je drahá (administrativa, nastavení, fragmentace routovacích tabulek), takže je rozumné vždycky si radši vzít trochu větší, případně s ohledem na plánované rozšiřování.
> Nehovoriac o tom, ako Snowden načrtol bežnú prax na západe, kde tajné služby vyvíjajú nátlak na pracovné skupiny, ktoré sa snažia vyvíjať štandardy pre IPv6, všetko smeruje k tomu, aby sme mohli byť ľahšie sledovateľní.
Nepleteš si to s tou falešnou přednáškou Operation ORCHESTRA? Já nevím, ale já furt v IPv6 nějak nevidím větší potenciál ke šmírování. Naopak tam funguje IPSec a díky tomu, že zase po 20 letech bude na Internetu fungovat end2end konektivita, je možné oprostit se od různých zprostředkovatelů sdílení souborů, VoIP atd.
> Nedostatok IPv4 je umelo vyvolaný.
Vždyť triviálním výpočtem lze dojít k tomu, že to není pravda: na světě je 7G lidí, z toho řekněme 3G jsou ve světě rozvinutém natolik, aby uvažovali o Internetu. Horní 1G (Evropa a USA) navíc často mají počítač, notebook, smartphone, počítač v práci, APčko, router, IP telefon, IP kameru a chytrou televizi. Adres je 4G, ale alokace nemůže mít 100% účinnost a něco taky je potřeba vyhradit na speciální adresy, infrastrukturu atd. Z toho je snad vidět, že už teď to prostě nestačí, a vypadá to, že chytrá zařízení budou přibývat a současně se Internet bude rozšiřovat do rozvojových zemí.
> Možno tam sídliť undeground, tak ako teraz sídli underground pod hladinou a potrebujete Tor ako ponorku pod túto hladinu.
Fun fact: většina lidí nemůže doma provozovat Tor node, protože nemají IPv4 adresu.
> I LOVE IPv4. Pretože tie sexi 4 čísla sú oveľa krajšie ako MAC adresa a oveľa jednoduchšia ako tá hnusná IPv6-ka. Bleee.
Ale je jich málo. Btw. existuje DNS, aby se ta čísla ve většině případů vůbec psát nemusela.
Mám zlú predtuchu ohľande IPv6 a myslím, že právom. Vezmime si tieto fakty najmä ohľadne hardvéru.
Zdroj: libreboot:
"Many people use non-free boot firmware, even if they use GNU/Linux. Non-free BIOS/UEFI firmware often contains backdoors, can be slow and have severe bugs, where you are left helpless at the mercy of the developers; you have no freedom over your computing."
"The Platform Security Processor (PSP) is built in on all Family 16h + systems (basically anything post-2013), and controls the main x86 core startup. PSP firmware is cryptographically signed with a strong key similar to the Intel ME. If the PSP firmware is not present, or if the AMD signing key is not present, the x86 cores will not be released from reset, rendering the system inoperable.
The PSP is an ARM core with TrustZone technology, built onto the main CPU die. As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x86 system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!)"
ďalej uvažujme o týchto faktoch:
článok na http://www.eteknix.com/expert-says-nsa-have-backdoors-built-into-intel-and-amd-processors/
ďalej uvažujme prečo Čína a Rusko vyvíja Loongson a Elbrus - pretože nemajú dôveru v hardware zo západu.
ďalej uvažujme o tomto:
https://securelist.com/blog/research/68750/equation-the-death-star-of-malware-galaxy/
EQUATION Group a ich malvér schopný infiltrovať firmware hardisku ba čo viac, tento malvér využíva vyše 80 modulov a niektoré z nich manipulujú so samotným sieťových rozhraním. Je to skrytý operačný systém priamo v hardwari, ktorí je mimo kontrolu užívateľa počítača, na ktorom beží.
Takže mám právo pochybovať o celom IPv6 protokole. Ja som už dávnom stratil dôvoru v IT - je to krám, ktorý nás špehuje a delí ľudí na skupiny, tak ako to robil istý pán v Nemecku pred II. svetovou vojnou. Viac k tomuto už nie som schopný napísať.
Takže bežná prax na západe je všade implementovať backdoory a ja mám veriť ako IPv6 je super a bezpečné? A o random pridelovaní IPv6 adresového priestoru sa ani netreba baviť - jediné skutočné random bolo zabudované v Truecrypte a vieme ako to dopadlo s TrueCryptom.
MAC v IP se používá jenom v případě, že chceš přístroj kontaktovat z venku. Tzn. musíš zařízení propagovat ven, třeba pomocí DNS nebo ho mít "spárovaný" třeba se svým noťasem. Najít ho hrubou silou je fakt super. A to tam máš přidaný i bit, jestli smí komunikovat ven, nebo ne. Ale jinak můžeš komunikovat po jiné IP adrese. Napadlo tě někdy, že v IPv6 můžeš mít díky adresnímu rozsahu co pět minut jinou IP adresu, nebo několik IP adres současně - po jedné komunikovat s manželkou, po druhé s milenkou... :D Co je za prefixem, to si vymýšlíš sám. Nemusí to být nutně MAC.
A dochází ti, že aby sis vyměnil soubor se sousedem, musíte se oba připojit na nějaký server a tam se to dá pěkně pochytat a analyzovat? Když se s ním v IPv6 uvidíš přímo, použiješ "netradiční" protokol a šifrování, tak si můžou šmíráci políbit pozadí. A máš šanci se vyhnout i racku u ISP, do kterýho si stát vynutí instalaci černé krabičky, pokud jsi ve stejné síti...
A ještě jedna sranda. S NATem máš v podstatě jenom jednu cestu, jak komunikovat se světem. Bez něj můžeš využívat současně několik cest a i jedna WWW stránka může, pokud má ISP konektivitu do několika uzlů, týct třeba třema cestama a dost to komplikuje snahu o zachycení přenosu a jeho analýzu... Jeden soubor se stáhne s adresou A po cestě X, další s adresou B po trase Y a kdo si spojí, že to skončilo v jednom fyzickým stroji?
Ja ako BFU ako dokazem mat co 5 minut, to inu IP adresu alebo niekolko IP sucane a jednou komunikovas manzelkou,... AKo to BFU mozemat pod kontrolou a vediet co sa deje? Rovnako sa to da aj zneuzit nie?
Ten druhy priklad. Ako viem vidiet suseda napriamo bez ISP? Cez ISP to musi ist stale. Stale bude mat niekto moznost sledovat moju komunikaciu. To by sme museli byt na lokanej sieti mimo akejkolvek infrastruktury ISP.
Pre treti odstavec plati to, co pre prvy. Ja ako BFU si to ako zariadim a budem mat nad tym kontrolu? Neboj sa urcite budu existovat viacery, ktory budu schopny a si to spoja a budu vediet, ze to skoncilo v jednom f. stroji.
Minimalne ISP by to mal vediet bez problemov. On vie aky rozsah ti pridelil. Nijako sa to nelisi od terajsieho stavu s IPv4.
Maly pocet IPv4 adries je problem ale osobne si nemyslim, ze IPv6 je najlepsie riesenie. Bohuzial je to v tejto chvili jedine riesenie a to je smutne.
IPv6 je stary protokol s kopu nedokonalosti podobne ako IPv4 a vidiet v nom aj rozne snahy a boj o presadenie roznych predstav a funkcionalyt urcitych firiem(ludi,....).
Tiez pochybujem, keby sa zacal vyvijat novy protokol, ze by bol urobeny lepsie. Skor sa bojim, zeby to dopadlo este horsie a tlak roznych isntitucii na presadenie roznych "nepotrebnych" funkcionalyt by bol este vecsi.
... radsi nic nepis, kdyz o tom nic nevis ... widle maji privacy ext zapnuty v defaultu. Takze jako bfu nemusis vedet vubec nic.
Pakety kupodivu tecou nejkratsi cestou a je dokonce v zajmu ISP aby to tak bylo, takze kdyz se sousedem budes na jednom switchi, tak ty vase data potecou prave pres nej, a nikam dal.
Kdyz mas net na mobilu a doma pevnou, muzes pouzivat oboje zaroven a bude to i fungovat ... vime?
Ano, pridame do IPv4 dalsi cislo a bude to OK ... zname, to uz tady je tradice v kazdy diskusi ...
Kdybyste cetl vlakno od zacatku, tak byste zjistil ze staci vzit ipv4, protahnout adresu na 128 bitu a bylo by vymalovano, ovsem akademicky board stvoril slozity bastl ktery se ani po dvaceti letech nikomu nechce nasazovat. Ten rozdil v pristupu zvlaste mlati do oci pri srovnani s HTTP 2, kdy google predlozil SPDY ke schvaleni v prosinci 2014. V kvetnu 2015 bylo RFC 7540 a krivka nasazovani leti vzhuru https://w3techs.com/technologies/details/ce-http2/all/all
"DHCPv6 je snad stejné"
Neni, potrebujete jeste RA https://cs.wikipedia.org/wiki/DHCPv6
Je zajímavé, že vždycky v diskusi o IPv6 někdo vytáhne, že to vymysleli akademici. V původní pracovní skupině byli naopak především zástupci firem: Cisco, AT&T, Novell, Boeing, Microsoft, Xerox, Lotus a dalších. Kromě nich tam byli lidi z CERN a MIT, ale neřekl bych, že si to navrhovali nějací akademici odtržení od praxe.
U http je treba predelat SW na obou stranach (server i klient) u ipv6 je treba predelat infrastrukturu (prevazne u klientu). Provider si otestuje nejakou ipv6 ready cinskou krabku, pote jich par beden koupi a technici objizdeji zakazniky a krabky meni. Nejake naklady to vygeneruje, ale tusim ze to nebude nic znicujiciho. Pripadne se contentari (protoze tem na tom zalezi zdaleka nejvice) spoji do nejake asociace a ISPckum na ty krabky prispeji. Navic kdyby se udelala nejaka skutecne hromadna akce, tak uz se vyplati si krabku nechat udelat na miru a v budoucnu si pak spolecne platit zaplaty FW.
Rozhodně IPv6 navrhovali lidé, kteří to následně neimplementovali. Centralizace správy sítě je v současné době v háji. Standardy a doporučení se mění častěji než ponožky. Všechno je úděsně komplikované a všude je mnoho variant s mnoha výjimkami a "ale". Tomu samozřejmě odpovídá i reálná ochota to nasadit... A bohužel na semináři jsem byl a byla to spíše akademická debata, kde se všichni tvářili, jak je to úžasné a jak nechápou, proč to už není všude. Není, protože to nikdo (tím spíše koncový uživatel) nepotřebuje. Není, protože implementace jsou tristní (Windows, routery, WiFi krabičky, tablety, mobily). Všude něco chybí. Správce z definice nemá IPv6 NAT, aby to mohl nasadit a okamžitě reagovat. Správce se musí prokousat desítkami výjimek, musí mít ponětí o specialitách různých řešení... Jedním slovem - IPv6 je skutečně běs. A když to někdo má osvětlit, tak se spíše tváří, že na tom není nic nepochopitelného... přestože IPv6 je mnohokrát složitější, než IPv4. A zkuste si jít po IPv6 třeba na Bing nebo idnes.cz. Na Windows to prostě nejede a nejede, i když se (opět) všichni tváří, jak je to na Windows platformě bezvadný a funkční. A z IPv6 přednášejících se na semináři nikdo kontroverzím a těžkostem nevěnoval, vše se "přešlo", aby to "náhodou nevypadalo s IPv6 špatně".
Správce z definice nemá IPv6 NAT, aby to mohl nasadit a okamžitě reagovat.
Viz doporučení na masáž o kousek vedle. K čemu kurník potřebuje správce k nasazení NAT? Aby to opět nefungovalo?
A zkuste si jít po IPv6 třeba na Bing nebo idnes.cz. Na Windows to prostě nejede a nejede, i když se (opět) všichni tváří, jak je to na Windows platformě bezvadný a funkční.
Ehm, když to nemá AAAA záznam, tak to skutečně po IPv6 nejede a nejede, a to nejen na Windows, a nic na tom nezmění ani deset dvojitých NATů.
Aaa dalsi mamloj co vzivote sit nevidel ... pokud si pamatuju, stejnej tam minimalne jeden sedel taky a presne tenhle dotaz tam vznasel, na coz bylo zcela adekvatne reagovano. => vystrel si mozek z hlavy a bez si stavet ty svoje desetinasobny NATy.
Ja sem jeden z tech spravcu, ktery behem 10minut nahodej IPv6 ...a ... nic se nezmeni, vsechno funguje, jen 50% jede pres 6tku ... a co vic, ta krasa kdyz nemusim porad vist dokumentaci kterej port vlastne kam vede, a resit ten zabordelenej NAT, a porad vymejset, jakou to zrovna v tuhle chvili bude mit IP, resit markovani paketu, abych vedel ze to je ten, kterej to ma bejt ...
Jinak by me zajimalo, jak uzasne jednoduse v IPv4 pridelis zakaznikovi prefix ... a o nic vic se nemusis starat ... neumis co? Nj, IPv6 to umi z definice ... divny.
Mimochodem, widle neumej sitovat ani na 4ce ....
> Standardy a doporučení se mění častěji než ponožky.
Co se třeba změnilo?
> Všechno je úděsně komplikované a všude je mnoho variant s mnoha výjimkami a "ale". [...] Správce se musí prokousat desítkami výjimek, musí mít ponětí o specialitách různých řešení...
Byly by tři příklady?
Jsem si vědom jediného kočkopsa, a to bordel kolem stateless DHCPv6 kvůli nastavování DNS, na což teď udělali field v RA.
> Správce z definice nemá IPv6 NAT, aby to mohl nasadit a okamžitě reagovat.
Nikdo nikomu nebrání IPv6 NAT (asi myslíš maškarádu?) implementovat. Dokonce to vypadá, že to do Linuxu už někdo napsal.
> A když to někdo má osvětlit, tak se spíše tváří, že na tom není nic nepochopitelného... přestože IPv6 je mnohokrát složitější, než IPv4.
Mně to fakt mnohokrát složitější nepřišlo.
> Len taky napad, nedalo sa to IPv6 urobit tak aby bolo spatne kompatibilne?
Ne, nedalo. Hlavička IPv4 má pro adresu natvrdo vyhrazeno 32 bitů.
Šlo by udělat rozšíření a mít možnost za původní IP adresou subnet -- díky tomu by routery na páteři mohly routovat pořád stejně a změna by stačila v sítích koncových ISP.
Jenže když se podíváš na současný stav věcí, tak zjistíš, že routery na páteří umí IPv6 bez problému už 10 let, a problém je právě v těch koncových ISP. Takže bychom si nepomohli.
> Takze centralne peeringy by to prehadzovali?
Peeringy právě nemají problém ani s IPv6, rozšíření by dopadlo na koncové ISP.
Rozšířený protokol tak přináší nejen tytéž problémy jako nový protokol, ale navíc přináší i další. Navíc neřeší již tehdy známé problémy IPv4 jako složitou autokonfiguraci, nespolehlivý multicasting, složité (= pomalé) zpracovávání páteřními routery (tj. pro páteřní routery je naopak výhodné přejít na IPv6), segmentaci adresního prostoru a chybějící podporu mobility.
Nebo tohle všechno opravdu bereš jen jako „nevyhnutelnou samozřejmost“?
Důležité je, že IPv6 tu komunikaci umožní. Jestli já si jí pak na firewallu povolím nebo zakážu je moje věc.
Osobně si myslím, že naopak padne iluzorní představa, že když je zařízení ve „vnitřní síti“, je nějak chráněné. Což ostatně neplatí ani dnes, protože to zařízení „ve vnitřní bezpečné síti za firewallem“ je obvykle ve stejné síti, jako spousta dalších pochybně zabezpečených zařízení, např. uživatelské desktopy s Windows nebo čínské WiFi AP. Navíc pokud je to zařízení napadnutelné skrze nějaké „nepoužívané“ porty, nemám moc důvěru v to, že obsluha těch používaných portů bude bezpečná. Takže pokud to zařízení bude potřeba nějak chránit, bude to spíš nějaký IPsec, který povolí komunikaci pouze se známými protějšky.
Něco jiného jsou DMZ v podnikových sítích, tam firewall jako druhá vrstva ochrany dává smysl, ale tam je nedostatek IPv4 adres menší problém a přesměrování portů tam někdo dokáže nakonfigurovat. Ale i tam je NAT pouze zbytečná komplikace.
Je mnoho veci, ktere pres takovy firewall projde, ale pres NAT (1:n) ne. Napriklad vzajemna UDP komunikace iniciovana pomoci treti strany (tedy voip, ptp hry, ...). Trik je v tom, ze odchozi provoz z A do B zaroven otevre diru ve firewallu pro prichozi provoz z B do A (a naopak).
Kdepak. 'Hole punching' do NATu (resp. NAPTu) 1:N pomoci treti strany funguje jen s nekteryma implementacema a zrovna u te linuxove to moc dobre nefunguje, nebot kazda session (srcaddr, srcport, dstaddr, dstport) se tam mapuje nezavisle.
Oproti tomu vzajemne otevreni UDP pruchodu mezi koncovymi stranami schovanymi za 'jednostrannymi' firewally bez NAPTu (tedy napr. na IPv6) je jednoduche - treti strana nedela nic specialniho, akorat vymeni vzajemne adresy a cisla portu:
Strana 1 otevre port P1 na adrese A1 a udaj A1:P1 preda strane 2 pres treti stranu. Strana 2 udela totez symetricky. Jakmile strana 1 dostane informace A2:P2, tak tam zacne posilat UDP provoz z A1:P1. Jakmile ten provoz prejde pres firewall na strane 1, tak se tam otevre session pro A1,P1,A2,P2, ale provoz narazi na firewallu strany 2, kde bude zahozen. Strana 2 ale nezavisle a symetricky udela totez, cimz tedy dojde k otevreni obou firewallu pro tuto session.
2MK: Naivni ses ty, rozhlidni se kolem, miliony dotazu proc nefunguje torrent, proc to dlouho trva nez to neco zacne stahovat proc to ci ono ... a to sme u jedinyho protokolu. A nefunguje to vyhradne kvuli ... NATu.
Pochopitelne ze v ceste bude firewall, ale tam si kazdy nstavi presne to, co chce aby bylo z internetu dostupne, a nastavi to velice jednoduse, protoze pokud bude mit doka stroj, kterej nazve "pes", tak rekne, ze pes ma provozovat web a ftp ... zatimco "kocka" pouziva trebas prave torrent. A nemusi resit, jestli port 12331 (co to je port???) vede na psa nebo kocku, a jestli je na tom ftp nebo web ... a uz vubec nemusi nikomu vysvetlovat, ze kdyz zada pes.upepy.cz .... ze za to jeste musi pripsat :12331 ... aby videl to co tam je.
Ja ako BFU neviem, co kto ma defaultne zapnute ale mas pravdu, ze ako BFU nemusim nic vediet. :)
Myslis si, ze ten ISP nevie zariadit aby tie data neisli aj niekam inam alebo ich neanalyzoval? Ides cez jeho infrastrukturu a tam si ISP moze robit, co chce.
Tu vetu "kdyz mas net..." som trochu nepochopil.
Nepisal som nikde a ani by som sa neodvazil napisat, ze pridat k IPv4 dalsie cislo a vsetko je vybavene, tak ta poprosim nevkladaj mi to do ust.
Niesom extra borec v IPv6 ale to, co som mal moznost si nastudovat a vidiet, ma nadsenim z IPv6 nenaplnilo.
Jo, jedeš na infrastruktuře ISP. Ale pokud teď chceš něco nasdílet sousedovi po torrentu, nemůžes. Protože:
1) Od ISP máš jednu adresu ty a jednu soused. U sebe máte oba dva routery s NATem. Ty nevíš, jakou IP adresu za NATem má soused a soused neví, jakou máš ty.
2) Abys to překlenul, tak potřebuješ server, který vidíte oba. Tzn. s veřejnou IP adresou, který vám dohodí DNSko. Ten sertver musí být mimo vaši síť, protože ISP používá CGNAT a veše routery se "neznají".
3) Abys mohl využít tenhle server, tak musíš data protlačit ven ze sítě ISP a soused ji pak musí tahat zpět.
4) ISP má omezenou konektivitu ven. Toky, co se dají "vyřídit" v jeho síti, mu zatěžují placený lajny ven, a to hned dvojnásobným trafficem.
Se šestkou souseda vidíš. Tvůj kompl pošle data na router, ten vidí stejný prefix a najde si souseda bez toho, že by tok opustil síť ISP. Předá požadavek routeru souseda a ten z konce IP adresy určí, na který stroj v síti to poslat. K nikomu dalšímu (provozovateli veřejnýho serveru mimo síť ISP) se data nedostanou. A máš to rychlejší, protože lajny ven jsou brzda.
A ne, ISP si nemůže dělat co chce. Musí se pohybovat v mantinelech, daných technicky a legislativně. Když šifruješ a nedáš mu klíč... Každopádně pokud ISP nedůvěřuješ, tak ho můžeš vyměnit.
> Myslis si, ze ten ISP nevie zariadit aby tie data neisli aj niekam inam alebo ich neanalyzoval?
To zařídit umí, ale obecně to vypadá, že NSA sbírá data pasivně na velkých zahraniční/podmořských linkách. Takže by to ISP musel dobrovolně poslat strašnou oklikou.
> Niesom extra borec v IPv6 ale to, co som mal moznost si nastudovat a vidiet, ma nadsenim z IPv6 nenaplnilo.
Zajímavé, a co jsi viděl?
"obecně to vypadá, že NSA sbírá data pasivně na velkých zahraniční/podmořských linkách. Takže by to ISP musel dobrovolně poslat strašnou oklikou"
NSA dela oboji (a Rusove v ramci moznosti taky- zejmena jsou prej experti na loveni+napichovani podmorkych kabelu) Ze Snowdenovo leaks vyplyva ze ISP nejenze nemusi oklikou nic posilat ale casto ani nevi ze ma "zabu na prameni" napr. belgickej telekom byl 1 z nekolika evropskych telco co byl hacknutej aniz by o tom vedeli a nektere staty ktere jsou cistokrevnymi vazaly USA (jako napr. Dansko) maj v zemi primo NSA agenty kteri se "staraji o chod black boxu" posazenych na uzlech infrastruktury a tito lide nepodlehaji jakekoliv kontrole mistnich uradu (podle danskych investigative zurnalistu kteri s Greenwaldem probirali Snowdenem poskytnuta data) K takovymtu cinnostem se s oblibou vyuziva backdooru v Cisco + Juniper routerech viz tady o nedavny Juniper pruser rozebira hacker Moxie Marlinspike na crypto konferenci RSA https://www.youtube.com/watch?v=k76qLOrna1w
BTW Whitfield Diffie tady vypada jak kouzelnej dedecek z Pana prstenu :o)))))))
A zbytek panelu jsou taky vsechno lidi kteri vytvorili crypto ktere dnes vsichni pouzivame.
Jinak kdyz uz je rec o podmorskych kabelech - tady je peknej clanek co popisuje jak to funguje a jaka jsou omezeni pri tahani optiky pod oceanem
http://arstechnica.com/information-technology/2016/05/how-the-internet-works-submarine-cables-data-centres-last-mile/
A tady je video kde to probiraj a shrnou tak nejak to nejpodstatnejsi:
http://www.jupiterbroadcasting.com/100161/10000-cables-under-the-sea-techsnap-269/
> Ja ako BFU ako dokazem mat co 5 minut, to inu IP adresu alebo niekolko IP sucane a jednou komunikovas manzelkou,... AKo to BFU mozemat pod kontrolou a vediet co sa deje? Rovnako sa to da aj zneuzit nie?
Je to podobné jako když máš dneska NAT a ten ti pro každé spojení přiděluje další zdrojové porty. Tak tady máš pro nová spojení nové odchozí adresy.
> IPv6 je stary protokol s kopu nedokonalosti podobne ako IPv4
Souhlasím a rád si poslechnu návrh na něco lepšího!
> a vidiet v nom aj rozne snahy a boj o presadenie roznych predstav a funkcionalyt urcitych firiem(ludi,....)
Můžeš uvést tři příklady?
Widle od Win Vista umí IPv6 OK. Umí si vzít DNS servery/domény z bezestavového DHCPv6, což dneska už umí i domácí krabičky posílat, pokud podporují IPv6.
Pokud s epodívám na informaticní shrnutí požafdavků na IPv6 hosta (RFC6434), tak neukazuje, že by byla aktuálně povinnost podporovat RA RDNSS:
Implementations SHOULD implement the DNS RA option [RFC6106].
DHCP neni a nikdy nebylo urceno na pridelovani koncovym zerizenim. Ostane viz ta prednaska. K tomu je RA a z RA to widle neumej. RA je tu proto, ze je to narozdil od dhcp trivialni na implementaci a umeji to vsechny normalni krabky (vcetne telefonu).
DHCP na ipv6 jako server pak neumi skoro vubec nic. Rozhodne ne soho krabky za par korun, ty prave pouzivaji RA. A je to tak presne proto, ze na tom netreba nic konfigurovat - narozdil od dhcp.
Prosím, prostudujte si ttu historii. Přidělování DNS serverů pomocí RA se legalizovalo v RFC6106 (listopad 2010). Historicky je v IPv6 to nastaveno tak, že se používalo k tomu bezestavové DHCPv6 (RFC3736, duben 2004), které sloužilo přávě pro přidělení adres DNS serverů (pomiňme krátkou epizodu pokusů s well known site local DNS server adresami fec0:000:0000:ffff::1 až ::3 z roku 2002, které vidím stále u řady věcí, že se je snaží používat). Neplést s plnotučným stavovým DHCPv6 (nebo DHCPv6-PD), to je něco jiného a není požadováno po klientech, aby ho uměly (protože plnotučné stavové DHCPv6 je dosti rizsáhlé na implementaci do malých krabiček). Ale bezestavové DHCPv6 je jen jednoduchá informational request-reply. Ano, distribuce přes RA je ještě jednodušší, ale RFC z roku 2010 je ještě dost horká novinka. :-)
A pokud se podívám ve svém okolí po nejruznějších zařízeních, tak většina z nich nepodporuje RA RDNSS jako koncové zařízení, ale snad všechny umí bezestavové DHCPv6 (a plnotučné DHCPv6 obvykle neumí) jako doplněk k získáné adrese z RA (opět pomíjím, že řada těch zařízení se stále snaží případně použít i ty odpískané well know DNS servery). I v Androidu je podpora pro RA RDNSS od verze 5? Jinak pro windowsy je na to GPL utilitka rdnssd-win32.
Takže stále tvrdím, že Windowsy od dob Vist umí fungovat v IPv6 only síti zcela korektně, pravidelně zkoušeno. Jenom je nutno mít vedle RA i to bezestavové DHCPv6 (Wokna umí samozřejmě i to, že se RA použije pouze pro adresu brány a IPv6 adresu získají z DHCPv6, stejně tka umí kombinaci, že si vezmou IPv6 adresu dle RA a zároveň i dle DHCPv6 přesně v souladu s tím jak jsou nastaveny v RA příznaky Other Configuration/Managed address configuration).
To s tím Androidem je trochu zavádějící. Je pravda, že RDNSS je podporováno od Androidu 5, na druhou stranu to byla první verze, která umí pracovat v IPv6-only síti a DHCPv6 Android neumí dodnes.
U malých krabiček z mé zkušenosti buď umí oboje nebo jen RDNSS (třeba Linksys a Mikrotiky).
A ta utilitka se do tech widli nainstaluje telepaticky a to 100% zatizeni CPU, ktery cas od casu generuje je taky vpohode ... o knihovne kterou to potrebuje ani nemluve.
Jasne, proc delat veci jednoduse, kdyz muzeme mit 10 serveru jen proto, aby fungovalo sitovani ... jeden bude pridelovat adresu, druhej prefix, treti dns, ctvrtej bude rikat, jestli se to smi pouzivat ,,,
Aby sitovani fungovalo, je treba IP, a DNS. A proto je naprosto logicky, ze to prideluje jeden server. Navic implementace je asi tak na 1 radek kodu, ze ... specilene, kdyz uz si ten system stejne ty pakety cte.
Přiznám se, že vím jenom, že to rdnssd-win32 existuje, protože ho nepoužívám, tak nevím, jak ne/funguje. Ve všech sítích mám aktivní to DHCPv6 stateless, které obshluhuje ten stejný router, jako to posílání RA (kde posílá obvykle paralelně i to RDNSS, takže je na klientu, ať si vybere co umí), takže nemám potřebu rdnssd-win32 zkoušet.
Ať je v roli routeru Mikrotik na home přípojce na té low cost obasti přes OpenWRT až po Cisco krabice pro větší/bohatší firmu, co trvá na "klasice".
Je hezké, že to RDNSSS se v RA objevilo, ale realita klientů je taková, že to bude trvat dlouho, než se z toho stane majortiní standard.
tak u Micro$oftu maj ted plny ruce prace s tim jak natlacit zbytku zemekoule W10
http://imgur.com/gallery/Nh902aV takze na naky prkotiny s IPv6 holt nezbejva cas..... :o)))
Na IPv6 není obsah , pořád je to o slepici a vejci ...
V naši síti je cca polovina lidí připojena na IPv6.
Ve špičkách tu máme provoz cca 1,2 Gbit ... tj přípojky s IPv6 (1700 ks) cca 600 Mbit z toho IPv6 cca 150-200 Mbit , do Nixu pouze cca 20 Mbit.
Dle toho soudím, že IPv6 v ČR zatím moc lidí nenasadilo.
Nejvíce dat proudí na Google a Facebook
Které bohužel pokrývá i IPv4 a ISP prostě nemají důvod přecházet a investovat čas (= peníze) pro překopání svých systémů. Můj domácí ISP je jeden z nejlepších kteří se v ČR dají najít, pokud jde o rychlost, cenu, veřejnou IPv4... Ale na můj dotaz na IPv6 jsem zjistil že jsem první kdo se na to ptal, technologicky na to připraveni jsou, ale prostě zatím nemají důvod věnovat čas dodělání podpory IPv6 do ostrého provozu.
Ono by se to hodilo všem, to je jasné. Jenže dokud lidi neví proč by se jim to hodilo (a vysvětluj to běžnému uživateli), nebudou na ISP tlačit. Běný uživatel ti na "pak bys mohl tohle" odpoví prostě "to už můžu přes službu X, takže mě to netíží". Jasně, můžu zavolat otci přes VoIP bez Skype přímo na PC. Jenže na to už má Skype. To samé sdílení souborů, vzdálený přístup k sobě domů (hurá, můžem použít TeamViewer), sdílení souborů (cloudová úložiště)... A ani ti hráči už nehrají napřímo, ale přes server hostovaný tvůrcem hry (a dřív použili hamachi).
jestli von ten zakopanej pes nebude spise v tomhle: "Operátoři ale CGN nasazují, protože umožňuje okamžité řešení problému nedostatku IPv4 adres. "Zároveň je to příležitost k navýšení výnosu, což mají rádi všichni manažeři. Setkávám se s tím, že se uživatelům seberou jejich IPv4 adresy a pokud je potřebují, musí si za ně zaplatit." Nasazení CGN umožňuje uvolnit velké množství adres, které je možné zpeněžit."
Tohle nefunguje a ani sem nezaznamenal, ze by se to delo. On totiz pokud user tu adresu ma, tak se ji dobrovolne nevzda. A kdybys jim ty adresy vzdal, tak mas big problem predevsim v lokalitach, kde konkurence existuje a to sou vsechny, kde se predevsim ti velci vyskytuji.
Jo, slohnou ti IPv4 pokud chces IPv6, to sem videl. Takze dotycnej jim poslal zpet fakovaka, a vyrobil si tunel a mel oboje.
Ceny 4ky pak budou rapidne klesat prave s narustem v6. On totiz ten provider pak zjisti, ze si s tema par 4kama vystaci, a nakonec, ze je vlastne nepotrebuje. Otazka rekneme ... 10 let.
Coz ale nezmena, ze by mozna nebylo od veci udelat kompletni redistribuci IPcek na 4ce. To by samo znamenalo, ze ti co maj obrovsky rozsahy by o ne prisli.
Problém je v tom, že koncovému klientovi je IPv6 úplně šumák. Malému ISP je to víceméně jedno. Většímu už to moc jedno není, protože díky dynamickému NAT (případně CGN) na sebe jeho klienti přímo nevidí. Vůbec to není jedno větším poskytovatelům obsahu (s většími datovými toky), protože CGN je drahý a má své limity - pro ně je levnější využít IPv6 a doufat, že se část provozu z dynamického NAT (CGN) odkloní na přímou konektivitu na jakýkoliv stroj do datového centra (a oni ušetří). Firewall stojí pak v cestě jak IPv4, tak IPv6, ale ten tam bude vždycky.
nebudou na ISP tlačit
Ano, tuhle výmluvu jsem už slyšel od mnoha ISP. "Zákazníci to nechtějí, jste první, kdo se ptá, není žádný tlak apod." Argumenty jak noha. A aby to chtělo ještě méně zákazníků, tak to ještě zpoplatní.
Tj asi taková kravina, jako kdyby mě instalatér opravil vodu trubkou z nějakého toxického materiálu co se za týden rozpadne a potom se bránil tím, že já jako zákazník jsem si neřekl o jiný materiál. Zákazník tomu zpravidla nerozumí (rozumím sítím, vodě nerozumím, u některých to může být naopak), rozumět tomu nemusí, protože si na to volá odborníka a očekává, že ten to udělá state of the art (což je teda i v případě řemeslníků dost náročný požadavek).
Takže chtít po zákaznících, aby oni tlačili na zavedení ipv6 je jen výmluva proto, aby ti ISP nemuseli nic dělat.
Jak tu nekde zaznelo, tim tlacitelem by moh byt i CTU - trebas tak, ze by trval na tom, ze ISP musi (pravidelne a opakovane) infomovat zakaznika o tom, ze NENI pripojen na internet ... ;D. To by myslim bohate stacilo.
Uz vidim ty reklamy ... nabizime vam pripojeni, ale ne k internetu ... a ty davy, co se pohrnou si to koupit ...
"Jak tu nekde zaznelo, tim tlacitelem by moh byt i CTU - trebas tak, ze by trval na tom, ze ISP musi (pravidelne a opakovane) infomovat zakaznika o tom, ze NENI pripojen na internet ... ;D. To by myslim bohate stacilo."
A definici terminu internet by urcila nejaka mimorita fachidiotu, nejlepe z fora root.cz, ze?
"Já myslím, že termíny internet i Internet jsou docela dobře definované."
Myslet si muzete co chcete, zalezi na tom co si pod onim pojmem predstavuje vetsina. Ovocny "caj" si taky lide v restauraci neobjednavaji jako: "Vyluh z ovoce ci bylin" ackoliv to co dostanou listky z cajovniku nikdy nevidelo.
"Myslet si muzete co chcete, zalezi na tom co si pod onim pojmem predstavuje vetsina"
To je dost silné tvrzení. Prvně by jste musel stanovit množinu "většina" a pak zjistit, co si skutečně myslí. No a pokud by jste chtěl vykládat definice podle toho, co si myslí většina, tak to bychom se taky mohli dozvědět, že sítě jsou jenom na ryby a komáry a adresa je ta v občance.
"Ovocny "caj" si taky lide v restauraci neobjednavaji jako: "Vyluh z ovoce ci bylin" ackoliv to co dostanou listky z cajovniku nikdy nevidelo."
To je ale špatně. Váš příklad není o pojmu "internet" ale o tom, jak tomu lidi říkají. Třeba "Net" a "World Wide Web" ale o definici ví kulové
"Váš příklad není o pojmu "internet" ale o tom, jak tomu lidi říkají."
Presne tak. A pokud nejaky provider bude nabizet "Pristup k facebooku a jinam" za 300,-kc (a kdyz to bude fungovat stejne jako spousta dnesnich produktu nabizenych jako "pristup k internetu") tak to lidi to budou kupovat. Co si o tom mysli par geeku z roota bude uplne fuk. Nic se nezmeni, jen to slovicko na letakach.
Definice připojení k Internetu dle ČTU zní takto:
Službou přístupu k síti Internet se rozumí veřejně dostupná služba elektronických komunikací, která umožňuje využívání obsahu, aplikací a služeb sítě internet, a tím propojení prakticky všech koncových bodů připojených k síti internet (a to protokolem IPv4 a IPv6), bez ohledu na použitou technologii sítě.
Označení „neomezená služba" či případný významový ekvivalent se nesmí používat u služeb přístup k síti internet, u kterých se používá omezení datového objemu, nebo u kterých dochází v průběhu čerpání služby k pozastavení poskytování služby, nebo se vyžaduje dodatečná platba k obnovení služby, či její kvality.
Čož se mi jeví na ČTU na docela slušnou definici, nicméně ve stádiu jen doporučneí aktuálně...
No pro mne je výsledek ze semináře, že se za poslední 3 roky z hlediska objemu provozu na ipv6 nezměnilo. A momentálně uživatele do ipv6 nic netlačí a je mu to prakticky jedno.
A když k tomu přidáme "Podle statistik AMS-IX je po šestce realizováno přibližně 1,5 % datových toků" a "IPv6 u nás přidává v průměru 30ms zpoždění", tak je provoz na ipv6 opravdu minimální a není kam spěchat.
"Většina důležitých věcí podle Surého bez problémů funguje" - zřejmě přistupoval na hlavně vlastní infra, protože bežně na internetu by si s tím rozhodně nevystačil...
PS: mám jeden ipv6 server, ale to jen ze zvědavosti a protože to hosting nabízí ;-)
Uzivatel netusi (v 90% pripadu) co je to IP. Ale zato moc dobre vi, ze mu nefunguje ftp, nefunguje mu VoIP, nefunguje mu torrent, nefunguje mu .... a to vse proto, ze nema internet.
Mockrat sem narazil na to, ze kdyz nekomu ukazuju trebas fotky, tak se pta, kde je mam. A kdyz mu reknu ze doma, tak to nedokaze pochopit. On je doma mit nemuze, protoze se na ne proste nijak nepodiva.
Myslím, že "hodně dobře" je na tom s IPv6 i Ubiquiti nebo Mikrotik, první volba WiFi ISP... A přes to jaksi nejede vlak, pokud mu někdo nevykope tunel :(
A protože tunel je pomalejší a s menším MTU, co asi bude na koncovým zařízení preferovaný? A není páka, která by to změnila.
Když mi někdo zakáže
Kdo ti to zakázal? Ta hovadina je v Linuxu (a některých *BSD) už drahnou dobu implementovaná. To, že to správci zásadně odmítají přidávat jako funkci do různých firewall distribucí typu pfSense, má kurva dobrý důvod - totiž tupost jedinců tvého typu, kteří by to okamžitě začali používat ve stylu IPv4 NATu.
co já potřebuju
K čemu?
s výhodou mohu použít.
A v čem je ta "výhoda"?
Vyhody sou v tom, ze jim to umozni zkurvit konetivitu, protoze tihle bridilove vubec netusej co je to routovani a jak to funguje. Natoz aby tusili, ze na 6tce muze mit kazdej stroj libovolny mnoztvi adres (a prefixu) a ze jim (WOW) dokonce muzes dorucit nekolik rout s ruznou prioritou ... a pripadne ji kdykoli obratem odstranit.
A samo NAT je prece chrani pred vsim zlem ... protoze firewall je pro ne sprosty slovo a nemaj paru jak to funguje.
Mícháte dynamický NAT (který skutečně u IPv6 postrádá smysl) s NAT 1:1, který má praktická uplatnění a ničemu nevadí. Natož aby vadil nějaké konektivitě. Vadit by mohl end-to-end šifrování, pokud to šifrování ověřuje koncové IP adresy. Jenže to jde proti dalším (novým) technologiím, které změnu IP adresy předpokládají (např. když přejdete z LTE sítě do WiFi). Takže to nakonec logicky nevadí ničemu.
NAT1:1 v podání IPv6, asi hlavně překlad prefixů (NPT), tak sice je to hezky vypadjaící cesta na řešení některých situací jako je stav, že mám LAN udělánu na ULA adresách a na bráně podle odchozího směru přeložím jen prefix za jiný podle odchozí linky "bezestavově", ale nedá se na to dívat jako na spolehlivou cestu. Sice to nebrání volnému průchodu oběma směry, ale přímo i specifikace NPT uvádí, že autoři aplikací a protokolů nemají své návrhy komplikovat mechanismy, které umožní fungování přes takové typy překladů a je na uživatlei se smířit s tím, že něco fungovat nebude....
Tak je to takové z bláta do poloouže. Ale neřeší to ani problém, když mám jen jenden prefix /64 a chci z něj udělat víc LAN segmentů.
Např IPsec po IPv6 přes to nefunguje....
situace přechodu z LTW na wif se dá řešit různými způsoby, IPv6 nabízí několik mobilních mechanismů, ale moc běně to implementováno není. To sna duž MOBIKE je častější, jako MobileIP.
Pokud jde o to, že poskytovatel Internetu přidělí jen jednu síť /64 pro uživatele, tak to teoreticky jde nastavit tak, že ISP propaguje v RA prefix /64. Router pak tento prefix naučený z WAN portu přesune na vnitřní rozhraní LAN a propaguje ho pro domácí počítače. S routerem poskytovatele pak komunikuje přes link local. Pouze by musel všechny pakety přicházející z link local z WAN portu posílat na LAN a naopak a mohlo by to fungovat. Asi by se hodila nějaká logika, aby nepřeposílal provoz z lokální sítě, který nemá jít do Internetu.
Žádný NAT, jen prostředky, co nabízí IPV6. Nenašel jsem to nikde jasně popsané, ale v podobném režimu by to mělo nějak jít.
Nejmenší přidělitelný prefix je /64, čehož se řada místních "ISP" drží jak jen můžou a víc dát zdarma nechtějí. Buď proto, že mají jen jeden PI blok /48 (nebo /48 PA od svůho uplinku), takže s příděly /56 na koncáka toho moc neoblouží nebo to vidí jako obchoní případ a za každý další blok /64 chtějí třeba 120 Kč/měsíc, viz O2.
Což je v podstatě i v souladu s doporučneíkm RIPE a RFC, akorát trochu vynechávají tu druhou část, že koncák by měl obvykle dostat výrazně více (než jen /64), aby nebyl nucen do blbostí typu IPv6 NAT....
Dávat blok /56 není snad nikde normován, je to jen dopručení. Také se používá z pohledu alokačních výpočtů využití přidělů ISPíkům.
Takže pokud je Milan na línce nějakého takového vydřiducha/škudlila s /64 per koncák a není moc podobně drahá alternativa v místě, tak se nedivím, že má touhu po věcech typu IPv6 NAT. Nicméně záleží dost na zařízení, co má. Mikrotik neumí třeba NAT pro IPv6 (snad s ROS7 to bude lepší), ale jde na něm nakonfigurovat, abych s jednou /64 měl oddělené sítě třeba pro domácí a návštěvu, kdy na IPv4 má každý jiný blok a pro IPv6 se od sebe odděleni a nevidí se, přestože sdílejí jen tu jednu /64. Ale je to takové drbání, kde s větím přídělem se to řeší naprosto přímočaře.
Jenže to znamená, že si ISP musí požádat u RIPE/LIRa o příděl, což znamená zaplatit vstupní poplateček a pak platit roční poplateček, což naprostá většina ISP odmítne, že to je drahé/složité/...
Tím pádem totální většina ISPíků si vezme jen to, co jim dá jejich uplink, což je obvykle tak jeden-dva bloky /48 a pokud chce víc, tak jej odkáže na RIPE.... Pak pár si případně koupí vlastní PI prefix /48 za jednorázovou platbu u ISP servisu (který vůbec nneí určen k provozu pro ISP, ale vesele se tak často používá)....
Takže těch, co absolvují to do zdárného konce s vlastním AS, vlastním /32 IPv6 přídělem a ještě trochu IPv4, co se z posledního dává, tak těch je totální minorita.
Nevidím důvod, proč by každý ISP musel být členem RIPE a dostat svůj vlastní prefix a navíc dávat opravdu každému /56. Nyní je cca 30 000 prefixů ve světové IPV6 tabulce. V CR je podle nějaké stránky cca 1 000 ISP. To by byly asi 3% světové tabulky, kdyby každý z nich měl svůj vlastní prefix /32. ČR má 10 mil. obyvatel, tj. 1 ISP na 10 000 osob. Se stejným poměrem ISP na počet obyvatel světa to dělá 300 000 prefixů (počet obyvatel 3 mld, aby se to dobře počítalo).
Počet ISP je u nás možná větší než jinde, ale i tak, musely by se pořizovat výkonnější routery, pokud každý ISP měl
svoje adresy. Plus dost kapacity pro stávající tabulku ipv4, to je cca 550 000. Každý zásah, který může zvětšit zbytečně zvětšovat světové BGP, by se měl promyslet.
Pokud menší ISP není členem RIPE, tak by z prefixu /48 mohl mít maximálně 256 zákazníků, pokud by rozdával /56 každému. Pokud by dostal o bajt víc - /40, tak by takových zákazníků mohl mít 65 5636, což by v českých poměrech mohlo stačit, i kdyby měl několik velkých zákazníků s prefixem /48.
Ovšem větší ISP (např. Dial telecom) má obvykle prefix /32, takže by mohl připojit max. 256 menších ISP.
/48 - 2 bajty na sítě, 256 prefixů /56 nebo 65 536 prefixů /64,
/40 - 3 bajty na sítě, 65 536 prefixů /56 nebo 16 777 216 prefixů /64,
/32 - 4 bajty na sítě, 65 536 prefixů /48 nebo 16 777 216 prefixů /56 nebo 4 294 967 296 prefixů /64
Nebo by takový ISP mohl dávat /60. Měl by pak dost adres pro 4 096 klientů, což by mu mohlo stačit, a 16 síti by stačilo naprosté většině zákazníků. IPv6 je primárně dělené na nibbly místo na bajty, jako to bylo u IPv4 (např. u reverzů), takže by s takovým prefixem problém nebyl.
Problém je v tom, že ten koncový ISP nedostane ten prefix /40 od svého data carriera, protože ten ISP vystupuje obvykle v roli ne ISP, ale koncového zákazníka. Takže podle pravidel RIPE má koncový zákazník dostat max /48. V případě hodně velkéhe zákazníka má dostat /47, ale pak si RIPE žádá vysvětlení, proč tomu tak je.
Sice pravidla RIPE očekávají, že datacarrier (v roli LIRa), který je členem RIPE, může přidělovat i prefixy koncovým ISP, kteřív RIPE nejsou, ale pro takový případ nechává pravidla na tom data carrierovi, jak si to udělá. A třeba zrovna zmiňovaný Dial nedá víc, jak /48, respektive dá několik /48, pokud jako ISP mám k němu několik linek, tak na každou dá jednu /48 (ani nenavazující bloky na sebe). Když chci víc, tak mě pošle, ať si to sám vyřídím u RIPE. Možná proto, protože by pak měl dle RIPE pravidel, že by za toho ISP ml provádět registraci jendotlivých bloků přidělených skrz toho ISP na koncové zákanzíky v DB RIPE.
A na tom právě většina těch malých ISP to zabalí, že se s tím nechce nechce otravovat, natož něco platit, že radši koupí další rádio, tka vezmou tu jendu /48 a škudlí s ní....
O fous s eto zlepšilo v poslední době, kdy se zoufale několik ISP do náruče RIPE a získání vlasntího /32 IPv6 bloku vrhlo jen proto, že chctějí pro sebe ještě něco utvat z toho zbytlu IPv4, co k tomu RIPE dává (takže pak nakonec stjeně nasadí jen to IPv4 a IPv6 nechávají ležet do doby, než jejich management to bude umět, viz o pár příspěvků níže).
Protože to měla být odpověď o příspěvek výše.
Jinka souhlasím, také to dělám tka, že home přípojky fasují /60, ale daší lidi dávám tak, aby byla mezera na /56 a zahušťovat segment začnu, až dojde. Malé firmy fasují /56 opět s dírama atd. Podobnou technikou se dá i s jednou /48 vydržet dlouho. :-)
> Problém je v tom, že ten koncový ISP nedostane ten prefix /40 od svého data carriera, protože ten ISP vystupuje obvykle v roli ne ISP, ale koncového zákazníka. Takže podle pravidel RIPE má koncový zákazník dostat max /48.
Nojo, jenze koncovy ISP nemusi vuci LIRovi vystupovat jako zakaznik. RIPE zavedl pravidla pro sub-alokace, takze namisto, aby LIR koncovemu ISP ten prefix /40 assignoval jako koncovemu zakaznikovi (coz by porusovalo pravidla), tak mu ten prefix muze sub-alokovat, viz:
https://www.ripe.net/manage-ips-and-asns/resource-management/faq/sub-allocation
Subalokace ma slouzit prave pro resellery, ci downstream providery, kteri sami nejsou LIRove.
Ano, to sice existuje, ale LIRům se evidentně nechce ALLOCATED-BY-LIR pro subdelegaci u IPv6 používat moc nechce. Asi jde o to, že pořád to mají na krku a odpovídají za stav těch sebdelegovaných bloků vůči RIPE a chce to pak rozumně oetřovat smluvně s těmi koncovými sítěmi. A jejich přístup k řadě věcí je v cleé řadě případů dost katastrofa...
Subdelegace jen řeší, že si to může definvoat koncový ISP, kterému něco subdeleguji. Možná hraje i zkušenost, že většina koncových ISP, stejně kašle na vyplňování ČTU formulářů, natož RIPE DB... :-)
Klidne i mnohem vic ... musis si uvedomit, ze lidi velmi casto neco hledaji, a nez najdes relavantni web, tak jich klido 50 zbezne prolezes, a pak treba zkusis zmenit dotaz a prolezes dalsich 50 ...
Spousta lidi pak pouziva ruzny rss, a proste si cte jen to, co je zajima, ale klidne sledujou stovky zdroju.
Tak jsem vznesl dotaz na ISP a prej jsou take tezce ipv6 ready, ale prej to neni nutne implementovat, dokud neni ipv4 uplne vycerpano. Takze kdyz jsou tak ready, tak nevim, co jako chteji implementovat. Kdyz to teprve musi implementovat, tak ready moc nejsou. Krome toho jim jeste asi nikdo nerekl, ze ipv4 vycerpano je uz dlouho. Do takove miry, ze uz nekde jsou lidi i za kaskadovanymi NATy a jiz dlouha leta clovek muze mit tak leda jednu verejnou ip na celou domaci sit, coz to vycerpani adresniho prostoru vclastne maskuje. Nehlede na neustale cachry s prerozdelovanim velkych bloku adres.
Koukam, ze typicky ISP prstem nehne, dokud to nedostane rozkazem formou zakona a dokud ten zakon nezakaze ipv4.
U řady ISP je hlavní brzdou nasazení IPv6 managemetn systém, který mají nasazen na správu sítě a jejich dodavatelé nevidí v IPv6 prioritu (horko těžko udržují v chodu to, co už tam je). Typické odpovědi od dodavatelů management systémů vypadají normovaně takto (neumí, nikdo to přeci nechce/ticho po pěšině na dotaz): http://wiki.ispadmin.eu/cz/378-cz/faq/obecne/1289-ipv6 http://forum.mikrobill.com/185-ipv6-support/0
Takže ISPíkům se nechce ručně nastavovat síť a dokud to nezvládne management pro tu hromadu Mikrotiků (přestože samotný Mikrotik to s určitým skřipěním zubů a řadě ale umí), tak to masovka nebude. ISPík třeba IPv6 má, klidně i v BGP má segment směrovaný k sobě, má ho daný na mial/web server, pro zajimavost zavedne k pá rlidem a třema nějvětším kňouralům a tím to končí, dokud se nepohne s tím centrálním managementem (stav mám vyzkoušen od několika ISP, kde jsem to IPv6 dostal k serverům, pár zaměstancům a pak stopka na managementu...).
Nu, v tom případě si musíte zvolit ISPíka, který plnohodnotný Internet nabízí. V řadě míst působí třeba 15 "ISP", ale pokud budete chtít nativní veřejnou IPv4 a IPv6 blok přímo od některého z nich, tak u žádného místního neuspějete.
V takovém případě zbývá dneska v Česku globálně leda tak xDSL od T-Mobile, který dává veřejku IPv4 i blok /56 IPv6...
Zkrátka tlak koncových zákazníků na IPv6 je zatím minoritní, takže se nic neděje. Je to úplně stejná písnička, jak řev na téma kvalitní potraviny, každý chce to nej, ale pak většina stejně sáhne po nejlevnějším šuntu v supermarketu bez zájmu, co v tom je, hlavně když to jde nacpat do břicha a nelehnu v křečích. S Internetem je to pro masu pořád stejné (hlavně, že to připojení stojí pár korun a nakonec ten stav na Facebooku změním)..
U řadě z nich neuspějete ani s požadavkem na veřejnou IPv4, protože sami nemají (zrovna jsem se odojil od jednoho routeru takového "ISP" na Moravě - jeho majetek je 32 veřejných IPv4 adres na několik tisícovek zákazníků, jeho dodavel konektivity IPv6 zatím vůbec nenabízí). U těch štastnějších uspějete aspoň s veřejnou IPv4 adresou, často doručenou formou NAT1:1 za příplatek 100~250 Kč/měsíc k tarifu.
Pokud jste v lokalitě, kde je víc ISP, kteří dávají bez mrknutí a v ceně tarifů IPv4 i IPv6, tak si toho važte, moc jich v Česku není a jestli EU dotáhne blud "online registr uživatelů" do reálu, tak řadu lidi čeká IPv6 only konektivita.
Zakazovat zákonem netřeba. Jenom do pravidel, co smí být nabízeno jako připojení k internetu, dopsat přístup do sítí IPv4 i IPv6 a veřejnou IP adresu v minimálně jednom z těchto protokolů. A pokud to do půl roku od nabytí platnosti ISP nestihne, tak povinnost informovat zákazníky, že se z jeho strany nejedná o připojení k internetu a nabídnutí převodu smlouvy k někomu, kdo to má vyřešeno. To by teprve byl hukot... :D
A možná by stálo za to, kdyby někdo zkusil NAT-only poskytovatele s omezením na IPv4 a slovem "internet" ve smlouvě zažalovat za podvod... Třeba by se lekli i ostatní, kdyby to odvysílala TV Noha.
Takový dokument už ČTU před časem vydalo, ale v aktuální podobě je nezávazný. Nicméně pokud se z něj stane opatření obecné povahy, tak ISPíci v reálu udělají jen to, že už nebudou nabízet "službu přístupu k síti internet", protože ta třeba znamená, že klient má veřejnou IPv4 i globální blok IPv6 adres současně, ale nazvou to nějak jinak "Facebook connect pro masy". :-)
Ano, aspoň se vyjasní, který ISP nabízí parodii a který to myslí vážně. Protože momentálně to není dost dobře vidět. Zvlášť u mobilních operátorů a nekterých Wifi poskytovatelů. Být za devaterým NATem a ještě přes proxinu, která zpomaluje "nežádoucí" služby, nabízejí to taky jako internet.
Ta proprietární řešení jsou ve skutečnosti většinou postavená na RFC a IEEE standardech sítě s velmi nízkou spotřebou a propustností (desítky až stovky kilobitů za sekundu pro celou síť). Nejpoužívanější je 6LoWPAN, což je komprimované IPv6 dle RFC 4944 a dalších běžící nad WPAN protokolem specifikovaným IEEE 802.15.4, který používají technologie jako ZigBee, MiWi či LoRaWAN.
Aha, tak to je potom situace lepší, než jsem si myslel. Moje původni představa byla, že IoT má být přes IP, jenže když jsem se - naposledy na letošním Amperu - dožadoval IoT na bázi IPv6 a nadával na mobilní operátory, kteří IPv6 v mobilních sítích nemají, koukali na mě ostatní, jako kdybych měl rohy. A třeba na Amperu vysvětlovali, že Sigfox je děsně super a že IP na nic nepotřebuji.
Sigfox je extra low-power přenosový protokol. Lze nad ním provozovat 6LoWPAN, akorát nevím, jestli to bude mít nějaký význam (obzvlášť při MTU 12 bajtů), stejně to není meshovací síť a je vázaná na jednoho konkrétního poskytovatele, má tak jeden centrální překládající bod, který může překládat IPv6 před vstupem do sítě (což již Sigfox nabízí).
No, to MTU 12 bajtů je právě ten problém. Mimo jiné. Já se orientuji spíš na aplikace, kde je dostatek šťávy na klasický GSM modul a mobilní internet, akorát bych tam chtěl mít IPv6, abych se s "krabičkou" mohl bavit napřímo a navíc nějakým protokolem jako je třeba Modbus TCP. A v tomto duchu jsem se i vyptával. Načež se mi dostalo odpovědi, že to co hledám není energeticky úsporné a že Sigfox ano. A že data budu mít u nich v cloudu, přístupná přes API, což je prý super...
Fajn ale tahle řešení nejsou dostupná pro koncového zákazníka. To jsou velkoobchodní záležitosti. To znamená, že kdybych to chtěl využít pro sebe musel bych přes nějakou obchodní přeprodanou nabídku a byl zcela závislý na takové poskytovatelské firmě. Tj. je to proprietární řešení jak technicky tak byznysově. Neboli monopolistický model, který se ne nepodobá situaci na mobilním trhu v 90. letech. Čili všechno špatně.
LoRa Alliance licencuje technologie operátorům, podobně jako to funguje třeba u LTE. V ČR síť LoRaWAN budují České radiokomunikace, které momentálně pokrývají všechna krajská města, a things.cz, které plánuje otevření sítě zdarma ve „2Q 2016“.
ZigBee je vyvíjeno a licencováno ZigBee Aliance. Funguje na stejné frekvenci jako Wi-Fi či Bluetooth, žádného poskytovatele nepotřebujete.
Když to shrnu: Jde mi o svobodný a otevřený IoT.
Ne o džungli buzzwordů, jejichž hlavním cílem je zalicencovat co jde a vykolíkovat si prostor pro rejžování na poli, které je technologicky omezené na IPv4 (realizace IPv6 je exkluzivní jen pro tyhle vykolíkovaný oblasti) a díky tomu tohle umožňuje. Je to ještě horší než se dá vůbec napsat slušnými slovy.
LoRa a ZigBee jsou svobodné a otevřené podobně jako Wi-Fi: vyvíjí je konsorcium, uživatelé je mohou používat volně a výrobu čipů si může licencovat kdokoliv; u LoRa je potřeba licence na pásmo, ZigBee sdílí frekvence s Wi-Fi a Bluetooth, tedy v rámci VO. MiWi je tak napůl, použít jej může kdokoliv a má dostupné zdrojáky, ale licence je jen pro provoz na HW od firmy Microchip.
LoRa vyvíjí LoRa Alliance, ZigBee vyvíjí ZigBee Aliance. To je velmi podobné jako u Bluetooth (vyvíjené Bluetooth Special Interest Group), USB (USB Implementers Forum) či Wi-Fi (Wi-Fi Alliance). Všechny tyhle technologie musíte licencovat, pokud chcete prodávat čipy, které je implementují. Implementací je ke každé z nich také několik, od různých firem.
Smart žárovky většinou používají Wi-Fi, Bluetooth nebo ZigBee a našroubované jsou v normální patici E27. U těch, které mám, se dá měnit barva a svítivost a nastavení, jaká Bluetooth zařízení v okolí mají sledovat (aby se zapínaly a vypínaly samy). Na žádném portu ale nenaslouchají, připojují se k serveru přes TCP, takže firewall ani nepotřebují.
Hm ... a to jako vadí? Google jako obrovské firmě pár posktytovatelů, kteří IPv6 neumí, přece nemůže vadit. A navíc by si nemuseli stěžovat, že po IPv6 jim jede jenom 12 %, protože po vypnutí IPv4 by měli hned 100 %.
Jako stěžovat si, že po IPv6 jeden jenom 12 %, umí každej, ale do zrušení toho, co nechtějí, se jim moc nechce.
Neboj, oni to vypnou, jak sem uz parkrat psal, pocitam ze az google preleze 30%, vyda prohlaseni, ze zacne IPv4 odstavovat ... a pak se z toho vsichni ti "taky ISP" poserou. Sem zvedav, jak pak budou oveckam vysvetlovat, ze ten zlej guugl je odstrelil proto, ze nebyly schopny nasadit 30 let starej protokol.
Google se presne stejne snazi protlacit trebas vp9 a spoustu jinych veci. A protoze adminovat dualstack = naklady navic + je to PR pro firmu, ktera se snazi prezentovat jako technologicka ... tak bych se tomu vubec nedivil. To neznamena ze to hned vypnou, ale ze proste nahodej udici "do 1/2 roku zacneme vypinat Ipv4, protoze 6tka je dostatecne rozsirena a nic nebrani jejimu nasazeni vsude".
Tak dobre udelam ze sebe debila a prosim j. a L.P., abe nereagovali moc vulgarne, protoze v mych ocich to dost shazuje vahu jejich argumentu.
Takze jsem blbecek, co jakztakz pocohpil IPv4. Tusim, jak funguje maska, brana, dhcp. Adresy na zarizenich doma jsem si bud vymyslel pevne nebo mi je pridelil dhcp server na mem routru, pouzil jsem rozsah, se kterym jsem se zatim na zadne zakazce nesetkal. Venkovni (z meho pohledu) adresu mi pridelil muj ISP. Tusim (resp. doufam), ze muj domaci router/firewall/wifiAP/dhcp za 400 Kc zvenci dovnitr nic nepusti, pokud nejde o odpoved na zadost zevnitr. Kdyz preci jenom chci zvenci na svuj domaci server, tak vim, ze na serveru musim tenhle port povolit a na domacim routrofirewallu tenhle port prostrcit zvenci na server. Pevnou verejnou adresu mi pridelil muj ISP, stacilo se zeptat, ale v tomto mam holt stesti. Kdyz chci doma z pocitace na pocitac, tak vim, kdo ma jakou ip adresu a pokud je ve firewallu na cilovem PC povoleno vse potrebne, tak neni problem.
A ted jako zkusim jit do sveta IPv6. Nejak nechapu, jestli budu jeste potrebovat svuj domaci routr/firewall/dhcp za 400, kdyz mi ISP prideli tolik adres, ze je ani nespocitam. Intuitivne tusim, ze nejaky firewall by to na vstupu do bytu chtelo, protoze si nedokazu predstavit, ze manzelka nebo deti budou mit jejich pocitac chraneny pouze windowsackym firewallem, ktery milerad dovoli vse, pokud na nej uzivatel aspon trochu mile zamrka. Pak tady zaznelo, ze misto jednoho stareho DHCP jsou dve DHCP (dynamicke/staticke?) a k tomu jeste nejake RA. Fakt to potrebuju? Co z toho potrebuju? Adresy doma mi prideli muj router/dhcpserver nebo mi je prideli ISP? Nebo se muj router/dhcpserver zepta ISP, z jakeho rozsahu mi ma tak asi pridelit adresy? A az zmenim ISP, tak se muj router zepta noveho ISP a zacne mym zarizenim doma pridelovat nove adresy? (Ale proc ne, ISP nemenim kazdy den.) Pak tu zaznelo, ze v ramci jakehosi ztizeni sledovani uzivatelu, se muze adresa odesilatele s kazdym otevrenym TCP spojenim menit. To si ty adresy losuje operacni system odesilatele, nebo to dela router transparentne? Z hlediska strojove narocnosti a debugovatelnosti mi to dost pripomina NAT? Kolik adres tedy jedno zarizeni ma? A kdyz chci v ramci domacnosti z pocitace na pocitac, tak doufam, ze to nebude vyrazne slozitejsi, nez kdyz jsem dosud ve firewallu povoloval neco jako 192.168.123.0/24 (pokud tedy nepocitam, ze logicky vsechny adresy budu muset psat delsi).
A jeste pokud mam doma nejaky server, tak jeho verejnou adresu si vymysli kdo? Ja nebo ISP? Predpokladam, ze ISP, protoze ISP zarizuje, ze pakety ze sveta dorazi az ke me do bytu. Pokud predpokladam spravne a pokud zmenim ISP, tak dale prepokladam, ze novy ISP mi da novou verejnou adresu pro muj server. Nejak si totiz nedokazu predstavit, ze by dokazal do sveta oznamit "pakety s adresou tamhletoho ISP ted posilejte me, protoze tuhle adresu ma ted muj zakaznik". A v tom pripade nevidim pokrok proti IPv4 (samozrejme krome toho, ze nekdo uz IPv4 adresy proste nema, nebo za ne chce hodne penez). (?)
> Nejak nechapu, jestli budu jeste potrebovat svuj domaci routr/firewall/dhcp za 400, kdyz mi ISP prideli tolik adres, ze je ani nespocitam.
Teoreticky by mohl RA provozovat rovnou ISP, ale myslím, že se to takhle většinou nedělá.
> Pak tady zaznelo, ze misto jednoho stareho DHCP jsou dve DHCP (dynamicke/staticke?) a k tomu jeste nejake RA. Fakt to potrebuju? Co z toho potrebuju?
Nepotřebuješ, stačí ti RA.
> Adresy doma mi prideli muj router/dhcpserver nebo mi je prideli ISP?
ISP ti přidělí prefix (prvních 64 bitů), druhých 64 bitů si tvá zařízení vymyslí sama (na základě MAC adresy, případně dočasné náhodně, aby nešlo podle MAC adresy vzdáleně sledovat).
> A az zmenim ISP, tak se muj router zepta noveho ISP a zacne mym zarizenim doma pridelovat nove adresy?
Ano.
> To si ty adresy losuje operacni system odesilatele, nebo to dela router transparentne?
OS. Router adresy nepřiděluje (pokud se používá RA), router řekne "mám tady tento prefix" a zařízení si vyrobí ten zbytek samo. (v případě DHCP přiděluje router)
> Kolik adres tedy jedno zarizeni ma?
Bez Privacy Extensions jednu (ve skutečnosti víc, protože ještě link-local a implicitní broadcasty, ale globálně routovatelnou jenom jednu), s Privacy Extensions dvě a víc (mění se například každých 10 minut, ale starou adresu není možno zahodit, pokud na ni je otevřené spojení - takže pokud máš třeba dlouho žijící SSHčka jako já, tak budeš mít adres třeba pět).
> A kdyz chci v ramci domacnosti z pocitace na pocitac, tak doufam, ze to nebude vyrazne slozitejsi, nez kdyz jsem dosud ve firewallu povoloval neco jako 192.168.123.0/24
Povolil bych link-local adresy, případně celý subnet. Stejně asi doma nemáš něco co by znemožnilo komukoli ukrást jakoukoli adresu.
> (pokud tedy nepocitam, ze logicky vsechny adresy budu muset psat delsi)
Použil bych DNS (tím nemyslím jako že bys musel mít autoritativní DNS server, ale multicast DNS).
> A jeste pokud mam doma nejaky server, tak jeho verejnou adresu si vymysli kdo?
Může si ji odvodit na základě MAC adresy, ale možná by bylo rozumnější serveru nastavit adresu staticky ručně v konfiguráku.
> Pokud predpokladam spravne a pokud zmenim ISP, tak dale prepokladam, ze novy ISP mi da novou verejnou adresu pro muj server. Nejak si totiz nedokazu predstavit, ze by dokazal do sveta oznamit "pakety s adresou tamhletoho ISP ted posilejte me, protoze tuhle adresu ma ted muj zakaznik".
Ano, tak to je. Existují nějaké Provider Independent mechanismy, jestli to chápu správně, tak by to v podstatě znamenalo mít vlastní globálně announcovaný subnet.
(mimochodem pro krátkodobé přechody třeba s notebookem existuje Mobility, které pošle protistraně redirect, že teď je ta adresa jinde)
> A v tom pripade nevidim pokrok proti IPv4 (samozrejme krome toho, ze nekdo uz IPv4 adresy proste nema, nebo za ne chce hodne penez).
Jo, není, ale to asi není jak jinak řešit. Prostě se ta změna zapíše do DNS.
Tusim (resp. doufam), ze muj domaci router/firewall/wifiAP/dhcp za 400 Kc zvenci dovnitr nic nepusti, pokud nejde o odpoved na zadost zevnitr.
Pokud to je opravdu firewall… Většina těch levnějších krabiček žádný firewall nemá, jen NAT.
Nejak nechapu, jestli budu jeste potrebovat svuj domaci routr/firewall/dhcp za 400, kdyz mi ISP prideli tolik adres, ze je ani nespocitam.
Nějaký router budete potřebovat, typicky tohle ale řeší modem poskytovatele připojení.
Intuitivne tusim, ze nejaky firewall by to na vstupu do bytu chtelo, protoze si nedokazu predstavit, ze manzelka nebo deti budou mit jejich pocitac chraneny pouze windowsackym firewallem, ktery milerad dovoli vse, pokud na nej uzivatel aspon trochu mile zamrka.
Možná. Ten windowsí firewall lze nastavit tak, že se takhle chovat nebude. Ale vícevrstvá bezpečnost je samozřejmě lepší než jednovrstvá.
Pak tady zaznelo, ze misto jednoho stareho DHCP jsou dve DHCP (dynamicke/staticke?) a k tomu jeste nejake RA. Fakt to potrebuju? Co z toho potrebuju?
Podle RFC by mělo stačit jen RA, Windows ale neumí RDNSS (čtení DNS konfigurace z RA) a potřebují ještě bezstavové DHCP. Oboje je ale oproti stavovému DHCP (ať již na IPv4 nebo IPv6) velmi primitivní, všem počítačům v síti to posílá ty samé pakety.
Adresy doma mi prideli muj router/dhcpserver nebo mi je prideli ISP? Nebo se muj router/dhcpserver zepta ISP, z jakeho rozsahu mi ma tak asi pridelit adresy? A az zmenim ISP, tak se muj router zepta noveho ISP a zacne mym zarizenim doma pridelovat nove adresy?
Typicky se router (modem) zeptá ISP přes DHCP Prefix Delegation a podle toho nastaví RA a DHCP.
U bezstavové autokonfigurace (SLAAC) si adresy zařízení přidělují samy z rozsahu ohlašovaného v RA. To je velká změna oproti IPv4, kde adresy vždy přiděluje jedna autorita.
Pak tu zaznelo, ze v ramci jakehosi ztizeni sledovani uzivatelu, se muze adresa odesilatele s kazdym otevrenym TCP spojenim menit. To si ty adresy losuje operacni system odesilatele, nebo to dela router transparentne? Z hlediska strojove narocnosti a debugovatelnosti mi to dost pripomina NAT?
Privacy Extensions fungují jen s bezstavovou autokonfigurací (SLAAC), kdy si všechny adresy vymýšlí operační systém odesílatele. Také se nemění s každým TCP spojením, ale jednou za určitou dobu (hodinu? dvě? záleží na nastavení) či při změně sítě.
Tyhle adresy (zvané dočasné) slouží pro odchozí spojení. Pro příchozí spojení se používají jiné IP adresy (zvané stálé).
Kolik adres tedy jedno zarizeni ma?
Kolik chce :-) Nejméně jednu link-local, a pokud má připojení k intenetu, tak ještě jednu globální (z rozsahu ohlašovaného RA). Při použití Privacy Extensions má globálních několik, jednu stálou (pro příchozí spojení), jednu dočasnou (pro odchozí spojení) a až několik dříve používaných dočasných (aby probíhající odchozí spojení fungovala i po změně adresy).
A kdyz chci v ramci domacnosti z pocitace na pocitac, tak doufam, ze to nebude vyrazne slozitejsi, nez kdyz jsem dosud ve firewallu povoloval neco jako 192.168.123.0/24 (pokud tedy nepocitam, ze logicky vsechny adresy budu muset psat delsi).
Pro příchozí spojení se typicky používají stálé adresy. Standardní jsou buď statické (třeba 2001:db8:1234:5678::1 či různé mnemonické jako 2001:db8:1234:5678::1337) nebo EUI 64 odvozené z MAC adresy (2001:db8:1234:5678::EUI64). V jedné síti lze kombinovat oba způsoby a běžně se to dělá (např. router mívá statickou adresu ::1 a tiskárna EUI 64). V rámci jedné sítě ještě existují link-local adresy (fe80::EUI64), které se používají třeba pro vyhledávání okolních zařízení.
A jeste pokud mam doma nejaky server, tak jeho verejnou adresu si vymysli kdo? Ja nebo ISP? Predpokladam, ze ISP, protoze ISP zarizuje, ze pakety ze sveta dorazi az ke me do bytu.
ISP vám přidělí celou síť, přinejmenším /64, a všechny adresy z té sítě směruje k vám (bez ohledu na to, jestli tu adresu někdo používá nebo ne). Jak si zorganizujete adresy v rámci té sítě, je tak jen na vás. Běžná použití viz předchozí odpověď.
Pokud predpokladam spravne a pokud zmenim ISP, tak dale prepokladam, ze novy ISP mi da novou verejnou adresu pro muj server.
Typicky ano.
Nejak si totiz nedokazu predstavit, ze by dokazal do sveta oznamit "pakety s adresou tamhletoho ISP ted posilejte me, protoze tuhle adresu ma ted muj zakaznik".
Můžete zažádat o Provider-Independent adresy a pak to takhle funguje. Přesněji je to obráceně, vy jako majitel rozsahu IP adres prohlásíte „pakety pro tuto síť posílejte přes tohoto ISP“ a ISP nahlásíte, že tenhle rozsah má směrovat k vám. Není ale moc ISP, co by to podporovali, tohle je spíš pro firmy, které mají více připojení (multi-homed) a potřebují pevné IP adresy pro příchozí spojení, které lze přesouvat při výpadku.
Panove, dekuji obema za odpovedi.
Moc jednodussi nez IPv4 mi to neprijde (preci jenom uz jsem se naucil s NATem zit), ale aspon uz trochu tusim, co me ceka.
Jeste budu muset nejak vstrebat to "RA" a "link-local", ale to snad z nejakych prednasek p. Satrapy pochopim, az to tedy bude potreba.
RA neboli Router Advertisment je paket, který router čas od času (či po vyžádání paketem Router Solicitation) pošle do sítě a říká: „já jsem router, tohle je síť 2001:db8:1234:5678::/64, DNS servery jsou 2001:db8::1 a 2001::db8::2 a adresy si každý přiděluje sám“ (či jak je to nastaveno).
Link-local adresy jsou adresy, které si každé zařízení přidělí po připojení do sítě bez nutnosti čekat na RA. Jednak slouží jako adresa pro případy, dokud to zařízení nezná adresu sítě (v IPv4 se pro to zneužívalo 255.255.255.255), a poté se využívá běžně pro vyhledávání v lokální síti. Lze použít i pro komunikaci, třeba pokud na LAN party spojíte několik počítačů v síti bez připojení k internetu, tak se samy nastaví.
Prave ze to jednodussi je ... pokud mas ipv4:
1) dostanes adresu od ISP (a to jeste pocitam s tou lepsi variantou, ze ji dostanes)
2) musis ji nejak nastavit na routeru (prevazne rucne), pripadne si ji muze vzit z dhcp
3) musis na routeru zprovoznit dhcp do vnitrni site
4) musis na tom routeru rict, jaky porty maji kam mirit
5) se spoustou protokolu ses v riti (trebas ftp) protoze to pres NAT nepreleze (v nekterych pripadech to lze resit, ale ne na krabickach za par stokorun)
U IPv6:
1) provider pres dhcp prideli tvy krabce tvuj prefix
2) tvoje krabka si ho sama natlaci do RA a ... sit ti funguje
3) maximalne povolis u konkretnich stroju konkretni sluzby ktere maji byt dostupne zvenku
4) funguje ti uplne vse, protoze neni v ceste zadny NAT.a primo se muzes pripojit na libovolny svoje zarizeni
Odpada ti kompletne nastavovani NATu a forwardu, nastavujes pouze firewall (to u v4 musis taky, ale je to mnohem slozitejsi, protoze musis brat v potaz prave ten NAT).
1. Zapomenul jsi, že od zákazníka musí získat DUID. Nebo nějak odposlechnout, či napůl hádat z toho, co se objeví na DHCP serveru. (zjistit MAC na portu switche mi přijde trošku jednodušší).
A zákazník, když už to tedy zjistí ... musí myslet na to, že se mu to změní po výměně krabičky nebo dokonce po upgrade.
Občas se také najdou systémy, co vyžadují nějaký formát DUID a jiný neakceptují. Např. mikrotik (i když to už snad myslím opravili).
Proč by se zdržoval pomocí DUID?
V přístupové síti ISP se můžu řídit informací o tom, z které linky přichází DHCPv6-PD požadavek a dle toho přidělit prefix bez ohledu na to, jaký DUID tam je nebo jak se mění. To stejné v podstatě platí i pro IPv4, vůbec se nemusím zajímat o MAC adresu zákazníkova routeru, ale o informaci identifikující konkrétní přípojku (kterou do DHCP požadavku přidá koncový koncentrátor, ať už je to xDSL, kabelový krám nebo Ethernet switch).
Jinak s DUIDy se sranda na xDSL síti T-mobile. Pokud na jejcih síť připojím dvě zařízení, které předloží stejný DUID (napříkald Mikrotik routery, kde se použilo klonování konfigurace přes backup/restore, které přenese DUID a zapojím ty routery za xDSL modem v bridge režimu), tak IPv6 příděl dostane jen to, které se přihlásilo první. Až to první vypnu, dostane daný prefix to zařízení druhé a tak se o to tahají, dokud se nezařídí rozdílné DUIDy i když jsou každý router na zcela jiné straně Česka.
Proč? Třeba aby měl jistotu ve stále stejném prefixu? Proč? Např. kvůli serverům či DNSkám.
Ne každý switch může umět vkládat optiony ... a už vůbec ne každý pro IPv6. Pokud takový požadavek je, tak cena implementace stoupá skoro exponenciálně.
To, na co skoro každý nadává a každý druhý to vyvrací je, že to funguje všechno krásně ... ale jen na laboratorní síti. A ne ve všelijakých heterogeních a historických částech. Měnit X let starý access switch jen kvůli IPv6? Proč proboha ...
Tohle se na switchích, které neumí options řeší velice snadno, Řada přístupových sítí to dělá tak, že co zákazník, to VLANa. VLANy umí cokoliv, co překročilo inteligenci šumící trávy. Pak mám co zákazník, to VLANa, nad VLANou běží DHCPv6-PD server, co přiděluje zákaznikovi prefix IPv6 i IPv4 pořád stejně, ať si mění MAC, DUID jak chce... Tímto jednoduchým způsobem se obchází řada jiných chytrostí, co by měl ideálně umět přístupový switch a přenáší se tak na centrální routery. Kde je toho hodně, tak se pak používá QinQ, kde vnější VLANa určuje objekt v kterém je switch a vnitřní VLANa pak připojku v daném objektu.
Druhá metoda je, že se používá PPPoE, kdy pak je prefix a IPčka svázany s PPPoE autorizací a na koncích jsou switch, co umí max izolaci portů mezi klienty a když je dobře, tak mají i filtr, co propustí od zákazníka jen PPPoE.
Ano, používá se kde co, podle techniky a co daný ISP umí ubastlit. Ale ta VLAN technika je nejlevnější, co obvykle zvládnou, pokud to chtějí mít podchyceno řízeně a nechtějí se starat o MAC adresy, DUID atd.
Jsou i sítě, kde je celá síť jeden L2 segment pokrývající kraj, která je postavena stirktně stromově (neexistuje žádná redundace v trasách nebo smyčky, protože je to složité a technici to nechápou) a na všech portech je použita nějaká forma izolace od sousedních portů, vyjma jednoho uplink portu, kdy koncový port u zákazníka tak může komunikovat jen s jedním centrálním routerem (mít jich víc pro rozklad/zálohu je moc komplikované) a vůbec neexistuje cesta, jak by dva zákazníci mezi sebou mohli komunikovat přímo, musí vždy přes externí subjekt - a nějakou tu tisícovku zákazníků a 10 Gbps uplink také mají (IPv6 ne, to je moc složitý). :-)
S dovolením využiji a přidám další dotaz, protože ohledně IPv6 také nemám tak podrobné informace a na netu se mi nepodařilo dohledat rozumně jednoduše. Netuším, jak nově na IPv6 správně přidělovat adresy, aby se nepohádaly pevné a dynamické adresy:
Aktuální stav: Je pár desktopů, kde děti často hrají i hry. Dané počítače mají pevné lokální IP (+ mapované porty na routeru, někdy UPnP když není třeba pevný port) a DHCP server má omezeny volné adresy tak, aby se s pevnými nehádaly - máme i kvanta dalších zařízení, které využívají onu dynamickou IPv4.
Problém. Desktopy (s pevnými IP) se vypínají, běží jen někdy.
xxxxx
Co potřebuji: Aby děti mohly zároveň hrát hry i vzájemně (dost často), ale také aby bylo možno aby si k sobě přizvaly i někoho z venku, aniž by pokaždé musely zjišťovat svou aktuální adresu. Pochopil jsem, že si na IPv6 mohu určit i pevné lokální adresy. Ale. To mi řeší jen část. Tam snad (za aktuálního stavu) zatím nepotřebuji, aby pro lokální bylo třeba mít dynamicky přidělované. Ale když chtějí přizvat někoho zvenku?
Dotazy:
1) Jak mít privacy extensions (resp. volné nepevné, ...) a zároveň možnost mít možnost i pevné globální adresy pro určité stroje. Jak tomu novému "DHCP - SLAAC?" zamezit, aby náhodou nevybral obsazenou cizí pevnou adresu, když zrovna cizí desktopy neběží (jen výjimečně běží všechny najednou). Jak se zjistí ta jejich "rezervovaná" IP. Je to sice okrajová možnost střetu, ale pokud se ta privacy adresa bude měnit často, tak ta kolize možná tak výjimečné nebude.
2) A pro jistotu. Jde vůbec na win zároveň možnost používat jak pevnou IP (z MAC třeba, ale ideálně i vlastní zapamatovatelné), tak i ochranu soukromí pomocí privacy extensions? A pokud ano, dá se vůbec konkrétnímu programu z vnějšku nařídit, aby pro daný program i pro outgoing provoz používala pevnou IPv6 a ne privacy? Nebo musí bind podporovat každý program zvlášť po svém - tedy skoro bez šance, typicky pro hry? Protože třeba na firewallech bývají problémy, pokud je jiná odchozí a příchozí ... nebo to na IPv6 už je běžné a počítá se s tím jako nutnost a zbytečně se obávám?
Zatím jsem, pro danou situaci, dohledal pouze pouze tu nejhorší možnost. Že úplně všechna zařízení musí mít jedinou pevnou globální adresu (z MAC), bez možnosti dynamických a ochrany soukromí. Jinak se to pohádá.
Ještě jsem zapomněl dodat. Máme v domácí síti i á la server(y) co potřebují pevnou IP vždy. Např. read-only FTP fotky, a co hůře, někdy dedikovaný server pro Minecraft a podobně. Takže není možnost mít úplně všude pouze dynamické IP (privacy extensions, ...) /i za cenu že by děti pokaždé zjišťovaly aktuální IP/. Navíc některé takové stroje (typicky Minecraft server a pak nějaké ty střílečky /ani nevím co/ či openttd) také neběží stále :-( Ale nelze protistraně vždy znovu říkat nové IP.
Netuším, jak nově na IPv6 správně přidělovat adresy, aby se nepohádaly pevné a dynamické adresy
Z praktického hlediska to není potřeba řešit, pravděpodobnost kolize je menší než 1:10 000 000 000 000 000 000. Máte tisíckrát větší šanci vyhrát jackpot Euromilionů dvakrát po sobě.
RFC rozlišuje adresy pomocí bitu 71 (7. bit za adresou sítě). Pokud má adresa zapnutý bit ::200:0:0:0, pak je z EUI-64/MAC adresy (tzv. univerzální), jinak je tzv. lokální (statická, Privacy Extensions, …).
Navíc u všech dynamických adres zařízení zkouší, jestli i přes tu astronomicky malou pravděpodobnost náhodou nevymyslelo stejnou, jakou už někdo má. Pokud už je použita, pak si jednoduše vymyslí jinou.
Aby děti mohly zároveň hrát hry i vzájemně (dost často), ale také aby bylo možno aby si k sobě přizvaly i někoho z venku, aniž by pokaždé musely zjišťovat svou aktuální adresu.
K tomu je nejlépe použít mDNS. Počítače v lokální síti pak lze odkazovat pomocí jméno.local (třeba ping jméno.local
nebo http://jméno.local/). Počítačové hry podporující IPv6 by měly pomocí mDNS najít rovnou počítače, kde ta hra zrovna běží.
Jak mít privacy extensions (resp. volné nepevné, ...) a zároveň možnost mít možnost i pevné globální adresy pro určité stroje.
Nastavíte pevné adresy těm strojům? S IPv6 může mít počítač adres, kolik chce, a i s Privacy Extensions má běžně jednu stálou a neměnnou adresu (EUI 64, odvozené z MAC), kterou nepoužívá pro odchozí provoz, ale poslouchá na ní. Navíc není problém to v síti kombinovat, dokonce se to běžně dělá.
Jak tomu novému "DHCP - SLAAC?" zamezit, aby náhodou nevybral obsazenou cizí pevnou adresu, když zrovna cizí desktopy neběží (jen výjimečně běží všechny najednou).
Pokud dvěma strojům ručně nenastavíte stejnou adresu, tak vzhledem k pravděpodobnosti kolizí i tomu, že zařízení dynamické adresy testují na kolize, bych to vůbec neřešil.
Jde vůbec na win zároveň možnost používat jak pevnou IP (z MAC třeba, ale ideálně i vlastní zapamatovatelné), tak i ochranu soukromí pomocí privacy extensions?
Ano, a je to IMO výchozí nastavení. Místo pamatování si adres doporučuji mDNS.
A pokud ano, dá se vůbec konkrétnímu programu z vnějšku nařídit, aby pro daný program i pro outgoing provoz používala pevnou IPv6 a ne privacy? Protože třeba na firewallech bývají problémy, pokud je jiná odchozí a příchozí ... nebo to na IPv6 už je běžné a počítá se s tím jako nutnost a zbytečně se obávám?
Jestli se použije dočasná nebo stálá adresa, záleží na tom, kdo to spojení zahájí. Pak už se ale po celé spojení používá stejná adresa pro pakety oběma směry.
Tisíceré díky za odpověď a nasměrování. Díky moc, hodně pomohlo.
P.S:: Tu malou pravděpodobnost kolize jsem si uvědomoval, ale nevím, jak moc často se mění ta z Privacy Extensions. Ale je fakt, že pro více strojů už se pravděpodobnost jen sčítá (tady jsem dělával systematickou chybu). Že i pokud se změní třeba 500x za den (co 2-3 minuty), tak pro více stojů je to "jen" n*500, ne 500^n. Takže asi riziko opravdu minimální.
Pravděpodobnost kolize je velmi malá, ale i tu řeší protokol: jakmile si počítač přidělí nějakou adresu, zahájí detekci duplicitních adres – prostě se zeptá na síti, kdo má takovou adresu pomocí standardního objevování sousedů (ND, obdoba ARP z IPv4). Pokud se mu nikdo neozve, pak si adresu nechá a používá ji.
Re: ... ale i tu řeší protokol ...
To jsem pochopil. Uvažoval jsem případ, když si pro některá zařízení nastavím i IPv6 pevnou adresu, ale daný stroj bude vypnutý /vypínaný/. Tak co se stane, až se zapne, pokud už danou adresu zabral někdo jiný (např. pro privacy extensions). Protože vypnutý stroj ho nemohl informovat, že adresa je zabrána.
Nicméně spokojím se velmi malou pravděpodobností kolize. Pokud si navíc uvědomím, že náhodná cizí (privacy) IP by se musela shodovat právě v okamžiku spuštění stroje s pevnou. Pro domácí použití, kde počet zařízení nepřesáhne dvouciferné číslo, to bude opravdu zanedbatelná pravděpodobnost. Doufejme.
U IPv4 to je jasné, tam mi nemožnost kolize řeší DHCP server s routerem s předvoleným menším rozsahem. A privacy řešil NAPT (dané jeho principem). Něco podobného ale pro IPv6 není (co by mi vyřešilo i soukromí), resp. i jen NAT je u IPv6 považován za problematický. Jestli jsem pochopil. IMHO určitým správným způsobem udělaný NAT by se mohl chovat obdobně jako privacy extensions (emulovat jejich funkci), přičemž vnitřní adresy by mohly být stále pevné, lokální. Řešilo by to i případ změny IP ze strany ISP (málo častý, ale bývá), případně náhradní mobilní připojení při výpadku pevného (jako mám teď). Že alespoň lokální zůstávají vždy stejné. Ale IPv6 na NAT není stavěna, pokud jsem dobře pochopil, a že by s tím byly potíže.
Re: ... záleží na tom, kdo to spojení zahájí. Pak už se ale po celé spojení používá stejná adresa pro pakety oběma směry ...
Ano, tak by to mělo být. Ale na starších win jsem s tím míval potíže. A to i v případě, když např. accept (pro socket na 0.0.0.0) vrátil správnou konkrétní odpovídající sockaddr_in.
Pro lokální adresy to bývalo OK, tam se to většinou nezblblo i pro více různých lokálních sítí /ať už virtuálních ať už fyzických/. Ani při dynamických změnách. Ale pro veřejné adresy jsem s tím někdy míval problémy. Navíc nedeterministicky /jen někdy/. Pokud člověk mezitím např. přidal veřejnou (např. navíc vytočil mobilní). Stávalo se mi, že někdy použil defaultní (novou) bránu, namísto routování po staré (přestože spojení pro soket, otevřené dříve, stále hlásilo příchod na starou veřejnou IP). A to občas neprošlo.
Snad už je to na novějších win, resp. pro IPv6, ošetřené 100%. Proto jsem se tak blbě ptal na možnost zvenku programu vnutit něco jako jedinou konkrétní trasu. Ty změny adres (pro priv ext) mi dělají mrazení v zádech.
Aha. Chybně jsem předpokládal, že už jednou otevřený (accept) socket si drží i routování (pokud existuje ta možnost, pokud je stále aktivní i připojení via původního providera, že je směrován stále tam).
Takže to možná nebyla chyba na straně windows, pokud některý z ISP měl problémy (občas to bývala divočina) a zahazoval pakety s "cizí" zdrojovou IP. Jestli to bylo něčím takovým, tak pokud dobře chápu, pak by neměl být na IPv6 se změnami IP problém ... půjde vždy stejnou "správnou" trasou, všechny ip "patří" pod jednoho. Takže toto asi vyřešeno. Díky.
Tedy, případ když vytočím další připojení může být stále stejně problematický.
Jen jsem ve svých úvahách dělal chybu, že jsem si myslel, že vytočení (a další nová veřejná IP) omylem mění zdrojovou adresu už otevřeného socketu (přestože API mi vrací že spojení je stále na původní). Protože jsem chybně myslel, že otevřený socket zachovává původní routování a z toho si chybně odvodil, že navenek musel podstrkávat novou IP, když změnil i routování.
... a tak jsem se nesmyslně bál, že se podobně divně bude chovat (tedy navenek měnit zdrojovou, že jen API dovnitř programu by stále hlásilo starou) i privacy extensions pokud budu mít i nějakou pevnou adresu ze stejného /64 prefixu.