Diskuse o velikosti přidelovaných IPv6 prefixů

[knedlik]

proklínám DHCP6 na mikrotiku

DHCPv6 bude docela problém a z toho důvodu se budu bránit nasazení IPv6 dokud to jenom půjde.
viz celý seriál na rootu: http://oskar.blog.root.cz/2010/09/27/pr ... ast-druha/

jenom krátký výsek:

Kód: Vybrat vše

Sečteno a podtrženo, takové řešení přináší tyto nové problémy:

    * Máme-li multi-boot systém, každý z operačních systémů bude pro DHCPv6 zcela jiným počítačem. Pokud budeme chtít stanici startovat ze sítě pomocí DHCPv6, bude startovací firmware pro server dalším nezávislým počítačem.
    * Naopak používáme-li klonování pro hromadnou instalaci více počítačů, budou všechny klonované počítače pro DHCPv6 server vystupovat jako jeden.
    * Vazba na MAC adresu síťové karty je nahrazena vazbou na soubor na disku. Každý, kdo kdy měl něco do činění s MS Windows ví, že na jeden život síťové karty (=1 MAC adresa) připadá několik, možná i desítka reinstalací operačního systému (a tedy 10 různých DUIDů)
    * Snad všechny DHCPv6 servery, které jsem testoval, umožňují  nastavit statickou IP adresu pro daný DUID, podobně jako IPv4 servery umožňují pevné mapování MAC adresy a IP adresy. Jenže u IPv6 je to špatně. DUID je identifikátor počítače, ten má obecně víc rozhraní rozlišených podle IAID. Současné DHCP servery tedy přiřadí stejnou adresu všem rozhraním jednoho počítače. Dalších komentářů netřeba.


A pokud chápu správně hvězdičku 3, tak nově po reinstalaci dostane PC novou "MAC" a tudíž se mu nepřiřadí IP adresa.... Opět budou uživatelé volat, jakou že mají IP adresu, že jim nejede internet

[hapi]

to je dobrá kravina. DHCPv6 nemá sloužit pro přidělování IP adres ale pro přidělování doplňujících IP adres jako DNS, NTP server atd... Pro přidělování ip adres slouží advertise. Jakmile se přiřadí ip adresa skrz advertise, nastupuje DHCPv6 pro doplnění ostatních parametrů připojení. DHCPv6 nefunguje jako DHCPv4. Tedy pokud jde o mikrotika a o řešení kterym se vydá.

Navíc autor toho článku je jaksi docela mimo. Userům se má dávat celá /64 a pak je ti jedno jakou ip dostane protože na bráně budeš mít povolenej celej prefix /64 pro toho usera. Jo já vim, asi máš sít v bridge a to nekoresponduje s IPv6 atd ale to je tvůj boj. Furt říkám že na wifiny bridge nepatří.

[okoun]

no jsem zvědavý jak se to bude vyvíjet.
byl bych rád kdybych mohl přidělit ipv6 dle mac adresy
fakt nevidím ani jednu racionální myšlenku přidělit zákazníkům rozsah /64
taky je právě problém stavět úplně jinou koncepci ipv6 na síti, která má ipv4 úplně v jiné koncepci. prostě šetření s ipv4 nejde k sobě s plýtváním ipv6

[hapi]

co třeba že od /64 jako nejmenší rozsah funguje advertise? je to dostatečnej racionální důvod?
Jako další důvod třeba to, že dneska dostaneš klidně /48 a to si každá i větší síť může veřejky rozhodit po všech klientech a celí síti. To jaksi u IPv4 stálo docela dost prachů aby jsi dostal třeba 50 Cček.

[okoun]

pokud dhcp6 plně nahradí advertise tak ho hnedle s radostí vypnu.
advertise mohlo být napsáno klidně pro menší rozsahy, nevím prečo nějakej trouba řekl že to bude pro /64 a více...

[hapi]

dhcpv6 nenahradí advertise. Advertise tu bude vždy. /64 kvůli tomu aby se tam vešla mac adresa + nějaká náhodně generovaná část. Někdo to tu psal proč to tak je.

[okoun]

počkat, takže z ipv6 adresy se dá přečíst mac adresa?

[hapi]

ne vždy. Přečti si to na ipv6 stránkách.

[Majklik]

to je dobrá kravina. DHCPv6 nemá sloužit pro přidělování IP adres ale pro přidělování doplňujících IP adres jako DNS, NTP server atd... Pro přidělování ip adres slouží advertise. Jakmile se přiřadí ip adresa skrz advertise, nastupuje DHCPv6 pro doplnění ostatních parametrů připojení. DHCPv6 nefunguje jako DHCPv4. Tedy pokud jde o mikrotika a o řešení kterym se vydá.

Navíc autor toho článku je jaksi docela mimo. Userům se má dávat celá /64 a pak je ti jedno jakou ip dostane protože na bráně budeš mít povolenej celej prefix /64 pro toho usera. Jo já vim, asi máš sít v bridge a to nekoresponduje s IPv6 atd ale to je tvůj boj. Furt říkám že na wifiny bridge nepatří.

Ehm, DHCPv6 má smysl hlavně k tomu, aby koncový user dostal přidělený segment pro svojí domácí LAN. Jak to probíhá tam, kde už to funguje:
Domácí router usera po zapnutí si pomocí DHCPv6 požádá o IPčko pro WAN port, dostane spolu s DNS, NTP, ... To si patřičně nastaví, následně požádá znovu pomocí DHCPv6-PD o přidělení IPv6 segmentu, co má používat na LAN straně, zde se očekává, že dostane minimálně ten /64. Správně by měl dostat /48, ale pro rezidenční segment je to zbytečné, takže hamouni dávají /64, někteří /56. Příděl /48 se dává firemnímu segmentu. Řekněme, že dostane to /64, tak to nahodí na LAN a sám začne fungovat jako DHCPv6 server pro LAN i s RAčkem. Některé routery už nepoužívají bridge mezi Wifi a LAN, tak potřebují další IP segment pro wifinu. Tak si opět pomocí DHCPv6-PD požádají o další segment pro wifinu atd (pokud dostane rovnou dopředu /48, tak nežádá, ale sám si rozebírá ten příděl jak potřebuje).
Na straně ISP se informace o segmentech, co se propagují koncovému klientu, automaticky vkládají i do koncového routeru ISP pro nastavneí routingu k němu. Data mám komplet v Radius serveru a jen tam to měním...
Takto to fungje v současnosti v kabelových sítích nad DOCSIS3.0. A fanguje to celkem dobře a modemy to umí. Umí to i některé home routery (pak kableový modem může jet jako bridge), např Draytek, ale to normálnímu koncáku za 6 kKč nevnutíte, ale obvykle ho nepotřebuje, ten modem od kableovky to umí sám. A takto bych očekával, že bude DHCPv6 fuungovat i v ROSu, jak na straně ISP - bude umět poskytovat IPčko pro WAN stranu home routeru i s dalšíma ůdaji, tak i pomocí PD pak data pro LAN stranu a dle těch PD dat to i vloží do routovací tabulky posledního routeru před zákazníkem (dál se to dostane přes OSPF3). Data komplet sosaná z radiusu Tak i na straně, pokud by byl ROS koncový home router - požádám o IPčko pro WAN stranu (nebo třeba i přes RA), následně si přes DHCPv6-PD požádám o příděl pro LAN strnau a ten si začnu dělit dál dovnitř (ideálně i jako DHCPv6 server)...
Takže se to komplet u zákazníka nastaví samo bez mého zásahu.
Ale asi to u ROSu zatím tímto směrme nespěje.

[Majklik]

fakt nevidím ani jednu racionální myšlenku přidělit zákazníkům rozsah /64

Souhlas, koncový zákazník (i domácnost), má dostat správně dle pravidel pro členění IPv6 adresního prostoru začínajícího 2000::/3 příděl /48 a ať si s ním dělá co chce. Proto /64 není dobře.
Nicméně se u rezidenčních dává obvykle méně, než /48, protože to reálně nevyužije. Viděl jsem nečastěji /56 nebo /60. Pár krchounů dává těch /64, ale to pro některé routery, co jsem měl v ruce, bylo málo (potřebovaly aspoň dva /64, kde jeden šel na LAN a druhýu na Wifi část, jak jsem zmínil výše).
ISPčko dostane /32, který si má sekat na ty /48. Pravda, to platí, pokud je to opravdu ISPčko se vším všudy, včetně vlastního ASka. Pokud není a využívá IP adresy nadřazeného operátora, tak dostane jeden /48 (plus spojovačku /64) a má probém to dělit dál podle požadavků (operátor nemá přidělit jednomu zákazníku víc bloků /48 a obvykle to odmítne udělat s odkazme na pravidla RIPE).

Ale tohle spíše už spadá do jiné rubriky....

[hapi]

to je ale nesmysl. Ty myslíš že průměrnýmu českýmu ISPíkovy nebude stačit /48? nějak nevidim žádnej důvod dávat userům pro doma víc než /64 a těch prefixů je v prefixu /48 je 65536 tedy pro 65 tisíc userů + nějaký spojováky na síti. 65 tisíc prefixů je problem rozdělit mezi podle požadavků? trochu přehnaný tvrzení a je dost přehnaný tvrdit že je někdo krchoun když pro jednoho usera s průměrnym využití dvou ip adres v domácnosti použije /64 čítajicí víc ip adres než je celej rozsah IPv4. Tohle myslel okoun, že pro usera stačí klasickej Cčkovej rozsah čítající 250 ip adres a tedy daleko menší prefix. On nemyslel že /64 je málo ale že je to zartaceně hodně.

[Majklik]

Průměrnému českému ISPíkovi, který nemá vlastní AS a dostane od nadřazeného operátora jedne blok /48, který bude sekat mezi koncáky, tak ten segment vydrží přesně do okamžiku, kdy první zákazník udělá problém typu SPAM, vir atd a půjde jeho IPčko na blacklist. Protože jak to zatím vypadá, blacklisty, které se začínají chystat i pro podporu IPv6 to budou dělat tak, že budou dodržovat stanovenou hiearchii členění IPv6 prostoru 2000::/3, takže na blaclist natvrdo půjde celý /48 segment... A budou mít podporu i např v RIPE DB, protože tam bude asi jako nemenší jendotka pod jednoho vlastníka ten blok /48 ukzující na celého ISPíka.
Takže to je jeden z důvodů, proč se snažit dodržet (minimálně pro firemní klientelu) platnou hiearchii: ISPdostává /32 (RIPE a spol přitom zatím přiděluje s dírama, takže když ISPík svůj /32 zaplní, tak je pro něj držek blok následující, takže bude mít pak /31), koncový zíákazník /48, koncová LAN/64 (protože tuna krámů ani nehodlá jiný prefix podporovat, přestpže existuje třeba i EUI48 s prefixem na LAN /80).
Inu, IPv6 projektanti byli rozhazovační a spoust aimplementátorů nehodlá jiné schéma zatím podporovat.
Když s eukáže, že je to volovina, tak se začné přidělovat IPčka z jiného prefixu, než je 2000::/3 a tma to bude případně jinak.

[hapi]

chceš mi říct, že když mi dodavatel konektivity dá /64 a já zaspamuju co pujde tak odříznou od mailu i někoho jinýho v /48 prefixu?

nemám důvod ti nevěřit ale je to opět nedomyšlený jako spousta věcí u ipv6.

[Majklik]

Jak je doporučeno přidělovat bloky koncovým klientům:
/47 - extrémně velké sítě (nadnárodní giga korporace) - tento příděl koncovému klientu v případě EU podléha dokládání a schvalování RIPE, dle požadavlu jejich IPv6 address allocation policy,
/48 - standardní příděl (domácí sítě, SOHO, malé až velké firmy),
/64 - velmi malé sítě, tento příděl je možno přidělit, pokud je jistota, že daný zákazník nikdy nebude potřebovat přidělit příděl větší (standardní příděl pro jeden mobilní telefon, automobil),
/128 - dial up nebo připojení jednoho koncového počítače (zákazník nemá síť, jen jeden připojený počítač).
A z toho zatím vychází úvahy blacklistů, že normální blok, který půjde na blacklist je ten /48. Praxe pak ukáže, jakým směrem se to vydá (bloky mobilních/dialup operátorů obvkyle jdou na blacklisty automaticky preventivně komplet)....
Domyšlený se mi tohle zdá naprosto v pohodě, protože zkrátka je řečeno, kolik má koncový zákazník dostat a nemusím špekulovat, kolik asi může mít masku, protože je to jasné by design. Podobně, jako to bylo jasné u IPv4, dokud se nepřešlo na classless, kdy maska pevně byla dána dle nejvyšších bitů prvního byte adresy /8, /16, /24. Akorát po zavedení classless sítí z toho vznikl u IPv4 bordel, než třídy zmizely v propadlišti dějin. Uznávám, že je to psychicky náročné přijmout, že by zákazník s jedním routerem a dvěma komply měl dostat /48, když doteď byl rád za jednu veřejnou IPv4 /32, takové plýtvání. Samozřejmě mi v podstatě nic nebrání to udělat jinak, ale budu muset řešit to, že zbytek světa může očekávat standardní chování a řídit se dle toho a bude na mě řešit komplikace z toho vzešlé. Stejně jako z toho, když budu trvat na tom, že koncová LAN má být méně, než /64, tak si budu muset pořešit z toho plynoucí komplikace, když RFC říkají, že pro IPv6 adresy začínající binárně 001 (2000::/3) by lokální část měla být /64 .
Problém toto dělá jen v případě (což v ČR bude hodně ISPček), kdy nejsem na úrovni LIRa a nedostanu jako ISPčko vlasntí /32 pro porcování svým klientům, ale jsem jen "koncový zákazník" nějakého většího data carriera z jehož přídělu dostanu tu jednu usmolenou /48 (plus spojovačku k němu /64) a při požadavku na další budu odpálen k řešení s RIPE dle bodu 5.4.2. alokačních pravidel RIPE (jak ten/47 příděl na začátku).

Ale tohle je asi totálni offtopic v tomhle tématu od dob, kdy se to odklonilo od DHCPv6 tužeb v ROSu. Takže případné pokračování asi spíše v IPv6 sekci...

[basty]

Dobre, takze chteji donutit kazdyho rekneme pod 1000 kl. aby mel ASko. Super.