Vlákno názorů k článku IPv4 jako služba aneb jak síť zbavit dual-stacku od Bishop - Je fakt, že za 2-3 roky by se...

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.

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.

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

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/neko­mentoval 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.

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

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/pa­tro/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í+vyrou­tová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ě.

Dělají to naši partneři na mnoha desítkách tisíc klientů. I když se jim za to posmívám, mají neskutečný obchodní úspěch a nikdo si na tohle konkrétně nestěžuje.

Je vidět, že si opět tvoříš svůj vysněný svět, trošku odtržený od rality.

Tohle si mohli standardizovat a hádat se o tom, ale jen jako doporučení (nebo povinný standard pro to, když si ISP zvolí EUI64), naopak volba jestli EUI64 měla být čistě na ISP. Naopak měly být povinné od poćátku všechny možnosti autoconfigu, tedy i statefull DHCPv6

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?

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,

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!

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 :)

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.

j končím s reakce ma tebe,jak mi chytře poradil p. Caletka.

Jen ke komunikaci z A do B, vše nám funguje přesně tak jak jsem popsal nad cca 100k přípojkama, plácáš nesmysly, navíc tvůj přiklád s bárákem by fungoval, pokud by se právě mohlo do bytu přidělovat třeba /96

Cos nakonfiguroval ty?

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í.

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.

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.

Výjimka nemusí znamenat lidskou práci.

Obchodní model „neumíme na požádání přidělit větší rozsah IPv6, i když to slibujeme“ je jistě zajímavý a doufejme, že poskytovatelů, kteří mají tuto konkurenční nevýhodu, bude ubývat.

Ještě je tu varianta, že se to zakomponuje do standardního konfiguračního mechanismu. Když si můžu vybrat, kolik chci u toho VPS RAM, jak velké úložiště a kolik procesorových jader, není zas tak pracné přidat tam i výběr velikosti přiděleného adresního prostoru.

Tento názor pochází z planety Země. Na ní ještě někteří domorodci dodržují zásadu, že si nejprve přečtou celý text, na který chtějí reagovat. „Není zas tak pracné přidat…“

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.

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.

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.

Jé, pane Caletka to je tak strašně moje řec.

Pro zvídavé, zkuste si postavit robustnost L2 vedle L3, můžete začít tím, že do switche zacvaknete patchcord obouma koncema :) a uvidíte jak vám jich popadá těba 20 za sebou, pokud to nebudete mít rozdělené do VLAN.

Ano pod to se podepíši, v diskusích jsem to samozřejmě značně zjednodušoval

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?

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 :)

256 klientů při /56 per klient? to má bejt invektiva?

Ne "stačí mu ale neumí" - NECHCE. CHCE mít síť takovou jakou chce, samozřejmě ze zachováním interoperability vůči zbytku internetu. Úspěch sítě ať posoudí jen zákazník, ne teoretici na MIT či jinde.

Strašně těžký.

Už jsem omílal proč asi 10x, tak jenom například, co když budu ten koncák? Třeba uživatel domu a budu chtít odroutovat byty? Nebudu chtít L2? nejlepší a nejlevnější ISP my dá v akci jen /64? Co potom s prostorem pro koncáka?

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.

Pozor na to, routování přez link-local vám zakazuje RFC (teď nevim jaké). Takže ano, funguje to, ale je to zakázané, to samé co řeším s /64. Někdo mne tu dokonce chtěl včera udat na RIPE ať nám prý seberou všechny adresy :)

Opravdu? To se mi nějak nezdá. Třeba takové OSPFv3 nedonutíte ani párem volů, aby se bavilo po jiných než Link-Local adresách. A stejnými adresami také plní směrovací tabulky.