Podle mě IPv6 v podobě, jaké je, nikdy neměl vzniknout. Právě to, jak vypadá a jak je zbytečně komplikovaný je příčinou pomalého přijetí
Ale to už je teď zbytečné řešit, je to tak daleko, že jiný už nebude a nechci se hádat s uřvanými aktivisty.
Nezbývá než zatnout zuby a s IPv6 bez špetky elegance se potýkat :-(
RFC6177? To je dostatečná komplikace, ne?
Shrnu jen, že nás (ISP) tím nutí klientovi přidělit minimálně /64. Pokud mu nepřidělíme doporučených /56 či dokonce /48, ani on si to nemůže dál routovat aniž by tohle RFC rozbil. Argumenty jsou stupidní, tj autokonfigurace a další kraviny (rozmuměj věci poplatné jedné technologii (Ethernet), případně skupině zájemců (mobilita)).
Pokud RIPE přiděluje /32 a budeme se držet doporučení /48 per klient, zbyde nám na jednu alokaci připojit maximálně 64k klientů a každý si ve firmě vyroutuje jen 64k sítí. Pokud to pro ISP bude málo, přikoupí si u RIPE další alokaci za €, tj získá trapný 1bit. Kde máte sakra ty miliardy slíbených adres?
Spíš v tom vidím politiku ICANN and RIPE keep spinning :(
Jak bych to vyřešil? Pokud tyto už vůbec vydávat takovéto "závazná ulepená doporučení", tak by mělo znít jako zajistěte klientům dostatečnou směrovatelnost dejme tomu /96
Přidělovat každému klientovi /48 je zbytečné plýtvání, tak proč to děláte? Přidělujte automaticky /56, to bude 99% klientům stačit a těch pár klientů kterým to stačit nebude může individuálně dostat víc. Pokud i s takhle rozumnou alokací využijete celý blok /32 tak budete mít od klientů tolik peněz že nebude problém přikoupit od RIPE další adresy - kde je problém?
A použít /64 pro spojení statisticky maximálně desítek a nařídit to normou PC plýtvání není?
Kde je problém? V tom, že přikupuju 1bit, ale návrh háže řečmi dejte /48, pokud nechcete, dejte /56. To je u mne dost disproporce. Pokud někdo chce adresovat hierarchicky, pořadně nemůže, resp se bude cítit jako s 10.x.x.x/8. Což necítíte ani trochu pnutí? Mně se to zdá dost absurdní, neustále mektat o netušených možnostech nového rozsahu a pak skončit u "tady můžete ušetřit, tady přikoupit, blablabla". Já teda problém mám, od nové generace internetu jsem čekal něco jiného.
Viz vejs, racej si laskave o IPv6 neco zjistit ... router se zabyva prvnima 64bity ... a NERESI a resit nemusi, zda nahodou nepotrebuje jeste dalsi cast adresy, prave proto to tak je udelano a prave proto jakykoli delsi subnet nebude na spouste zarizeni fungovat a to tak ze vubec.
Proboha vzdyt to je presne to co rika pan nad vami, toto ma byt na zakaznikovi a na jeho ISP, necht to trh urci co kdo a za kolik koupi. Stacilo by kdyby norma rekla, ze "paterni" BGP pojede na /64 (nebo jeste mene) a urci tak pravidla peeringu velkych hracu, ale nebude omezovat velikost/malost subnetu v jedne "zone". Tam at si to dela kazdy jak uzna za vhodne - co od nej jeho zakaznici chteji. Jestli maji stacit "hloupe" 64 bitove routery, nebo "chytre" 128bitove.
BGP routery mezi sebou vůbec nepotřebují globální adresy nebo giga blok /64, klidně fungují i na link local adresách. Samozřejmě se globální často používají a pak na té spojce mezi dvěma routery je blok /127.
Zákazníci si můžou nasadit co chtějí, ale pokud nasadí něco, co jim nesežeoru páteřní routery a zahodí to, tak mají smolík a ne spojneí se světem. Například doporučení Cisca, že vše, oc má masku delší než /32 máte rovnou zahazovat a neroutovat, protože masky do /32 se routují v hardware a delší masky musí jít přes slabý CPU, tak je raději zahažte. A stále se tím řada subjektů řídí (i na malém IPv6 písečku v Česku) a pokud nepoužívají aspoň jednu nějakou defualt routu, kam by poslali lidi s těmahle prefixy, tak mají dotyční štastní majitelé smůlu, že se se svým do BGP propagovaným PI blokem /48 nespojí k některým místním zdrojům...
1) tím /64 Myslel právě co nejméně routovat, ne spojovací sítě
2) ad routování do /32 v hardware, to je totální nesmysl, přečtě si o tom něco - jak ve switchích je implementovaná TCAM. My routujeme IPV6 na DCRS5750 někdy i Gbps, po /56 a /64 a kdyby to nejelo pomocí TCAM, switch by šel okamžitě do kolen. Cisco 4900M na sw routing například přepne po překročení velikosti TCAM jako celku a přepne celkově, už se nám to stalo, okamžitě se položí mngt a propustnost klesne na desítky mbps.
Ano, je velmi veselé, když se objeví hláška "Some entries will be software switched ". :-)
Jak funguje TCAM vím, taktéž jak je smutný pohled na čítače při dual-ipv4-and-ipv6 templejtu. Že to novější L3 switche umí, neznamená, že se tak chová veškerý, zvláště starší, hardware. Zkráka dle dřívějších představ v globálních tabulkách nebudou pobíhat routy s maskou delší než /32, tak asi starší páteřní routery uměly nativně jen masky do 32 a pokud se náhodou jenda-dvě objevila, tak to šlo přes SW. Pak se to "rozbilo" objevením se /48 PI segmentů, tak se to routery naučily. Jiná věc je, že řada adminů se tak v BGP chová stejně a stále masky nad /32 dropuje, takže z toho pohledu, že já mám svoji pravdu a budu si propagovat co chci, se občas koriguje tím, že pak nemám spojení. takže nezbývá než se přizpůsobit, byž u toho můžu skřípat zubama.
Switche jsou asi různé, vše co jsme zkoušeli my, jelo jak má. pokud někde tvrdím, že zadrátobvat /64 ne nesmysl, pro min prefixy na BGP úrovni na /32 se klidně podepíšu, tam sítě pod velikost minimálního přídělu nemají co dělat. A vidímte že to jde i bez explicitní regulace, prostě většina operátorů to dropuje, nikdo si to nedovolí udělat.
Kolik jsi toho zkonfiguroval, sítí nastavil a RFC přečetl? Nechci tu začínat flamewar, ale pokud někdo nic neví a začíná "laskavě si zjisti" trochu mne to popohání k reakci.
Repleskuju sem txt co jsme psal pod jiný post:
_Totální_ nesmysl. Ano úmysl s dělením prostoru byl již v počátečních fázích návrhu, ale ne kvůli zlevnění routerů, vždy padala jen stateless autokonfigurace. mobilita, bezpečnost atd.Ostatně to ani není možné, RFC připouští i P2P spoje /126 už proto routery musí být stavěny na routování obecné.
SW routery by jak říkáte pracovali až 2x rychlejí, statisticky ale méně při vyhledávání routů v B stromu což většinou dělají.
U HW routerů (L3 switchů) by byla rychlost naprosto stejná, ale je třeba 2xvětší TCAM.
_Všechno_ co jsme zkoušeli zaplaťpánbůh podporuje routování obecně, takže tyhle nesmyslné RFC půjde někdy v budoucnu zrušit. Zkoušeli jsme Linux, Miktorik, Cisco router, Cisco L3 sw (4900M 6500), Edge-Core sw (ES4624, ES4626), DCN sw ( DCRS5750, DCRS5960), H3C sw (5820x). některé switch mají 4x menší hw počet rout v 6 než 4, což potvrzuje teorii o velikosti TCAM
Me prozmenu vzdycky fascinuje, kdyz nekdo vykrikuje o plejtvani adresama a sam si neumi nastavit politiku v pidisiti (a to v CR plati pro naprosto vsechny) kterou provozuje ... V CR existuje nekolik malo subjektu, kterym by nestacil /32 rozsah pri pridelovani /48 zakaznikovi a ani jedinej, kterymu by to nestacilo pri pridelovani /56. Totez plati pro zakazniky, kterych bude nekolik jednotek takovych, kteri potrebuji realne vic nez 250 subnetu. A taci tak jako tak budou mit vlastni PI adresy.
Kdybys ty RFC cet, tak moc dobre vis proc je to rozdeleny prave takle a nevytahujes tu ty nesmysly v kazdy diskusi omilany. Adres je dostatek, jako ISP mas na IPv6 prideleno vic potencielnich subnetu, nez ma cela republika na IPv4 adres ... . ISP kterej mi bude vnucovat ze mi na IPv6 prece staci cokoli mensiho poslu rovnou kam nalezi ... a jeste budu hodne premejslet o tom, jestli si nemam dat du praci a nabonzovat ho, necht mu pridelenej rozsah odeberou, protoze nabourava funcionalitu site. At si klidne vystaci naveky s jednim Cckem na IPv4 a provozuje 150ti urovnovej NAT.
Predpokladam ze provozujes presne 0x BGP s kompletni IPv4 tabulkou ... to bude opravdu nadhera, az v 6tce kvuli podobnym umelcum bude o 3 rady vic zaznamu ,,, protoze proc trebas nevypropagovat /126 ze ... a proc vubec zakaznikum davat nejaky adresy, na 4ce taky zadny nemaji, ti stastnejsi jednu ... na sestce by jim to mohlo staci taky ... a kazdou dalsi za kilo mesicne ... ze ...
Jé to je stupidní reakce
- ja jsem nikde neříkal, že by to nestačilo, je to o pohodlí na straně ISP i klienta, pokud dostane jen /64 a chce routovat musí porušit také. Proto bych radši jako klient bral /96 bez těhle sraček než /64 s. Tenhle přístup ono by "stačilo" - stačilo by i IPv4 a jen více natovat.
- Ještě jednou: Chci straaašně plýtvat s adresami na své straně hierarchickým routováním velkého procenta adres nikam, ale jednoduchou sítí s prázdnými tabuklami, je to užitečnější než je nechat smrdět v práaaaazdnotě lokální sítě. Pro obě strany.
- Pouč mne tedy proč je to na /64 rozdělený a zároveň tu nezaznělo/nekomentoval jsem prosím.
- Kdyby norma neplatila, neposílal bys mne s /96 k šípku. Neměl bys EUI64, ale mě bys třeba 16m svojich sítí :) Pokud bys mne poslal, věř mi, že bychom stále pěkně prosperovali :)
- Klidně mne nabonzuj, už jsem zval k úřadům/soudu několik horkých hlav ... a pořád nic :) Tady ale nemáš za co, jak jsem psal, podřídili jsme se :(
- Ad BGP máme NIX+SIX+DE-CIX+AMS-IX+tranzit od GTS, není to FULL, ale máme asi 200k routes.
" V CR existuje nekolik malo subjektu, kterym by nestacil /32 rozsah pri pridelovani /48 zakaznikovi a ani jedinej, kterymu by to nestacilo pri pridelovani /56. Totez plati pro zakazniky, kterych bude nekolik jednotek takovych, kteri potrebuji realne vic nez 250 subnetu. A taci tak jako tak budou mit vlastni PI adresy."
Ja mel dojem ze nasazovanim IPv6 resime neco na destiky let do budoucna, tudiz stavajici stav neni uplne smeroplatny. Pokud skutecne prijde IOT nebo neco podobneho, tak se potreba adrese zvysi radove
Bavime se o tom, ze vyse zmineny tu vyklada, jak prave jemu nestaci /32 prave ted. A opravdu nemam pocit, ze by CR v prisich 100 letech mela vice nez 16 milionu domacnosti a firem potrebujicich net ... coz je pocet /56 subnetu v jedny /32 siti (a takovych siti ma CR prideleno uz nekolik desitek).
> Pokud RIPE přiděluje /32 a budeme se držet doporučení /48 per klient
Dej mu /56. Pak můžeš mít 16 M klientů.
> a každý si ve firmě vyroutuje jen 64k sítí
A to je málo? Firma, které nestačí 256 sítí, už je asi opravdu velká, a ISP takových velikých firem zase nebude mít 64 k. Srovnej s IPv4 :-)
Ale jo, souhlasím, že tohle je blbě.
Pokud RIPE přiděluje /32 a budeme se držet doporučení /48 per klient, zbyde nám na jednu alokaci připojit maximálně 64k klientů…
RIPE NCC nyní přiděluje /29, pokud máte /32, můžete požádat okamžitě o rozšíření své alokace na /29. Pokud se přiblížíte k 80% obsazení svého alokovaného prostoru, není problém získat další alokaci. Adres je opravdu dostatek.
…a každý si ve firmě vyroutuje jen 64k sítí.
To vám připadá málo? 64k podsítí bude odhadem stačit tak 90 % všech firem. Pokud budete mít to štěstí a připojíte tak velkou firmu, že s tím bude mít problém, nebude mít RIPE NCC žádný problém pokud jí přiřadíte /47 nebo ještě kratší prefix. Jen budou nejspíš zvědaví, na co nějaký zákazník potřebuje tolik adres.
Pokud to pro ISP bude málo, přikoupí si u RIPE další alokaci za €, tj získá trapný 1bit. Kde máte sakra ty miliardy slíbených adres?
RIPE NCC přiděluje členům alokace zdarma. Už od roku 2013 navíc platí plochý model, kdy všichni členové platí stejnou částku, bez ohledu na velikost. Poplatkům podléhají pouze nezávislé prostředky (provider independent adresy a čísla autonomních systémů), tam jde ale o regulační funkci, protože je pro Internet dobré, aby se takových prostředků užívalo co nejméně.
Pokud RIPE přiděluje /29 (když jsme alokovali přidělovali standardně /32)a odečtu limitované rozsahy, jsme zase někde na 16M alokacích pro celý svět. To mi do budoucna docela smrdí. My třeba máme AS v rámci z.s.p.o a každý člen má jednu /40. Jak mám vědět kolik bude členů? proto jsme nechali 8bitů a lupho: už máte 256x míň, prostě _je_ to problém technické volnosti na straně ISP i uživatele.
64k sítí mi připadá vážně málo. Opět, proč by univerzita nemohla dát 8bitů adresy dát jako číslo budovy a dalších jako třeba číslo místnosti? A už je tam jen 256 objektů. Ano vím co napíšete: dynamické routování, můžete přece hemto či tamto, blablabla, ale to není obecný argument. Je to prostě nesmyslný zásah do místních kompetencí.
Zdarma? to je ale dočasné že? nám se to v r 2009 a 2010 započítávalo do vzorce a byli jsme "medium", tohle je jen "investiční pobídka". O prachy ale ve finále nejde, jde o to, že přikupujete po pár bitech
Svoboda jednoho končí tam kde začíná svoboda druhého, takže určité zásahy do místních kompetencí nejsou nesmyslné ale naopak nutné. Prostě není možné nechat každého aby svým nehospodárným využíváním sdílených zdrojů (adresního prostoru) omezoval ostatní. Není žádný technický důvod k tomu aby v budově univerzity měla každá místnost svůj rozsah /64. Všimnul jste si že v IPv6 se už pro NDP přestaly používat broadcasty, na rozdíl od ARP u IPv4? Svět se hýbe od routování (L3) ke switchování (L2) a tím je nutnost oddělených síťových segmentů dramaticky zredukována, takže pokud budete od RIPE chtít víc adres tak si musíte najít jiné zdůvodnění.
To je samé, svět se hýbe tam či onam teď se dělá spíše L2 než L3 bla bla bla, tak hned zareagujeme tak a atd. Žvásty. Návrhy tohoto typu jsou tu na 100 let. Proto by měli řešit jen minimum nutné ke kooperaci, a ne betonovat aktuální zvyky nebo technologie a znepříjemňovat život. Nebo snad na minimu /64 per síť vidítě kromě EUI64 nějakou výhodu?
> To je samé, svět se hýbe tam či onam teď se dělá spíše L2 než L3 bla bla bla, tak hned zareagujeme tak a atd. Žvásty. Návrhy tohoto typu jsou tu na 100 let. Proto by měli řešit jen minimum nutné ke kooperaci, a ne betonovat aktuální zvyky nebo technologie a znepříjemňovat život.
V tomhle ale právě tkví jádro pudla. Vámi popisované "problémy" IPv6 vycházejí čistě ze snahy nějak na něj mermomocí napasovat zažité zvyky ze světa IPv4. Ano, Vámi zmiňovaná univerzita doposud chtěla mít jednu /16 na budovu a jednu /24 na místnost, protože ve světě v4 jim nezbýval jiný rozumně efektivní způsob, jak rychle dohledat určité zařízení. Tedy když vidím, že 10.4.113.2 vesele sype do světa 1Gbps porna skrz CESNETí trubku, jdu do budovy, najdu místnost 113 a vynadám tomu, kdo tam sedí. Samozřejmě za předpokladu, že si ve Woknech během půl minuty nenaklikal IP z jiné /24ky (a já nemám v síti 802.1x).
Ve světě v6 můžu na tohle docela klidně zapomenout a dát celou skupinu/ústav/patro/budovu (dle toho, jak velký jsem tvrďák) do jedné /64ky a věci se tím jenom zjednoduší. Vidím spamující IP, okamžitě mám (s EUI64) MAC adresu zařízení a s ní i (nemám-li celou síť postavenou na pětiportových Edimaxech) během pár sekund konkrétní port na konkrétním switchi, přes který to teče.
Tisíc adres v jedné síti (budova v /64ce) pohodlně uswitchuje i ten nejlacinější switch, který stejně mám už proto, abych měl kam ty kabely nastrkat. Přesvědčit ho, aby nešířil Ethernet broadcasty po celé škole taky nedá moc práce. Pokud ho navíc přinutím, aby zahazoval vše, co leze dovnitř portem s jinou MAC, než odpovídá EUI64 v6, mám i slušnou ochranu proti studentům hrajícím si s konfigurací. (Takhle hezky to samozřejmě funguje jen v čistě v6 prostředí.)
Pokud bych náhodou místo univerzity provozoval ISP, kde stejně zákazníkovi předávám Ethernet za APčkem, které spravuji sám, a přišlo by mi /64 na zákazníka jako šílené plýtvání (protože konkurence vyhynula, rádiové spektrum se totálně vyprázdnilo a já mám najednou v jednom okrese dvacet tisíc klientů), nic mi nebrání dát jednu /64ku na jeden panelák a dál to neřešit. Zákazníkovi je putna, jestli je opravdu na fyzicky izolované L2 síti, nebo jenom ve VLANu. Popravdě řečeno, většině zákazníků je putna, i když nejsou izolováni vůbec. Pokud jim doteď nevadí, že je celé město za jedním NATem, nějaké VLANy je asi neberou.
Ad 1) Ano v tomhle tkví jádro pudla. Já Vaše argumenty znám i chápu, ale závěr máme jiný. Já říkám nechte na nás jestli budeme kopírovat zvyky z IPv4 nebo se podřídíme novým metodám. Jak víte, že nemáme třeba ARCnet a tudíž jde pro nás o čirou komplikaci? Jak víte, že to za 10 let nebude jinak? Pak zrušíme nepohodlný standard? Není lepší ho vůbec nezavádět, když není nutný a některé sere už ted?
Ad 2) Ano, ale pokud by nebyly nesmylsné nařízení, nemusím :) Proč to nenecháte na nás.
Ad 3+4) Vidíte, my jsme si před 8 lety řekli, že chceme síť stavět stylem "co nejméňe krámů do chalupy", ale přirozenou robustností. Nepotřebujeme firewally, kontroly EUI64 vs MAC, ani 802.1x. Naopak máme VLAN per klient na FTTx a přímý routing na SU klienta u FWA, všude L3 oddělení+vyroutování /28 v IPv4+DHCP. Na naše FWA přípojky kromě DOS nelze útočit z principu vůbec. Na naše FTTx lze teoreticky útočit věcmi jako FDB a i to sundá jen lokální access switch pro pár klientů. Všechny konfigurace máme generované systémem. Stačilo by nám vygenerovat to samé pro IPv6 a pustit. Klient ani nemusí měnit domácí routery, stačí když ji je přepne na bridge, pokud to tak nemá. Bohužel, při splnění /64 nám zbývají stejně mohutné celky jako při použití 10.x.x.x a proto zatím váháme to udělat plošně.
Kdyby za jednim NATem ... nekolikrat sem narazil na "ISP" ... ktery zcela "standardne" pridelili ovecce jednu ... privatni ... adresu. A pokud mela ovecka krom pocitace jeste neco, tak si to muselna znatovat jeste jednou. Coz samo vedlo k tomu, ze to co funguje za natem blbe nefungovalo vubec.
Co si pamatuji, tak kolem toho EUI64 bylo před lety hodně hádání a navrhovalo se použití EUI48, ať je maska /96. Jak to dopadlo víme. Jeden z argumentů byl, že ať je tam rezerva a nemusí se to za 100 let předělávat, až EUI48 nebude dle tehdejších odhadu v roce 2100 stačit.
Už dneska některé technologie používájí 64 bit L2 adresy, takže v případě IPv6 by pro ně stejně musel být i standard s /64 vedle /96 po autokonfiguraci ve stylu, jak je zavedena, tka už to nechali na tom /64 pro všechny (někdy se i ty bity hodí pro private extension a podobné)..
S tou maskou /64 áž nehnu, na tom se můžu vztekat jak chci. sice i s jednou /64 můžu routovat na X dalších sítí, ale to by znamenalo, že pak připojuji jen zařízení, co umí udělat konfiguraci IPčka pomocí stavového DHCPv6 nebo ručně, což umí minimum věci, když povinná znalost je jen SLAA, tak většina krámů umí jen tu.
Pokud RIPE přiděluje /29 (když jsme alokovali přidělovali standardně /32)a odečtu limitované rozsahy, jsme zase někde na 16M alokacích pro celý svět. To mi do budoucna docela smrdí.
V současné době RIPE NCC přiděluje z bloku 2a00:0000::/12. Ten vystačí na 128k alokací. RIPE NCC má v současné době 10000 členů, přičemž většina si vystačí s jednou alokací na vždy. Stále zůstává nepoužito pět osmin celého prostoru (nějakým způsobem použity jsou jen rozsahy 2000::/3, ::/3 a e000::/3) Zkrátka adres je dost a budou. :)
My třeba máme AS v rámci z.s.p.o a každý člen má jednu /40. Jak mám vědět kolik bude členů? proto jsme nechali 8bitů a lupho: už máte 256x míň, prostě _je_ to problém technické volnosti na straně ISP i uživatele.
To je zajímavé, že v předchozím příspěvku vám vadila přílišná velkorysost v 64bitovém suffixu pro každou podsít, ale tady se chováte úplně stejně velkoryse.
Kolik máte členů teď a v jaké relaci je k to k číslu šestnáct? Víc než jednu číslici bych na identifikaci člena nepoužil, pokud se v budoucnu členská základna rozroste, je jednoduší ji uspokojit z nového přídělu (za předpokladu, že stávající příděl je rozumně zaplněný). Také je dobré levé části adresy číslovat zleva (jako 00, 80, 40, C0, 20, A0, atd.), aby byl dostatečný prostor k pozdějším úpravám. Asi nikdo nedokáže naplánovat adresy napoprvé a navždy správně :)
Zdarma? to je ale dočasné že?
O tom rozhoduje valná hromada RIPE NCC, které jste členem. Hlasujete? Už od roku 2012 je tam silná tendence k plochému modelu placení.
O prachy ale ve finále nejde, jde o to, že přikupujete po pár bitech
Ve finále jde o to, že nic nepřikupujete, ale zdarma dostanete tolik, kolik budete potřebovat. Takový socialismus v praxi :)
Ano, v současné době stačí alokace pro 100tis členů, pak se dá to a to a opět nepodstatné blablabla. Holt jsem asi fantasta, když jsem očekával, že IPv6 smrskne RIRy na "dvě úřednice", které jednou za život ISP přiřadí prefix. Že ISP si najde svoji politiku přidělování adres, pokud bude dávat málo, vyřeší to konkurence trhem atd.
Ad velkorysost, hoooooodně mícháte hrušky s jabkama. Samozřejmě, že vzhledem v mé vlastní síti chci být velkorysý! A na úkor klienta! Chytrý klient totiž pochopí, že EUI64 značně omezuje i jeho. Ale je to _naše_ rozhodnutí, náš obchodně technický model atd. Od standardizátora čekám maximum volnosti a technologické neutrality, což se neděje.
Ne, přiznávám se, že na VH nehlasujeme, možná proto, že bych tám rád viděl ty dvě holky :)
Ad příděly zdarma: Je to úplně jedno, dostávám takové příděly, že se adresní prostor zvyšuje o jednotky bitů, ale zahazuji žekněme 32 bitů kvůli nesmyslnému standardu.
Vtip je v tom, že vy vidíte očima Vodafone, na všechno jsou lidi: Ten na ježdění na RIPE, ten na dynamický routing a alokace, ten na to a to a vše je řešitelné nic není ve finále problém.
EU, vláda a ČTÚ, neustále (logicky) volá po konkurenci, a logicky lokální konkurent, bývá ve vlastní výstavbě ten nejefektivnější. Představte si ale firmu tohole typu:
malé s.r.o: zakabeluje sídliště, stane se za pakatel členem RIPE, nakoupí rozumně okruhy a konektivitu, pomocí L3 switche+party L2 switchů s VLAN rozvede do bytů a chce poskytovat. V dnešním modelu prakticky nemožné, musí řešit sračky tohole typu, kvůli byrokracii jsou vstupy drahé. Pokud by byly triviální normy, tento model by mohl být možný, byly by stovky tisíc AS, vadilo by to někomu?
Už mi rozumíte?
Cece prober se ... ukaz mi, kolik ceskych provideru ma k dizpozici na IPv4 tzv "Bcko" (=/16) ... to je presne to, co mas ty, pokud mas /32 a pridelujes /48.
Kupodivu MAC ma taky 48bitu a nikdo se stebou nebavi o tom proc a nac. Pritom na LANce jen vyjimecne bejva vic nez pas stovek zarizeni ... takze by stacilo vyrazne min ...
Jeko nevim o cem tu vubec porad vykladas. Az prijdes s tim, ze mas mililon zarizeni v siti ... a ze mas nejakej problem, tak se ma smysl o necem bavit ... kolik zarizeni v ty siti mas ted? Tisicovku?
Zajimavy je, ze prave ti vsemozni pidi lokalni ISP zadny problem s IPv6 nemaji, proste to jednou nahodi a funguje... vetsinou totiz ani neresi zadny automatismy, protoze tem par stovkam/tisicovkam lidi to proste prideli rucne.
Naopak, musi resit sracky typu NAT na IPv4, protoze tyhle adresy mu jaksi uz nikdo neprideli ... kupovat se mu je nechce ... a bez toho se porad jeste neda fungovat.
Macka ma 48 bitu, protoze nikdo nechece resit reklamace typu "tyto dve sitovky nesmi byt na stejne siti", pak tech 48 neni zase az tak moc. Obzvlast, kdyz se prideluji jako 24bitu vyrobce + 24bitu id zarizeni od toho vyrobce. Pred ethernetem bylo nekolik pokusu (treba ARCnet), kde IDcko nebylo prednastaveno od vyrobce, a zjevne se to neujalo. Dnes by si zarizeni v ramci "autokonfigurace" dovedly vymyslet / nechat pridelit adresu i bez unikatniho identifikatoru, ale v dobe zacatku ethernetu byly veci typu DHCP zbytecne slozite a IP zdaleka nebyl jediny protokol provozovany nad ethernetem.
No a pointa (na kterou jsem malem zapomel) je v tom, ze argumentovat sirkou MACky by melo byt pro IPv6 nerelevanti (pokud by nekdo nezamontoval do navrhu, ze poslednich 48 bitu bude macka, ale co kdyz si to bude chtit domacnost jeste nejak routovat, takze kazde domacnosti dame na tech deset domacich zarizeni 64 bitu).
Chlape prober se ty, prostě nad 10k klietů je s _pohodlnou_ adresací reálný problém, pokud nejedu přes MPLS tunely per klient z jednoho poolu. Ale to stejně potřebuju (hierarchické?) Ipv4 a jsem zase na začátku.
1) neříkám že to nejde, jen že už vůbec nechci řešit bity na straně ISP, bohužel kvůli stupidnímu návrhu bez technické neutrality, poplatnému jedné technologii a určitým zamýšleným aplikacím musím.
2) kolik bitů má MAC s tím _vůbec_ nesouvisí, je to lokální věc na tvé síti. Mohu si vymyslet formát rámce kde místo MAC bude 1000bajtů digitální podpis stanice a od L3 to bude abstrahovat. Naopak na úrovni adresy v lokální síti je celosvětová unikátnost totálně nepotřebná kapišto?
3) Je jedno, jestli mám v síti 100k zařízení nebo milion. problém s pohodlnou adresací je už od 10k. Věř mi ale, že jsme počtem přípojek ISP v ČR do pátého místa takže se cítím oprávně minimálně mluvit tady
4) Já neříkám, že mám s IPv6 problém, jedou nám tací klienti jako magistrát krajského města a podobně. Přemýšleli jsme, jestli RFC porušit, nakonec jsme si to nelajzli, ale máme z toho pachuť v puse takové to, když někdo slíbí zlaté prase a je z toho ohlodaná kost,
5) Škoda, že se někdy nemohu sejít s lidmi jako ty _fakt_ bych se rád pokusil pochopit takový ten hujerský přístup dá se řešit..., kde máte problém... Soudný člověk podle mne prostě musí mít pachuť v ústech - stejný názor má alespoň cca 20 lidí kolem mne,
Cece co to porad vypravis, 10k klientu a nestaci ti na ne 65k prefixu? lol ...
IPv6 je zcela techniky neutralni Ty jako ISP mas k dizici hornich 64bitu. Spodnich 64bitu te naprosto nezajima a nemas se do toho co hrabat. TECKA.
MAC stim souvisi presne stejne - tedy jak pises vubec nijak ... ale je to PRESNE stejne plytvani ... proste proto, ze tolik zarizeni na jedny fyzicky siti NIKDY nebude.
Ze je nekdo neschopny a ma potrebu si do technickyho identifikatoru coz je adresa, psat povidani ... je ciste a vyhradne jeho blbost ... chudaci spravci budov kde maj vic nez 250 mistnosti ... ti musi byt radne vprdeli kdyz musej pridelit IPcko na 4ce .1024. Vazne netusim k cemu by mi bylo dobry si pamatovat kterou adresu kdo pouziva. To je pro me naprosto nezajimavy a to i v siti, kde jsou stovky subnetu. Komu co patri totiz zjistim lusknutim prstu pohledem do databaze.
Jo, takovej magistrat urcite potrebuje aspon tisic subnetu ... tohle vypravej detem jako vecernicka ... by me zajimalo jak to chudaci delaj stema 8mi ... mozna 16ti adresama co maj na IPv4....
Díky právě těmto "zlepšujícím RFC" je ta neutralita trochu omezená, napadá mne příměr voleb na ukrajině.
MAC není plýtvání, jde o to minimalizovat ppost kolize, těch 6 byte je podle mne optimum. Ale hlavně je to "jen" standard z dílny 802.x, tedy jednoho výrobce jedné technologie. Nikdo ho netlačí do světa v podobě závazku pro celosvětovou síť, jen se jich prostě hodně prodává, tak to bereme jako samozřejmost. Chápeš ten rozdíl?
Magistrát má 1/2C a /56 (takže jen dvojnásobek) Ale pro všechny zřizované organizace jim to stačí.
Obávám se, že nerozumím.
Holt jsem asi fantasta, když jsem očekával, že IPv6 smrskne RIRy na "dvě úřednice", které jednou za život ISP přiřadí prefix.
Ale ono to tak přesně je. Drtivá většina práce, kterou RIPE NCC odvádí, se týká IPv4. IPv6 prefix jednou přidělí a od té doby o daném LIRovi nevědí. Práce kolem IPv4 také časem ustane, protože v momentě, kdy došlo na burzu IPv4 adres, už není potřeba, aby NCC detailně zkoumalo oprávněnost přidělení adres. Dá se předpokládat, že když je někdo ochoten za adresy zaplatit, asi je opravdu potřebuje.
Jinak to RFC 6177, co vám tak leží v žaludku, je pouze popis nejlepší současné praxe, žádný závazný předpis. Když dojdete k závěru, že si to sám navrhnete lépe, klidně to tak udělejte. Já osobně to vnímám tak, že IPv6 adresa je 64bitová, těchto 64 bitů je potřeba hospodárně a optimálně přidělit. K ní se pak přilepí dalších 64 bitů jen proto, aby se prostor dostatečně zředil a nedalo se tak snadno skenovat celý dostupný prostor.
Ne, přiznávám se, že na VH nehlasujeme, možná proto, že bych tám rád viděl ty dvě holky :)
No vidíte, a přitom je možné se plnohodnotně účastnit on-line, a každý člen, ať je to Deutsche Telecom nebo poslední vesnický LIR má právě jeden hlas. Bohužel, je to stejné, jako ve většině zájmových sdružení − 80 % vůbec nejeví zájem účastnit se společného rozhodování a zbývajících 20 % pak určuje pravidla, která se všem nemusí líbit. A mimochodem, dívek a dam je na setkání RIPE několik desítek.
Pokud by byly triviální normy, tento model by mohl být možný, byly by stovky tisíc AS, vadilo by to někomu?
Nejspíš by to vadilo všem BGP routerům. A asi máme jiné představy o tom, co je triviální norma. Pro mě je triviální právě to, že je jasně dáno, že koncová síť má mít /64, zákazník /48 nebo /56, takže nejste nucen ke zbytečné kreativitě.
Ale pokud opravdu zvládnete vyběhat ty miliony razítek, abyste mohl rozkopat chodníky, a domluvit s desítkami družstev a společenství vlastníků, že jim rozvrtáte domy, pak vás přece nějaká norma ohledně počtu bitů nemůže zastavit. Zvlášť když přídělů dostanete kolik budete potřebovat a zadarmo. Myslím si, že v porovnání s místní samosprávou musí být jednání s RIPE NCC procházkou růžovou zahradou.
Ad "Ale ono to tak přesně je. Drtivá většina práce, kterou RIPE NCC odvádí, se týká IPv4": To je jen tím, že IPv6 ještě nežije, s takto blbě nastavenými parametry bude té práce podobně, neustálé doalokace, stoupající počet rout atd :)
Ad Jinak to RFC 6177, co vám tak leží v žaludku: Tady je mojí chybou, že si ta ćísla RFC zamozřejmě nepamatuju a už jsem línej Googlit. Jsou i jiná RFC kde je vysloveně *must* /64 OR /127 PtP tuším. Dále jsou na to navázané RFC týkající se mobility a kromě stateless configu asi ještě nějaký další balast.
Ad VH: tady máte pravdu na 100%. Povídání zde mně de facto jen baví a trochu se odreaguju. I když zajímavé myšlenky jsem slyšel, např od Vás. Na to to začít reálně řesit, tj objíždět RIPE a další místa vlivu+psát RFC+plameně o tom přednášet jsem línej, nemám čas a asi ani schopnosti.
Ad BGP: Vím, to měl být spíš modelový případ tento vývoj asi nikdo nepředpokládádá. Trivialita v mém podání je absence této a další normy která není esenciální. Pokud už povyšovat doporučení na normy, tak technicky neutrálně, např. Každá pŕípojka musí umožnit připojení minimálně 1000000 zařízení
Asi je vám jasné, že nás tato norma nezastaví, a co navíc rozhodli jsme se ji respektovat :) Ale nadávat nepřestaneme to slibuju!
Boze to sou zase placy...
Ukaz mi kolik ISP ma vic nez 65 TISIC klientu ... v CR mozna 5... Navic, kdybys mel aktualni predstavu, doporuceni je /48 NEBO /56. Pro ISP je pak radove jednodussi pridelit zakaznikovi prefix ... nez mu co 14 dnu pridelovat nejaky dalsi adresy ... protoze si zrovna vzpomel ze potrebuje.
RIPE zcela samozrejme prideluje i vetsi rozsahy nez /32 ... jen si to jaksi musis umet nejak rozumne zdovodnit. Kdyz tam prijdes a reknes ze mas milion zakazniku, tak ti jiste prideli vic.
Nemluve o tom, ze stim, ze polovina (64bit) adresy bude idetifikovat sit a zbytek jednotliva zarizeni se jaksi pocitalo odjakziva (opet ... odkaziva = od roku 1995). A to prave a jen proto, aby ... ROUTERY meli FIXNI delku adresy, kterou se museji zabyvat (tedy prave a jen tech 64 bitu). Ono se stim jaksi pracuje nasobne rychleji, ze ...
Stenej Bullshit, jako u podobných postů. Chceme mít hierarchický adresování, máme klienty odroutované na posledním skoku nebo v separátní VLAN. Je to prostě náš systém, vyhovuje, je perfektně robustní a nevím proč bychom ho měli měnit. Při minulé diskusi jsem byl kvůli tomu nějaký "profíkem" dokonce nazván garážovým ISP, což teď ale nevadí, protože technická neutralita by měla garantovat i potřeby garážových ISP :)
Pro každý takový sektor rezervujeme agregujeme prostor pro 64 klientů, abychom měli systém. Samozřejmě tím prostor není naplněn. Těšíli jsme se na rozšíření adresovacího prostoru a více pohodlí, místo toho někdo vymyslel nesmyslný standard, bez technické neutrality a nás to štve to je vše nic víc, nic mín
RIPE přiděluje větší prefixy, ale pomůžu si tím o pár bitů, je to nesystémové a vidím v tom politiku, už jsem to tu dnes psal.
Poslední odstavec je _totální_ nesmysl. Ano úmysl s dělením prostoru byl již v počátečních fázích návrhu, ale ne kvůli zlevnění routerů, vždy padala jen stateless autokonfigurace. mobilita, bezpečnost atd.Ostatně to ani není možné, RFC připouští i P2P spoje /126 už proto routery musí být stavěny na routování obecné.
SW routery by jak říkáte pracovali až 2x rychlejí, statisticky ale méně při vyhledávání routů v B stromu což většinou dělají.
U HW routerů (L3 switchů) by byla rychlost naprosto stejná, ale je třeba 2xvětší TCAM.
_Všechno_ co jsme zkoušeli zaplaťpánbůh podporuje routování obecně, takže tyhle nesmyslné RFC půjde někdy v budoucnu zrušit. Zkoušeli jsme Linux, Miktorik, Cisco router, Cisco L3 sw (4900M 6500), Edge-Core sw (ES4624, ES4626), DCN sw ( DCRS5750, DCRS5960), H3C sw (5820x). některé switch mají 4x menší hw počet rout v 6 než 4, což potvrzuje teorii o velikosti TCAM
Jsem nějakej rozjetej, jinak bych se neopakoval, takže:
naše z.s.p.o. má /32, z toho naše firma /40 dále dělíme na jakési lokality /48, dále na sektory /56 v sektoru jsou klienti /63 (umožní klientovi delegovat prefix nebo přes switch přímo připojit zařízení). Tohle nám velmi zjednodušuje adresaci, zmenšuje tabulky atd. Bohužel díky tomu, že jsme členem z.s.p.o, nemůžeme dávat ani /56 (zjednodušuju).
Proč bychom nemohli být členem nějakého ambiciózního z.s.p.o a dále prostor dělit? IPv6 má přece úžasné možnosti adresace ne :)
Ano Já nemám dost Ipv6!
Nechci větší alokaci /29 místo /32 pro naše sdružení. Nechci řešit, že sdružení má jen pár členů a že si vezmu tedy /33 místo .
Co opravdu chci je Sebrat klientovi řekněme 4 byte :) Ale neudělám to, budeme škudlit bity u sebe a jen se z toho vypíšu na Rootu a nechám se zmasírovat jak to máme blbě tak jen do mne :)
Tvuj router nezvladne 64kB zaznamu? To teda nic moc podle toho jak ses prsil sem ocekaval HW nejmin za miliardu ...
Krasne tu ukazujes jak si neumis nastavit rozdeleni site .. moc fajn ... mas 10x vic subnetu nez klientu .. chmm hezky ... to musej klienti skatkat radosti kdyz potrebujou dalsi subnet pro wifi trebas ... tvle ... zbouchat 65 tisic subnetu na poznamkovej blok ... jestli to takhle zacne delat trebas kyslik ... tak jim ani /3 nebude stacit.
Chlape ty to furt nechápeš
Samozřejmě naše síť má mnohem více subnetů než klientů. Subnety jsou vysměrovány po 64 na každý koncový bod, i když tam jsou třeba jen 3 klienti, zbytek je unreachble. Instalace nového se udělá jen lokálně na posledním bodě. Po páteři se routuje jen při výstavbě nové infrastruktury. Tyhle routes se několikrát agregují, takže po cestě i na hlavních core je třeba jen 30 routes.
Proč bych to tak doprdele nemohl mít? nebo to jen stále nechápeš?
To samé chci aby si mohl udělat i klient, ale pokud mu někdo zabetonuje mnoho možných hierarchií do trapných 256 routes nebo nemožnosti dále routovat při /64, je to škoda
Nekrmte trolla, nemá to cenu.
Kéž by takhle hierarchicky k adresování IPv6 přistupovali všichni. Bohužel, většina sítí hierarchii vůbec neřeší, když mají 2000 zákazníků, mají někde v jádru 2000 rout. A ještě třeba namítají, proč to řešit, když jejich router bez problému zvládne desetisíce rout.
Ano, souhlasím, že v IPv6 vám může být těsno. Jako odstrašující příklad bych demonstroval jednoho VPS providera, který se holedbá tím, že na jednu VPSku přiřazuje /64 a po domluvě není problém víc. Když jsem chtěl víc, zjistilo se, že to vlastně problém je, protože celý svůj příděl /48 routují jako jediný segment. Zrovna v případě VPS nedává přidělování /64 vůbec žádný smysl. Na to, aby z toho člověk udělal tunnel brokera je to málo, na to aby VPSka mohla mít více personalit bohatě stačí třeba /112.
Stejně tak je obvykle těsno malým ISP, kteří nejsou LIR a jejich upstream provider jim nabídne jednu /48. Z toho pak /56 na zákazníka dosáhnete velmi těžko.
jj caletka, potrebujem Ipcko aspon 100MB dlouhy ... aby si kazdej moh pridat svych par MB a delat sit jako stromecek ... jenze mr caletka, takhle IP sit NIKDY nefungovala a NIKDY fungovat nebude. Nastesti ... prototoze ty kteri nemaji slepicky mozky davno prisli na to, ze takova sit je neprovozovatelna z mnoha ruznych duvodu.
Vazne chci videt, jak se vam ta uzasna struktura bude chovat v okamziku, kdy nekdo z bodu A bude chtit komunikovat do bodu B v jiny casti site ... a bude treba tam udelat pricku ... aha ... ono to pak stejne nepujde agregovat ... chmm ...
Jen jeste dodatek pro ty, co zvladaji matematiku na urovni 1. tridy ZS... pojdme si postavit realnej stromecek ...
Mejme takovy "prumerny" panelak (ale ono je to celkem jedno) ... 8 podlazi, 5 vchodu 3 byty => 120 bytovych jednotek, 120 potencielnich zakazniku (+ mozna nejaky kramek ve sklepe).
Rekneme, ze budu pridelovat /56 a rekneme ze sem tak uber, ze zasituju uplne vsechny. At nezeru s bohatou rezervou pridelim tomu baraku /46.
Predpokladejme, ze sidliste ma takovych baraku 60 ... (to je pro zajimavost cca 20 000 obyvatel - tedy +-polovina okresniho mesta) a protoze sem stedry, tak sidlisti pridelim 128 x /46 => /39 ... mno porad mi z /32 zbejva 7 bitu ... tedy dalsich 128 sidlist ... coz je asi tak 1/4 cely CR s jednim /32 rozsahem (a nikde sem nesetril)
Pojdme se podivat na routovani ... rekneme ze kazdy zakaznik ma vlastni (nebo muj) router. Ten ven hlasa svuj /56 (nebo jiny) jeden rozsah.... takovych bude na urovni toho panelaku (nebo aglomerace RD, to je celkem putna) tech +- 120, coz je taky maximalni pocet zaznamu, ktere bude znat router na urovni toho panelaku, kterej ven ohlasuje 1x /46. Router na urovni sidliste (nebo celyho mesta, protoze to uz je +- sumafuk) pak bude znat tech +- 60 zaznamu a ven bude ohlasovat /39.
Ale jo, asi sem uplne blbej a delam neco zcela zasadne spatne ... kdyz se do /32 s prehledem vejdu pro desitky tisic zakazniku.
Proč pokládáte toho poskytovatele VPS za odstrašující případ? Pro všechny svoje VPS vyhradili blok /48, nejspíš proto že předpokládají že budou mít max. 64k VPS. Kdyby vyhradili pouze /56, vešlo by se jim tam max. 256 VPS což je málo. Rozhodili se přidělovat /64 na VPS, což je jejich konkurenční výhoda protože si to od nich zákazník může přes IPv4 natáhnout tunelem k sobě domů (a bude mu fungovat SLAAC) když bohužel jeho domácí ISP o zavádění IPv6 nechce ani slyšet. Proč by to mělo být špatné využití, když mají přiděleno /32 (pokud se tedy bavíme o tom samém poskytovateli VPS s datacentrem v České Třebové) a tedy mohou takových bloků VPS (např. v různých datacentrech) zprovoznit až 64k? Bylo by podle vás lepší aby zákazníkům poskytovali méně než /64 jen proto aby zbytek svého přídělu /32 nechali ležet ladem?
Pokud to většina zákazníků používá pro tunelování IPv6, proč to poskytují jako VPS (a zákazník si ten tunel musí řešit sám), místo aby to poskytovali rovnou jako hotové řešení IPv6 tunelu? Pokud to jako zákazník takhle využíváte vy sám, proč musí mít těch /64 přiděleny všechny VPS, proč vám nemohou těch /64 dát na požádání?
Mimochodem, tím odstrašujícím příkladem bylo myšleno spíš to routování.
Je to jejich obchodní model a myslím že nemáme právo jim do toho mluvit. Zpoplatnit VPS se daří, ale jak byste zpoplatnil tunnelbrokera? A co se týká výjimek na požádání - jde o lidskou práci a ta je drahá. Jednodušší je dát všem /64, když je IPv6 adres k dispozici dostatek tak není důvod si komplikovat život tím že jimi budu šetřit. Hrají přesně podle pravidel - dostali /32 a používají je dle vlastního uvážení.
Nechápu co je na tom routování odstrašujícího. Všechny VPS mají v jednom datacentru v jednom L2 segmentu, tak proč by vymýšleli něco komplikovanějšího? V jednoduchosti je síla!
Já právě chtěl svou VPS použít jako Tunnel Brokera a to z jednoduchého důvodu: starám se o několik domácích sítí, které jsou připojeny za nejrůznějšími NATy. Mám mezi nimi VPN a VPS slouží jako koncentrátor. Rád bych do té VPN dostal i IPv6, abych nemusel na každé síti zvlášť konfigurovat tunel (a hlavně se o něj doprošovat u SixXS :) ). Jenže jedna /64 mi na to nestačí. Pokud VPS provider celý svůj příděl odroutuje jako jeden segment, nemá ani při nejlepší vůli možnost naroutovat mi na VPS něco většího, protože prostě nemá odkud.
Nějak jste se ve svém přemýšlení zaseknul na nutnosti routování (L3). Pokud se donutíte přemýšlet i o switchování (L2) tak uvidíte řešení která si teď neuvědomujete.
V modelu "jeden velký L2 segment pro všechny VPS" v principu nic nebrání poskytovateli povolit jednomu VPS používat více než jeden blok /64.
Nedonutíme, sorry. Již jsme viděli L2 ataky různými FDB poison útoky, že se řada switchů se rozblikala, popadali managementy a tahali se zněj postupně kabely aby to přestalo. Chceme síť robustní. A už před léty jsme udělali rozhodnutí, že se nesoustředíme na defacto podpůrné ochrany typu MAX mac count, ARP storm protection atd, ale chceme systémovou izolaci mezi klienty. Jak má třeba O2 na ADSL.
Aha, a jak se ta výjimka vyřeší když ne lidskou prací? Mně napadá jen práce programátora na nějakém automatizačním procesu pro tento druh výjimek, nebo práce administrátora při konfiguraci, uniká mi nějaká jiná varianta která neobsahuje lidskou práci?
S tím "neumíme přidělit" mi spíš připadá že umějí přidělit, ale do sdíleného L2 segmentu, zatímco zákazník si vymýšlí že mu to není dost dobré a požaduje extra L2 segment (routování).
Původní příspěvek úplně na začátku jsem pochopil tak, že každá jednotlivá výjimka znamená další lidskou práci. Znamenat může a nemusí. Záleží na konkrétním poskytovateli služeb, jak si to zařídí, jestli má těch požadavků tak málo, že se mu nevyplatí pro to dělat nějakou podporu, nebo zda to třeba zahrne do základních konfiguračních možností. Podobně je to třeba s reverzními DNS záznamy nebo glue záznamy pro DNS – někdo pro to má nějakou podporu v systému a jednotlivé případy už má bez práce, někdo to řeší na žádost ručně. No a někteří mají možná obchodní model postavený na vysvětlování, proč to nejde – což zřejmě není lidská práce, takže je to zadarmo.
Evidentně se nebavíme o tom samém. Ten můj není LIRem, má od svého LIRa přiděleno /48 a celých /48 routuje jako jeden segment. Přidělovat /64 na VPS je nerozumné, vámi zmíněné natahování tunelem domů bude velmi obtížně proveditelné, zahrnující obezličky jako bridging nebo NDP-proxy. V tomto případě mi jako mnohem efektivnější mi připadá všechny VPSky, které sdílí stejný IPv4 segment, naházet i do jednoho /64 segmentu a pokud by některému zákazníkovi nestačila jediná IPv6 adresa (takových nebude víc než ~ 20 %), je možné na jeho VPS naroutovat dalších /56 - /64 podle potřeby. Takový rozsah si pak zákazník může protunelovat kam chce, případně může libovolné množství adres naházet na loopback rozhraní.
Jasně, směrování nebude hierarchické, ale je na jde myslím o rozumný kompromis, jak využít příděl efektivněji.
OK, nebavíme se o tom samém poskytovateli, ale i tak - proč bych když mám v jednom datacentru přidělený jeden blok /48 ho nemohl nechat v jednom kuse a místo routování switchovat? Zákaznický provoz v případě potřeby budu filtrovat pomocí ebtables místo iptables, no a co? Proč si komplikovat život prací navíc (routováním)?
Co se týká natahování tunelů, je to jednoduše proveditelné přesně jak jste napsal, pomocí NDP proxy (např. http://priv.nu/projects/ndppd/) a bridge, jen nechápu proč to označujete za obezličku.
Přistup s jedním velkým L2 segmentem pro zákazníky s VPS se v principu ani nevylučuje s routováním extra adres na jednotlivé VPS, pokud by nějaký zákazník měl vysloveně tu nutnost - ale je vždy třeba zvážit zda mi ten zákazník stojí za to abych si kvůli němu komplikoval infrastrukturu. Nezapomínejte že trh s VPS je dnes vysoce konkurenční a poskytovatelé musejí náklady držet na minimu aby na trhu obstáli.
Co je na routování komplikované? Celý Internet je postaven na routování. Je to ta nejjednodušší funkce, kterou každý IP stack umí a pro kterou byl postaven, což se rozhodně nedá napsat o bridge a už vůbec ne o ProxyARP/NDP-proxy nebo EBtables.
Myslím, že Geoff Huston někdy někde řekl: „Friends don't let friends deploy large scale L2 networks“.
Z mého pohledu je správné škálující řešení založené na routingu, bridging považuji za nutné zlo, nelze-li problém vyřešit jinak. Ebtables je pak peklo, tedy pardon, tím je NAT na L2.
Routování je o kousek komplikovanější než switchování, chápu že se někteří poskytovatelé VPS rozhodnou si zjednodušit život switchováním. Routování například komplikuje přesun VPS mezi hypervisory - není to nic neřešitelného, ale komplikace to je. Dále routování rozbíjí adresní prostor a je potřeba více plánovat.
EBtables jsou v tomto případě srovnatelné s IPtables.
Nebavíme se o "large scale L2 networks“ ale o síti v jednom datacentru na které jsou připojené jenom hypervisory s VPS.
NAT na L2 jsem vůbec nezmiňoval, to je samozřejmě zlo a ještě o kus větší než NAT na L3. Nevidím důvod proč u tohoto scénáře vůbec o NATu uvažovat (na úrovni poskytovatele - co si budou dělat zákazníci ve VPS je jejich věc).
Zdá se, že si stále nerozumíme. Já nemám nic proti tomu, používat L2 sít v rámci datacentra například pro snadné migrování VPS mezi hypervizory. Large scale L2 se z toho stane v momentě, kdy v té VPSce udělám další bridge a začnu jí roztahovat tunely stovky kilometrů do různých směrů. Scénář s routováním dalších prefixů směrem na konkrétní VPS, je podle mě mnohem použitelnější ze všech stran.
Jasně, takhle jsem to nepochopil. Samozřejmě není moc dobré vytvořit super-L2-segment roztažený přes spoustu vzdálených míst, ale udělat tunel (nejlépe UDP aby to prošlo přes IPv4 NAT, takže třeba vtun nebo openvpn) do jedné konkrétní vzdálené sítě, nad tím pustit ndppd a radvd pro propagaci jednoho bloku /64 mi nepřipadá jako nijak špatné řešení. Opakujme tolikrát kolik máme vzdálených sítí a dostupných bloků /64.
Hlavně takový L2 bridge mezi LAN v datacentru a skrz L2 tunel tahán dál může být datově zajimavě náročný, pokud se to vhodně neošetří. Zvláště pokud těch VPS bude víc na jednom stroji, to pak v tom broadcast/multicast bordelu běhá občas i slušný datový tok.
Viděl jsem jednu takto udělanou instalaci, zrovna za účelem posunutí IPv6 z datacentra dál do domácí sítě, když ASka po cestě na téma IPv6 tranzit nechtěly slyšet. Jen byl majitel občas neštastný, že mu to tunel hltilo někdy i desítky Mbps multicast/roadcast bordleu, co při nějakých přesunech a managementu mu do toho lezly (i když asi i kapánek neprofesionalita datacentra, pokud vnitřní management běhal normálně po stejné LAN/VLAN jako zákaznícká data).
Asi si nerozumíme. Já jsem nepopisoval L2 bridge s LAN v datacentru kde skutečně může být všelijaký broadcast bordel (i když v profi datacentru by to být nemělo). Na straně datacentra se k odfiltrování nežádoucího provozu dá použít NDP proxy, např. http://priv.nu/projects/ndppd/ a teprve na straně vzdálené sítě se udělá bridge mezi tím tunelem a LAN.
Nezlobil bych se na malé ISP, že mají v centru někde 2000 rout. Někteří jich tam mají i mnohem více....
Ono hiearchie dokonalá je krásná, ale realita menších sítí, hlavně wifi a podobných bezdrátů, ji ne vždy podporuje, zvláště pokud mám pro redundanci a zálohování v síti smyčky na L3 a nastupuje dynamický routing, tak ne vše lze úspěšně agregovat. Pomíjím stav, že u těchto malých je běžná praxe Mikrotik a RouterOS a jeho implementace OSPFv3 pro IPv6 přímo taková, že mít síť s víc jak jednou areou byl donedávna celkem nefunkční problém (už to je chvíli opraveno, ještě nestabilitu při převážení externích rout by to chtělo), takže agregaci na hraničních roputerech areí nešlo používat.
Dokud jim to HW dává a vyznají se v tom, tak ať to tam tak mají. Možná je i spíše pochválím za to, že když se jim zákazník přestěhuje z místa A na místo B, tak mu ponechají jeho IP příděl nezměněn, než ho nutit k novým IPčkám v rámci hiearchické čistoty.
Dokud si to ISPík umí uřídit, ať si to řídí. Polud bude aspoň trochu přemýšlet, aby to nasekal tak, aby to dalo aspoň trochu naději na agregaci, až toho bude moc a používaná technika si s tím poradí, tak má dobré plus.
A co takhle jinýpříklad:
Já teď nemám dost peněz, svítím výjimečně, tak si koupím jen obyčejnou žárovku. Nekoupíš hehe, zakázala je EU, protož rozhodla, že jsou nehospodárné.
A já jen nahlas přemýšlím, zda si ji nepřivést třeba z Egypta až tam budu a vykašlat se na to nařízení.
Ad tvůj příklad, kdyby všichni postupovali hrubou silou (více peněz) a neštval je tehdy standardní stav věcí, kde by byl pokrok?
Ne, ty si delas z ADRESY ... poznamkovej blok. To je tvuj zcela zasadni (zjevne i psychyckej) problem.
Zjevne bys potreboval aby jedna adresa mela spon mega, aby se tam dalo napsat "franta vopicka, na komine 147, bohnice" a prilozit fotka ...
Pokud vim, nic ti nebrani takovy RFC navrhnout ... pocitam ze na to mas nejakych bywoko 9 mesicu abys stih termin ...
Ty z ní děláš něco posvátnýho óm ani jedna adresa sítě nazmarrrr, óm, prostě to stačí tak to nějak vyroutujeme.
Já chci velkou {jednoduchou efektivní staticky routovanou síť}=hierarchicky adresovanou síť
To samy chci pro klienta, ale zřejmě to nějak nedáváš, kopeš tu kolem sebe jako muslim, kterému žena řekla že nebude nosit hijab :)
Pri jeho poctu klientu mu bohate staci /48 ... ale on neumi proste IP protokol pouzivat. Kdyz pridelim ve svy soukromy pidisiti kazdymu hopu 8bitu ... tak mi IPv6 rozsah bude sotva stacit ...
Vem si, ze prave ted to mam na seznam 10 hopu ktery se ozvou. 10x 8 = 80 bitu ;D. Kdyz se posunu na konec svy pidisite, tak tam jeste 4 hopy pribudou ... => naprosto nezbytne nutne potrebuju 112 bitu, protoze bez toho se prece ta sit neda provozovat ... nebo ne?
No jasně, to je ten základní problém, že něco, co někdo původně zamýšlel jako „dále nedělitelné“ někdo další chce zase rozdělit. Ze stejného důvodu vznikl kdysi IPv4 NAT a dnes máme i implementace IPv6 NATů :)
Ale obávám se, že tady řešení neexistuje, protože pokud by se nejdelší možný prefix posunul více doprava, dejme tomu na /96, bude to jen znamenat, že nejlepší a nejlevnější ISP bude dávat v akci jen /96 namísto /64.
Ale v dnešní době, s tím, jak se stále zlepšuje podpora DHCPv6, si docela dokážu představit v nějakých nouzových situacích rozsekat jednu /64 třeba na segmenty po /96.
Ad posun doprava, ano je to relativní, tlaky by byly pořád, ale existuje určitá rozumná mez které když dosáhnete, problém už není problém (kde dnes např, řeší velikost disku u kancelářských PC? je totiž docela irelevantní)
Ta mez je podle mne u IPv6 někde kolem /96. Ale jak říkáte DHCP6 se zlepšuje, tu a tam to někdo poruší a nakonec ten standard zbyde jen na papíře.
U IPv6 navíc ve své pidi síti pro její celou správu mi stačí jen pár adres. V podstatě včetně spojovacích segmentů na zákaznický router to může být link local adresa. Routery po cestě mají jen jednu /128 globální adresu na loopbacku a s okolím se baví přes link local adresy. I s routerem koncového zákoše se můžu bavit přes link local adresy a routovat na ně jeho segment, který si on použije až uvnitř dle svého uvážení (i když se to tak většinou nedělá a na spojovacím segmentu s koncákem bývá globální segment).
No jsem tady jen laik, a nemam nic nacteno, ale prijde mi to, jako ze OSPF ma zaukol vyresit routovani a tedy se mezi sebou bavi uzly co na sebe vidi - tedy pro komunikaci nepotrebuji routovat. Potom takovato komunikace muze klidne pouzivat MAC adresy (nebo link-local adresy z IPv6).
Kdepak, žádne RFC to nezakazuje. Naopak: http://tools.ietf.org/html/draft-ietf-opsec-lla-only-08
Tak o o tom slyším poprvé. Spíše naopak, že je doporučováno routovat přes link local adresy a ani router nezatěžovat hromadou globálních adres jen jako linkové spojovačky. A snad všechyn dynamické routovací protokoly tak činí, když nepočítám BGP, který umí dle nastavení jet jak přes link local, tak i přes globální adresy.
A i default routa u stanic získáná z SLAAC je na link local adresu (v tomto směru je snad jen vysloveně zakázáno, aby krabice s profilem router se naučila default routu posloucháním ohlášení od jiné krabice, vvyjma end user routeru, který to má naopak dělat).
Dokonce mám vyzkoušeno, že používání statických rout mířících na globální adresy mají v některých platformách problémy - zkrátka čas od času ta routa přestane fungovat a musí se do toho nějak štouchnout.
A ani těch /64 není neprůstřelná zeď. Pokud si to umím udělat jinak... Ale musím počítat s tím, že vše standardní dneska počítá s tou autokonfigurací a /64. Pokud budu štastný uživatel pouze krabic s podporou stavového DHCPv6, tak mi nic nebrání jít na cokoliv (nebo s emůžu stát podpůrcem systému DNMS od Sixscape, který se snaží jedním vrzem nehradit všechny přežitky typu DHCPv4, DHCPv6, SLAAC, ...). :-)
Vždyť ani to, jaká má být maska na PtP spojích není zeď, jedna říká /126, druhá /127 a arguemntuje se bezpečností a zapomíná na problém s anycast adresou subnetu (a /127 i některým krabicícm zase dělalo problém)...
Bohužel, jako ISP musím plavat v tom, co se z poslendích 30 let uvařilo a nemá moc smysl se snažit prorazit hlavou některé hranice, pokud chci ty zákoše k internetu funkčně připojit...
To je pak těžký :-) A co když ten uživatel bytu bude chtít odroutovat spolubydlící a ty spolubydlící své kávovary a ty své kapsle, že ano? :-) Ty bity by prostě stejně někdy došly i když by neexistovala EUI64.
RFC nejsou tesané do kamene, ale dynamicky se vyvíjí podle skutečné potřeby a reálných zkušeností s praktickou implementací. Ovšem je potřeba proto něco udělat, od toho se to jmenuje RFC. Další možnost je zatnout zuby a plkat na rootu :-)
Ale dost už. Nechce se mi už dělat ďáblova advokáta ;-)
No ale to je prece na tom uzivateli bytu, jestli si sezene ISP, co mu da dostatecne siroky adresni prostor. A idealni bude kdyz norma nerekne tak ani tak a necha na uzivatelich a ISP ktere biti budou ci. Pokud ISP hierarchickym routovanim snizi naklady a nabidne pripojeni za 80% ceny konkurence, vyberou si uzivatele konkurenci, ktera jim da 96 bitu, nebo tohoto ISP, ktery jim da treba jen 12bitu z adresy?
Jak už někdo poznamenal, V6 je špatně od samého počátku a idálně neměl, v takovéto podobě, vzniknout. Sice V6 nějak moc nesleduju, ač siťařina patří k mojí práci, myslel jsem, že mne u něj zas tak moc nepřekvapí. Ale vždy se najde nějaká šílená obezlička "aby to fungovalo", které překvapí. Co naplat, že to není kompatibilní tady, tamhle a onde. Co naplat, že to rozbije DNSSEC (pokud jsem to správně pochopil, kdyžtak mi to někdo pls vysvětlete, jak to s tímto pojede, neb pokud podepisuju jen V4 a očekávám V6). Důležité je jen to, že ta ten šílenej kočkopes bude fungovat :) A když ne, vymyslíme tunel a překlad ještě tunelovější a ještě překladovější než všechny ostatní (o: Haleluja !
R.
DNSSEC samozřejmě s IPv6 normálně funguje. Například tady na Rootu jsou pochopitelně AAAA záznamy podepsané, stejně jako všechny ostatní.
O komplikovanosti IPv6 mluví obvykle ti, kteří to ve skutečnosti nikdy neviděli. Naopak v šestce je spousta věcí jednodušších a moc pěkně navržených. Ano, má to některé mouchy, ale není to taková tragédie, jak se snaží občas lidi prezentovat v diskusích. Doporučuji si alespoň zkusit v některé síti IPv6 rozjet.
Já mám šestku všude a jsem s ní naprosto spokojený.
Ten tunel zpřístupňuje V4 do V6. Takže se nedá předpokládat existence AAAA záznamu. Na to jsem narážel. Ne na samotnou existenci DNSSEC na V6. To snad bylo z toho postu jasné...
No, jestli jsem ji viděl nebo ne, to nevím. Vždy to bylo jen virtuání (o: Stack jsem na ni psal, do malých embeded zařízení, stejně tak jako pro 4ku, takže z praktického hlediska s ní nějakou zkušenost mám... Proto nám všechno jede na V4, bez výjimky.,,, Na úrovni o které píšeš, funguje (asi obvykle) bezproblémově. Stačí si dohledat diskuzi snad skoro pod každým článkem V4 x V6 :) Mne naopak přijde, že všichni její zastánci předpokládají, že každé zařízení má tuny MHz, tuny RAM, ... Ale reálné věci, které ovládají chod strojů, na kterých jsme zavislý, obvykle tyto vymoženosti nemají. Ba dokonce se často ani nepoužívá linux (ikdyž to ma kapacitu), nebo jinej velkej OS/kernel. Prostě už jen protože jsou to miliony řadek, kde se může něco rozbít. A mit 20K něceho, nebo milion jiných ? To je jen otázka míry pravděpodobnosti chyb.
Co by si byl radši, kdyby v rozvodně, díky který mas elektriku, bylo PLC s nějakým "mini" softem nebo (jakejkoliv) kernel s milionama řádek ? CPU vyráběnej supr-dupr-skoro-nano technologií, nebo šváb co má hradlo 10ti násobně širší a díky tomu přežije "věky" ? (o ESD, přepěti a pod nelmuvě, tyhle věci nelze nikdy uplně odfiltrovat).
V6 nebyla evoluce, ale revoluce, kde si každej chtěl prosadit něco svého. Proto to dopadlo jak to dopadlo a ještě poměrně dlouhou dobu se nic nezmění. Jen můj názor, nic víc nic míň. A ještě pěkných pár let budou lidi řvát, jak je V6 skvělá, lepší, nejlepší, jen proto, aby tomu ostatní uvěřili.
R.
Co se týká DNSSECu a DNS64, tak kompatibilita je zajištěna. Validace se dá provádět ještě před DNS64. Pak musí být mezi DNS64 a klientem bezpečný kanál. Druhou možností je, že si validaci bude dělat klient přímo u sebe, pak si musí u sebe dělat i DNS64, což by si měl objevit pomocí RFC 7050, stejně jako CLAT zmíněný v článku.
Takže už nemohu validovat sám, ale pouze přesouvám důvěru "kamsi" - k tomu poskytovateli. A to podle mně podráží princip DNSSEC, který vnikl, abych *já* jako klient měl jistotu, že můj dotaz je nepodvržen. Ale dejme tomu, že poskytovatelovi věřím. Jak udělám "tunel" pro DNS ? Pokud nemám po cestě nějakou krabici (co to uděla transparentně), ale mám jen třeba NTB a podobně, tak standarně to není zas tak snadné. Alespoň mně nenapadá, jak to udělat např. s Widlema bez podpory další aplikace (to neznamená, že to nejde, jen to třebas nevím)... A to je celé jadro podobných obezliček. Je to jako alopati versus jiné přistupy. Neřeší příčinu, jen zalepují následky příčiny...
R.
Přečtěte si prosím znovu příspěvek, na který reagujete. Validaci si samozřejmě sám dělat můžete, jen se pak předpokládá, že si i sám uděláte DNS64.
A propos, zkoušel jste takovou validaci na vlastním stroji provozovat? Speciálně ve spojení s forwardováním na DNS resolver ISP dochází často k poměrně nepříjemnému drhnutí, na které si třeba často stěžují uživatelé routerů Turris.
„A propos, zkoušel jste takovou validaci na vlastním stroji provozovat? Speciálně ve spojení s forwardováním na DNS resolver ISP dochází často k poměrně nepříjemnému drhnutí, na které si třeba často stěžují uživatelé routerů Turris.“
Můžeš to nějak upřesnit a pokud možno mě kontaktovat i mimo root? Fedora (či jiná distribuce, kde se to umí) s instalovaným dnssec-triggerem aktivně testuje DNS servery ISP a v případě, že nepředávají záznamy potřebné pro DNSSEC používá server, který s DNSSEC funguje.
Jedná se o problém s validací žolíkových domén, když je forwardováno na BIND<9.9.0. Více na http://wildcarddnssec.jdem.cz a offline.
Požadovanou funkcionalitu, že validaci dělá nadřazený DNS server a Windows jako klient si k němu udělají zabezpečené spojneí pro zajištění důvěryhodnosti, tak tu Windows umí od verze 7. Je to na 2 kliknutí myší. :-)
Windows 7 totiž obdsahují nevalidujícícho DNSSEC forwardujícího klienta, který sám validaci nedělá, ale umí od nadřazeného převzít informaci o tom, zda validace DNSSEC proběhla OK nebo záznamy byly bez DNSSEC. Proto ten poslední hop zabezpečuje pomocí IPsec transportu, aby se zabránilo manipulaci po cestě od validujícího DNS serveru ke klientu.
Jiná věc je, že to moc neumí ty DNS servery, pokud to není Windows 2008 a novější server. :-(
Nastavení viz "Name Resolution Policy Table".
„Validace se dá provádět ještě před DNS64.“
Pokud vím tak aby DNSSEC poskytoval nějaké zabezpečení, je potřeba důvěřovat validujícímu DNS serveru, což lze v praxi typicky jen pokud běží validující DNS server na localhostu. Z toho důvodu je řešení, které navrhuješ, debilní.
Já osobně už jsem před delší dobou navrhoval toto řešit tím, že se použije vždy obecně známý DNS64 prefix a klient použije validační data IPv4 i pro IPv6.
Jenomže obecně známý prefix NAT64 se například nesmí použít pokud se pomocí NAT64 připojuješ k RFC1918 adresám. Plus hromada dalších důvodů, proč může někomu vyhovovat provozovat NAT64 na svém prefixu (testovací instalace v go6lab je jeden z nich).
Podle mě je DNS server na localhostu naprosto v pohodě, stačí do DNSSEC-triggeru přidat detekci PLATu podle RFC7050 a vývojáře unbounda dokopat k podpoře DNS64 v upstreamu (patche jsou v projektu Ecdysis a zdají se být funkční). Při tom kvantu věcí, které DNSSEC-Trigger dělá už teď, by se klidně mohl postarat i o toto.
Ja tomu fandim. Ma sanci to zabit duveryhodnost DNSSEC coz je prvni vyznamny hrebik na ceste zbavit se DNS jako takoveho. Tim spis, kdyz to nad IPv6 neprinasi nic vic nez zduplikovani "trustee". i kdyz to se muze nekomu hodit na delegaci roli.
Uz jen aby nekdo implementoval nejakou uzasnou ficuru pod rouskou kompatibility a jako spravny MIM utocnik podepisoval na tom tunelu vsechno co prijde a prevede ze ctverky a podstrkaval to klientum v sestce.
Tak tyhle ipv4 kontrolery by snad nebyly problem. Kdyz se z ipv4 podari vystrnadit domaci uzivatele s porne, fejsbuckem a mailem, budete mit na kontrolery cely ipv4 rozsah a tolik tech zarizeni snad hned tak nebude, aby to nestacilo. Celkem nevidim duvod, proc do podobnych zarizeni rvat ipv6. I kdyby uz neexistovala zadna konektivita po ipv4 skrz Internet, porad si to muzete nejak protunelovat. Tak jako tak tyhle veci asi nevisi rovnou na verejne ip, aby si s tim hrali crackeri, ale za poradnym firewallem, VPN a co ja vim.
Je to jen otázkou pohledu. Z pohledu poskytovatele služeb a správce tuny "krabiček" prostě nemám jedinný důvod pro V6ku. Naopak vše jen kompikuje. Pokud by se nešlo revolucí, neměnila se tuna věcí a nepřidávaly se zbytečnosti, bylo by to určitě jiné. Na začátku vyhrála loby, ne smysl pro funkčnost systému. Nemá význam opakovat co je skoro pod každým podobným evangelickým článkem :)
R.
A stejně tak se pod každým podobným článkem opakuje otázka: „Jak chcete rozšířit adresní prostor a přitom zachovat kompatibilitu?“
Jasně, můžeme se bavit o tom, že princip RA, SLAAC, EUI-64, DHCPv6, atd. je špatně, že se mělo radši 1:1 převzít to, co fungovalo v IPv4, ale stejně bychom měli dva nekompatibilní světy, pro které bychom museli stavět přechodové mechanizmy.
IPv6 rozhodně není špatně od začáttku. V základu je navržené velmi pěkně a řeší dost neduhů IPv4, nejpalčivější je možná TCP window size.
Problémem IPv6 je halda sraček které tam před 15ti lety nakakali odtržení teoretici na univerzitách, ve snaze panelově vyřešit všechno od VPN přes mobilitu. Halda naštěstí trochu zatuhla, část hovínek se oddrolila ještě před masovým nasazením, o časti děláme že ji nevidíme a do těch míst nešlapem, já vnímám jako největší problém RFC6177 a spol, viz můj post výše.
Osobně věřím jen na dual stack, tyhle obezličky vyvolávají jen další problémy k řešení vyvolávají disproporce na síti a nemají smysl. Protože přechod nespěchá, má cenu spíš postupné řešit pořádný dualstack.
S tím se nedá prakticky nic jiného než souhlasit, s výjimkou začátku, V6ky kde by možná bylo lepší nejít novým formátem paketu, ale rozšířit header existujícíma možnostma V4ky. Ale i to ma své nevýhody. V každém případě, zařízení, která by uměla předávat tyhle headery by mohla podporovat V6ku automaticky, což je, zcela logicky, nechtěná featura, že... Už jen to, že IPSEC bylo mandatory pro V6ku. To ukazuje na to, jakej typ lidí to sestavoval...
R.
To vaše „řešení“ se objeví pod každým článkem o IPv6. Opravdu má své nevýhody – všechny nevýhody IPv6, a jako bonusovou nevýhodu navíc to, že by to velmi zpomalovalo páteřní routery. Stejně byste měl dva nekompatibilní světy, IPv4 a IPv4 s rozšířením. Oproti současnému stavu by navíc docházelo k problémům, kdy byste IPv4 paket s rozšířením poslal zařízení, které by tomu rozšíření nerozumělo.
Osobně věřím jen na dual stack, tyhle obezličky vyvolávají jen další problémy k řešení vyvolávají disproporce na síti a nemají smysl.
Hlavní problém dual stacku je, že všechno je potřeba konfigurovat, dohledovat a troubleshootovat dvakrát. A zejména ten troubleshooting bývá oříšek i pro zkušené techniky, pro BFU volající na zákaznickou podporu jde o v podstatě neřešitelný problém.
Například: IPv6 konektivita funguje, ale setinovou rychlostí proti IPv4. Takový problém uživatel popisuje tak, že „se mu videa z Youtube načítají hrozně pomalu“. Jen málokdo z toho okamžitě odhalí spojitost.
Hlavne proto proste nebudou adresy, vlastne uz nejsou. 80% potizi se sitovanim ktere sem v poslednich minimalne 5ti letech resil byly dany tim, ze dotycny proste ... zadnou sit (internet) nemel. Nemel verejnou adresu = z jeho pohledu mu proste neco nefungovalo (trebas vymena souboru pres icq/jabber ..).
Dtto bezpecnost - NATujici firewall ma vetsinou 3-5tinasobek pravidel nez totez bez NATu. Coz zcela automaticky vede k chybam, prehlednutim ... daleko casteji. Uz vubec nemluve o takovych vecech jako ze se nejaky stroj z nejake interni natovane site snazi pripojovat na verejnou adresu toho natu ... (proste proto, ze googli DNS mu samo nerekne 192.168.2.3), coz jsou dalsi pravidla a dalsi chaos.
> Osobně věřím jen na dual stack, tyhle obezličky vyvolávají jen další problémy k řešení vyvolávají disproporce na síti a nemají smysl.
Dual stack je dobre reseni v okamziku, kdy ma ISP dost verejnych IPv4 adres, takze muze kazdemu uzivateli pridelit aspon jednu.
V okamziku, kdy IPv4 adresy dochazeji a ISP by stejne musel nasadit stavovy NAT, tak nasazeni MAP-E resi hned nekolik problemu najednou - zaprve umoznuje casem prejit na IPv6-only paterni sit, zadruhe odstranuje skoro vsechny komplikace s provider-based stavovym NATem (jak pro ISP tak pro uzivatele).
Otázka v úvodu ....přidávání druhého protokolu do jejich stávající infrastruktury představuje náklady, které nikdo nezaplatí. Nešlo by to nějak jinak?.... Zůstává nezodpovězena.
Podlě mne to ani nemá řešení. Celkově se do toho promítá to, že často je znát to že v rámci jakési "společenské potřeby" myslíme že práce, služby, zboží bude levnější nebo rovnou zadarmo. ...protože my to potřebujem... Jenže tak to není.
Odpověď na úvodní otázku dávají všechny tři v článku popsané postupy, které spočívají v provozování podstatné části infrastruktury pouze jedním protokolem a to IPv6. Není tedy potřeba se starat o dvě sítě v jedné, stačí se starat o jedinou a třeba jako německé kabelovky nové zákazníky připojovat jen k IPv6, staré nechat dožít na IPv4.
Jenže lidská práce, hw a služby má vždy vyšší cenu než 0. Takže ono ...představuje náklady, které nikdo nezaplatí.... tím nemizí. Předpokládám že ISP nejsou neziskovky ani charitativní organizace.
Technické řešení není vždy tržním řešením. I to co je zmíněné v článku má při nasazení nějakou cenu a ISP sito budou chtít naúčtovat.
K ideálnímu stavu přechodu na IPv6 s tím že služba zůstane stejně pro klienta nákladná podle mně nedojde.
To, že další rozvoj jakéhokoli ISP bude stát další peníze navíc je nezpochybnitelné. Máme tu problém, že další IPv4 adresy nejsou a za stávajících podmínek nebudou, takže ISP musí hledat řešení. Tím může být nákup dalších IPv4 adres na burze, může to být pořízení CGN a nebo to může být nasazení IPv6 spolu s nějakým přechodovým mechanizmem.
Všechna tato řešení nějakým způsobem nedostatek řeší, mají své výhody a nevýhody a i své ceny. Podle mého názoru je pro technická oddělení ISP hlavně důležité uvědomit si, že možností řešení je víc a zavedení IPv6 je jednou z těch možností. Z mého pohledu je to navíc možnost pro technická oddělení nejvíce přijatelná, už jen z toho důvodu, že tím jako bonus vyřeší to malé procento „otravů,“ co se svého ISP stále ptají, kdy už konečně zavede IPv6 :)
Můj odhad?
Do 4let bude na 95% netu nějakou formou dualstack a začnou se objevovat první vlaštovky (ISP) bez IPV4, zájemci budou odkazováni na výše uvedená řešení.
Do 5ti let pojede 80% provozu přes IPv6
do 6let spadne podpora IPv4 pod 90%, pak to půjde po log křivce dolů v dlouhém horizontu, dejte tomu v r 2025 to bude ještě 70% atd.
Google do nás (ISP) třeba dost tlačí, NATovat 500lidí pod 1IP už dobře nejde (vyhledávač jim háže "podezření na rekurzivní dotazy", háže jim captchu atd)
Dozijes ... a pujde to velmi rychle ... je otazka kdy (%) nastane ten zlom. Ale jamile penetrace prekroci nejakou hranici ... tak se vyvoj velmi urychli. Zkus si predstavit, ze by v ceskych podminkach trebas zitra telecum prohlasil, ze Ipv4 zcela rusi. Automaticky by to vyvolalo vlnu u vsech co provozuji servery, rychly nasazovani Ipv6 ... a minimalne cast z nich by proste rekla, ze 4ku rusi taky, coz by prozmenu vyvolalo rychly zavadeni u vsech ISP.
Samo Ipv4 nikdy uplne nezmizi, to je velmi nepravdepodobny, minimalne v lokalnich sitich se bude vesele jeste desitky let pouzivat dal.
Zapomen ... odeslo by mozna nekolik desitek zakazniku. A jak rikam, nebude to dneska ani zitra .. ale jednoho krasneho dne prijde managor nejakyho velkyho poskytovatele ... bude mit pred sebou papir o nakladech na administraci ... a zjisti, ze je tam vsechno 2x ... a ten den nemusi byt nijak zvlast daleko.
To by me zajimalo kde? Jako marketingovej zvast dobry ... ;D. jinak co ja si pamatu, tak ATM melo predevsim jeden problem - bylo to pekelne drahy. A kdyz se jen tak zbezne mrknu do historie .. nejen IT ... tak vzdy uspelo to, co bylo mozna horsi, ale levnejsi.
Trebas firewire vs usb, beta vs vhs, ... do zapomeni upadly vsemozny magnetoopticky disky proti plastovym kotouckum jako CD a DVD ... presto ze nabizely trebas lepsi format ...
Ethernet je vlastne technologicky taky uplna hruza ... ale proste to funguje dostatecne dobre.
Pokud si dobre vzpominam, tak to bylo na katedrach telekomunikacnich technologii kdy to do nas hustili kakademici spolecne s telescumem. ATM melo byt i technologii pro lokalni site;) Sitovka za tricet litru nebo ethernet za par stovek;) A navzajem ne zcela kompatibilni implementace.
Ethernet je tak pitoma,funkcni otevrena vec, ze proste musela prorazit;)
Ja to tedy vidim jinak. Ne vsichni provideri maji problem s nedostatkem IPv4 adres.
To se tyka hlavne poskytovatelu domacim uzivatelum.
Je mnohem jednodussi a levnejsi prehodit sit na dual-stack, respektive 6PE v core siti. Velky provider ma v siti obvykle MPLS kvuli VPN a v takovem pripade CORE routery nemaji obvykle v sobe ani IPv4 ani IPv6 tabulky a routuji na zaklade MPLS tagu. Hranicni PE routery pak musi umet dual-stack, coz obvykle i nekolik let stare routery umi. Problem u routeru je s nedostatkem RAM na full BGP IPv4 tabulku. Mnozstvi IPv6 prefixu je zatim zanedbatelne v porovnani s IPv4.
Vetsi problem vidim s investicemi do podpurnych systemu pro IPv6, pro plneni Radius serveru, DNS a hlavne mizerna podpora v koncovych zarizenich. Ciste IPv6 reseni spolecne s nejakym CGNAT ma smysl u uplne novych provideru, kteri od RIPE zadne IPv4 adresy nedostanou. U existujicich provideru ma vetsi smysl dual-stack, pripadne 6PE/6VPE. Nejaky velky NAT znamena velke investice a ze zacatku velke problemy.
Ach jo, to jeste bude bordel. Jinak teorie je to krasna, ale jaksi nevetsim problemem je, ze spousta ISP se nejakym ipv6 vubec neobtezuje a mozna o nem jeste ani neslyseli.
A proc proboha treba Android vyzaduje ipv4 konektivitu? Je to proto, ze ipv6 vubec neumi nebo proto, ze dela bud ipv4 nebo oboji, ale samotne ipv6 ne?
Android umí IPv6 velmi dobře, ale zřejmě zjišťuje dostupnost sítě podle toho, jestli nabere IPv4 adresu. Mám doma jednu IPv6-only síť a Android se zkusí připojit, ale pak zahlásí, že se to nepovedlo. U jablečných zařízení třeba problém není a ta fungují. Sice se většina aplikací nechytá (protože se šestkou nepočítají), ale prohlížeč krásně surfuje.
U Androidu je ještě bizarní, že na mobilní síti umí v6-only fungovat, problém mu to dělá jen na Wi-Fi. Někde už nějaký vývojář sliboval, že to opraví, ale zatím ani nejnovější 4.4.3 si s v6-only sítí neporadí.
K první části: Ale slyšeli. Určitě přinejmenším od zákazníků. Podle mě je zásadní problém v tom, že spousta ISP používá NAT už od svého vzniku (nejlépe ještě několikanásobný) a protože jim to na Wi-Fi spojích o jednotkách Mbps fungovalo naprosto spolehlivě, nemají důvod nic řešit. Problém je, když takový ISP vyroste k optickým přípojkám o desetinásobné rychlosti. Pak zjistí, že stávající NAT řešení přestává stíhat a jediné, co je napadne je pořídit větší NAT.
K Androidu: B je správně. Jediné, co v Androidu IPv6-only nepodporuje, je netd, starající se o Wi-Fi sítě. Všechno ostatní nemá s IPv6 nejmenší problém.
Kdyz lidi za 2-3 roky (dle vyjadreni CTU) zahodej 90% televizoru, ktery si pred 2ma rokama koupili, kvuli prechodu na DVB-T2 ... tak jim urcite nebude delat problem zahodit androida. V Redmondu neumej implementovat korekne IPv6 ani z casti... takze tam se cervenat maji proc.
Sem si udelal takovou sondaz, obesel sem par marketu kde maj telky ... a poptaval T2 ... v 70% pripadu netusili o cem je rec, v cca 20% pripadu tusili, ale nevedeli jestli to vystaveny kusy umej, s tim ze mi to najdou na internetu, jen v 10% pripadu mi prodavac byl schopen ukazat/vyjmenovat modely, ktery T2 umej ...
Zato vsichni basnili o stovkach kHz a dalsich zcela nesmyslnych cislech. Vsichni mi taky vypraveli o tom, co vsecho ty jejich "smart" tv umej ... skoda ze sem sebou nemel flashku s par filmama, abych jim ukazal jak neumej nic.
Drobné, ale v tom, že:....
TV přímač začíná být zbytným kusem elektroniky. TV byznys umírá a počet kusů TV přímačů na hlavu klesá.
Smartphony ne, tam naopak počet roste kusů na osobu roste.
U TV vysílání DVB-T/S verze 1 vypnou a máte smůlu pokud nemáte možnost přímu verze 2 . Jenže IPv4 vám nikdo nevypne. ;-)
Žádný Tier 1 není sebevrah aby vypnul IPv4, když už ho v síti má, funguje mu a generuje zisk. A s menšími poskytovateli je to to samé - prodávat IPv6-only připojení by byla tak významná konkurenční nevýhoda že si to nikdo neriskne a vždy přidávají i IPv4, i když třeba jen přes NAT. Obchodní stránka věci je to co nenechá IPv4 v klidu zemřít a proto si myslím že jsme odsouzeni k dualstacku na velmi dlouhou dobu.
Pozor, po té velmi vzdálené budoucnosti bude potřeba ještě vzdálenější budoucnost ve které všechen obsah který byl dříve přístupný přes IPv4 nově přístupný buď oběma protokoly, nebo jen přes IPv6. Pak teprve bude možné uživatelům přestat poskytovat IPv4 konektivitu. Myslím že my se toho už nedožijeme a budeme tedy doživotně odsouzení k dualstacku.
No ale pozor, treba nekde v Dolnim Stasove nainstalujou chytrou^h^h^h^h^h^h^hhloupou krabicku, co ja vim, treba do ovladani semaforu ve meste (ano je uhozeny mit takovy system pripojeny k internetu) a tato krabicka bude umet jen IPv4. Na druhou stranu, ve chvili kdy takovych krabicek bude dostatecne male mozstvi, tak bude ekonomictejsi IPv4 vypnout a prodavat vychytrale krabicky, ktere pro ty hloupe namapuji nejakou malou cast IPv6 sveta jako IPv4 (dle potreb tech hloupych krabicek).
To se spíše obávám, že někteří veřejní telko operátoři v rámci EU vypnou IPv4 sami. A to ti, kteří nebudou mít dostatek veřejných IPv4 adres pro své klienty, pokud myšlenka, jak vyřešit sledování lidí a nedráždit Evropský soud dozraje do podoby zákazu 1:N NATu u operátorů v rámci unie (vyjma doplňkových datových tarifů u mobilních telefonů k hlasovému terifu) - nemáš dostatek IPv4 adres, tak další lidi nepřipojuješ nebo je budeš připojovat jen přes IPv6 a stát online bude mít přístup k seznamu, kdo aktuálně jakou IP adresu/blok využívá. Asi by to fungovalo pro IPv4 i pro ten MAP režim. Nu, uvidíme, co nám komis vymyslí..
CGN buzzword znám. Ale právě jde o to, aby operátoři nelogovali a nebyl problém, že sbírají data o spojeních pro potřebu státu. Aby měli zkjendodušeně řečeno tabulku zákazník=IP adresa/blok a tu měl stát dynamicky k dispozici a dokázal tak identifikovat koncový subjekt bez obtěžování operátora nějakým dotazem.
Pořád si myslím že toto je řešitelné i se stávajícími logujícími NATy. Technicky není problém pro operátora vystavit automatické rozhraní kterým ta zalogovaná data pro stát budou zpřístupněná. Liší se pouze legislativa v jednotlivých zemích, v ČR jsme na tom tak že operátor musí obdržet autorizovaný požadavek na dodání informací který je povinen splnit, v jiných zemích je operátor dokonce povinen dát státu přímo přístup do své sítě (viz např. aktuální prohlášení Vodafonu).
Nemyslím si. Na světě je 7G lidí a z toho řekněme půlka žije ve společnosti, kde je elektřina a internet. Tak to jsme právě vyčerpali celý adresní prostor IPv4 a ani jsme neuvažovali, že miliarda lidí z „prvního světa“ má zařízení víc (smartphone, počítač doma, počítač v práci, notebook) a že taky je potřeba mít nějaké servery a že účinnost alokace ani zdaleka není 100%.
Na těchto stránkách se často lidé dohadují o ochraně soukromí, dírách v programech umožňující třípísmenkovým organizacím vše sledovat atd.
A najednou je zde obhajována technologie, která zajistí, že každé zařízení v síti bude jednoznačně identifikováno zvenčí.
Skutečně vám to nepřipadá, jako důkladný zásah do soukromí? Zásah, který si mohly vlády připravit a komunita ho ve svatém nadšení pro novou technologii radostně podporuje.
Jako že zařízení s IPv6 adresou 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 má IPv6 adresu 2001:0db8:85a3:08d3:1319:8a2e:0370:7334? To mi jako převratná informace nepřipadá… A důkladný zásah do soukromí? Do soukromí koho, toho zařízení?
To, že má každé zařízení připojené k internetu jednoznačnou adresu, a může tedy (z pohledu transportních protokolů) komunikovat každé zařízení s každým, je základní princip Internetu. A platí to úplně stejně i pro protokol IPv4.
Většina lidí je připojena stylem: zařízení dostane IP od domácího routeru. ten je připojen k poskytovateli internetu a malí poskytovatelé pak ještě k další firmě. Domácí zařízení je tak i za 3 IP adresami z rozsahu privátních sítí. To je pro útok z venčí dost velký problém.
Dále se zde často mluví o sledování a Velkém bratru u mobilních telefonů. Teď bude tablet, notebook, chytré hodinky atd. mít pevnou adresu a krásně se tak bude kontrolovat, odkud se připojujete. Jestli jste v práci, sedíte v kavárně, jste na dovolené, prostě opět lepší kontrola pohybu lidí, nyní dokonce i s přístupem k tomu, kam se zařízení připojovalo.
Dnes oproti tomu v kavárně nebo hotelu dostanete dynamickou adresu a nic ji s vaším zařízením nespojuje, při příští návštěvě dostanete jinou. Takže vzhůru a radostně do kontrolovaného světa.
Sledování mobilujících zařízneí se dá zařídit i jinak, než dle IP adresy. A zrovna IPv6 toto řeší pomocí privacy extensions, kdy si zařízení periodicky mění svoji IPv6 adresu z které navazuje spojení ven (respektive tu část posledních 64-bitů), klidně každých pár minut... Má jednu adresu napevno odvozenou od své MAC a prefixu ohlášeném routerem, tu normálně pro odchozí spojení nepoužívá (tumá pro příchozí spojneí teporeticky), ale pro odchozí spojení generuje periodicky adresu novou, kterou používá po definovanou dobu.
Ano, to IP je z rozsah daného ISP. Stejně jako teď za těma třema NATy mám stále IP z rosahu daného ISP. Jestli si myslíte, že to, že o tu jednu IP se dělíte se stovkama dalších uživatelů, že to zajišťuje nějakou anonymitu, tak to je omyl.
U toho IPv6 je to stejné. OK, o trochu míň schovávací, protože dle prvních 64 bitů dokážu rychle odlišit koncové sítě od sebe na první pohled. Tam je hlavní smysl toho extension eliminovat sledování na základě té MAC adresy, neboť v sítích s autokonfigurací normálě je těch 64 bitů LAN adresy pořád stejných a tím snadno sledovatelných. Tomu to extensions zabrání. Ale nebrání vůbec jiným technikám lokalizace a sledování, je to úplně stejné s IPv4 za Xtero NATy (pokud pomíjím techniky VPN tunelů někam jinam, ale i zde není principiální rozdíl mezi IPv4/6).
V prvním komentáři jste psal o ochraně soukromí a identifikaci zařízení. Teď píšete o útoku. Jak to spolu souvisí? Navíc bych NAT neoznačoval za "dost velký problém" pro útok. Mnohem větší problém je, pokud si někdo myslí, že to pro útočníka představuje dost velký nebo dokonce nepřekonatelný problém.
Pokud se s tím mobilem nebo tabletem budete připojovat přes GSM síť, budete mít jednu IPv6 adresu od operátora, stejně jako dnes můžete mít jednu veřejnou IPv4 adresu. Zda jste doma, v práci nebo v kavárně z toho nikdo nepozná. Pokud se z těch zařízení budete připojovat přes WiFi, budou mít pokaždé jinou IPv6 adresu přidělenou ze sítě, kam je to zařízení zrovna připojené. Jinak by vůbec nemohlo fungovat směrování v internetu.
Takže se v tomto směru rozhodně nemusíte bát o soukromí. Když si někde přečtete, jak fungují základní principy Internetu, bude vám jasné, že ta ztráta soukromí, jak si ji představujete, je i technicky nemožná a byla by v rozporu se základními principy, na kterých Internet funguje.
Soukromí, kde z logů na serverech různých poskytovatelů mohou státní orgány zjišťovat, kde se pohybujete?
Proč by mi měl poskytovatel WIFI přidělovat pokaždé jinou adresu? Směrování nebude problém. Prostě přiděleným adresním rozsahem bude určeno vše. Od jména vlastníka až po jeho domovský stát. A že se momentálně místo v ČR připojujete v USA vám na rozdíl od dneška stránky pro americké občany nezpřístupní.
A o rozporu se základními principy fungování internetu si nechte jen zdát. Už dnes máme MAC adresu, identifikaci podle dat odesílaných z prohlížeče (nemyslím sušenky) atd.
V budoucnu si dovedu představit, že v zájmu bezpečnosti obyvatelstva si půjdete koupit třeba tablet. A proti občance do něj nainstalují IP adresu z již přiděleného rozsahu nebo poslušný občan vyplní registraci a adresní rozsah mu bude přidělen. Vždyť teroristé pořád hrozí a tak se s radostí nechá šmírovat.
Vy si prostě nedovedete připustit, že techniku vlády čím dál víc používají na kontrolu obyvatelstva za radostného potlesku těch, co v nových technologiích vidí pokrok typu setina uživatelů nebude muset routovat adresy pro viditelnost nějakého zařízení z internetu.
Dobře, zkusím vám ten základní princip fungování internetu stručně popsat. Každé zařízení v Internetu má tam, kde je připojené, přidělenu číselnou adresu (IP adresa). Zařízení, která jsou připojena v jedné síti, mají začátek té adresy společný. Sítě, které jsou u sebe a vede do nich jedna cesta, mají začátky adres sítí společné. Atd. Takže když chce nějaký počítač z druhého konce světa komunikovat s vaším počítačem, nezná jeho přesné umístění. Akorát ví, že všechny počítače, jejichž adresa začíná nějak, jsou támhle někde v Evropě, a pošle svá data do Evropy. Teprve jak se pak blíží k cíli, počítače znají větší a větší část adresy.
Je to úplně stejné, jako v reálném světě – také máte adresu, kde je nejprve kontinent, stát, obec, ulice, číslo a až úplně na konci vaše jméno. A když vám bude někdo posílat něco z Austrálie, nebude australské pošťáky zajímat Klikatá 5 ve Vrbové Lhotě, ale zásilku pošlou do Evropy. Vaše adresa tedy bude třeba Evropa, Česká republika, Vysočina, Vrbová Lhota, Klikatá 5, Veterán. Když se přestěhujete, adresa se vám logicky musí změnit – nově budete mít třeba Španělsko, Madrid, Calle de Goya 75, Veterán. Nemůžete si nechat tu svou původní adresu, protože pak by vám nic nedošlo. Kdyby vám z té Austrálie poslali balík do Evropy, bude to ještě v pořádku. Ale v Evropě by vám ho pak podle té adresy poslali do ČR, ale vy už ve skutečnosti budete ve Španělsku. Jenže do Španělska by se ten balíček podle té vaší původní adresy nikdy nedostal, natož aby vás našel v Madridu.
Takže stejně, jako jsou poštovní adresy přidělovány na základě hierarchie geografických oblastí, a adresu prostě dostanete z té oblasti, ve které se právě nacházíte a z jí nadřazených geografických oblastí, na Internetu jsou adresy přidělovány na základě hierarchie sítí, a adresu dostanete z té sítě a jí nadřazených sítí, do které se právě připojíte.
Poskytovatel WiFi v kavárně vám tedy přidělí IP adresu z rozsahu jeho sítě, protože kdyby vám přidělil IP adresu z vaší domácí WiFi, budou data pro to zařízení chodit pořád do vaší domácí WiFi a ne do té kavárny.
Jinak to, že s IPv6 budou všechna zařízení přistupující k Internetu zároveň v Internetu adresovatelná, není žádný pokrok, to je návrat do nerozbitého stavu, který tady fungoval v době, kdy byl ještě IPv4 adres dostatek.
> A proti občance do něj nainstalují IP adresu z již přiděleného rozsahu nebo poslušný občan vyplní registraci a adresní rozsah mu bude přidělen.
To by mě zajímalo - abych mohl snadno přestěhovat třeba server bez změny IP adresy. Jak je to řešené, že mám IP adresu 2a01:5e0:36:5001::22 a přijdu do sítě 2001:67c:2190:c0de::/64 a bude to fungovat? To se v globální směrovací tabulce a ve všech routerech po cestě nastaví záznam 2a01:5e0:36:5001::22/128 -> 2001:67c:2190:c0de::/64?
> Prostě přiděleným adresním rozsahem bude určeno vše. Od jména vlastníka až po jeho domovský stát.
Přiděleným adresním *rozsahem* bude určeno něco podobného jako je dnes určeno „veřejnou“ IP adresou. Tedy nejspíš segment jako domácnost, dům či kus vesnice garážového ISP.
> A proti občance do něj nainstalují IP adresu z již přiděleného rozsahu nebo poslušný občan vyplní registraci a adresní rozsah mu bude přidělen. Vždyť teroristé pořád hrozí a tak se s radostí nechá šmírovat.
Opravdu je k tomuto potřeba dělat šaškárnu s IP adresama?
Ohledně toho:
"To by mě zajímalo - abych mohl snadno přestěhovat třeba server bez změny IP adresy. Jak je to řešené, že mám IP adresu 2a01:5e0:36:5001::22 a přijdu do sítě 2001:67c:2190:c0de::/64 a bude to fungovat?"
Ano, tohle je ve světě IPv6 možné, zajišťuje to služba MIP (Mobile IP), že jsem pod jednou svou "domácí" IP dostupný, ať s ní cestuji do různých sítí. MIP bylo pak z IPv6 backportováno i do IPv4, ale moc se nerozšířilo (používáme ho třeba na mobilech, kde mám tka mobily lidí dostupné pořád pod jejich domácí adrsou, ať jsou v jakékoliv síti).
Vyžaduje to spolupráci s routerem v mé domácí síti, kterému se mobilující klient ohlašuje a říká, kde je aktuálně k zastižení ve skutečnosti a kam se má provoz pro něj přesměrovat (a po návratu domů zae svému home agentovi řekne, že je doma a netřeba s edo toho plést).
Jinkas jistě, jde uživatlei přidělit jiný identifikátor, který krabičky budou hlásit, že patřím jemu ať jsem, kde jsme, již tak dneska skoro všechny činí, ať uživatle chce/nechce, včetně celkem přesné lokace. :-)
No, jenže se snažíte zamlčet, že mobile IP je služba, kde si zařídíte "proxy" (byť je to jen L3 proxy) ať už u vás doma, nebo u nějakého providera. Tato proxy do internetu vystupuje (mimo jiné) pod tou vaší mobilní IP adresou a jí pak hlásíte skutečnou IP adresu, na kterou vám ta proxy víceméně tuneluje provoz. Takže když bych si chtěl pomocí té mobilní IP (proxované přes domácí ADSL) poslat z mobilu v kanceláři v práci video do počítače v té samé kanceláři, tak se pěkně načekám (Záměrně dávám extrémní případ, aby bylo jasně vidět v čem se mobile IP liší od "běžné" IP).
Toto je prostě obezlička a ne skutečné stěhování IP adresy do jiné lokace (z pohledu routování).
Aha, tak pardon. Takže to je obezlička ve smyslu redirektu. Ta může mít své výhody, ale také má spoustu nevýhod a bude záležet na použití takové věci. Osobně bych se bál, že někdo vymyslí na tuto funkcionalitu nějaký útok, podobně jako se už stalo u spousty věcí v ICMP protokolu.
"Odvolavam co jsem odvolal. Slibuji co jsem slibil."
Podival jsem se letmo na http://en.wikipedia.org/wiki/Mobile_IP a prinejmensim IPv4 varianta je proxy s tunelem, a verim, ze IPv6 je totez.
Pakety „z mobilní adresy“ by taky přímo chodit neměly, to odporuje BCP38, které se snažíme všemožně tlačit kvůli DoSům.
Pokud si dobře vzpomínám, tak režim „proxy“ se používá pouze pro úvodní komunikace a/nebo když protistrana nepodporuje MIPv6. Jinak se nějakým způsobem (detaily si nepamatuji) domluví a IPv6 stack automaticky přepisuje v odchozích paketech cílovou adresu z domácí na dočasnou a v příchozích paketech dočasnou na domácí. Takže aplikace si myslí, že se stále baví s domácí adresou, ale po síti ve skutečnosti běhá provoz na/z dočasnou adresu. Aby se to nedalo zneužívat, musí takovému přepisování předcházet ověření podle domácího agenta a spojení mezi domácím agentem a zařízením na cestách musí být autentizované (IPSECem; jsou i ale nějaké experimenty s TLS, protože IPSEC se spoustě lidem nelíbí :) ).
Pro IPv6 to funguje trošku jinak, než pro IPv4. V podstatě po úvodní komunikaci od klienta na domácí mobilní adresu to home agent tunelem pošle mobilujícícmu cíli, ten zkusí vyjednat spojení přímo k dotazujícícmu tak, aby se dotazující dozvěděl jeho aktuální adresu a bavili se tak napřímo (route optimization). Pokud se nepovede (původní tazatel nepodporuje MIPV6), zkouší se režim asymetricky, kdy se posílá odpověd k původnímu tazateli se zdrojovou adresou mobilní napřímo a k mobilujícímu hostu to jde skrz home agenta (triangular routing), což většinou filtrování dneska zařízne a když selže vše nebo se ty dvě strany nedomluví, tak vše jde tunelem přes home agenta oběma směry (bi-directional tunneling) jako poslední nouzovka. Záleží, co se těm stranám mezi seobu podaří vyjednat napřímo (pokud obě strany podporujií MIPv6, tak mobilující klient může měnit své IPv6 adresy průběžně a pořád se domlouvají průběžně o tom, jak kam co posílat a pakety jdou mezi nima relativně napřímo).
U IPv4 to fakticky dneska funguje jen v tom režimu tunelu všeho oběma směry přes home agenta.
Ale kdeze ...
mobilni brana funguje ve dvou rezimech ... bud jednoduse v roli prostrednika (pokud koncove zarizeni mobilitu neumi) - pak proste vezme prichozi pakety a presmeruje je na aktualni IP "sveho" zarizeni, a prozmenu to zarizeni v tomhle rezimu vraci pakety sve brane a ta je predava jako odpoved.
Pokud komunikujici zarizeni mobilitu umi, tak udela jen jedine - rekne mu aktualni IP sveho zarzieni a dal pres branu uz zadna komunikace nebezi
Ten prvni rezim ma tu zasadni nevyhodu, ze vytezuje domaci linku v obou smerech, coz je prinejmesim hloupe. Technicky by samo slo, aby zarizeni odpovedi posilalo primo ... ale za normalnich okolnosti zadny IPstack neprijme odpoved z jine IP nez na kterou odesilal pozadavek. Samo pak by slo, aby zarizeni do hlavicky src naladovalo svoji domaci IP ... a takove pakety by v 99% pripadu i dorazily, ale ... .
V tom režimu triangular routing to funguje tak, že mobilní zařízení posílá odpověď přímo a jako zdrojovou adresu používá tu "domácí". Směrem k němu to jde tunelem. Nicméně zde záleží na tom, zda ta síť v které je a uplinky takový provoz neodfiltrují, což dle doporučení by měly. Pak, pokud oba komunikující strany nepodporují mobilitu, aby se dohodly na přímém spojení, tak musí jít oboustranným tunelem přes home agenta.
"Podival jsem se letmo na http://en.wikipedia.org/wiki/Mobile_IP a prinejmensim IPv4 varianta je proxy s tunelem, a verim, ze IPv6 je totez."
A přitom si o tom stačilo něco málo přečíst.
> Vyžaduje to spolupráci s routerem v mé domácí síti, kterému se mobilující klient ohlašuje a říká, kde je aktuálně k zastižení ve skutečnosti a kam se má provoz pro něj přesměrovat (a po návratu domů zae svému home agentovi řekne, že je doma a netřeba s edo toho plést).
Ano, a přesně proto mi to přijde krajně nepraktické pro deklarovaný účel „šmírování podle IP“. Obzvláště když zrovna IP adresa je věc, která lze celkem snadno podvrhnout kýmkoli, kdo má cestou MITM. Vymyslete si něco lepšího, třeba IPSEC klíče.