Vlákno názorů k článku Pravidla pro nové IPv4 adresy se zpřísňují, utáhněte opasky od sgfg - Musim reagovat na poslednu vetu (suvetie): „IPv4 končí a...
-
sgfg (neregistrovaný)
Musim reagovat na poslednu vetu (suvetie):
„IPv4 končí a IPv6 nastupuje, je to řešení na příštích pár desítek let a už klepe na dveře, na nás je, abychom mu otevřeli.“
Velkost IPv6 adresneho priestoru je:
340,282,366,920,938,463,463,374,607,431,768,211,456
A preto si nemyslim, ze IPv6 je riesenie na „příštích pár desítek let“:
„The earth is about 4.5 billion years old. If we had been assigning IPv6 addresses at a rate of 1 billion per second since the earth was formed, we would have by now used up less than one trillionth of the address space.“
Citacia je z http://www.tcpipguide.com/free/t_IPv6AddressSizeandAddressSpace-2.htm
Samozrejme na mnozstvo realne dostupnych adries bude velkou mierou vplyvat aj politika pridelovania, no nemyslim si, ze by sa jednalo o riesenie na „pár desítek let“. Ci je eticke, aby deti nasich deti pouzivali tie iste adresy, a ci taketo opatrenie sposobi stratu anonymity, je o niecom inom. -
bitsmith (neregistrovaný)
Len aby sa aj tento obrovsky priestor nezmenil rozhadzovanim na dalsi riadok v historii usmevnych tvrdeni :-)
http://www.rinkworks.com/said/predictions.shtml -
Bohužel nějaký de*ment (odpusťte mi to slovo) prosadil do nějakého RFC, že nejmenší alokovatelná lokální síť bude /80, tj 6 byte!!!, zřejmě aby se dala použít přímá konverze MAC. Pokud jsem firma a chci mít víc sítí, budu žádat po providerovi 256 těhle prostorů, tj. /72 (tohle není ten problém), abych mohl routovat několik takovýhle nesmyslně mohutných a neuvěřitelně řídkých adresních prostorů.
RIPE přiděluje standardně bloky /32, to znamená, že ISP zbývá pro interní sdresaci v nejhorším případě 5byte. To je sice 256× víc než celý prostor IPV4, ale takovýhle rozplýtvání v prvních letech se mi vůbec nelíbí a smrdí do budoucna readresacema uvnitř ISP.
Zaplaťpánbůh, že podle http://www.getipv6.info/index.php?title=IPv6_Addressing_Plans&oldid=2998 se zdá, že zřejmě půjde jen o doporučení.
No, my budeme přidělovat klientům sítě /116 (2 byte), což znamená např. 256 sítí pro 256PC. To je dost pro všechny. Podle našich statistik, tam stejně cca 85% koncáků má jedno PC. -
Mojža (neregistrovaný)
Ne, je to ještě víc „horší“, než si myslíte. Podle RFC 3587 a 4291 mají být koncové sítě /64. Současně se razí politika, že přes prefix delegation by koncák měl dostávat /48.
U pana Tomáše Šimka (garážové ISP?) bych se tedy nenechal připojit ani zadarmo. Jeho škudlilství a diletantství je opravdu trochu silné kafe. -
Ke škudlilství se přiznávám. Stejně jako „škudlí“ projektant, který (stavbu, síť, obchodní plán – dosaďte si co se Vám líbí) se snaží naprojektovat tak, aby splnil všechny parametry za co nejmenší náklady (nemyslím jen peníze, ale např. objem betonu, složitost atd.), robustně, elegantně a rozšiřitelně.
Situace s těmito RFC je taková, že nařizují projektantovi bez rozmyslu stavět pro každý kůlek v plotě podsklepený betonový základ.
Nám by nakonec nevadilo přidělovat zákazníku 8 byte adresy pro jeho síť (máme od RIPE prefix /32. Ale co tento klient udělá, pokud bude chtít více odroutovaných sítí mezi svými středisky? Buď i on poruší tyto „normy“, nebo si požádá o /48.
Nám pak zbydou pro interní adresaci 3 byte (to je „jen“ 16.7M zákazníků), klient má na routování svých sítí „jen“ dva byte, ale super, RFC plníme. Samozřejmě, díky takhle hubenému prostoru pro adresaci bude třeba na obou stranách optimalizovat routy na bity, na někajé rozumně hiearchické směrování (po osmi bytech per router) můžeme oba zapomenout.
Větším ISP přidělené /32 navíc za čas dojde, ale od toho je tu dalsí alokace že?
Model funguje, každý plastový switch v kanceláři a domácnosti pro několik počítačů (velice převážně 1) dostane 18446744073709551613 adres, hlavně že nebude potřeba DHCP6 na Ethernetu (jedna z mnoha L2 technologií, to asi jako zaměstnanec T-mobile víte že?).
Ano model funguje, jen se nemůžu ubránit tomu, že jsem čekal víc a někdo nám i zákazníkovi zatraceně ztížil práci nesmyslnou byrokracií, která stejně do budoucna padne, až ji 30% ISP (převážně „Gárážových“ ISP – mají na to odvahu) bude ignorovat), včetně půlky firemních zákazníků (co nemusí vykazovat, např. kvůli ISO, že plní vše co je dáno), domácnosti to řešit nebudou.
Rád bych s vámi diskutoval, ale místo urážek zkuste příště přinést nějaké argumenty (ty nejsou ani v těch RFC). K té garážovosti: Ano, proti T-mobile jsme asi garážovka, nicméně nám z té „garáže“ do NIXu prokazatelně teče více než z celého T-mobile. -
David Hrbáč (neregistrovaný)
Přesně tak. Já z nasazení IPv6 a RFC mám pocit, že čím větší adresní prostor máme, tím více plýtváme zdroji. Koncovým bodům, ve smyslu sítí, se přiděluje standardně /64 a jde to do takových absurdit, že /64 se používají na spojovačky. Pro jeden server, rozumněj slovy jeden kus HW, jsme onehdy v jednom telehousu žádali o přidělení IPv6. Box má dvě IPv4 adresy, takže jsme chtěli k tomu adekvátní počet IPv6 adres. Provider se mne zeptal, zda chci 2 IPv6 adresy či celý /64 prefix… Co myslíte, že jsme si vzali…
-
jkjkj (neregistrovaný)
Celkom nerozumiem Vasej argumentacii. Ak ste ISP, ktory ma mnozstvo predplatitelov s jednym PC, mozete takychto predplatitelov dat na jeden /64 subnet (rfc3177):
[i] When a network number is delegated to a place that [b]will not[/b] require subnetting, therefore, it might be acceptable for an ISP to give a single 64-bit prefix – perhaps shared among the dial-in connections to the same ISP router.[/i]
Ak mate predplatitela(instituciu), ktory ma v umysle si dalej delit siet, date mu /48 prefix (rfc3177):
[i]the IETF's IPNG working group has recommended that the address block given to a single edge network which may be recursively subnetted be a 48-bit prefix. [/i]
V com je teda problem? Mozno nerozumiem ako ste to mysleli. Dakujem. -
Tak to zkusím vysvětlit polopaticky. Není problém, v tom, že bychom něco nedokázali, nebo neuměli rozchodit. Problém vidím v tom, že přidělit domácnostem /112 bez těchto omezení je ve výsledku pro obě strany daleko méně limitující než jim přidělit /64 a respektovat normy! Přidělit jim 4 adresy pro 1 PC zavrhuji rovnou, dost klientů má již více PC a tento krok by byl krokem do pekel. Neustále bychom řešili: „přikoupil jsem PC, nefunguje atd.“
Proč je /112 méně limitující? Pokud domácnost bude respektovat normy, nemůže si udělat na /64 další podsítě. Ještě jednou: domácnost dostane 18446744073709551616 adres A NEMŮŽE JE ROZDĚLIT NA PODSÍTĚ!
Jak psal někdo nahoře, seriózní ISP by se měl dotázat: stačí Vám jedno PC (přidělí /126), chcete mít malou síť? (přidělí /64), nebo chcete mít více sítí (přidělí /48). Nebo každému přidělí /48 (to už je opět systémové řešení, protože pak se ISP tohle řešit nemusí). Co ale řeší, že má POUZE 3 byte na interní směrování, což opět není zásadní problém, ale zase to zesložiťuje práci. Zákazník má POUZE 2 byte na interní směrování, což může být opět problém, zvlášť při potřebě hierarchického dělení směrovací politiky na více úrovní.
Kdybych např. jako správce firemní sítě měl tři státy, ve dvou státech tři kraje a v každém kraji 5 poboček, v pobočce několik oddělení a v každém oddělení několik PC:
a) kašlu na RFC: vyhradím, 1byte na adresu PC v síti, 1, byte na adresu sítě oddělení, 1byte na adresu pobočky, 1byte na adresu kraje atd. Stačí mi v pohodě /96
b) respektuji RFC: horní případ nelze použít (pokud má síť oddělení mohutnost /64, pak bych potřeboval pro adresní plán 4 byte, tj. pro firmu síť /32 TO JE ALE ALOKACE OD RIPE PRO CELÉ ISP!!! VYPLÁCANÁ PRO JEDNU FIRMU!!!) Chápete to? Já ne. Takže budu muset velice pečlivě plánovat: 2 bity použít pro stát, 2 pro kraj, 3 pro pobočku, řekněme 4 pro addělení a 64 pro adresu PC. Hurá dostal jsem se na /53! Do /48 mám ještě rezervu. No jo, ale co když management bude chtít dva státy navíc? celé to přeadresuji? nebo tyhle státy nějak nesystémově přilepím z nevyužitého prostoru?
Takže, už chápu, že tyhle RFC pomůžou:
1) Trochu usnadnit konfiguraci domácích plastových krabiček.
2) udržet, kvůli neustálým dodatečným alokacím v RIPE a ostatních RIRech, včetně ICANNu jejich současnou důležitost a pracovní místa (zase budou „politiky“, aby se IPv6 nevyplítvalo, až LIROVÉ budou hltat alokace po stovkách).
3) to samé platí do ISP, kde budou odborníci svelkýma hlavama po jednotlivých bitech optimalizovat velikosti jejich lokalit včetně rezerv, aby to pak nemuseli přečíslovávat nebo tam lepit tam dodatečné rozsahy.
4) Udržet Ciscu a dalším výrobcům zisky. S nesprzněným hierarchickým směrováním, by časem ISP mohli přijít na to, že jim stačí L3 switche s max několika desítkami hw routes. No radši to zkomplikujeme, ať potřebujou zařízení, které něco „umí“.
Za svojí firmu prohlašuji: pokud to bude jen trochu technicky možné (implementace ve Windows nebude chtít nějaké zvláštnosti, které budou komplikovat koncákům život) najdu za naši firmu vůli tyhle nesmysly ignorovat! Ano, beru na sebe riziko, že zde budu opět označen za garážistu, diletanta atd. Nicméně, ignorace nám umožní snadnější, levnější směrování a zákazníkům pomůže (pokud bych měl pocit, že to bude zákazníkovi vadit, normami bych seřídil – jsou to moje prachy, věrte mi, ale že nebude). -
davro (neregistrovaný)
Sice zajímavá argumentace, bohužel jediné ospravedlnění tohoto přístupu je, že někdo potřebuje „hierarchické dělení“.
K čemu? K tomu, aby si správce lépe zapamatoval kde má konkrétní síť? Je to možné, ale dost zbytečné. K lepšímu vytváření třeba firewallových pravidel? K tomuto stroji mohou pouze lidé ze státu XY a nesmějí odnikud jinud? (obvykle je to spíš tak, že je požadavek „k tomuto serveru mohou pouze lidé z obchodního oddělení odevšad“)
Podívejte se do současných globálních routovacích tabulek Internetu. Připadne vám, že tam existuje nějaká hierarchie? Je tam rozdělení maximálně tak na jednotlivé RIR, a pak už nikdo nepozná vůbec nic.
Co se týká toho příkladu, tak /53 znamená, že využívám pouze 1/16 adresního prostoru, kterou jsem dostal. To znamená, že si dotyčný dost mizerně tu hierarchii rozvrhl. Protože s dělením 16 bitů má mnohem víc volnosti než v současné situaci. -
Děkuji za věcné argumenty, poprvé od „oponentů“ v debatě.
K čemu? K tomu, aby si správce lépe z… K lepšímu vytváření třeba firewallových pravidel…
Tak, to je přesně ono. Proč to prokristapána nenechají na dotyčném. Normy jsou dobré, ale proč někomu nařizovat, jak má stavět síť, když to není nutné? Nebylo by lepší pravidla maximálně uvolnit a nechat ruku trhu ať vybere? Jako u projektantů domů: Normy ohledně únosnosti, požadavků na tepelné izolace jsou dobré, normy na to, že každý barák musí mít pětibarevnou fasádu (aby ho majitel poznal) jsou nesmysl. Jsem přesvědčen, že násilné určování prefixů, je za touto hranicí.
Podívejte se do současných globálních routovacích tabulek Internetu. Připadne vám, že tam existuje nějaká hierarchie?
Zatim mají wolrd IPv6 tables asi 35k záznamů (IPv4 500k). Skoro každý ISP už má IPv6 alokaci. Já patřím k těm naivkům, kteří věří, že by IPV6 síť mohla být daleko víc hierarchická. Bohužel takhle bude za chvíly stejný bordel jako v IPv4. Víte zajímalo by mne, co by se stalo, kdyby někdo navrhl nový široce používaný L2 protokol o mohutnosti MAC třeba 20byte :) Veškerá výhoda těchto nařízení tatam.
Co se týká toho příkladu, tak /53 znamená, že využívám pouze 1/16 adresního prostoru, kterou jsem dostal. To znamená, že si dotyčný dost mizerně tu hierarchii rozvrhl. Protože s dělením 16 bitů má mnohem víc volnosti než v současné situaci.
To ano, má více volnosti, nicméně, kdyby nebyl onen stupidní požadavek, měl by volnosti ještě 1099511627776× více.
Víte, po zavedení IPv4 také byly třídy A/B/C, nic jiného oficiálně nešlo. Když bylo ouvej najednou se „povolilo“ classless adresing. My na něco takového čekat nebudem :) -
davro (neregistrovaný)
Vycházíte z toho, že hierarchie je dobrá věc. Jenže hierarchie je věc špatná. Zkuste se třeba zamyslet nad existující analogií v L2. Tam taky existuje naprosto hierarchická struktura pomocí STP. Jenomže dnes už se všichni od Cisco až po IETF snaží STP zbavit, tak aby byla síť víc full-mash, např. pomocí protokolu TRILL. TRILL je založen na klasickém směrovacím protokolu IS-IS, takže nebojte i těch 20 bytových NSAP adres se dočkáte.
-
Mluvíte rozumně, ale proč to sakra autoři nenechají na mně? Proč mi někdo zakazuje normou stavět nehezký barák? Komise posuzující kulturu byly za minulého režimu do, internetu se nehodí.
Pokud i vy věříte, že budou mít L2 adresy někdy víc než 8 byte, proč teď tak obhajujete obětování 50% mohutnosti směrovacího prostoru pro dočasnou feature jedné rodiny L2 protokolů z celé množiny? Uznávám, že nejpoužívanějšího.
Já věŕím, že IPv6 by tu mělo být v podstatě do konce civilizace v této podobě :) Tenhle nesmyslný krok bude stát hodně enregie v budoucnu změnit.
Ještě bych se zeptal: vy tyto normy vidíte opravdu užitečné? Nebo převládá potrěba respektovat standardy? -
pavlix (neregistrovaný)
„Mluvíte rozumně, ale proč to sakra autoři nenechají na mně? Proč mi někdo zakazuje normou stavět nehezký barák? Komise posuzující kulturu byly za minulého režimu do, internetu se nehodí.“
To jsou výkřiky do tmy, nic takového se neděje. Nicméně nikdy vyhovět všem.
„Pokud i vy věříte, že budou mít L2 adresy někdy víc než 8 byte, proč teď tak obhajujete obětování 50% mohutnosti směrovacího prostoru pro dočasnou feature jedné rodiny L2 protokolů z celé množiny?“
O kterém L2 protokolu mluvíte? Snad ne o Ethernetu, ten pokud vím 64-bitové adresy zatím nemá.
„Ještě bych se zeptal: vy tyto normy vidíte opravdu užitečné? Nebo převládá potrěba respektovat standardy?“
Celosvětový síťový protokol lze realizovat pouze celosvětovou normou. -
To jsou výkřiky do tmy, nic takového se neděje. Nicméně nikdy vyhovět všem.
Myslím, že právě přesně to se v RFC 3587 a 4291 děje :(Celosvětový síťový protokol lze realizovat pouze celosvětovou normou.
Neměly by být stavěny normy tm, kde mají být maximálně doporučení (a zároveň jde o velmi důležité věci). „Světu“ je jedno jak cílovou adresu k cíklovému serveru dosměruji, a jak mohutná je sít s posledním skokem, že? -
pavlix (neregistrovaný)
RFC 3587 je mimo hru (viz jeho status).
RFC 4291 je řekněme zbytečně moc zaměřené na EUI-64. Můžete zkusit navrhnout změnu nebo počkat, jestli změna přijde z praktického světa sama.
„„Světu“ je jedno jak cílovou adresu k cíklovému serveru dosměruji, a jak mohutná je sít s posledním skokem, že?“
Tady opravdu jde o prosazování toho, aby se daly zařízení uzpůsobit (aspoň by default) na bezstavovou konfiguraci a aby se prosadily slušné prefixy od providerů.
Dá se říct, že tuhle snahu vítám (jako zákazník, který bude rád za /48, pokud ho vůbec dostane). Na druhou stranu uznávám, že pro fungování IPv6 routingu to nemá naprosto žádný význam. -
davro (neregistrovaný)
Však vás nikdo nenutí ty standardy používat. Používejte si, co uznáte za vhodné.
Co se týká těch L2 adres, tak nepředpokládám, že by se ujalo něco výrazně delšího než MAC adresy v ethernetu.
Normy považuju za užitečné. Umožňují nám totiž vůbec fungovat. Jenom si představte výrobce šroubků, kde bychom byli bez standardů. -
pavlix (neregistrovaný)
„Proč to prokristapána nenechají na dotyčném. Normy jsou dobré, ale proč někomu nařizovat, jak má stavět síť, když to není nutné?“
Ty normy nic takového nenařizují. Jistě jsou jejich důsledkem určitá omezení, ale ta mají určitý praktický základ.
„zajímalo by mne, co by se stalo, kdyby někdo navrhl nový široce používaný L2 protokol o mohutnosti MAC třeba 20byte :)“
Řekněme, že se došlo k číslu 8 bajtů pro routing a 8 bajtů pro lokální adresu. Pokud by se ten názor nějak výrazně přehodnotil v daleké budoucnosti, bude k dispozici jiný hardware a pravděpodobně nebude problém přejít na další iteraci protokolu.
Chápu, že nová iterace protokolu vždy přináší i své problémy, proto malý rozbor, co by fungovalo a co ne:
Link-local adresy: fungovaly by, jen by se musely generovat jinak (asi náhodně s nějakou mírou persistence).
Stateless autoconf (EUI-64): nefungovalo by
Stateless autoconf (privacy extensions): fungovalo by bez problémů
DHCPv6 (DUID-based): fungovalo by bez problémů
Tzn byla by to určitá komplikace, nicméně neznamenala by nemožnost nasazení IPv6… na druhou stranu obětovalo by se jen to nejnutnější.
„Já patřím k těm naivkům, kteří věří, že by IPV6 síť mohla být daleko víc hierarchická.“
Pokud vím, tak mezi ně ze začátku patřili i sami návrháři IPv6.
„To ano, má více volnosti, nicméně, kdyby nebyl onen stupidní požadavek, měl by volnosti ještě 1099511627776× více.“
Ten požadavek je tu kvůli ISP, aby zákazníka zbytečně neokrádal o možnost použít aspoň těch 16 bitů k rozčlenění a stateless autoconf.
Nemá žádný vliv na to, jak si zákazník rozvrhne síť postavenou na DHCPv6, tam má tu volnost takovou, jakou si může jen přát. -
Ten požadavek je tu kvůli ISP, aby zákazníka zbytečně neokrádal o možnost použít aspoň těch 16 bitů k rozčlenění a stateless autoconf.
Nemá žádný vliv na to, jak si zákazník rozvrhne síť postavenou na DHCPv6, tam má tu volnost takovou, jakou si může jen přát.
A mají technické normy řešit obchodní vztah firma zákazník? Pokud ano, dobrá ale tyto normy přece platí i pro zákazníky! tudíž zákazník, který si svých /48 rozdělí např na /120 tyto RFC také porušuje a teoreticky by neměl dostat ISO9000, protože nemá v pořádku svoji síť. Je to tak? Nebo tyto RFC řeší jen vztah ISP<->zákazník? mně vychází závazné obecně, jak jsem se tím pročítal. -
pavlix (neregistrovaný)
ISO9000 není moje parketa, takže to nechám na jiných.
„A mají technické normy řešit obchodní vztah firma zákazník?“
Ta norma popisuje síť, ve které funguje bezstavová konfigurace. Má to další, například i bezpečnostní důsledky. Může se vám například stát, že na vaše zákazníky ve stejném /64 či dokonce /48 bude aplikován například filtr na počet requestů na některých službách.
Takže… na jednu stranu by to tam vůbec nemuselo být a vy byste byl asi spokojený. Na druhou stranu… možná nedohlédnete (ani já ne) do všech důsledků s tím spojených. Takže pokud byste prosazoval změnu v příští (pravděpodobně několikáte) iteraci jakéhokoli RFC ohledně IPv6, můžete narazit na hromadu souvisejících problémů.
Samozřejmě to lze brát jako obecně závazné a držet se daného schematu. Já to beru spíše s pohledu technického než „politického“. Takže kdekoli vím, že porušení nějakého pravidla nezpůsobí chybné chování, posuzuju pro a proti a ne zákazy/výjimky.
Můžete to brát tak, že vaši připomínku považuju za oprávněnou, i když mě její vyřešení nepálí. -
davro (neregistrovaný)
ad 4) Vaše řešení ovšem narozdíl od standardu znamená, že i ta nejhloupější krabička si bude muset pamatovat směrovací informace až do prefixu /128 místo toho, aby si mohla podle rozumného předpokladu pamatovat pouze /64 (zbytek leží v místní síti). Hierarchické směrování je v dnešní situaci nesmyslné, zkuste se podívat, jakým způsobem jsou jednotliví ISP propojení. Hierarchické směrování by znamenalo hierarchickou topologii Internetu a to je něco, co je v dnešní době absolutně nepřijatelné.
Dál bych rád věděl, co byste řekl svému řediteli, až vám začnou odcházet zákazníci, protože jim kvůli vašemu nedodržování standardů přestanou fungovat některé aplikace. Řeknete mu „to je chyba těch aplikací, že nepočítají s mým geniálním rozdělením!“? (Karel s Pepou si chtějí po IPv6 telefonovat, ale ty jejich telefonky počítají jen se sítěmi většími než /64?) -
Právěže ty nejhloupější krabičky mají v sobě Linux nebo jiné sw řešení, kterému je velikost asociativního klíče celkem pumpička, algoritmická složitost vyhledávání s velikostí klíče roste pouze lineráně, celkově nalezení route má logaritmickou slošitost, která je zanedbatelná. Ale pravda, toto by mohl být argument u hw routerů (L3 switchů), tam realizace opravdu vyjde trochu nákladněji. Ale RFC připouštění přidělování /128 prefixů, takže výrobce to (naštěstí) musí naimplementovat kompletně.
Hierarchické směrování je dnes nemožné s IPv4, s IPv6 by to mohle být pěkný favor, ale bohužel ne pokud nějaký diletant nařídí víc než 50% mohutnosti zahodit kvůli nesmyslu, pak je to velká škoda.
Dál bych rád věděl, co byste řekl svému řediteli, až…
Bohužel odpovídám jen sám sobě a kolegovi. Ani nevím co je v případě neúspěchu lepší.Když už tu takto diskutuji, zkusil jsem si vykonfigurovat pokusný okruh z ČB do Pahy na Sitel (Linux proti L3 sw Edge-core ES4626SFP) a pověsit na něj IPv6 /120. Všechno funguje, svět se ještě nezbláznil :)
ES4626-SFP(config-if-vlan51)# ipv6 address 2a02:0c60:0000::1/120 enable config t interface Vlan51 ipv6 address 2a02:0c60:0000::1/120 ES4626-SFP(config-if-vlan51)# ... core1:~# ip addr add dev eth0.51 2a02:0c60:0000::10/120 PING 2a02:c60::1(2a02:c60::1) 56 data bytes 64 bytes from 2a02:c60::1: icmp_seq=1 ttl=64 time=13.1 ms 64 bytes from 2a02:c60::1: icmp_seq=2 ttl=64 time=6.00 ms 64 bytes from 2a02:c60::1: icmp_seq=3 ttl=64 time=5.84 ms 64 bytes from 2a02:c60::1: icmp_seq=4 ttl=64 time=6.02 ms
-
davro (neregistrovaný)
Nikdo neříká, že to fungovat nebude. Nicméně:
1. IPv6 je určeno také pro sítě typu zapoj a funguj. S těmito prefixy nebude fungovat autokonfigurace, základní vlastnost IPv6. Někdo bude muset nakonfigurovat DHCPv6 server nebo nastavit adresy ručně. S tím se u normální domácnosti až tak moc nepočítá. Prostě zapojím do sítě ledničku, mediální centrum, atd., vůbec nic nenastavuju a přesto všechno funguje.
2. co se týká hierarchie, tak jistě každého potěší, když si člověk, který má videokonferenční hovor mezi Sýrií a Marokem musí komunikovat přes nějaký centrální bod s největší pravděpodobností v USA. Jak by musely vypadat ty routery, které by dělaly to přehazování paketů mezi kontinenty? V současnosti máme standardizovaný 100Gbit ethernet, ale na přehazování dat na těch nejvyšších úrovních by nestačila ani hodně tlustý vazek takových linek. Nehledě na to, když nebude slabým místem linka, tak bude slabým místem router – Cisco CRS-1 nebo CRS-3, což jsou dnes asi nejvýkonnější routery, mají pouze jeden port na 100Gbit kartě. Navíc se kvůli hierarchii nedá dost dobře řešit redundance a vyvažování provozu. Prostě – hierarchické směrování je nesmyslné, ikdyž ušetřím na složitosti routovacích tabulek. -
ad 1) DHCP se nám generuje pro každou přípojku (FTTB i bezdrát) už teď. S generací DHCPv6 počítáme, máme toereticky vyřešeno, není to problém.
Ad 2) hierarchické adresy!=hierarchické propojení! Na správné proroutování máme směrovací protokloly (pouźíváme ospf) takže počítání potřebných gigabitů bude stejné jako bez hierarchicky naplánovaných adres
Btw na takovéhle uzly bych volil asi Brocade nefo Exascale :) -
čistě obecně, za předpokladu dokonalé alokace adres do těchto regionů. Nicméně oba víme, že to povede ne na stanovení dostatečných rezev (typu Praha 1000000* /48, Plzeň 350000* /48 atd) ale na systematické řešení např sm+erovat do lokalitz univezální route např. 256* /48 do lokalit a když to dojde, tak dalši a další.
Vznikne stejný bordel jako za IPv4.
My věříme, že s novým protokolem bude stačit směrovat jednu síť na jedno místo a ta tam bude stačit napořád.
A pokud to nebude násilné (zase blázni nejsme) budeme tyto „estetické normy“ ignorovat. -
Sob (neregistrovaný)
Abysme si rozumeli, ja neobhajuju skudleni s adresama za kazdou cenu. Kdyz uz je jednou vymysleny, ze autokonfigurace na /64 je nezbytnej zaklad a tezko uz se to zmeni, tak nezbyva nez se tomu prizpusobit. Mensi sit se proste beznymu uzivateli dat neda, pokud ma byt jistota, ze mu vsechno bez problemu pojede. Ale to nic nemeni na tom, ze je to naprosto sileny plytvani. A /48 je ze stejnyho soudku. Automaticky 65 tisic podsiti na zakaznika, proboha na co? Pro velky klidne, ale beznymu domacimu uzivateli staci treba /60 a omezujici to bude tak pro jednoho z milionu. Proste to cely pusobi jen jako zbytecna demonstrace, ze IPv6 adres je *fakt hodne*.
-
pavlix (neregistrovaný)
Naopak, podle mě to celé vede na to, že IPv6 se bude používat daleko víc podle potřeb, než podle těžce vyškudlených adres, jako je to teď na IPv4.
Ten systém mi připadá navržený naprosto geniálně, 16 bitů na lokální dělení (tedy 64k podsítí) a 64 bitů na automatickou konfiguraci statických adres (pomocí MAC/EUI-64), případně dynamických adres (privacy extensions). -
vidíte, mne to přidatá naprosto stupidní. Pokud začnete routovat větší síť, daleko složitější je udělat pořadný číslovací plán. Pro to je 16bitů prostě strašně málo (obecně), takže zdegradujete tam, kde teď je IPv4
Naopak MAC/EUI-64 je vlastnost vázaná na jeden z L2 protokolů (ethernet). Nemá být náhodou L3 navrhován v maximální nezávislosti na L2? Co když pracovní skupiny kolem 802 vymyslí 802.3-new verzi ethernet rámců se 100bitů MAC adresou?
oni totiž 48bit MAC taky docházejí :) Pak bude tato nesmyslná feature úplně k ničemu. -
pavlix (neregistrovaný)
„Nevím jak je to s rezervovanými kódy pro jednotlivé výrobce a podobně, to přiznávám, jen vím, že až to někdo bude redefinovat, MAC spíše zdvojnásobí, než by přidával 2 byte. Tedy pokud jim někdo nepřiloží ke krku nůž v podobě EUI-64 :)“
V rozporu s vaším tvrzením to redefinovali právě o ty 2 bajty a tím z EUI-48 vytvořili EUI-64. EUI-64 pokud vím není ze stejné dílny jako IPv6. -
pavlix (neregistrovaný)
16 bitů na číslování sítí měly v IPv4 jen ty největší organzace, kterých ani v nejdivočejších snech na světě nemohlo být víc jak 256.
„Naopak MAC/EUI-64 je vlastnost vázaná na jeden z L2 protokolů“
Špatný předpoklad, EUI-64 není nijak vázána na žádný konkrétní L2 protokol. Zbytek vychází právě z tohoto špatného předpokladu.
„oni totiž 48bit MAC taky docházejí :)“
Právě proto se EUI-64 používá. -
16 bitů na číslování sítí měly v IPv4 jen ty největší organzace, kterých ani v nejdivočejších snech na světě nemohlo být víc jak 256.
My si v naší síti dokážeme na číslování sítí představit třeba 64bitů, naopak EUI-64 nevidíme jako (tolik) potřebné. Proto mi vadí, že je nám vnucováno to co by mělo být doporučováno. -
pavlix (neregistrovaný)
EUI-64 pokud vím tak moc vnucováno není. Koncový zákazník může svoji síť nakonfigurovat prakticky jakkoli, pokud bude navenek vypadat nakonfigurovaná správně.
Ano, dá se najít pár citací z RFC, které nasvědčují tomu, že /64 je všeobecná povinnost pro všechny zákazníky… ale pokud zákazník poruší něco, co nemá vliv na funkčnost ani z pohledu aplikací ani z pohledu vnějšího světa… řekl bych, že na sebe tuto zodpověnost může vzít.
Pokud ale to samé udělá ISP s rozsahy pro zákazníky, prakticky vždy tím zákazníka poškodí. Tyto pasáže ve standardech mají z hlediska koncového zákazníka
až příliš přísný tón, ale důvod vidím spíš ve snaze zabránit ISP zákazníka poškodit, což je ve chvályhodné.
Možná by to šlo napsat líp, ale i současné znění považuju za velmi použitelné.
Jinak EUI-64 a bezstavovou konfiguraci považuju za velmi užitečnou možnost. -
Jimmy (neregistrovaný)
64 tisíc podsítí pro jediného zákazníka je málo ?
Schválně jsem se podíval do routovacích tabulek největší czfree sítě v ČR. Cca 13 000 členů, cca 41 000 pc, cca 450 routerů různé velikosti (většina OSPF, páteřní OSPF + BGP) a interní routovací tabulka má lehce přes 1400 položek.
Jak velký musí být zákazník aby mu nestačilo 64 tisíc podsítí ? A nebude náhodou takový zákazník už tak velký, že stejně bude mít provider independent adresy ? -
Ježíš marjá, ňenuťte mne odpovídat, aniž by jste četl celou debatu co tu vedu. Samozřejmě že 65ti podsítí je obecně vzato „dost“.
Já od nového protokolu čekám pohodlnější (hierarchické) adresování, tj. jeden byte nechat na město, jeden na okrsek, jeden na hotspot a jeden na zákazníka. Takže bych rád podsítí 4 miliardy :)
Protože 99% členů má 1–5, je EUI-64 zbytečný favor, který se týká jen jednoho L2 protokolu, ale podřídí se mu stavba celého nového internetu (kromě nás, my se tímhle nesmyslem řídit nebudeme :) ) -
pavlix (neregistrovaný)
„Já od nového protokolu čekám pohodlnější (hierarchické) adresování, tj. jeden byte nechat na město, jeden na okrsek, jeden na hotspot a jeden na zákazníka.“
Ahááá, to jsem tu ještě nečetl (ale možná moje chyba).
„EUI-64 zbytečný favor, který se týká jen jednoho L2 protokolu“
Jen připomínám, že toto není pravda.
„(kromě nás, my se tímhle nesmyslem řídit nebudeme :) )“
Pak vězte, že to bude jeden z důvodů, proč zvolit vaši konkurenci. -
Pak vězte, že to bude jeden z důvodů, proč zvolit vaši konkurenci.
Teď jste uhodil hřebíček na hlavičku! Přesně tak by to mělo být (myslím to vážně). Tohle by fungovalo i bez RFC. Teď nás RFC trocu poškozuje, protože je prokazatelné, že ze svými /96 porušujeme normy. Jinak by to bylo naprosto v pořádku a stačilo by to všem našim zákazníkům.Jak jsem již psal, všude inzerujeme možnost veřejné IPv4 zdarma. Víte kolik se na ní ptá lidí? 1–2%! Asi tušíte, že vsadím boty, že tohle porušení norem obchodně ustojíme. Navíc, váš specifický požadavek na /48 by zřejme propadl až na mů stůl (jsme celkem malá pružná firma) a já bych Vám ho schválil :)
-
pavlix (neregistrovaný)
Jenže ono neexistuje žádné RFC, jehož účelem je nařídit vám přidělovat /48. To RFC, o kterém mluvíte je klíčové RFC, které určuje adresování IPv6 vůbec.
To, o čem mluvíte je nejméně důležitá část tohoto RFC, bez kterého by opravdu IPv6 fungovalo. Pouze by nefungovala bezstavová konfigurace.
Ono je potřeba číst trochu mezi řádky, nejen že to v té normě napsáno je, ale i proč to tam je. To, co vy nabízíte není úplně plnohodnotné přidělení podle RFC, protože neumožňuje využít všech konfiguračních možností IPv6.
Pokud je s tímhle zákazním srozuměn, tak v tom nevidím problém. Pokud by to ale v RFC chybělo, byla by taková alokace považována za normální (standardní), což by bylo špatně, IPv6 normy by tak byly nekonzistentní.
„Víte kolik se na ní ptá lidí? 1–2%“
Většina firem se nerozhoduje podle počtu hlav, ale podle peněz.
„Navíc, váš specifický požadavek na /48 by zřejme propadl až na mů stůl (jsme celkem malá pružná firma) a já bych Vám ho schválil :)“
Tak to je jiná. Takovýhle postup by vám tu pravděpodobně schválilo daleko víc lidí. Doteď to vypadalo, že /48 nedáte. -
„Navíc, váš specifický požadavek na /48 by zřejme propadl až na mů stůl (jsme celkem malá pružná firma) a já bych Vám ho schválil :)“
Tak to je jiná. Takovýhle postup by vám tu pravděpodobně schválilo daleko víc lidí. Doteď to vypadalo, že /48 nedáte.
Již jsme se posunuli dále od norem, já to mez řádky toho RFC také čtu, nicméně si pořád myslím, že to mělo být „jen“ doporučení.
V dnešním Telco bysnyse, neexistuje říct zákazníkovu ne :) Tuhle chybu nikdy neděláme a nedělá nám problém dělat kvůli lidem extrabuřty. Je snimi jedinný problém a to jejich intergace do systému, nebo hůře alespoň jejich dokumentace, aby je by schopen řešit helpdesk, obchod o nich věděl atd. Nejlíp funguje nabízet sice věci zdarma (veřejná IP, blok /48 dle RFC :), pevné SIP číslo k tomu), ale nedávat je automaticky, nechat se zákazníka zeptat. A máte odfiltrováno 98% lidí, pro které telco služby nejsou dnes významejší než rohlíky nebo párek. -
pavlix (neregistrovaný)
„V dnešním Telco bysnyse, neexistuje říct zákazníkovu ne :)“
Dá se říct, že si docela dobře rozumíme. Jako zákazník bych tedy došel k výsledku, což je důležité.
K tomu RFC… řekněme, že ještě pořád chápu i důvody, proč to tam je, i důvody, proč by to tam být nemělo… a možná bych to dokázal shrnout slovy „účel světí prostředky“.
Mám pocit, že kdyby to v tom RFC nebylo a řekl bych si o /48, že byste mi možná dokázali vysvětlit, že ji nepotřebuju, a nebo že to bude stát hodně peněz :). Je to tak? -
pavlix (neregistrovaný)
Pro mě z toho plyne důsledek: Zákazníkům to pomohlo, ISP to neomezilo víc než původní schéma v IPv4 (myslím v době plýtvání), a ISP může dávat:
/48 těm, kteří chtějí tvořit standardně řešenou podnikovou síť (teď nemyslím přesné znění RFC, ale síť, která téměř beze změny přežije změnu poskytovatelů, administrátorů i třeba velikosti).
/x, kde 48 < x < 64 těm, kteří chtějí jen jednoduché dělení na pár sítí
/64 těm, kteří mají jednu SOHO krabičku s autokonfigurací
/x, kde 64 < x < 127 těm, kteří jsou ochotni si nakonfigurovat DHCPv6, nebo kterým spravuje síť přímo poskytovatel.
/127 nedává smysl, stejně jako /31 IPv4
/128 těm, kteří chtějí připojit jediné zařízení
A samozřejmě na propojovací point-to-point sítě /x, kde 64 <= x < 127. V lepším případě se nějaká možnost ustálí, v tomhle může být dobrý nápad pro konzistenci používat /64, i když je to určitá forma plýtvání. -
davro (neregistrovaný)
Je to hodně časté, možná převažující, ale zajímalo by mne proč. Možná je to zvyk, případně nevhodné chování některého směrovacího protokolu. OSPFv3 i IS-IS mohou fungovat bez globálních adres, takže podezírám BGP pro address-family IPv6 běžící nad IPv4. Ale ani tam si nejsem jistý. My používáme link-local a zatím bez problémů.
-
pavlix (neregistrovaný)
Samozřejmě, že to umožňuje, DHCP(v4) to umožňovalo taky.
„Pokud si WIN bez problémů požádají jako první o DHCPv6, pak je po problému a já budu spokojený“
To podle mě ukazuje na nedostatečnou znalost DHCPv6 a přidělování adres v IPv6 vůbec. DHCPv6 se používá jako doplněk, a koncový počítač ho používá pouze v případě, že je k tomu vyzván. -
pavlix (neregistrovaný)
K *vynucení* stateful konfigurace se používá stejný protokol jako k *provedení* stateless konfigurace.
Nerad bych se vás jakkoli dotkl, ale píšete tu velmi sebejistě a nepůsobí úplně dobře, že k tomu nemáte potřebný přehled. Vážně tím nemyslím nic zlého, jen bych doporučil si pro takto vehementní argumentaci (myslím ostatní příspěvky) doplnit informace o skutečném fungování protokolu IPv6. Jsem ochotný případně i pomoct. -
Děkuji, přiznávám se, že trochu agresivnější rétoriku volím tehdy, pokud si přeji aby někdo se mnou diskutoval:) Všimněte si, že na toto téma přede mnou již dva něco napsali (Blek), bez odezvy.
Ale máte pravdu, jsme ve stádiu, kdy máme alokaci, během několika dní to kolegové na BGP rozchodí, a já se rozkoukávám. Přidělovat /48 a nechat si 2 byte na naší adresaci se mi zatraceně nelíbí a já provádím studii, jestli je to opravdu nutné.
Mám v úmyslu pro každou přípojku (FTTx i bezdrátovou) vykonfigurovat statefull DHCP server, který přidělí síť řekněme /96. Toto již děláme pro IPv4, každému dáváme /28 z privátního rozsahu. Pokud by vše (rozuměj Windows) takto fungovalo, pak je to OK. Jestli s s tím máte zkušenost, budu moc rád, pokud mi ji napíšete.
Děkuji -
pavlix (neregistrovaný)
ad agresivnější rétorika: Beru, přesto doporučuju dobrou rétoriku doplnit dobrými fakty.
„Přidělovat /48 a nechat si 2 byte na naší adresaci se mi zatraceně nelíbí a já provádím studii, jestli je to opravdu nutné.“
Nutné to není, ale přidělováním delších prefixů (menšího adresního prostoru) byste si mohli způsobit konkurenční nevýhodu, a to zvlášť v případě zákazníků, kteří budou mít vlastní routery a budou chtít využít stateless autoconfiguration na svých podsítích.
„Pokud by vše (rozuměj Windows) takto fungovalo, pak je to OK.“
Odhaduju, že s koncovými OS nebude problém. Nejsem si ale jistý, jestli krabičky zákazníků budou obsahovat DHCPv6 server.
„Jestli s s tím máte zkušenost, budu moc rád, pokud mi ji napíšete.“
Jsem ve fázi experimentování, což je přecijen o něco málo víc, než teorietizování :). Dlouhodobé nasazení IPv6 na velké síti má v merku opravdu málokdo.
Chápu vaši motivaci pro vlastní bohatou hierarchii… v tomhle opravdu 16bit prefix úplně nestačí. Situace je srovnatelná například s privátní sítí 10.0.0.0/8.
Pokud byste chtěli zákazníkům dávat nepříliš omezený privátní rozsah (řekněme 150 počítačů), musíte použít bajt. Takže vám zbydou dva bajty na členění, a zákaznická síť vypadá následovně: 10.a.b.0/24.
Udělat to stejné s veřejným rozsahem IPv4 je prakticky nemožné (/8 nedostanete).
Udělat to s veřejným rozsahem IPv6 lze (prov:ider:aabb::/48). To už je samo o sobě pokrok.
A teď přijde konflikt tří zájmů: (Někteří) zákazníci by rádi /48, aby mohli používat bezstavovou konfiguraci, která triviálním způsobem zajišťuje statické adresy (či s privacy extensions velmi dynamické) na protokolech s hw adresou mapovatelnou na EUI-64. Vy byste rád měl víc než 16 bitů na členění uvnitř ISP. Registrátoři adres, kteří chtějí (či dokonce musejí) zabránít přílišnému plýtvání s těmito /48 rozsahy.
Někdo musí ustoupit a registrátoři to neudělají. Takže zbývají kupodivu tři možnosti (ne dvě): (1) vy obětujete vnitřní hierarchii, která nikoho kromě vás nezajímá, (2) zákazníci implementují DHCPv6, nebo (3) zákazníci obětují vás. -
Velice děkuji za rozbor
Nutné to není, ale přidělováním delších prefixů (menšího adresního prostoru) byste si mohli způsobit konkurenční nevýhodu, a to zvlášť v případě zákazníků, kteří budou mít vlastní routery a budou chtít využít stateless autoconfiguration na svých podsítích.
Nutné je to kvůli tomu RFC, ale to už jsme probrali :) Konkurence se opravdu nebojíme, k nasazení vůbec jsme blíže než všichni ostatní tady na Jihu a pokud bude klient domácnost, nebude to řešit vůbec (pokud nenarazíme na problémy např. s domácímy routery, ale dá se očekávat, že tyto krabičky se univerzálně poperou s jedním /64 ze strany ISP, třeba fungováním jako filtrující bridge, nebo DHCP6). Pokud bude klient firma, tyto věci se řeší až po objednání cenové nabídky a řešit podobné věci byla vždy ochota:) Pokud ne, /48 přiřadíme mimo standardní hierarchický adresní plá no problém.Jinak až kolegové prošněrují BGP, začneme taky zkoušet. Největší problém jsou naše L3 switche ES4612, které to neumějí a kterých máme na síti nejvíc. Zřejmě uděláme krok zpět a IPv6 okruhy vrát=ime dočasně na L2, než se to povyměňuje.
-
pavlix (neregistrovaný)
„nenarazíme na problémy např. s domácímy routery, ale dá se očekávat, že tyto krabičky se univerzálně poperou s jedním /64 ze strany ISP, třeba fungováním jako filtrující bridge, nebo DHCP6“
Potom nezbývá než doufat, že DHCPv6 bude všeobecně implementováno a předat zákazníkům konfigurační údaje (popřípadě jim DHCPv6 router nakonfigurovat).
Jenom úplně pro jistotu, DHCPv6 router nefunguje zdaleka tak automaticky jako DHCP(v4) NAT router. Předpokládám, že to víte, ale jistota je jistota. -
Vím, ale ani první NATy nefungovali tak automaticky jako dnes:) Takže očekávám, že se ustálí nějaká množina zvyklostí, při jejichž dodržení to časem půjde stejně snadno.
Selským rozumem by mělo stačit udělat krabičku jako bridge (ať mi routuje ISP), s firewallem na úrovni bridge (Linux umí, tj do plastové krabičky to číňan schová za pár dní). není to úplně čisté, ale za to to bude fungovat. -
pavlix (neregistrovaný)
„Vím, ale ani první NATy nefungovali tak automaticky jako dnes:)“
Vůbec netuším, co si pod tímto tvrzením mám představit. NAT ve smyslu IP maškarády s přednastaveným privátním rozsahem (např. 192.168.1.0/24) funguje sám o sobě.
Routovaný rozsah se musí nějakým způsobem konfigurovat. Každý zákazník má jiný.
„Selským rozumem by mělo stačit udělat krabičku jako bridge (ať mi routuje ISP), s firewallem na úrovni bridge (Linux umí, tj do plastové krabičky to číňan schová za pár dní).“
Tohle řešení už jsem viděl, ale je to obezlička a sdílení linkové vrstvy mezi zákazníky vede na některé komplikace.
To už se mi mnohem víc líbí možnost, že ISP na dálku konfiguruje použitý /64 prefix, i když ani to není ideální, protože pro firemního zákazníka se to zas bude řešit jinak.
Ale zase tu není problém odlišit úroveň zákazníka a na připojení bytů a menších firem používat /64 autoconf a modem konfigurovatelný od ISP, a /48 dávat jenom těm, co jsou schopni si tu síť sami nakonfigurovat (plus nabídnout konfiguraci jako nadstandardní službu).
