Záleží na tom, jak kdo a co používá. Ono je to trochu jako s Flashem: pro někoho dávno mrtvá záležitost, někdo jiný si bez něj stále ani neškrtne. Já mám konkrétně doma IPv6 dual stack a komunikace s Googlem, Youtube, Wikipedií, Ubuntu repozitáři a dalšími významnými servery ho automaticky používá (jak jsem zjistil), takže celkově kolem 50% objemu veškerých přenášených dat mi jde přes IPv6. Je ale pravda, že na nějaký razantní nástup IPv6 Evropě a Severní Americe si ještě počkáme (kromě Belgie, tam už mají téměř polovinu uživatelů na 6). Hlavní růst šestky asi opravdu uvidíme především v rozvíjejících se zemích - v Indii, Africe apod. kde jsou obrovské rezervy potenciálních uživatelů a velice málo disponibilních bloků IPv4.
Nemyslím, že by tady byla nějaká snaha, natož důvod se "zbavit" V4. Pokud někdy zanikne, bude to v perspektivě desítek let. Otázka je spíš, co se stane, až přijde další vlna startupů, cloudů apod., které už budou mít problém získat potřebnou zásobu V4 adres a perspektivně jejich služby budou přístupné pouze přes IPv6.
Vetsinou s tebou celkem souhlasim,ale tady se dle meho nazoru pletez.
Ipv4 je dost problem pri pushingu na klienta kvuli ruznym nat po ceste. Tzn. Zde vznika nedeterministcnost kdy budou spojeni zavrena,coz u long pollingu (ale i treba ws) predstavuje zasadni problem. Nektere nat proste po urcitem timeoutu komunikace spojeni proste zahodi a neposlou ani ukonceni spojeni,tzn. browser o tom nevi...
U ipv6 routery (ci jejich fw) nat standardne neprovadi (ani dokonce nemusi delat conntrack),pakety posilaji cilove stanici,tudiz uzavreni spojeni je v rukou prohlizece/os, coz je mnohem spolehlivejsi.
Všechny mechanismy pro push na klienta používají nějaký ping pro udržování aktivního spojení. A klient musí počítat s tím, že se spojení může kdykoli přerušit a znovu ho navázat. NATy v IPv4 přidávají jen další důvod, proč se spojení může přerušit, v tom s vámi souhlasím, ale není to jediný důvod. Může to udělat kterýkoli prvek na trase, který sleduje spojení (třeba stavový firewall), může to udělat proxy server, může to způsobit výpadek mobilního signálu nebo WiFi.
Zrovna push z webového serveru je myslím technologie, která si s NATy poradí velice dobře. Mnohem hůř jsou na tom podle mne třeba služby pro IoT (routery, webkamery, NASy apod.), VoIP nebo sdílení souborů, které používají různá serverová a cloudová řešení jenom proto, aby se spolu domluvili dva klienti za NATy, kteří by jinak mohli komunikovat přímo. A to možná některým poskytovatelům cloudových služeb naopak nahrává, protože kdyby spolu mohla zařízení komunikovat přímo, nebudou potřebovat obezličky jako Skype.
Samozrejme, ze se to musi resit i tak a ze je to jen jedna vec. Nejaka forma keep alive je samozrejme potreba tak ci onak.
Ale nesouhlasim s tim, ze si s tim NAT poradi uplne dobre... Docela jsme to resili na jednom projektu, kde mel uzivatel permanentne otevrenou stranku a notifikace chodili opravdu sporadicky a resili jsme mnoho ruznych incidentu, kde to problmy zpusobovalo (vetsinou tak, ze NAT proste spojeni tise zapomnel). Pravda, bylo to zejmena u mensich a obskurnich ISP, skoncilo to u uplne nesmyslneho aplikacniho keep alive (45 vterin).
Na IPv6 se to chovalo vsude dobre.
Samozrejme, i na IPv6 muze vzniknout podobny problem diky stavovemu firewallu, ale dle me zkusenosti je to mnohem mene caste reseni (proste proto, ze to neni nutne, tak ty FW na trase typicky stavove nejsou, coz je samo o sobe vyhoda)
„A to možná některým poskytovatelům cloudových služeb naopak nahrává, protože kdyby spolu mohla zařízení komunikovat přímo, nebudou potřebovat obezličky jako Skype.“
Pochopitelně. Kdo někdy řešil Voip SIPem, zjistil, že většina operátorů Voipu nepřidělují klientovi sipovou adresu, ale jen tel. číslo jen proto, aby se nemohli klienti spojit přímo (vyjednáním spojení SIPem), ale museli přes operátora placeně, přestože je to zcela zbytečné. A to se ani nebavíme o přímé viditelnosti klientů, kteří by tak nepotřebovali ani prostředníka (SIP proxy).
Zrovna Voip je VZOROVÝM příkladem, jak triviálně může fungovat přímá komunikace a jak je na hovno, když to nejde.
Jenže u ipv6 routerů bude NAT nahrazen firewallem, který ke stanicím nepropustí spojení iniciované zvnějšku - nikdo rozumný tohle nenechá. (Mimochodem, to je i hlavní důvod nasazení NATu, protože určitou ochranu - přes ideologické žvásty IPv6 propagátorů - přeci jenom představuje. Nedostatek IPv4 adres je jen výmluva...)
Je zde jeden zásadní rozdíl. Pokud na IPv6 chci otevřít UDP port (třeba pro VoIP), pošlu UDP paket na IPv6/port vyjednaný s druhou stranou, port se otevře pro příchozí spojení a vše funguje. Pokud to chci v IPv4 s NATem, tak jsou tři možnosti, jak to dopadne. Pošlu ten paket někomu jinému a ten port se otevře a namapuje pro všechny IP adresy. Pokud jej zrovna používá někdo jiný, tak mu ukradnu provoz. Bezpečnost hadr. Za to vám zákazníci určitě poděkují. Nebo to ten firewall namapuje jen pro daný IP/port, pak musím nějak zjistit, jakou veřejnou IP adresu má druhá strana (pokud má NAT, tak to neví). Anebo je tam „nejmodernější“ symetrický NAT, který mění číslo portu odchozích paketů, pak pokud má druhá strana též NAT, tak mám smůlu, protože není jak zjistit, jaký port má vlastně použít. A to pomíjím obrovské problémy, pokud bych chtěl ten provoz šifrovat pomocí IPSec či přesměrovávat u roamujících klientů (např. mobil přecházející mezi LTE a Wi-Fi).
O žádných zásadních problém nevím. Server prostě posílá RTP na por a ip adresu odkud dostává RTP sám. Tedy koncové zařízení musí posílat zvuk už i během vyzvánění. V SIP hlavičkách jsou pak nesmysly, který se ignorují. Kazí to celý koncept SIPu ale funguje to relativně dobře. Koncept SIPu jaksi na NATy zapomněl a má i jiné zásadní chyby.
Kdo začne posílat, pokud jsou obě strany za NATem?
Pro zjištění portů v SIPu se používá TURN server a doufá, že tam není symetrický NAT, jinak musí jít veškerý provoz přes nějakého prostředníka. To je také důvod, proč se SIP prosazoval v 90. letech a pak už moc ne.
NAT není problém jenom SIPu, ale veškeré P2P komunikace. Třeba WebRTC naráží na ty samé problémy.
Ti zamichaji leda simkartama. Uz v roce 2008 kdy Vodafone koupil firmu Broadnet jsme tam meli IPv6 v pateri, pripravovane na webhostingu a planovali jsme zacit nabizet i zakaznikum. Vodafone to pak cele stopnul, sliboval ze tak az rok atd... Dodnes nabizi leda kulovy. Zdejsi mobilni kartel se rozvoj jen brzdi tak jako to drive delal zluty smejd SPT Telecom. Vsechno je to stejna pakaz.
To se asi nedozvíme. Když se podíváme na IP 80.250.8.---, tak nám z ní sem se stejnou inteligencí píše kvákvá a bflmpßwẓ. A pro zajímavost to podle whois směřuje k firmě Gordic, tedy firmě už dlouho přisáté na státní peníze. Že by v některé ze smluv a tech. specifikací přehlédli zmínku o IPv6, teď to po zadavatel chtěl a proto tak kopou kolem sebe? ;-)
Hele, není třeba vymýšlet žádné další důvody. To už si vymysleli. Prostě jsme specifickej trh. Stačí.
Tohle se dá použít univerzálně, v potravinářství (prostě budeš chlastat fruktózu), při stavbě dálnic (nejdražší a ještě neustále v přestavbě), pro mobilní operatéry (nefunkční nejdražší s fupem na 10minut a když se ti to nelíbí, odstěhuj se do Polska), pro isp (nat stačí, veřejnou nikdo nechce a o šestce jsme v životě neslyšeli) a tak dále.
Prostě specifickej trh no.
Nejsem priznivcem zakonnych opatreni / zasahu do soukromeho podnikani, ale na druhou stranu je pravda, ze tohle neco podobneho jako mobilni site. Dovedu si zde predstavit jistou regulaci ze strany CTU, regulace ISP uz nejakym zpusobem funguje. Kdyz je mozne zaukolovat ISP kvuli takove 3.14vine jako je blokovani hazardnich webu, tak tady by to bylo aspon ku prospechu veci. Ale samozrejme to neni v dusledku dobry napad, protoze by se rozjeli zaloby a napadani kvuli udajnemu zvysovani nakladu (ktere je povetsinou imaginarni).
A kolko bolo zalob za kasy? Tie naklady nezvysili? Ak to proste nejde inac tak to CTU vynuti zakonom. Dalsi priklad su roomingove poplatky od EU. Ked to proste neslo, vsetkym na trhu to vyhovovalo tak to proste vynutili. Existujuce mozu nechat ale nove pripojenia musia ponukat aj IPv6. Ked nechcu investovat mozu pomaly umierat.
Na co? Já si nepamatuju ani svou veřejnou IPv4, a to je jenom jedna... zato dám z hlavy lokální IPv6 adrsy na domácí LAN.
Kde je v IPv4 192.168.1.10, tam můžu v IPv6 použít na lokální síti fe80::10 (prefix se zapamatovat dá, konec si dám v BCD to, co na 4ce a zbytek nulový, zajištěn pomocí dvojteček). A je to...
localhost mi je putna, mám co do činění s firemními sítěmi, kde jsou desítky tisíc koncových stanic a tisíce serverů, občas se řeší nějaký incident nebo se ladění routování. IPv4 se dá relativně snadno zkontrolovat a projít z hlavy, už mám vycvičený zrak, abych IP adresu našel v haldě textu v terminálu.
Nekritizuji IPv6, je v mnoha ohledech lepší a přínosem pro podobné sítě, ale tohle je pro mě její nevýhoda, toť vše.
Zeptám se, můj poskytovatel nemá problém mě připojit přes IPv6, ale nechá si to platit navíc, stejně jako za veřejnou adresu. Vím, že si musí koupit velký blok adres za peníze, ale kvůli tomu přece platím za internet, nevím proč platit něco navíc... Rád uslyším názory ostatních
Pokud tohle nabízí, tak už nějaký bloky adres mít musí. Tzn. má zaplacený registrační poplatek a ročních pár litrů rozpočítaný do nákladů. A v takové situaci má zdarma IPv6 adres, kolik si vzpomene.
Technologicky, pokud tohle nabízí, musí být po celé trase kompatibilní s IPv6. Takže náklady na technologii 0. Maximálně to musí technik zadat do systému (50Kč poplatek za aktivaci by pak byl OK), ale paušál za IPv6 je lumpárna.
Mám dojem, že roční členství v RIPE stojí 1400€, takže těch "párů" rozpočítaných do nákladů není zase úplně málo...
Po celé trase to kompatibilní být nemusí. Pokud jsou to nějaký jelita, tunelují třeba šestku přes IPv4 a mají s tím práci navíc, za kterou chtějí dostat zaplaceno. Nevíme o tom ISP nic, to se nám to spekuluje...
Zrovna s Dragonem jsem to nedávno řešil a jsou takoví... řekněme zmatení. Nejprve mi na můj dotaz ohledně velikosti ipv6 rozsahu řekli, že ta stovka + dph je za každou jednu adresu a až poté, co jsem ze srandy chtěl nacenit /56 blok, jim došlo, že to je asi blbost. Nakonec to stejně skočilo na tom, že ve své mikrovlnné síti ipv6 neumějí.
Spojení domů jsem nakonec vyřešil pomocí VPS za 30 Kč/měs. a OpenVPN tunelem.
Přesně tohle řešení jsem zvolil taky. Přes VPN jako client nemusím řešit nic víc, prostě zařízení se propojí bez ohledu na libovolně paskvilózní síť a tisíc NATů. Jediná podmínka je stálefunkční server se stabilní veřejnou IP. Ideální pro mobilní zařízení, který furt mění typ a způsob připojení. A to nejméně do té doby, než bude IPv6 samozřejmostí.
Ale mobilní zařízení ho nemá a v říši IPv4 nikdy mít nebude.
OpenVPN aplikace se ptá tuším každých 10s na spojení a pokud se změní, tak opakuje připojení. Nějaké delší výpadky jsou tímpádem skoro nemožné (ano dalo by se to řešit aktivním tunellingem ze zařízení na server, ale VPN tohle umí automaticky a nastavení je univerzální a triviální).
Dále uvnitř VPN sítě je už IP statické (pokud to tak nastavím), takže nemusím řešit záložky a různé odkazy na všelijaké služby v každém členském zařízení. Čili mi je pak celý problém zapráskaných operátorů (providerů) a jejich neochoty hnout tlustou zadelí ukradenej. A to jsem se dřív hodně snažil přimět některé k implementaci IPv6, na základě zkušeností bych řekl, že takové chování bude ještě hodně dlouho zcela donchitotská marnost...
Az na to, ze samotne IPv6 neda tomu mobilnimu zarizeni statickou ip adresu. Jedine snad IP roaming, ktery ve skutecnosti funguje na principu "tunelu" od routeru, kam je ta IP naroutovana k zarizeni, ktere se tomu routeru ohlasuje svym aktualnim pripojenim. Takze kdyz mate dve takova zarizeni vedle sebe, ale maji domovsky router na jinem kontinentu, tak se holt mezi sebou budou bavit skrz podmorske kabely (s prislusnou latenci).
Pokud ale zvazujete pouze pripojeni mobilnich zarizeni z pripojeni jake zrovna maji na verejnou ipku:port, tak staci jen tu verejnou ipku:port dat pred NAT. Uz ted, v IPv4.
2ebik: To by nekdo musel tusit, jak funguje mobilita zejo ...
Protoze tunel je sice taky moznost, ale az ta posledni, kdyz to nefunguje jinak, ve vsech ostatnich pripadech to funguje tak, ze nekdo z venku kontaktuje IP toho zarizeni (pres DNS samo), a protoze zarizeni je v jiny siti a poinformovalo svuj domaci router o svy aktualni IP, tak ten router datovej provoz na jeho aktuani IP preposle ... a co vic, on se dokonce pokusi toho nekoho o te aktualni IP informovat, tudiz v optimalnim pripade se po nejaky zahajovaci sekvenci uz komunikuje naprimo.
To je zazracna technologie co? Chci videt, jak to budes delat za NATem ... nemluve o tom, ze pres nej ani ipsec neproleze.
Tahleta zarzracna technologie pres DNS ma ve vetsine 5 minut timeout nez se dozvi ze stara adresa nefunguje. Hodne dns serveru ma nastaveno min-ttl na 5 minut. Takze vase mobilni zarizeni se prepne z LTE na wifi, a je minimalne 5 minut nedostupne pro jine mobilni zarizeni, ktere se nemuze ptat vaseho routeru pomoci dns naprimo.
Tak v tom pripade jsem nepochopil tvuj predchozi prispevek - proc do toho DNS vubec tahas, kdyz to je na urovni IP. Ja jsem predpokladal, ze IP protistrana proste vi, protoze je fixni, a je jedno jestli pres DNS nebo jakkoli jinak. Pokud je IP fixni, tak protistrana posila posle mobilnimu zarizeni packet na to IP a ten se odroutuje pres ten "domovsky router". I kdyz je ten router na jinem kontinente nez obe zarizeni. Jak se dostane packet zpet k tomu mobilnimu zarizeni ted neresim, jen jsem psal ze to muze fungovat napriklad pomoci tunelu.
Nevidím důvod ani pro ten aktivační poplatek. U mnohých "ISP" by to znamenalo, že si za peníze pořídíte připojení k ISP a za další peníze (onen aktivační poplatek) vás teprve ISP připojí k internetu. To se mi zdá absurdní.
Mnoho ISP má poplatek čistě jen pro regulaci, aby to nemuseli dělat a aby potom mohli říkat, že ipv6 nikdo nechce.
Nevím, zda-li si rozumíme, platím měsíční poplatek plácnu 500kč a pokud chci IPv6, tak budu platit 600kč měsíčně, stejně jako za veřejnou IPv4, což odporuje logice, když IPv6 je "nevyčerpatelná" a nevidím důvod platit za to jako u IPv4, které už došli a obchoduje se s nimi..
To je chybná interpretace té situace. Ten service provider provozuje nějakou svoji síť, adresní rozsah bude nejspíš někde 10/8 apod. podle RFC1918. Do ní Vás připojí za 500,- peněz měsíčně. A Vy se nějak dostanete na ten Facebook, možná i někam jinam. No a pak vás taky může připojit k Internetu. To je ta síť s globálním routováním, kde potřebujete celosvětově unikátní tzv. "veřejnou" adresu. A je úplně putna, jestli to bude adresa IP protokolu v4 nebo v6. Za to, že Vás připojí do této síťe, mu budete muset měsíčně zaplatit 600,- peněz. Pokud Vás připojí přes IPv6, bude s tím mít samozřejmě vícenáklady, protože jeho privátní síť shodou okolností použává stejný protokol IPv4 jako Internet, takže s tím má jenom jednu práci, zatím co na IPv6 musí všechno udělat podruhé.
No tak tohle je tedy velmi vyšroubovaný příklad (a ano vím, že se mnozí "ISP" k této zrůdnosti uchylují).
mu budete muset měsíčně zaplatit 600,- peněz
A to jako proč? Před tím to měl ten ISP za natem, což je hw náročnější než obyč routování. Tak připojením na internet (což je teda podle mě základní úloha ISP) by v takovém případě znamenalo odlehčení na straně toho providera. Tak proč by za to měl zakoš platit cokoliv navíc?
samozřejmě vícenáklady
Samozřejmě...
Takto neschopný ISP, kterého popisujete, je FASTER?
To není vyšroubovaný příklad, tak to prostě je. Nazývejme věci pravým jménem. Pokud někomu service provider nedá veřejnou, globálně routovatelnou adresu, připojil ho všude možně, jenom ne k Internetu. A je to - bohužel - naprosto běžná věc.
mu budete muset měsíčně zaplatit 600,- peněz
A to jako proč?
To já nevím, na to se musíš zeptat toho providera, proč to má dražší. Já neznám jeho mechanismus cenotvorby. Je to čistě otázka jeho nabídky. Jeho síť, ze které se možná dostaneš na Fejs, je za 500,- , Internet je za 600,-. Pokud chceš Internet, musíš si koupit ten.
samozřejmě vícenáklady
Samozřejmě...
Co se Ti nelíbí? Je to, jak píšu. Pokud budu v síti mít dva protokoly místo jednoho, budu všechno nastavovat dvakrát. Budu si to muset nastudovat, možná si koupím nějaké školení, abych věděl co mám dělat, budu to dělat delší dobu a budou z toho tedy větší náklady. Jo, jiná věc je, jak se s těmi vyššími náklady vyrovnám. Jestli je promítnu do konečné ceny služeb.
Takto neschopný ISP, kterého popisujete, je FASTER?
Ježišmarjá nestraš. Na Faster si rozhodně nemůžu stěžovat, s jejich službami jsem naprosto spokojen.
Popisuji především různé ty venkovské šmrdly, se kterými jsem měl v minulosti tu smůlu se setkat. Je to bída a děs.
Je třeba jedno místo na vesnici, cca 15 km od našeho krajského města. Já bych se tam rád připojil a chci IPv6. Jenže - v místě jsou tři šmrdlové. Jeden na moji poptávku neodpověděl vůbec. Druhý mě ubezpečil, že IPv6 nemají, mít nebudou a mít nechtějí. Ten třetí vypadal zpočátku slibně. Tvrdil, že šestku plánuje a teď s ní experimentuje, ať prý se ozvu za půl roku. No, když jsem se ho ptal po cca dvou letech, řekl mi, že šestku dal k ledu a raděj se věnoval "vylepšování sítě". A to je jenom jeden ilustrační příklad. Zažil jsem toho, na jiných místech, mnohem víc.
Takže takovéto neschopné zoufalce jsem popisoval.
Tak na to to nemusí být malá vesnice. Stejná situace je i na sídlištích ve velkoměstech. Kromě opravdu velkých providerů ti ostatní chtějí poplatek za všechno. To znamená nasadí cenu o 50 korun levnější a vykompenzují si to tímto. Velcí provideři zase vydírají jinak například tím, že všechny smlouvy jsou ze závazkem, aniž by se to zákazník dověděl jinak než malými písmeny v podmínkách (jistý kabelový operátor) anebo výpovědní lhůtou 45 dnů (jistý mobilní operátor). Všechno stejná pakáž.
Na kolik ho v reálu přišel CGNAT?
- Je na to potřeba nějaký železo, za kolik?
- Jakou životnost to železo má?
- Kolik stojí škálování, když přibývají klienti a tím i požadavky?
- Kolik ten hardware žere elektriky a za kolik?
- Kolik času tráví jeho nastavováním, updatováním,...?
- Kolik stojí ukládání dat o tom, kdy kdo z které IP adresy kam lezl (disková kapacita, nasazení řešení,...)? Je to levnější než tabulka, ve které má napevno jméno-IPv6?
- Kolik % trafficu jde draze placenou linkou ven a zase dovnitř (tj. o kolik víc kapacity si musí platit), protože Božka chce předat Máně z vedlejšího baráku fotky z dovolené?
Tak, a fčíl mudruj, jestli je to levnější, než ty lidi rovnou pustit ven.
Ten zásadní problém tady je, že i když ISP nasadí IPv6, stejně musí CGNAT provozovat. Je tedy potřeba srovnávat pouze o kolik může být CGNAT menší, pokud se offloaduje část provozu do IPv6. A to vyjádřeno penězi zřejmě není velký rozdíl, resp. taková úspora zatím nejspíš nevynahradí náklady na zavedení IPv6. Proto jsme tam, kde jsme.
Až náklady na další škálování CGNATu přesáhnou náklady na zavedení IPv6, racionální ISP IPv6 zavede a dokonce ho svým zákazníkům vnutí.
Otázka spíš je, jestli se nevyplatí to železo pro CGNAT použít pro tunelování 4ky a interně jet po 6ce. Protože teď jde NATem 100%, pokud upřednostní 6ku, tak G, FB, Centrum.cz a další pojede nativně po 6ce a najednou to železo musí překládat jenom třeba 40% trafficu (levnější, míň logů,..).
Tohle je zase zejména ekonomická otázka. Obecně ale nejspíš platí, že technologie IPv4 NATu je dnes vyvinutá a dostatečně stabilní, takže krabice provádějící IPv4 NAT je levnější, než stejně výkonná krabice provádějící například NAT64, nebo DS-lite AFTR. Z dlouhodobého hlediska je ale takový krok správným směrem, protože po prvotní velké investici budou náklady na další rozvoj jen klesat. A pokud dojde v prvopočátku k přetížení IPv4 překladače, jako se to dělo/děje v Německu, vznikne tržní tlak na poskytovatele obsahu, aby IPv6 zapnuli.
No to je otázka, jestli na NAT64 potřebuje stejně výkonný železo. Většina trafficu od BFU budou Win Update, YouTube a FB po IPv6. A jestli ty prachy na NAT64 nebudou ty samý nebo menší, jako na CGNAT.
Když vezmu IPv6 a BFU u nás doma, tak tunelem Hurricane jde 60-70% manželčiných dat, když ho hodím jako preferovaný (má menší MTU, takže často jde čtyřkou i to, co by jinde dala šestka). U takvýh by byl dost velký potenciál.
Co třeba příměr:
"Zeptám se, můj zmrzlinář nemá problém mi dát malinovou polevu, ale nechá si to platit navíc, stejně jako za čokoládovou. Vím, že si musí koupit suroviny za peníze, ale kvůli tomu přece platím za zmrzlinu, nevím proč platit něco navíc... Rád uslyším názory ostatních"
Takže řešení jsou defacto tří:
1. smířit se s tím a zaplatit
2. najít jiného zmrzlináře
3. rezignovat na polevu
Ale ano. Urcite su take siete, kde sa pouziva ATM a ine protokoly ale tipujem ze su to uz len dozivajuce siete udrzovane z nejakeho specifickeho dovodu. Urcite niesu ale rozsiahle/globalne. Ked som sa ja ucil o ATM(okolo roku 2000), tak ATM a podobne protokoly uz zacinali byt nedostatocne. Ucili nas, ze buducnost su NGN siete postavene na TCP/IP.
Uz pred rokmi operatori u nas na NGN prechadzali. Tipujem, ze aj v CR.
Tak, vzhledem k tomu, že u široce používaného ADSL je na 2 vrstvě právě ATM, bych ji za mrtvou technologii rozhodně nepovažoval. Na VDSL jsem nekoukal, ale skoro bych čekal, že tam je taky.
Nebudu to psát sem, to by bylo zbytečné, dá se to nastudovat - podívej se na Signalizaci č. 7. Tam je celá škála protokolů v mnoha vrstvách OSI modelu. Celé se to používá v globální signalizační síti, která je s Internetem naprosto srovnatelná, byť slouží k poněkud jinému účelu. Další takový globální internet mají banky. Mám na mysli takovou tu "mezinárodní zúčtovací síť", já ji bohužel neumím správně pojmenovat. Tam se najde třeba X.25 nebo FrameRelay (ale IP nepochybně taky).
Já ale mluvím o druhé vrstvě na tom drátě, který vede z modemu do DSLAM. Na něm je ATM. Ve VCI 48 se přenáší Internet, ve VCI 35 IPTV. V tom VCI 48 v minulosti býval zavřený rovnou PPP a pak se tomu říkalo PPPoA. Mělo to ale nevýhodu, že se ten PPP musel ukončit v modemu, takže se to blbě připojovalo k routerům. Veřejná adresa byla v modemu, ne v routeru. Dnes je ve VCI 48 zavřený Ethernet a teprve v něm je PPP. Proto se tomu říká PPPoE. Pokud je modem v režimu bridge a to PPP zakončené až za modemem v nějakém routeru, modem ethernetový paket vyndá z ATM a přes ethernet ho pošle dál. Poslechni si někdy provoz na takovém portu - můžou tam jednak být pakety s MAC toho modemu (pokud se do něj poleze přes jeho web rozhraní) a pak tam budou pakety s MAC DSLAMu.
ano, jistě. Ale bavíme se zde o protokolech představujících základní stavební bloky internetu, nikoliv o jedné specifické aplikaci. Pokud mezi ně počítáte protokol použitý pro spojení DSLAM→modem, můžete rovnou tvrdit, že část internetu je řešená třeba na bázi SDH. ATM se v internetu pro spojování okruhů už nepoužívá a last-mile na ADSL na tomto faktu nic nemění.
Aha, takže nemůžete a plácáte tady nesmysly. RIPE samozřejmě nijak neřeší ekonomické a smluvní vztahy mezi zákazníkem a ISP. Vyžaduje pouze aby všechny přidělené zroje byly řádně přidělovány a evidovány v databázi v souladu s RIPE policy, připadně v některých případech doporučuje aby vztah mezi koncovým uživatelem a ISP (rep. LIREm, což nemusí být totéz) byl upraven smluvně.
pod pojmem kšeftovat s adresama je asi myšleno prodávat celé prefixy jiným LIR. Zpoplatnění přidělení veřejných IPv4 adres zákazníkovi je dnes naprosto běžná věc (u IPv6 to tedy slyším poprvé a přijde mi to jako neskutečná prasárna), ikdyž se obvykle zpoplatňuje třeba přidělení většího prefixu velké firmě.
Ono vždy záleží na způsobu výroby statistiky. Počet klientů podporujících IPv4+IPv6 je jedna věc, ale například například AMS-IX (https://ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic) - průměr 3.533 Tb/s z toho IPv6 50,2 Gb/s, takže se stále motáme kolem 1,4%. Po takřka 22 letech zavádění nikterak oslnivý výsledek.
Kritika IPv6 je tedy více než na místě. Jakákoliv diskuse a posun je ale docela obtížný pakliže je na IPv6 nahlíženo jako na nedotknutelnou, posvátnou krávu o které je přijatelné hovořit výhradně v pozitivních konotacích.
Technicke problemy ze v IPv6 nejsou? Ani nahodou. Klasicky pripad je DHCPv6, ktere neposkytuje adresy DNS resloveru. Takze v kontrolovane siti mate problem navic, jak zajistit, ze klient nepouziva podvrzenou DNS.
Nebo IPv6 pozaduje jako povinnou soucast IPSEC. To neni vec jednoducha z zadneho pohledu. Napriklad pro embedded zarizeni pro ktere je IPv6 pry jednodussi je to primo nocni mura. Krome toho komplikuje doprednou i zpetnou kompatibilitu, protoze siforvani se neustale meni a co se pouziva dnes je zitra zastarale a pozitri to protistrana odmitne. (SHA1 jako priklad)
WTF???
1) DNS umi posilat RA (widle to neumi prijimat)
2) DNS samozrejme posila dhcpv6 (coz je jedinej zpusob, jak to poslat widlim, bez instalace appek tretich stran)
3) IPSEC uz par let povinou soucasti ipv6 neni (bohuzel). Kdyby byl, nemusely by se resit chujoviny na tema jak zasifrujem dns ...
Tak to, ze IPSEC uz neni povinny jsem prehledl. Alespon ze tuhle blbost vyradily. Problem s IPSEC je ten, ze zadny stav neni finalni a neustale se vyvyji. Jsou zarizeni, ktere se planuji do provozu na desitky let s tim, ze aktualizace SW je vec prakticky nemozna z duvodu bezpecnosti a s tim souvisejicim schvalovanm, ktere trva i roky. Chapejte to tak, ze napriklad technologie v chemicke tovarne musi byt predevsim bezpecna z pohledu vybuchu a bezpecnosti lidi. Sitova bezpecnost se resi jinde nez na koncovem zarizeni, napriklad tim, ze je zarizeni je pripojene na oddelenou sit, nebo tim ze neni pripojene vubec nikam a rozhrani je tam jen pro diagnostiku pri udrzbe ve vypnutem rezimu.
To je úplně zcestná argumentace. Oddělení sítě zvýší bezpečenost o několik řádů.
Samozřejmě to nezajistí 100% bezpečnost a hrozí, že když tu síť provozuje někdo, kdo tomu moc nerozumí, tak nabyde pocitu falešného bezpečí - a ignoruje ostatní možné vektory útoku.
Průmysl je plný historických sběrnic, které se spoléhají pouze na fyzické oddělení - a pokud byste zvedli zadek a překonali tu fyzickou bariéru a připojili se na médium, tak ovládnete dočasně cokoliv.
Ty továrny budou samozřejmě v budoucnu přecházet na různé sítě postavené na průmyslovém ethernetu a IPv4, takže IPv6 je pro ně hudba vzdálených let. Ale je potřeba si uvědomit, že i takové sítě existují - že jsou zařízení, která budou mít za úkol fungovat až desítky let.
Klasicky pripad je DHCPv6, ktere neposkytuje adresy DNS resloveru.
Nejspíš myslíte SLAAC, protože v DHCPv6 adresy DNS serverů bez problémů mohou být. A mohou být ostatně i v ohlášeních směrovačů.
Takze v kontrolovane siti mate problem navic, jak zajistit, ze klient nepouziva podvrzenou DNS.
Můžete to trochu rozvést? Zejména pak, jakým způsobem zajišťujete, že „klient nepoužívá podvrženou DNS“ u IPv4.
Nebo IPv6 pozaduje jako povinnou soucast IPSEC.
Tohle bylo už dávno změněno na mělo by. S IPSECem je to tedy stejné jako u IPv4. Jen díky end-to-end principu by měl být IPSEC na IPv6 použitelnější.
S autorom clanku NESUHLASIM.
Pise:
"Okamžik s velkým „O“, kdy do toho IPv6 pořádně praští. Ten skoro jistě nenastane."
Mohol by nastat skokovo keby sa velki poskytovatelia sluzieb a konektivity (HE, Cogent, Google, Amazon) dohodli na konkretnom Deadline kedy vypnu IPv4.
Napriklad, od 1.1.2020 iba IPv6 --to je riesenie.
Samozrejme, po celom svete je mnozstvo neschopnych, nekompetentnych a lenivych firiem/ludi, na ktorych vsetci beru ohlad.
Jedna věc mě strašně mrzí: Jsou tu lidi, kteří nasazení lepšího protokolu (a tím IPv6 bezesporu je, ale platilo by to zrovna tak pro jiný) věnovali dost času a úsilí, a nakonec to stejně dopadne tak, že používat jej budou všichni bez ohledu na to, zda pomáhali nebo škodili. Přál bych si, aby 6ku měli jen ti, co si to zaslouží, nebo alespoň nevysírali, a naopak aby těm zmetkům zůstala napořád 4ka (samozřejmě včetně NATů a sraček okolo).
Az na to, ze IPv6 bude(je) lepsi az od chvile kdy bude(je) masove nasazena. Kdyz nejsou lidi, neodladi se chyby v implementacich, a kdyz se neodladi chyby v implementacich, tak se neda mluvit o pouzitelnosti. V dnesni dobe se toho ovsem meni tolik, ze mne jen tak nekdo nepresvedci, abych pro nej zdarma delal pokusneho kralika.
Zatim jsem se od propagatoru IPv6 nedozvedel jak u tohoto protokolu ucinne (tedy i za financne prijatelnych podminek) bojovat s DDoS. Jestli me neco odrazuje od pouzivani tohoto protokolu, tak je to prave tento problem. Zatimco u IPv4 jsme dnes schopni relativne levne filtrovat "cely svet", u IPv6 to mozne neni. Radeji budu bez IPv6 nez pred timto problemem strkat hlavu do pisku.
Normálně. Blokuje se celý blok IP6 adres. ISP dostane blok, ten dělí na zákazníky. Když chci odpojit zákazníka, tak ustřihnu /32, když celou síť, filtruju podle třeba horních 16 bitů. A kapacita spojení je stejná...
U IPv4 je průšvih v tom, že ISP má třeba /16 z jednoho bloku, pak přikoupí /20 z Izraele a /20 z USA a neaktualizuje záznamy a nevíš, kdo a odkud na tebe pálí. Proto se o obraně na IPv4 tolik mluví, protože je složitější lokalizovat a vykrýt útok.
Prefix si nezvolí náhodně, to by k němu žádný paket nedoputoval, náhodně si zvolí naopak suffix. V čem je rozdíl proti situaci v IPv4 s NATem, kde odstřelení jedné IP adresy odstřelí celou univerzitní/firemní síť, kde náhodou byl jeden zavirovaný počítač?
Co je s geolokací a IPv6? Není tam žádný technický rozdíl proti geolokaci na IPv4, naopak může dávat přesnější data, protože má lepší rozlišení.
Ale ja nechci filtrovat cele site, ja chci filtrovat pouze skodlivy provoz a to u IPv4 jde. Adresni prostoru IPv4 (tedy 32bitu) to umoznuje. Zariznout 32bit prefix u IPv6 znamena zariznou celou republiku. A na uzsi masku nemate dostatek pameti. Vychazim z principu programovani techto ochran. Pokud to budete delat databazove, tak to reseni zase nebude mit dostatecnou propustnost. Ten stroj nema cas v pameti hledat, kde se ten konkretni counter nachazi...
Zariznout 32bit prefix u IPv6 znamena zariznou celou republiku.
No, tak jsme si zapřeháněli. /32 má můj malý lokální isp, takže kdyby někdo zablokoval tohle, tak to postihne max pár tisíc lidí (a to ještě pouze v případě, že mají zájem jít na vaše služby). Pokud se rozhodnete blokovat /48, zaříznete jednoho zákazníka daného isp, tedy jen pár lidí.
Takže máte jednodušší situaci, než u ipv4 (kde za jednou adresou bude celá vesnice), můžete blokovat /64 nebo /48 a zařezávat pouze jednotlivé zákazníky případně jejich sítě.
proc je problem efektivne filtrovat /40
No to by mě zajímalo, proč je to problém. Naše společnost poskytuje software jako službu (dalo by se to tak říct), máme vlastní hw v DC, nějaké velké ddos útoky se nám vyhýbají (a otevřeně říkám, že na naší úrovni si s tím stejně neporadíme, pokud nám někdo zahltí porty do DC, tak jsou prostě zahlcené), ale občas jsme pod útoky na jednotlivé služby a není nejmenší problém to na úrovní IPv4 filtrovat klidně i po jednotlivých IP a v případě větších problémů klidně po celých subnetech.
Rozdíl pro ipv6 nevidím, prostě místo jedné IPv4/32 bude jeden /64, místo /24 bude /48 a tak dále. Stejně na nás neutočí celý svět, takže v tom firewallu je těch záznamů jen pár. Fakt nevidím důvod (a rád bych ho znal), proč bych měl řešit velikost blokovaného subnetu a proč by mě to mělo způsobovat nějaký problém. Se subnety pracuju jako s jednotlivými záznamy a pokud detekuju, že jsou všechny z jedné sítě, tak to nahradím větším subnetem a počet záznamů ve firewallu se tím sníží. Nevidím problém.
Vidím, že hodně lidí nepochopilo, jak to je. Takže srovnání:
IPv4
ISP: Prefix řekněme /16
Oblast (město,...): /32 (CGNAT)
Zákazník: Nelze rozlišit (/32 za CGNATem)
Počítač zákazníka: nelze rozlišit (/32 za NATem za CGNATem)
IPv6:
ISP: Prefix řekněme /32
Oblast (město,...): Nelze rozlišit, interní pravislo ISP
Zákazník: /48 (nebo /56)
Počítač zákazníka: nelze rozlišit (schováno v dolních 48b - PE apod.)
Když dělá problémy někdo nebo něco v síti konkrétního zákazníka, v IPv4 bloknu jednu adresu a je out celá oblast (třeba 10 zákazníků, kteří by v tu chvíli utráceli).
V IPv6 bloknu /48 a postihne to jednu konkrétní domácnost... Efekt stejný, jako u čtyřky volat ISP a zjišťovat, odkud v jeho síti to jde a žádat ho za odstřižení něčeho (neví se čeho) za NATem.
Jo, jenomze ty tady pises o blokovani. Coz je samozrejme uplne jednoduche. Ale me jde o detekci DDoS. Uz u masky /40 neni technicky mozne dosahovat stejnych kvalit detekce jako se dnes bezne dosahuje u IPv4. Pritom /40 je obrovska oblast na rozdil od 1 IPv4 s NATem. Vic uz k tomu nejde rici. Konec. Pekny vikend.
Ne, u wedos nepracuji, ale uvazoval jsem nad tim jejich problemem. Vy tu rezete cele IPv6 site. U IPv4 jste schopni filtrovat pouze skodlivy provoz. Proc to nejde u IPv6? Staci se zamyslet jak takova ochrana funguje. Zariznout koncaka je jedna vec, ale zariznout hosting uz je vec druha. Ja v tom rozdily nedelam.
Hosting nejede jako jedna síť. Pokud je rozumně udělaná, tak má /32 a zákazníkům dává třeba /48. Když zlobí jeden jejich zákazník, zařízneš jednu (nebo několik) /48 a zbytek jede. V čem je problém?
Pokud zlobí celý /32 (někdo zneužuje 0-day na infrastruktuře ISP nebo datacentra), a bordel chodí z celýho /32, tak se zařízne /32 jedním pravidlem a je to.
Naopak je průšvih, když přes maškarádu portů schová pět zákazníků za jednu IPv4 adresu a tu někdo odřízne. Vypadnou pak další čtyři zákazníci... Nebo když je 20 zavirovaných IoT krámů za jedním CGNATem, kde je za jednou IPv4 celá vesnice s 50 barákama.
Osobne vidim problem nasadenia IPv6 vo viacerych rovinach.
Najvecsi problem su ISP. ISP sa do toho nehrnu a spekuluju. Casto je to z dovodu maximalizacie ziskov a obavy ohrozenia ich trzieb a pozicie/dolezitosti na trhu. Dnes ISP veselo zarabaju na IPv4 adresach a na obmedzeniach IPv4. Prechodom na IPv6 stratia argumenty na odvodonenie roznych extra prirplatkov (za verejnu pevnu IP adresu,...) . Rozvoju IPv6 hadzu umele prekazky(zakaznikom davaju mensie rozsahy ako by mali davat, tie rozsahy su dynamicke, a komplikuju plne vyuzitie potencialu IPv6. Komplikuju zivot poskytovatelom obsahu a chcu z nich vytrieskat nejake $ za nic.
Maly ISP(neviem, ci si vobec taketo oznacenie zasluzia) su na tom este horsie, kedze su casto zakaznikmi tych velkych ISP a v podstate prevadzkuju lokalne siete, ktore pripajaju na internet. Oni budu posledny, co nasadia IPv6.
Zakaznici. Tam je to podobne ale s tym rozdielom, ze su na druhej strane barikady.
Celemu tomu nepomahaju ani vyrobcovia HW, hlavne vyrobcovia "krabiciek" za par $.
Z celeho toho je ptom na konci poriadny gulas, ktory sposobuje aktualny stav.
Myslim, si ze dany stav sa dal ocakavat(hlavne ludia z praxe to ocakavali) a tie odhady boli od zaciatku prehnane optimisticke a otrhnute od reality. Tak mi pripada aj tento clanok.
Da
Naopak. U sítí na IPv6 odpadne nat a logování pro poldy, takže je (interně) levnější.
Pár služeb je jenom na IPv4. Takže kdo chce do čtyřkové sítě, připlatí si (za provoz NATu z 6 do 4). A to je teď většina. Už jenom to, že iVysílání ČT jim nefunguje po IPv6, může být motivace.
A když se to postaví do roviny "kdo nepotřebuje IPv4, má 5% slevu" nehbo levnější tarif "6 only" ... ;) Každý zkusí levnější a pak se vrátí na vyšší tarif, protože mu ještě něco nepojede... A zůstane tam, i když pak už nebude důvod. Při stejné rychlosti a ostatních parametrech. A vůbec bych se nedivil, kdyby pak potichu NAT vypli a nechali původní cenu...
Akorát s touhle taktikou by museli začít okamžitě, protože zásadních věcí, co jedou jenom po 4ce, každým dnem ubývá.
A co se HW týká, tak za 10 let už je snad všechno u ISP vyměněno, ne? ISP si navíc může tuhle výměnu přece hodit "do daní" jako náklady. Takže poslední problém je přinutit lidi, aby neutekli někam, kde si "vystačí s původní krabičkou" a zaplatili si nový router.
Hmmm...
viz: "Takže poslední problém je přinutit lidi, aby neutekli někam, kde si "vystačí s původní krabičkou" a zaplatili si nový router."
Což jsou nakonec lidi, co tuhle legraci nakonec platí - banda líná a neschopná co není ochotna pochopit, co je pro ně dobré a co ne...
No jo no, zase stejná diskuse se stejným výsledkem - IPv6 je neskonale lepší, nemá žádné problémy - akorát ji nikdo nechce (možná trochu přehnané) a mimo velice ohraničený svět IT ani nikoho nezajímá. Takže až zde bude služba, kterou nebudu "moci" opomenout tak si ji objednám - a způsob připojení bude součástí dodávky a je mi jedno zda IPv6 nebo poštovní holuby. Do doby, než tohle pronikne do komunity, jiné to nebude :-) Jak jsem psal posledně - uvidíme za 10 let - myslím, že tenhle (nebo podobný) článek uvidíme zase.
Koncoví zákazníci každou chvíli řeší problémy způsobené NATem nebo tím, že jejich zařízení nejsou dostupná z internetu. IPv6 je řešením těch problémů. Koncoví zákazníci nikdy nebudou chtít IPv6, protože to je jen nástroj, který je nezajímá. Bohužel vzhledem k laxnímu přístupu spousty operátů asi nezbude jiná možnost, než že se zákazníci o IPv6 zajímat začnou a vysvětlí operátorům, že jejich problémy operátor vyřeší právě nasazením IPv6.
Pokud bude auto splňovat požadavky - mimo jiné bude jezdit jak potřebuji - nějaký motor si klidně nechte.
Nerad bych se dostal do absurdit - řešit technologie pro technologie je hezké, ale často to nikam nevede. Ale pokud technologie umožní dodat službu, kterou zákazník chce - pak se rozšíří bleskově. Je určitě mnoho zákazníků, kteří řeší, že se nemohou dostat zvenku ke svým datům - ale není jich dost. Obrovské většině je to jedno - neprovozují nějaký typ serveru u sebe doma, IP telefonie je nechává v klidu a rozdíl "být v nějaké síti za 5-tým NATem" a "být v internetu" je pro ně zcela nepostřehnutelný. No a když něco nejede tak zvednou telefon a někdo to opraví nebo, pokud je možnost, přejdou k někomu jinému... Ale to je přece v pořádku - IT má sloužit lidem a ne naopak.
No nic, už přestanu otravovat - omlouvám se...
Tento týden jsem shodnou okolností posílal email svému ISP a byť jsem s jeho službami spokojen, odpověděl, že s nativní podporou IPv6 v blízké budoucnosti nepočítá. Jen pro úplnost je to docela velký jablonecký ISP. Schválně mě ta odpověď zajímala, reagoval jsem na výzvu SixXS "Call Your ISP for IPv6!". Na druhou stranu, kolik hardware pro obyčejné lidi IPv6 podporuje? Tady je situace také tristní.
Na druhou stranu, kolik hardware pro obyčejné lidi IPv6 podporuje?
Osobní počítače, tablety, mobily – bez problému.
Domácí routery − kromě těch nejlevnějších je to taky celkem dobré (na druhou stranu, spousta zastaralých routerů stále „dobře slouží“)
Smart TV – těměř nulová podpora.
IoT – úplná nula.
" Na druhou stranu, kolik hardware pro obyčejné lidi IPv6 podporuje? Tady je situace také tristní."
Cokoliv, kam jde vrazit OpenWRT. A to je nutnost i jiných důvodů - měli jsme doma router, co zamrzal 2x týdně. Po upgrade na WRT vydržel jet bez problémů rok a jak jsem se pak dozvěděl, původní FW měl ROM-0...
Pohled pana Satrapy je mi sympatický, leč praxe je nyní taková, že masy menších poskytovatelů služeb, kam také patřím, si infrastrukturu kupují jako službu. IPv4 dostaneme v základu a IPv6 je méně či více složitější práce navíc. A někde není ani odstupná.
Třeba Amazon u EC2 začal IPv6 podporovat teprve v prosinci, a to jen pro Ohio. Přitom toto by byla cesta - pro správu svých instancí používat IPv6 a všechny problémy s public-facing dual stackem oddelegovat na pronajaté infrastrukturní služby (load balancer, CDN, mail apod.).
/62 jsou myslím jen čtyři podsítě, nikoliv 18446744073709551616 adres. Jedna podsíť je pro bydlící lidi, druhá podsíť pro domácí elektroniku, třetí podsíť je pro návštěvníky co chtějí heslo k WiFi, protože mají vyčerpaný GSM FUP a čtvrtá podsíť je pro přicházející IoT. Teď jen doufat, že nebude potřeba pátou podsíť.
Osobně bych si přál domů /56, ale myslím, že /60 běžné rodině bude stačit. /62 je ale na hraně, zatímco /64 by se IMHO vůbec nemělo přidělovat, to je na úrovni jedné IPv4 adresy, tedy do budoucna nedostatečné.
2Pali: Jiste, a nebude nic fungovat ...
ISP muze dostat NEJMENE /32 ... lusknutim prstu dostane /29
56-32 = 24 ... 2^24 = ... 16M, KAZDEJ JEDEN PODELANEJ PIDIPROVIDER MUZE ROZDAT 16 MILIONU /56
Jinak receno, jedna jedina /32 staci pro celou CR a jeste hromada zbude. A to i v pripade, ze svoji /56 dostane i kazdy embrio.
Mělo by se vždycky přidělovat podle standardu, všechno ostatní jsou jenom problémy a náklady navíc:
- Routery a standardní SW s nestandardem nemusí počítat.
- Nikdo mimo zákazníků ISP neví, že je to jinak. Pokud rozdělí /56 na několik /62 a ty dá zákazníkům, tak v případě problémů dvou z nich je postižen i ten zbytek, protože zbytek světa předpokládá, že je to jeden blok /56
- BFU bude mít složitější konfiguraci (třeba firewallu), protože standardní návody neřeší /62 a budou otravovat ISP kvůli každé prkotině. "Jak nastavit na firewallu, který počítá (v GUI) s /64 a /56, že ven má jít /60? Po SSH? A co to je?" Anebo rovnou "Jak je možná, že se nám může soused hrabat v komplu? Jak to nastavit, aby mu to nešlo?"
Predevsim neexistuje absolutne zadnej duvod, proc takovyhle ptakoviny pridelovat, kazdej ma automaticky dostat /56 a na pozadani /48.
BTW: Tri wifi site - privatni, pro navstevy, verejna, sit pro kravince (IoT), sit pro pocitace, dev sit na testovani, dalsi nejmin 4 site k sousedovi ...
/64 ma smysl tak maximalne jako pridel per server/vps, a i tam muze nastat poreba neco odroutovat.
https://tools.ietf.org/html/rfc6177
[RIPE-ENDSITE] have revised the end site assignment policy to
encourage the assignment of smaller (i.e., /56) blocks to end sites.
(původní politika byla přidělovat /48)
No a to je přesně jedna z věcí který mi IPv6 vaděj, ta bezbřehá adresní rozhazovačnost. Já osobně jsem proti takovému rozhazování, proč musí být základní velikost /64? Proč se v tom koncepčně musí dělat takovej s prominutím "mrdník"? Rád mám svoje síťe pod kontrolou což mi bohužel by-design IPv6 vůbec neulehčuje.
@bez přezdívky
Základ /64 se používá, aby fungovala bez problémů autokonfigurace. MAC adresa má 48 bitů, takže menší síť než /80 nemůžeš použít ani teoreticky. No a protože 80 bitů je z hlediska výpočetní techniky škaredá délka a také protože je žádoucí, aby tu byla jistá flexibilita a také aby nešlo jednoduše identifikovat uživatele, tak se k host části přidalo 16 bitů a tím vzniklo /64.
V případě IPv6 je jedno, jak moc se rozhazuje, adres je takové množství, že je jenom těžko vyčerpáš. Řádově jich je 10^38. Dokážeš si takové číslo vůbec představit?
"Nakonec byla stanovena na 128 bitů, tedy čtyř-
násobek délky použité v IPv4. To znamená, že k dispozici je 3,4 · 1038 adres.
To je jen těžko představitelné číslo, zkusme je uvést do souvislostí. Povrch
zeměkoule činí přibližně půl miliardy kilometrů čtverečních. To znamená,
že na jeden čtvereční milimetr zemského povrchu připadá 667 · 1015 adres.
Ano, řeč je o milionech miliard. V kapitole o adresování uvidíte, že IPv6
velmi plýtvá. Celých 64 bitů věnuje na identifikátor rozhraní, což znamená,
že v jedné podsíti lze rozlišit miliardy miliard počítačů. Každá síť má prostor
na adresaci 65 tisíc podsítí. A takovýchto sítí je k dispozici bezmála
30 tisíc na každého obyvatele zeměkoule4
. IPv6 adres je v každém ohledu
dost a dost, jak se přesvědčíte v kapitole 3 na straně 55."
https://knihy.nic.cz/files/edice/ipv6_2012.pdf
mohla teoreticky narazit při meziplanetárním síťování
Při meziplanetárním síťování se narazí na takové problémy, že IP protokol bude naprostá prkotina.
Třeba jen latence, na nejbližší planetu (Mars) jsou to 3 minuty a to jen pokud je nám nejblíže. Přes Slunce nelze vysílat, takže je nutné použít retranslačních družic. Nejdál je Mars od Země 22 minut (takže jen TCP handshake by trval více než hodinu). A tak dále. A to je pouze nejbližší planeta, uvažovat o "síti a protokolu ipv6" pro komunikaci s exoplanetami je už úplně mimo.
Bylo to myslím ve spojení s tímto (snad to je správně)
http://io9.gizmodo.com/5744143/particles-can-be-quantum-entangled-through-time-as-well-as-space
což by teoreticky mohlo umožnit komunikaci na meziplanetární vzdálenosti s nízkou latencí.
Takových myšlenkových experimentů je. Normální kvantová provázanost je známý a ověřený jev. Nedá se tím přenést informace. Časovou provázanost (pokud vím a v rychlosti jsem nic nenašel), zatím nikdo netestoval, to jednak, a hlavně nevysvělil*, jak přenést informaci (nadsvětelnou rychlostí).
Ale bylo by to hezké :-)
*) Už jen ta hromada věcí, kterou mají v úvodu toho papíru, jsou jen nepotvrzené hypotézy.
https://arxiv.org/pdf/1101.2565.pdf
Kdyz to takhle popisujes, trochu mi zacina rozum stat. Napadaji me dva "rozumne duvody":
1.) ipv6 bude meziplanetarni protokol
2.) nanoboti budou pouzivat ipv6
3.) zabranit Shodanu skenovat internet =)
Opravdu mi to prijde jako intergalakticky kanon na hmyz, je k tomu rozumny a realny duvod? A diky za odkaz na knihu, urcite si ji musim dat na vrch sveho seznamu.
Rozumný a reálný důvod k tomu je – neopakovat stejnou chybu, kterou udělali už autoři IPv4. Přeci jen, když IPv6 vzniklo především kvůli nedostatku IP adres, bylo by docela hloupé udělat tu samou chybu znova. Přičemž ta chyba vznikla přesně tím způsobem, který předvádíte – autoři IPv4 se omezili tím, co jim v tu chvíli připadalo představitelné a reálné. Určitě tenkrát někdo argumentoval tím, že větší adresní prostor by měl smysl jedině když:
1) IPv4 bude celoplanetární protokol
2) běžní lidé budou používat IPv4
3) lidé budou mít běžně několik počítačů, každý bude mít IPv4 adresu, IPv4 adresu budou mít i telefony, telefon bude mít každý člověk, někteří dokonce více, IPv4 budou mít i televize, hry, diáře…
Vidíte, a dnes jsou tyhle absurdity realitou. Takže by nebylo příliš rozumné adresní prostor IPv6 určovat podle stavu internetu v roce 1998.
"Kde je teda ten s nazvem ARP ??"
tady: https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol
Protoze to NENI nezbytne.
Zmena delky adresy u IP _JE_ nezbytna, takto to (poucene) verejnosti bylo vysvetleno a ona s tim v zasade souhlasila (argument neodvratneho vycerpani je neobycejne silny a snadno pochopitelny i pro laika). Takto silny a "verejnosti" jasne pochopitelny argument u ARP chybi a presto "verejnosti" bude ARP v ramci "zlepsovani internetu" spolu s prodluzovanim IP adresy zcizen. Vyznamne to pripomina nechvalne znamou praktiku naseho parlamentu zvanou "prilepky" (kterou ustavni soud prohlasil za neslucitelnou s beznym demokratickym provozem).
Nezbytný není ani Internet. Nezbytný není ani IPv4 ani IPv6. Ovšem bylo výhodnější přejít na IPv4, protože se lidé poučili z chyb NCP a navrhli IPv4 lépe. Stejně tak je výhodné přejít na NDP, protože se autoři poučili z chyb ARP, IRDP a ICMP Redirect a navrhli NDP lépe. A je výhodné na to přejít právě při změně z IPv4 na IPv6, protože se stejně mění síťový stack, takže je lepší to udělat jednou než dvakrát. Dnes vám stačí rozlišit, zda zařízení umí IPv4 nebo IPv6. Představte si, že byste místo toho musel rozlišovat, zda zařízení umí IPv4 s ARP, IPv4 s NDP, IPv6 s ARP nebo IPv6 s NDP.
Vaše námitky by byly pochopitelné, kdybyste uvedl nějaký příklad, v čem je NDP horší než ARP+IRDP+ICMP Redirect. Ale vy jen obhajujete, že staré je lepší, i když má horší vlastnosti. Já vám ten názor neberu, ale pak byste se měl vrátit k doručování pomocí poštovních holubů a nepoužívat takové zbyteční modernosti jako IPv4.
"Nezbytný není ani Internet. Nezbytný není ani IPv4 ani IPv6."
Opravuji tedy formulaci na "prodlouzena IP je nezbytna pro dalsi provoz a rust internetu"
"Vaše námitky by byly pochopitelné, kdybyste uvedl nějaký příklad, v čem je NDP horší než ARP+IRDP+ICMP Redirect. Ale vy jen obhajujete, že staré je lepší, i když má horší vlastnosti. Já vám ten názor neberu, ale pak byste se měl vrátit k doručování pomocí poštovních holubů a nepoužívat takové zbyteční modernosti jako IPv4."
Nejde o to zda si myslim ze by se vzdy a za kazdych okolnosti mela zavadet technicky nejlepsi verze cehokoliv. Jde mi primarne o to ze internet se tvari demokraticky (board, hlasovani, atd....), ale pro prosazovani "lepsich" reseni pouziva velmi spornych nastroju.
K posuzovani toho co je technicky "lepsi" se necitim byt povolan ani erudovan.
„internet“ se nijak netváří, „internet“ je médium, které se nemůže nijak projevovat. Nijak se netváří ani „Internet“, protože je to jen propojení mnoha různých sítí. Dodavatelé různých síťových řešení dodávají implementace IPv6 s implementací protokolu NDP. Žádný „internet“ je k tomu nenutí – nevím, jak byste si vůbec takové nucení představoval. A nevím, co by podle vás bylo demokratičtější, než že si to každý může udělat, jak chce. Nic vám nebrání dodat na trh router nebo vytvořil modul do linuxového jádra, který bude pro objevování IPv6 sousedů používat ARP.
Pro to, abyste se dokázal připojit k Internetu, musíte používat protokoly IPv4 nebo IPv6. Jak si zařídíte komunikaci ve vaší vlastní síti, do toho vám nikdo nekecá, udělejte si to, jak chcete. Nikdo vás nenutí používat tam NDP, klidně se tam používejte ARP nebo si adresy sousedů udržujte ručně.
"Já vám ten názor neberu, ale pak byste se měl vrátit k doručování pomocí poštovních holubů a nepoužívat takové zbyteční modernosti jako IPv4."
Pokud by nastana nahrazenim ARP nejakou jeho jinou variantou srovnatelne velka kvalitativni zmena (rychlost, latence, ztratovost) jako pri nahrazeni Holubi posty protokolem IPv4, tak by to byl prave ten silny a (poucenym laikum) jasne srozumitelny argument ktery mi v pripade ARP chybi.
NDP versus ARP je možná špatný příklad, ale obecně mám u rodiny protokolů, které přicházejí s IPv6 pocit, že budeme opakovat dvacet let ladění protokolů vůči vektorům útoku, které jsou nové a nebo vektorům útoku, které jsou v IPv4 známé, a v IPv6 mají dokonce podobné teoretické řešení. Akorát v praxi se na to výrobce bezpochyby vykašle. Stejně tak tu někdo zmiňuje, že NDP nebude umožňovat nějaké "antipaterny". IMHO měli lidé pro ty antipaterny nějaký důvod. Vždyť správně nastavit a spravovat to je složitější, než standardní řešení. A ty důvody s IPv6 těžko pominou. Takže budeme znovu nacházet ohejbáky na věci, které v původním návrhu nejsou.
Neříkám, že není čas protokoly zmodernizovat. Jen z toho co jsem zaslechl mám pocit, že jde o revoluci a ne o evoluci. To je jako napsat program celý znovu a přitom se nedívat do zdrojového kódu toho původního. Tím se také poztrácí spousta vlastností, která byla do programu zavedena během jeho ostrého provozu, ale chybí jim někde zaznamenané zadání, jako k čemu ta vlastnost byla užitečná. Tak se nám nedivte, že chceme vědět, zda ten nový protokol bude zaručeně lepší. Protože kolem starého vznikla nějaká "kultura", know-how (v podobě různých utilit), a to bude zahozeno, nebo se bude muset "přeložit" pro ipv6.
Lidé pro ty antipatterny měli nějaký důvod – nedostatky IPv4. Spousta z nich je v IPv6 vyřešená. Ovšem ne tak, jak by si někteří představovali – tedy že by se vzal ten hack z IPv4 a na něj narouboval další hack v IPv6. Ale je to vyřešené čistě od začátku. Takže dotyčný administrátor musí zapomenout, jak to ohackoval v IPv4, musí si nastudovat IPv6, nadefinovat si, v čem je vlastně problém, a pak to vyřešit s prostředky, které IPv6 nabízí. V drtivé většině případů je to možné a vede to k daleko lepšímu řešení, než v IPv4 – ale vyžaduje to od administrátora nějakou práci. Když to přirovnáváte k psaní programu od začátku – je to, jako kdyby se napsal celý program znovu, přitom by se vzaly všechny známé hacky původního programu a nový program by se implementoval tak, aby ty hacky už nebyly potřeba. Jenže pak k tomu přijdou uživatelé a začnou se shánět po svých haccích, místo aby si zjistili, jak mají daný problém řešit pomocí možností nového programu.
> přitom by se vzaly všechny známé hacky původního programu
Ze skušenosti je reimplementátorům známá jen část hacků původního programu. Druhá část je pro poptavatele samozřejmost, protože už dávno zapoměli, že se to někdy řešilo, a implementátoři to pak nemají jak zjistit. Co se týče antipatternů..., Jak souvisí výše zmíněný antipattern dvou defaultních gatewayí s délkou/počtem adres v protokolu? Já předpokládám, že spíš někdo chtěl aby na sebe nějaká zařízení viděla přímo (třeba proto, že spolu mluví i jiným protokolem, než IP), ale zároveň chtěl, aby každé dostalo jinou výchozí bránu (pokud možno bez manuální konfigurace těch zařízení).
Když píšete o dvou výchozích bránách, píšete o tom hacku. Jak jsem psal, v takovém případě je potřeba nejdřív si uvědomit, jaký je vlastně ten problém, který se tím hackem řešil – a pak ten problém vyřešit pomocí prostředků, které jsou dostupné.
Jak je to s délkou adres protokolu už jsem vysvětloval. Nedává smysl všechen hardware a software předělávat teď kvůli IPv6, za dalších 10 let kvůli NDP, pak kvůli bezestavové konfiguraci. Když už se ta změna dělá, je dobré to udělat všechno najednou. Tedy je rozumné s přechodem na IPv6 vyřešit i ostatní známé problémy a navrhnout nové protokoly tam, kde ty staré mají nějaké nedostatky. To, že přechod z IPv4 na IPv6 bude problematický, bylo od začátku jasné, tak je lepší takový přechod udělat jednou a ne každých deset let. Ostatně, kdyby to bylo takhle rozdělené, bude penetrace IPv6 ještě nižší, protože by si spousta správců řekla, že zatím nebudou IPv6 nasazovat a počkají, až bude i RA a NDP.
Protokol s názvem ARP je definován v RFC826: An Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware. Na to, na co jste se asi chtěl zeptat (ale nezeptal), vám už odpověděli jiní.
Dovolim si jednu poznamku, kterou jsem jeste na zadnem z IPv6 evangelizujicich for nevidel. Hlavni problem z pohledu ISP je (nebo alespon cca. pred rokem, kdy jsem IPv6 resil) ten, ze neni mozne vnutit pres DHCPv6 ani SLAAC default gateway jinou nez je primo iface daneho DHCP/SLAAC. Davno neni problem ani DNS, jak pro SLAAC tak DHCPv6, ale pokud se vam, ve jmenu autokonfigurace, nastavi jako gateway ip adresa DHCPv6 nebo RA serveru, tak s tim v prostredi ISP moc nepochodite, protoze pokud vam ma fungovat prefix delegation, tak potrebujete DHCPv6, ale zaroven potrebujete klientum poslat spravnou gw a ne adresu sveho DHCP serveru. Dalsi problem je DUUID, protoze ten se meni a neni to MAC, takze dalsi promenna, kdy musite myslet za koncaky, resp. hlidat/evidovat jejich DUUID. Je samozrejme pravda, ze pokud by ISP neresil, kdo ma co za prefix, tak to bude jakztakz fungovat at uz s SLAAC nebo DHCP, ale do toho se nikdo, kdo chce mit svoji sit trochu pod kontrolou proste nepusti, protoze to smrdi akorat pruserem a momentalne to 99% zakazniku proste neoceni. Pokud je situace u DHCPv6/SLAAC ohledne jine gw vyresena, tak se omlouvam za ot. Problem s DUUIDem kazdopadne trva a jen tak nezmizi. Staticky pridelovat a routovat IPv6 prefixy samozrejme lze, ale momentalne pridelovani ipv4:ipv6 podle zajmu uzivatelu vychazi, tak asi 5000:1. Coz asi uznate neni zrovna enormni zajem o IPv6. Krome poblaznenych studentu a adminu z VS o to vlastne nikdo zajem ve skutecnosti nema.
Výchozí brána se v IPv6 nastavuje buď ručně, nebo na základě ohlášení směrovačů. Žádná jiná možnost není a vůbec to nesouvisí s SLAAC ani DHCPv6 – to jsou protokoly na přidělení IP adresy a případně dalších parametrů koncovému uzlu. Jako adresa brány se skutečně použije adresa směrovače, který ohlášení poslal, ale tak je to v pořádku a jinak to nedává smysl. Pokud chcete, aby zařízení používalo jinou výchozí bránu, musíte mu zajistit spojení s touto bránou a pokud to spojení existuje, pak tím spojením protečou ohlášky od té správné brány a nastaví se to samo správně.
DUID se mění, MAC adresy se taky mění. Kde je rozdíl? Jen je nepříjemné, když je potřeba kvůli souběhu IPv4 a IPv6 evidovat obojí – o důvod víc proč IPv4 z přístupové sítě vyhodit. Nebo si můžete pořídit takový hardware, který vám do DHCP zpráv (v4 i v6) při předávání bude přidávat identifikátor portu, po kterém zpráva přišla přidělování adres otočíte proti tomuto. Takhle to ostatně pokud vím dělají snad všichni velcí ISP.
Ale to je prave ten problem. Pokud chci mit sit zautomatizovanou natolik, ze dojde vzdy k prideleni stejneho prefixu konkretnimu zakaznikovi, musim evidovat DUUID a jit cestou DHCPv6. Jenze presvedcit paterni cisco, aby si informace o prefixu a DUUIDu bralo z externi db je problem, takze potrebujete externi DHCPv6, ktery je podstane flexibilnejsi. Tady ale narazime na problem s GW, protoze dostanete ip DHCP serveru. Chapu, ze z principu navrhu to neni nic proti nicemu, ale pokud potrebuju mit nad pridelovanim ip adres kontrolu a zaroven to mit navazano na system pro spravu zakazniku/siti, tak uz to problem je. Pritom by stacila moznost mit v DHCPv6 serveru moznost podsunout jinou GW.
Samozrejme muzete mit DHCPv6 pro PD a RA pro prideleni GW, ale taky musite mit router pro zakaznika, ktery to zvladne a ne kazdemu se chce dat za router misto 500,- Kc treba 2000,- Kc, atd. Taky ne kazdy zakazik ma na konci router. S cimz zase souvisi problem s DUUIDem.
Protoze MAC, narozdil od DUUID, se vam nezmeni jen pri prebootovani do jineho OS nebo preinstalaci systemu, takze tech problemu, kdy to budete muset vysvetli zakaznikovi je tam vicero.
Btw. pokud vite o cisco switchi s podporou IPv6, ktery umi predavani identifikatoru o portu, aspon se dvema 1G/10G SFP/SFP+ porty v cene do 5K/10K ,- Kc, tak sem s nim. Samozrejme muze byt necisco, ale zase by mel umet rapid-pvst s pathcost method long.
Proste prestoze to vypada jako peace of cake, tak tech cernych petru tam par je a z pohledu koncoveho zakaznika, ktery dostane svoji /56 videt nejsou.
Nerikam, ze vsechny tyto problemy nejde nejak obejit/vyresit, ale za stavu, kdy o IPv6 projevi zajem jeden zakaznik rocne se to proste nevyplati.
Pokud chci mit sit zautomatizovanou natolik, ze dojde vzdy k prideleni stejneho prefixu konkretnimu zakaznikovi, musim evidovat DUUID a jit cestou DHCPv6.
Nemusíte. Stačí přidělovat podle identifikátoru okruhu, který vám do DHCP zpráv vloží relay agent podle fyzického portu, na kterém je zákazník připojen.
Tady ale narazime na problem s GW, protoze dostanete ip DHCP serveru.
Ne, tak to vážně nefunguje. Adresu brány přiděluje brána samotná, DHCPv6 server jí vůbec přidělit neumí. Čili každé zařízení se dozví správnou adresu brány prostě jen tím, že ho k té správné bráně připojíte. Nijak jinak.
Pritom by stacila moznost mit v DHCPv6 serveru moznost podsunout jinou GW.
Viz výše, DHCPv6 neumí poskytnout vůbec žádnou bránu.
Samozrejme muzete mit DHCPv6 pro PD a RA pro prideleni GW, ale taky musite mit router pro zakaznika, ktery to zvladne a ne kazdemu se chce dat za router misto 500,- Kc treba 2000,- Kc, atd.
Tohle zvládne každý router, který umí IPv6, protože jinak to ani dělat nejde. Bez RA se router nemá jak dozvědět adresu brány a zbývá tak jenom ruční konfigurace.
Protoze MAC, narozdil od DUUID, se vam nezmeni jen pri prebootovani do jineho OS nebo preinstalaci systemu, takze tech problemu, kdy to budete muset vysvetli zakaznikovi je tam vicero.
DUID se vám zase nezmění, když se klient připojí jinou síťovou kartou ze stejného počítače. Navíc díky němu může DHCPv6 fungovat i po linkách, které žádné MAC adresy nemají, například PPP.
Btw. pokud vite o cisco switchi s podporou IPv6, ktery umi predavani identifikatoru o portu, aspon se dvema 1G/10G SFP/SFP+ porty v cene do 5K/10K ,- Kc, tak sem s nim. Samozrejme muze byt necisco, ale zase by mel umet rapid-pvst s pathcost method long
Na tohle je potřeba ptát se dodavatelů. Oni dodávají primárně to, o co mají zákazníci zájem. Když nebude zájem, nebude funkčnost. Existuje k tomu třeba hezký dokument RIPE-554, který shrnuje, jakým způsobem požadovat ICT vybavení, pokud chcete poptávat HW pro IPv6.
Nerikam, ze vsechny tyto problemy nejde nejak obejit/vyresit, ale za stavu, kdy o IPv6 projevi zajem jeden zakaznik rocne se to proste nevyplati.
Tak jistě. IPv6 by měl být zájem především ISP. Uživateli je to většinou naprosto ukradené.
Výchozí brána se v IPv6 nastavuje buď ručně, nebo na základě ohlášení směrovačů. Žádná jiná možnost není...
Tohle není vymyšleno příliš šťastně.
Vede to k tomu, že např. nelze nastavit rozdílnou výchozí bránu pro různé klienty v jedné síti. Všichni klienti jsou nastaveni stejně, což omezuje některé scénáře. V IPv6 třeba nelze určité klienty přesměrovat na jednu default gw a určité klienty na jinou, podle aktuální potřeby správce sítě. Přitom tento scénář se u IPv4 v některých situacích používá a nemožnost to samé udělat v IPv6 je pak problém.
Další problém je třeba nemožnost specifikovat globální IPv6 unicast adresu jako výchozí bránu. Opět je to limitace pro některé návrhy a požadavky klientů.
...
:(
Ano, koncepce směrování je navržena tak, aby bránila používání anti-vzorů, jakým je například sdílení stejného spojového (L2) segmentu pro více nezávislých sítí – což je totéž jako nastavovat rozdílnou výchozí bránu pro různé klienty v jedné síti. Není k tomu žádný důvod, zbytečně se tím snižuje bezpečnost, neboť na spojové vrstvě obvykle nedochází k žádné autentizaci.
Je spousta věcí, které se běžně používají a přitom to je anti-vzor. Možná zkuste trošku rozvést, proč byste mohl potřebovat, aby v rámci jednoho segmentu používaly různé stanice různou bránu.
A mimochodem, globální adresu výchozí brány můžete nastavit jenom ručně. Vzhledem k tomu, že brána musí být přímo dostupná na segmentu, stačí (a autokonfigurace tak funguje) použít vždy jen Link-Local adresu.
proč byste mohl potřebovat, aby v rámci jednoho segmentu používaly různé stanice různou bránu
Už jsem psal v předchozím příspěvku - load balancing.
globální adresu výchozí brány můžete nastavit jenom ručně
Mno však ano - právě proto ten předchozí povzdech, že je naprd, že to nejde. Dost zbytečné omezení protokolu.
"Už jsem psal v předchozím příspěvku - load balancing."
Takze dalsi ukazka toho, ze netusis jak IP (nejen v6) funguje ... kdyz bude v siti vic GW se stejnou prioritou, tak se bude provoz rozkladat sam. Pricemz bych vazne chtel videt ten jeden segment s desitkama tisic stroju, aby to melo nejaky smysl.
Viz OC, navic neni problem mit v siti smerovacu vic, kazdej muze mit dokonce svoji prioritu, a kdyz nejaky z nich umre, tak se vse naprosto prirozene a samo posle pres ty ostatni. Narozdil od IPv4 jde je treba resit vsemozne zhuverilosti - napriklad klinetovi odpojit port, aby si poslal novy dhcp req a dostal novou gw.
BTW: Podle MAC si muzu dovolit pridelovat adresy tak maximalne v siti, kde mam vyhradne vlastni HW.
Je mi jasny, ze me ostatni zakaznici prehlasujou. Protoze kdyz doted stacilo najit na domacim routeru spravnou diru na vrazeni kabelu, proc najednou zavadet nejaky "komplikovany" nastavovani. Ja to chapu. Ani DHCP neni nutne problem, pokud ISP dokaze garantovat, ze prefix zustane stejnej. Ale prece jenom staticka konfigurace by ho motivovala urcite vic, aby do toho fakt nehrabal. A ja opravdu nechci adresy, ktery budou sice verejny, ale teoreticky se muzou petkrat denne zmenit.
S tím tvrzením, že "velké servery už běžně nabízejí své služby po IPv6" bych byl trochu opatrný. Best-effort služby určitě ano, ale tam, kde jde o peníze, jsou myslím dobré důvody se IPv6 vyhýbat. Cvičně jsem si otestoval podporu IPv6 u všech našich bank, na které jsem si vzpomněl, a ani jedna nemá pro svou hlavní stránku AAAA záznam v DNS. Předpokládám, že internet banking už tuplem ne. Ono je to celkem logické – po zapnutí by byli okamžitě zavaleni problémy klientů s připojením.
Myslíte, že web banky používají lidé výrazně častěji, než třeba Google nebo Seznam? Že by klient problém s IPv6 nezjistil při pokusu o otevření Googlu nebo Seznamu, ale při přístupu k bankovnímu webu? O tom silně pochybuju. Navíc banka nezískává peníze z toho, že někdo jde na jejich web nebo bankovnictví, ale Seznam nebo Google takhle peníze získávají. Takže v případě banky tam o peníze nejde, v případě Googlu nebo Seznamu ano.
Nesouhlasím. Pokud budu jako klient banky chtít zaplatit fakturu a to se mi nepovede, tak se obrátím na jejich support, který ovšem nemá moc šancí zjistit, co je v síti mého ISP nebo jinde po cestě shnilého. A pokud by se toto mělo opakovat, tak změním banku. Vtip je v tom, zpřístupněním zdrojů přes IPv6 banka nezíská nic, ale velmi pravděpodobně si způsobí potíže, které bude muset řešit.
Kdyz ten ISP podela routovani, tak se jeho zakaznik dostane jen na Google, Seznam a Youtube, protoze to budou jedine routy co jeho technici otestuji. Uz jsem zazil, ze jsem pres IPv6 videl jen pulku internetu a ta druha byla v nejake cerne dire (nevim jestli to bylo routovani, nebo packet filtering). Google chodil, Seznam ne.
A tím se dostáváme ke klasickému problému slepice a vejce. Když to nasadí jen pár zákazníkům, tak nebude mít dost zkušeností a správně nastavené dohledové technologie na to, aby mu to chodilo 100% správně. A těch pár zákazníků vygeneruje jen specifický traffic, takže bude mít odladěný jen ten. A když přijde jiný zákazník a zjistí, že jeho traffic přes IPv6 nejde, tak si vypne IPv6 a ono mu to najednou pojede. Výrazně jednodušší, než řešit s ISP, aby to opravil. No a ISP se o problému nedozví, takže neopraví...
Jak psal někdo výše, hlavní problém IPv6 je nekompatibilita s IPv4. Dokud bude hrát IPv6 druhé housle, tak se staví do role "záložní trasy", ale jak už to se zálohama bývá, většinou se neinvestuje úsilí do ověření, že záloha je funkční (to je sice špatně, ale je to fakt).
Navíc provozovat IPv6 poctivě znamená IPv6 dobře rozumět. Rozhodně natolik aby si mohl ISP udělat audit monitorovacího systému, že sleduje vše potřebné. To ale jaksi vyžaduje aby jeho síťaři byli proškolení. Jednou to na ně přijde, ale vůbec se jim nedivím, že se do toho teď nehrnou.
Slyšel jsem o tom, že banky v zemích, kde se masivně nasazují CGNATy (třeba jako součást DS-lite), mají naopak o zavedení IPv6 velký zájem. Tou hlavní motivací je, že používají nejrůznější fraud prevention systémy, které pracují s IP adresou klienta jako s jedním z klíčových vstupů. No a vlivem CGNATu tenhle vstup přestává být spolehlivý.
Samozřejmě, aby zavedení IPv6 mohlo pomoci, musí platit, že ten kdo je za CGNATem zároveň má IPv6. Nicméně prošel jsem náhodně stránky několika německých bank a také jsem nikde IPv6 nenašel.
Pane Satrapa, tuhle hysterickou propagandu Vaší IPv6-ideologie si laskavě strčte do análního otvoru!
Vážím si Vaších věcných článků, ale tahle propaganda je vážně mimo!
To, že se IPv6 rozšiřuje tak pomalu je zcela jasně důsledek její nedomyšlenosti a špatného designu. O tom byste měl psát!
Vůbec si nemyslím, že je IPv6 nedomyšlené a špatně navržené. Zásadní problém je v tom, že není kompatibilní s IPv4, jenomže jak to měli udělat? Chyba totiž byla hned na začátku v tom, že se pro IPv4 zvolila pevná délka adresy. Jak píše jeden pamětník, proměnná délka adresy byla v r. 1977 navrhována, ale "otec Internetu" Vint Cerf vahou své autority rozhodl o pevné délce.
Ve skutečnosti bychom měli úplně ty samé problémy, jako máme teď, a k nim ještě další, způsobené tou variabilní délkou. Víte, jak by to vypadalo v praxi, kdyby se použil ten váš návrh? Routery by routovaly čtyřbajtové adresy. Konec. Pak by se začalo řešit, že čtyřbajtové adresy docházejí, bude potřeba začít používat i ty 16 bajtové, pomalu by se začaly používat, pak by se to postupně začalo používat na serverech, progresivnější ISP by vám tvrdili „připravujeme“ a méně progresivní „zatím s tím nepočítáme“, a na Rootu byste dne četl článek: „16bajtové adresy: nechtěné dítě (pomalu) přichází“.
4 nebo 16 neni zrovna moc variabilni delka ze? IP vznikalo v dobe, kdy i 8bitovy pocitac mel velikost budovy a predevsim v dobe, kdy 1kB RAM mel cenu nekolika automobilu. Ostatne puvodni navrh nepocital prave z techto duvodu ani s maskou, ale s fixni velikosti siti, kde by se hned podle prvniho B dalo poznat, zda je treba vubec resit ty dalsi.
Uz jen to, ze se prakticky v nezmenene podobe pouziva dodnes svedci o tom, ze navrh byl naopak naprosto dokonaly.
IPv6 ten navrh pouze prejima a zdokonaluje. Zdokonaluje v tom, ze jednoznacne stanovuje, ze router zajima prvnich 64 bitu MAX. A tudiz je snadne jednoznacne nadimenzovat HW tak, aby prave tech 64bitu routoval.
Já bych byl ohledně počítačové historie opatrnější. Vznik sady protokolů TCP/IP se datuje do roku 1973 - tehdejší sálové počítače (třeba IBM/360) už zdaleka neměly velikost budovy a kromě toho existovaly minipočítače, i ve druhé generaci (DEC PDP8, PDP11; HP1000 aj.). IBM byly 32bitové, PDP8 12bitové, PDP11 a HP1000 16bitové.
Mam o ni vazne pochybnosti. Zvlaste pro nasazeni pro GW a routovani. Napr. na Linuxuovych jadrech 3.16 se po nejake dobe behu zacne rozpadat ospfv6 kernel: icmp6_send: no reply to icmp error.. povyseni jadra na 4.3 - vysledek je ze GW do 4h lehne na OOM...
Tolik k pratickemu nasazovani ipv6.
Linux a routing ipv6 no asi tak nějak.Ospfv6 ok běží,že neumí prefix agregation jsem překousl,ale že linux neumí DHCPV6 PD už ne.Mikrotik DHCPV6 celkem ok,prefix agregation rozbité(prý oprava ve verzi 7?),nakonec vyřešeno jinak(jak taky že?lepší než XXX prefixů /56 v routingu).Ubnt u koncáků jedině v mode bridge(a za ním router)jinak nepoužitelné.TP-link router KONEČNĚ
Linux a routing ipv6 no asi tak nějak.Ospfv6 ok běží,že neumí prefix agregation jsem překousl,ale že linux neumí DHCPV6 PD už ne.Mikrotik DHCPV6 celkem ok,prefix agregation rozbité(prý oprava ve verzi 7?),nakonec vyřešeno jinak(jak taky že?lepší než XXX prefixů /56 v routingu).Ubnt u koncáků jedině v mode bridge(a za ním router)jinak nepoužitelné.TP-link router KONEČNĚ už tu 6ku umí.Windows si neumí vzít DNS z RA(proboha proč),naštěstí aspoň z DHPCV6 to funguje,teda fungovalo,po některém update nefunguje.
Ale já 6ku nezatracuji,má nějaké porodní bolesti,ale to snad většina věcí okolo internetu.Sám 6ku používám a mám přes mi 80% provozu.Podle mě,kdyby se začala 6ka nasazovat ve velkém,spoustu firem zabývajících se HW,by ty problémy rychle vyřešila.Takhle je to bohužel "to není priorita,on to nikdo nechce".U ná ipv6 běží,koncák dostane na požádání /56,a když potřebuje tak /48.Bohužel nasadit ipv6 u všech se zatím bojíme(možná zbytečně).
Linux přeci žádné OSPF neumí. (A žádné OSPFv6 neexistuje ;) ). Jde tedy spíše o problémy nějakého konkrétního userspace démona, bylo by fajn, uvést kterého.
Co vím, tak linux má jen problém s výkonností IPv6 stacku, která je znatelně horší, než IPv4, nebo než IPv6 na *BSD. Ale dokud nezpracováváte statisíce spojení za sekundu, asi to není žádný zásadní problém.
281 474 976 710 656 (2 na 48) - počet MAC adries
4 294 967 296 (2 na 32) - počet IPv4
na jednu IPv4 adresu pripadá 65 536 MAC adress - není možná identifikace hardvaru a jeho spárovaní s IPv4 adresou
340 282 366 920 938 000 000 000 000 000 000 000 000 (2 na 128)- počet IPv6
na jednu MAC adresu pripadá (2 na 80) 1 208 925 819 614 630 000 000 000 IPv6 adres!!!!!!!
iným slovami MAC adresa je "vpálená do chipu pri výrobe" vždy keď sa budete chcieť pripojiť do IPv6 internetu
tak sa vám vygeneruje IPv6 adresa tak aby obsahovala váš jedinečný identifikátor MAC adresu
a či si môžete zmeniť MAC adresu? áno môžete si zmeniť MAC adresu - otázne je akú kontrolu máte nad vaším
hardwarom so super 3D UEFI BIOSOM a so super bezpečnými firmwarmi ktoré vyvinuli americké firmy je už vec druhá.
In IPv6 when using address auto-configuration, the Interface Identifier (MAC address) of an interface port is used
to make its public IP address unique, exposing the type of hardware used and providing a unique handle for a user's online
activity.
MAC adresa: 10 14 a4 41 61 5b (2 na 48)
IPv6 adresa: 12ab 34cd 56ef 78ab 90cd 12ef 34ab 56cd (2 na 128)
Ďaľšia vec:
maximálna veľkosť packetu pri IPv4: 65 535 BYTES = cca 65kB
maximálna veľkosť packetu pri IPv6: 4 294 967 295 = cca 4GB
vždy sa ľahšie analyzuje provoz kde paket má max. 65kb ako keď môže mať viac a o dosť viac
Pri IPv6 internete môžete na súkromie už úplne načisto zabudnúť.
A ďaľšia vec. na IETF - ktorá vyvíja štandardy pre tie "internety", tak nie raz ich
tajné služby chytajú pod krk, aby implementovali tak ako im to bude vyhovovať
a keď už raz začne verejnosť+firmy niečo používať ťažko to budete meniť už neskoršie.
takže toľko k tej vašej dementnej IPv6
28-ho 3 2013
https://www.root.cz/clanky/botnet-proskenoval-cely-internet-pouziva-se-jen-tretina-ipv4-adres/
Prečo sa využíva iba cca 1/3 - 1/2 IPv4 adries?????
Prečo majú niektoré americké university viac IP adries ako niektoré štáty na iných kontinentoch????
Prečo sa nevyužité IPv4 nevracajú späť tým, ktorý by ich používali?????? česť britským úradom - ktoré vrátili tisícky IPv4 adries!
Kto vykupuje IPv4 adresy?????
Prečo nie je vybudovaný transparentný trh-burza s IPv4 adresami?????
Prečo niekomu tá IPv4 tak nevyhovuje????
Chodte do ***** s tou IPv6-kou!
IPv6 _muze_ byt nastavena pres SLAAC, nikoliv musi.
SLAAC pouziva /64 a u MAC adresy si prida uprostred FFFE = cela IPv6 adresa.
U SLAAC muzes, a ve vychozim stavu to je i zaple, mit pouzitou Privacy Extension (to resi ten tvuj strach ohledne MAC adres).
U DHCPv6 te zajima DUID, ne MAC adresa.
U statickeho nastaveni IPv6 adresy ses na tom stejne jako u IPv4.
V cem je tedy problem ze kopes kolem sebe jak pominuty?
Nekdy se prestavam divit, ze veci vypadaji, jak vypadaji, kdyz i takovi lide maji volebni pravo :)
Samozrejme je to cele totalni nesmysl, o PE pisatel zrejme nikdy neslysel, zadny zanik soukromi se nekona...A o tom, ze se pouziva jen tretina IPs, to je taky ehm, ono kazdy stroj na IPv4 o sobe verejne roztrubuje, ze tu je a odpovida na prichozi sitove pozadavky (kdo by taky treba resil neco jako firewall, ze :))
A o konspiracnich blabolech, no to snad radsi skoda mluvit...
Jojo, optimalizaci vyuziti IPv4 ke svetlym zirkum! Kdyz s nima budem pekne setrit, to by bylo, aby nam nevydrzely jeste aspon dalsich dvacet let. A co dvacet... tricet, ctyricet! Pravda, uz dneska nekteri rejpalove tvrdi, ze by jich potrebovali desetkrat vic nez jich maji, ale je prece nesmysl. Komu nestaci jedna verejna adresa na vsechno, ten neni sitovej guru. Vsem to sebrat, rozezranym univerzitam nechat maximalne /24, atd. Nakonec proc mit jenom maly cile, kdyz se do toho poradne oprem, vydrzi nam IPv4 rovnou sto let!
Tak u těch univerzit bych prostor k optimalizaci viděl a to docela značný.
Chodím na univerzitu na které je, když to přeženu, 10k studentů a asi 500 zaměstnanců.
Univerzita má přidělený /16 IPv4 rozsah, tj, 65536 adres. Každému zařízení v síti se přiděluje veřejná adresa a následně je domrvená dropováním veškerého inputu na straně routeru, takže nepřináší vůbec nic.
Celkově si myslím, že kdyby univerzita měla rozsah /21, bohatě to vystačí a 63 tisíc adres může jít k novým majitelům, kteří pro to mají 100% lepší využití, než to dávat koncovým zařízením. Když jsem se o tom zmínil u síťařů, považovali mně za blázna, ale jestli takhle funguje každá univerzita, tak se nedivím, že se řeší nedostatek adres.
Což by nejspíš vedlo k dalšímu zvětšení routovacích tabulek, protože pak někdo, kdo bude chtít /21 bude kupovat po uvolněných /24, nebo v horším případě i /26 nebo menších. Dnes mají globální routovací tabulky zhruba 2^19 záznamů. IPv6 může díky dlouhé adrese zajistit geografičtější přidělování IP adres a tedy i o něco jednodušší routování. To jen že vlastní přidělení adres je jen špička celého problému.
To je prece normalni, ze kazdy zarizeni ma svoji verejnou adresu, k tyhle moznosti bysme se prave s IPv6 chteli vratit. :) Jasne, my uz jsme si ted zvykli, ze lze vyzit s malem a uplne kazdy zarizeni svoji verejnou adresu nutne mit nemusi. Mnozi uz si temer ani neumi predstavit, ze by mohla byt sit bez NATu. Ale to neznamena, ze je to rozumna cesta do budoucna.
Realne se zadny prerozdelovani IPv4 adres konat nebude, takze zatimco nekdo ma nasysleno na mnoho let dopredu, jinym nezbyva nez se omezovat a delat ruzny nechteny kompromisy uz ted. Tohle IPv6 resi, protoze prinasi dostatek adres pro kazdyho (ze muze byt ISP idiot a davat zakaznikum jednu /64, to je zase jinej pribeh). A pokud se nekomu fakt hodne moc libi NAT, nikdo mu verejny adresy nenuti, klidne muze nahodit maskaradu i na IPv6 a celou svoji sit opet schovat za jedinou spolecnou verejnou adresu. :)
A co kdyz chci mit neco i bez zprostredkovatele? Proste si jen tak nahodit servrik, kdyz uz budu mit krasne verejnou IPv6 adresu? Tady jsem aktualnim vyvojem ponekud zklaman. Kdyz jsem zacinal s IPv6 a vlastne i IPv4, bylo celkem normalni, ze na verejnou adresu se dalo pripojit odkudkoliv a pripadnej firewall si resilo jedine dany zarizeni a casto ani to ne, proste zadnej nebyl.
Jenze doba se zmenila a ted je pokud vim treba pro domaci routery vychozi blokovani prichozich spojeni doporucena vychozi konfigurace. Coz znamena, ze to tak budou mit vsechny. Osobne je mi to ukradeny, vzdycky si pustim co budu potrebovat. Ale beznej uzivatel ne. Dival jsem se, ze nejaky rozsireni pro IPv6 ma UPnP a pak je jeste PCP (RFC6887), takze teoreticky moznosti asi jsou. Jina otazka ovsem je, jak jsou na tom s podporou aktualne prodavany "krabicky", ktery vydrzi dalsich deset let a zadnej novej firmware uz nikdy neuvidi.
Jenze tohle zdanlive vyssi dobro je ve skutecnosti cesta do pekla. Uz je to vic nez dvacet let co nekomu doslo, ze IPv4 adres bude do budoucna malo. A tak nam vzniklo IPv6, ktery to resi. Z dnesniho pohledu pritom tenkrat bylo IPv4 adres volnych jeste dost. Ale kdyz vime, ze se s tim bude jednou muset neco delat, je lepsi zacit driv, dokud je pripojenych zarizeni relativne malo a nebude s tim tolik prace. A i pokud se to nebude hned naostro nasazovat, tak at o tom aspon vsichni vi, aby uz na to novy veci (hw, sw) mohli pripravit.
A ted si dejme rychlej posun o dvacet let dopredu, tzn. do soucasnosti a pokochejme se, jak pekne ten plan vysel. Kdo mohl, vzal to stylem "ani jedno hnuti prstem navic". Pokud bysme ted prerozdelili IPv4 adresy, tak si pouze podobnych dvacet let dame jeste jednou a na konci nebudeme rozumnymu reseni bliz ani o milimetr.
Jedinou fungujici motivaci k nejaky cinnosti je, kdyz nekdo zacne mit problemy s nedostatkem IPv4 adres. Pomineme mozny externi vlivy, treba ze by se do toho vlozil stat a neco naridil (ucel sveti prostredky, ale tady bych radsi odmitnul). Takze tady z toho pohledu trikrat hura univerzitam, firmam jako HP, IBM, Apple a dalsim kreckum.
V tom případě doporučuji se zamylet, kam se odstěhovat. Protože v rámci EU to začíná smrdět tím, že tohle končí. Běží diskuse o další legislativě, že ISPíky (respektive posktovatele veřejně dostupných služeb) čeká zákaz používání CGN. Čili nenařídí používání IPv6, jak po něm někteří vehementně volají, ale ISPík nesmí CGNatovat, musí dávat koncákům veřejky, pokud nemá dost IPv4 veřejných adres, bude dávat IPv6 only připojení (koncová síť zákazníka má buď IPv4 veřejky, IPv6 globalní adresy nebo IPv4 veřejky plus IPv6 globální adresy). ISP zpřístupní svou databázi zákazníků s informacemi o tom, kdo má co přiděleno státu a stát si v tom může hledat stejně, jak v databázi regitračních značek aut. Tohle má nahradit současnou legislativu o retenci, kterou neustále soudy shazují pod stůl, s tímhle asi vrukují, až si ověří, že by s tím neměl mít problém ani soud ve Štrasburgu...