Hlavní navigace

Praktické problémy s IPv6, část druhá

11. 12. 2010 11:05 (aktualizováno) Ondřej Caletka

Jak jsem minule slíbil, v dnešním díle seriálu se zaměřím na problematiku IPv6 z pohledu správce sítě. Ani oni to nemají s příchodem IPv6 snadné, zvlášť pokud si chtějí v síti zachovat pořádek.

Automatická konfigurace

Na začátek malá exkurze do historie. V době, kdy vznikal protokol IPv4, se rozměry počítačů neudávaly v jednotkách U, ale v počtu sálů. Každý takový počítač měl k dispozici dostatečně erudovaného správce, pro kterého nebyl problém při instalaci nastavit celý systém, včetně IP adresy a směrovací tabulky. Teprve s rozmachem Internetu se objevila potřeba konfigurovat aspoň ty nejnutnější parametry IP protokolu automaticky. Tak vznikly postupně protokoly BOOTP a DHCP, bez kterých si dnes síťování nedovedeme představit.

IPv6 je zařízeno fundamentálně odlišně, už v návrhu bylo počítáno s nutností automatické konfigurace. Ta zde není nadstavbovým protokolem, který by zkonfiguroval původně statické parametry protokolu, ale přímo integrální součástí protokolu. Došlo to tak daleko, že každé síťové rozhraní získá svojí první IPv6 adresu prakticky ihned po aktivaci rozhraní, aniž by síťový kabel vůbec někam vedl. Počítač ji vytvoří slepením prefixu linkové adresy (fe80::/64) a 64-bitového identifikátoru rozhraní.

V obdobném duchu funguje i konfigurace směrování, každý směrovač vysílá do sítě ohlášení, podle kterých stanice nastavují svou směrovací tabulku. Velmi vzdáleně to připomíná například směrovací protokol RIP.

Úskalí autokonfigurace

Výše popsaná bezestavová autokonfigurace funguje velice dobře a jednoduše. Její zásadní problém spočívá v tom, že adresy nejsou koncovým zařízením přidělovány (jako např. u DHCPv4), ale jsou vytvořeny spoluprací sítě, která dodá prefix a zařízení, které dodá identifikátor rozhraní. V dřevních dobách IPv6 to zas takový problém nebyl – identifikátor rozhraní byl prakticky vždy odvozen z MAC adresy ethernetového rozhraní.

Pak ale přišli lidé, nazvěme je třeba novotvarem privateroristi, kterým se zdálo, že MAC adresa síťové karty je příliš unikátní číslo, a že by na základě této adresy mohli ostatní uživatelé Internetu sledovat pohyb zařízení mezi různými sítěmi. Bez ohledu na to, že takové sledování je dost dobře možné už dnes (stačí k tomu třeba obyčejné cookie v prohlížeči), byl argument uznán jako oprávněný, a vzniklo RFC 4941, které k pevným idenrifikátorům rozhraní přidává ještě další,  náhodně volené, v čase proměnlivé identifikátory. Klientské systémy s MS Windows si v rámci ještě většího soukromí ani pevný identifikátor neodvodí z MAC adresy, ale náhodně zvolí při prvním startu.

DHCPv6

I když je bezestavová autokonfigurace zabudovaná v protokolu vcelku použitelná, byl nakonec vyvinut i pro IPv6 protokol DHCP. Vývojáři tehdy měli možnost vybrat mezi  drobným rozšířením stávajícího DHCP tak, aby umělo poskytovat i IPv6 adresy a zásadním přepracováním protokolu tak, aby řešil problémy, které se za dobu existence „starého“ DHCP objevily. Vývojáři se vydali druhou cestou, a za sebe říkám bohužel.

Ve starém DHCP byla základním identifikátorem MAC adresa. Na základě té se vyhledal na DHCP serveru záznam v databázi konfigurací a následně byla klientovi nabídnuta odpovídající adresa, jako i další parametry. Tento systém začal drobně selhávat zejména s rozmachem notebooků, vybavených jak ethernetem, tak i wi-fi adaptérem, každý samozřejmě s jinou MAC adresou. Pro DHCPv4 server takový notebook vypadá jako dva zcela nezávislé počítače, nemá  možnost zjistit, že jde ve skutečnosti o jeden systém. DHCPv6 tento drobný problém řeší. Bohužel, řešení je tak svérázné, že zároveň způsobuje několik mnohem fatálnějších problémů.

DHCPv6 se rozhodlo jít cestou zavedení nových identifikátorů. Každý počítač dostane jedinečný identifikátor DUID, každé síťové rozhraní daného počítače IAID. Nápad to není špatný. Praktická realizace ale jednoznačně špatná je.  Všechny současné PC systémy implementující DHCPv6 používají DUID typu 1, což je identifikátor odvozený z MAC adresy jedné (náhodně volené) síťové karty a časového razítka prvního startu operačního systému. Tento identifikátor je uložen na pevném disku, z principu jej není možné predikovat.

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.

Správce sítě, který se rozhodne mít v síti pořádek má obvykle velkou tabulku s jménem PC, MAC adresou, IP adresou. Napadne ho, že by snad mohl existovat DHCPv6 server „v kompatibilním režimu“, který by na celý koncept s DUID a IAID kašlal a identifikoval klienta hezky postaru podle MAC adresy. Jenže neexistuje. A co víc, tvůrci protokolu DHCPv6 takovému přístupu aktivně brání, například tím, že z DHCPv6 zprávy odstranili informační pole s MAC adresou klienta. Případný „kompatibilní server“ by se tedy musel uchýlit ke sniffování MAC adresy, ze které požadavek přišel. Jenže tohle může fungovat jen tam, kde se nepoužívají DHCP relay agenti. Pro další studium si dovoluji odkázat na vlákno „Pre-determining DUID“ v archivu mailing listu DHC WG, zejména příspěvek Teda Lemona, jednoho z tvůrců protokolu, který právě existenci zmíněného „kompatibilního serveru“ rezolutně odmítl.

Konec druhé části

knize o IPv6 situaci kolem autokonfigurace Pavel Satrapa glosuje humorem sobě vlastním:

Chaos v síti. Divocí uživatelé zapojující bez jakékoli kontroly a evidence nejrůznější aparáty. Jak v takové situaci řešit problémy, které způsobí? Jak odpovídat na dopisy „Tehdy a tehdy byl na počítači s adresou X z Vaší sítě nabízen P2P službou Y film „Zachraňte vojína Ryana“. Zbylo nám tu z natáčení pár tanků, tak s tím koukejte rychle něco udělat, nebo s nimi přijedeme!“

Skutečně současný stav autokonfigurace nahrává spíše nepořádníkům. Lidem, kteří chtějí mít v síti pořádek, zbývají v podstatě dvě cesty – buď zablokovat na nejbližším routeru všechny adresy kromě adres odvozených z MAC adres (a že se to dělá, dokazuje i existence modulu eui64 pro ip6tables), nebo nasadit sledovací software, který bude sledovat jaké IPv6 adresy který počítač právě používá. Oba přístupy ale tak říkajíc kulhají na obě nohy…

V tomto místě ukončuji druhý díl seriálu. Na třetí a snad i poslední díl zbývají témata, která s autokonfigurací celkem dost souvisí:

  • Nechtěné Man-in-the-Middle útoky
  • Ochrana soukromí vs. odpovědnost za obsah
  • 27. 9. 2010 13:45

    Petr (neregistrovaný) 195.47.10.---

    Naprosty souhlas s clankem.
    Autokonfigurace je dobra tak na doma. Proto jsem odlozil implementaci IPv6 ve vnitrni siti ve firme na neurcito.

    Dalsi problemek vidim ve zmene prefixu. Zatim jsem testoval pres 6to4, ale kdyz
    si predstavim, ze po prideleni prefixu bych musel zmenit vsechny konfiguraky daemonu na serverech....
    Preci jen v IPv4 a SNAT + DNAT resi zmenu verejne ip adresy daleko elegantneji.

    Na to nejaky trik neznate?

  • 27. 9. 2010 16:18

    tomas (neregistrovaný) 212.158.136.---

    Pekne.

    >> Správce sítě, který se rozhodne mít v síti pořádek má obvykle velkou tabulku s jménem PC, MAC adresou, IP adresou.

    ..a priblizne v teto dobe jsem si rikal, ze celej IP protokol je v podstate jen zdvojnasobeni problemu a ze by bohate stacily MAC adresy - a jeden funkcni jmenny system (DNS).

  • 27. 9. 2010 16:23

    Ondřej Caletka (neregistrovaný) 147.32.30.---

    [3]. Nestačily. Nejsou hierarchické – plní funkci univerzálního identifikátoru, ale ne lokátoru. A ani nemohou, jestliže jsou pevně dány výrobcem. Znamenalo by to, že každá síťová karta by byla vyrobena na míru pro danou síť a v žádné jiné by nefungovala.

  • 27. 9. 2010 18:09

    multi (neregistrovaný) 90.177.214.---

    dik, za clanecek, prvne musim souhlasit, ze prechod nebude pro poskytovatale asi uplne jednoduchy.

  • 27. 9. 2010 19:31

    Jenda (neregistrovaný) 213.220.240.---

    Hezký článek, jen tak dál :-).

    Nemůže DHCP relay předávat nadřazenému serveru i MAC adresu? Chápu, že to asi v dohledné době nebude zakotvené v RFC, ale technicky tomu snad nic nebrání.

  • 27. 9. 2010 20:03

    petr_p (neregistrovaný) 147.251.48.---

    Přijdu k síti, pozměním si MAC adresu a připojím se. Privacy extension je pouze standardizovaný způsob řešící výměnu adresu. Pokud chci stroje evidovat, hlídat a blokovat, musím mít filtrující switch s linkou vyhrazenou ke každé stanici (802.1x). V opačném případě si na zabezpečení jenom hraji.

    Že DHCPv6 přešlo na DUID má svůj význam. (Už jste zkoušel IPv6 na neetherenetových point-to-point spojích?) Já jsem například ve své síti zažil více výměn síťových karet než přeinstalací. Váš problém pravděpodobně tolik lidí nepálí, protože jinak by někdo takovým způsobem klienta už upravil (například implementoval by ruční specifikaci DUID; ostatně specifikace nic takového nezakazuje, naopak tvrdí, že DUID má být nezávislý na výměně hardwaru). Nicméně například dibbler umožňuje odvodit DUID jen z linkové adresy (duid-type duid-ll).

  • 27. 9. 2010 20:25

    Ondřej Caletka (neregistrovaný) 147.32.114.---

    [7] Ano, mohl by, kdyby normotvůrci chtěli. Jenže oni nechtějí. Viz odkazovaný mail Teda Lemona.

    [8] Díky za příspěvek, přesně něco takového jsem chtěl slyšet. Ještě by mě zajímalo, protože nemám v téhle oblasti moc zkušeností, jestli switche, které umí 802.1x, umějí také nějak monitorovat, jaké IPv6 a IPv4 adresy na daných portech komunikovaly? Protože jinak v případě bezpečnostního incidentu pouze zjistím, že v dané chvíli bylo k VLANě autentifikováno 200 uživatelů a jeden z nich má incident na svědomí…
    Nebo to má smysl jen když každý klient má svou VLANu? To by byl samozřejmě ideální stav, leč na spoustě míst, včetně např. Strahova, velice těžko dosažitelný.

  • 27. 9. 2010 21:34

    Krystl (neregistrovaný) 94.113.160.---

    prirazeni IP MAC port muzes delat napriklad pomoci dhcp snoopingu

  • 27. 9. 2010 23:42

    mard (neregistrovaný) 89.24.32.---

    [8]Cože? Více výměn síťových karet než reinstalací OS? To si nedovedu představit. Vy jste asi přecházel z Token Ring na tlustý Ethernet, pak na koaxiál, pak na 10MBits kroucenou dvoulinku, pak na 100MBits, pak na 1GBits a pak FO? A to jste vydržel s jedním, nebo několika málo OS? Opravdu jsem zvědav co to bylo za experimentální instalaci - nějaká videostřižna či animační studio?

  • 28. 9. 2010 14:27

    f. (neregistrovaný) 88.101.198.---

    [9] 802.1x standardne toto neriesi, pricom samozrejme je mozne pomocou accountingu pomocou RADIUS protokolu zalogovat MAC adresu autentifikujuceho sa zariadenia/za­riadeni na danom porte. Obvykle sa to riesi skor/zaroven vytahovanim MAC adres tabulky zo zariadenia (SNMP) - zistime na ktorom zariadeni/porte ktora MAC bola cca. od-do (pri RADIUSe to "do" nemusime vzdy zistit). IP adresu co sa tyka autentifikacie cez 802.1x neriesime, pretoze ju prideluje DHCP/RADV, k comu dochadza v inej fazy nez vo fazy autentifikaci­e/autorizacie zariadenia (samozrejme existuju konfiguracie s pridelovanim cez RADIUS, ale je to komplikovaniejsie a u IPv6 som sa s tym nestretol). Co sa tyka zistenia IP adresy, tak sa pouziva ndpmon (obdoba arpwatch) a tym sa ku kazdej MAC zisti IP, spoji sa s informaciou ziskanou zo SNMP a je to. Sofistikovanejsie riesenie je zatial dostupne len u Cisca (a to som zatial netestoval), kde je mozne pouzit funciu "RAguard", kde mozeme zapnut dhcp snooping pre ipv6 a ip source guard pre ipv6 - ale to nam riesi ak ma pamat neklame len pripad, kedy je pouzite DHCPv6. Vzhladom k tomu, ze vo velkych sietach su rozne typy zariadeni a to hlavne docasne prinesene zariadenia, ktore nie su sucastou siete, potom diskless stanice, mobilne hracky a pod. je nasadenie len DHCPv6 dost obtiazne (pretoze nie vsetky zariadenia vedia DHCPv6). Takze sa pouziva RADV metoda a proste sa to riesi metodou logovania MAC a IPv6 adries, ich parovanim atd..

  • 28. 9. 2010 14:39

    f. (neregistrovaný) 88.101.198.---

    inak EUI64 checking je fajn, ale vzhladom k tomu, ze zatial to je akurat tak v linuxe, tak na velkych sietach, kde su HW boxy v ulohe routrov to nie je mozne pouzit. Samozrejme niektori spravci to zatial riesia tak, ze IPv6 prehanaju cez linux router, kde je EUI64 checking zapnuty. Problem je v tom, ze sa tym padom u docasne prinesenych notebookov (hlavne s windows), vyzaduje rekonfiguracia sietovych nastaveni, co casto znamena aj restart windows, co je dost casto velmi iritujuca zalezitost pre uzivatelov - pokial by mal windows defaultne nahodne generovanie IPv6 adresy vypnute, tak by to bolo zatial jedno z najlepsich rieseni, ale takto je to tazko nasaditelne v pripade velkych heterogennych sieti.
    Inak co sa tyka privacy extension (samozrejme nie je to len problem samotnych PE), tak vidim to ako dost velky problem, pretoze vo chvili ked dojde k masivnejsiemu rozmachu IPv6 a zacne sa skodit z nejakeho PC v sieti, tak v cielovej sieti viac menej neostane ina moznost ako vyblokovanie celeho IPv6 rozsahu odkial utocnik pochadza, pretoze bude velmi malo sieti kde bude EUI64 checking a utocnika bude mozne v cielovej sieti vyblokovat zakazanim jeho IP.
    Sice v zdrojovej sieti zistime po case (tj. v pripade analyzy logov ak nejake mame), ze kto vtedy a vtedy skodil, ale v cielovej sieti bude vyblokovany cely nas adresny range. Samozrejme su predpoklady, ze postupne dojde aj k nasadzovaniu inteligentnych IDS/IPS v kazdej vacsej sieti, ale kedze je to otazka penazi a zaroven aj otazka urovne vyspelosti admina, tak sa obavam, ze to az take ruzove nebude.

  • 29. 9. 2010 7:59

    tomfi (neregistrovaný) 193.222.130.---

    Problém ohledně DUID jsem nějak nepochytil. V plném DHCPv6 přidělenou adresu řídí server, řídí ji podle toho, ze které sítě požadavek přišel a podle DUID (identifikátoru stroje). Takže DHCP server má vědomí toho, ke které síti a kdo se chce připojit. Na základě toho přidělí adresu, nebo nepřidělí :). Nevim jak vadí, že DUID je neměnné. Pokud jednou přidělím zařízení DUID, tak podle toho DUID je mu možné přidělit klidně 100 adres najednou (jednu ethernetu, jednu WIFI, jednu v tunelu ... Jestli je problém, že Dualboot má pokaždý jiný DUID, tak jej nastavte stejně, nebo na druhou stranu se radujte, protože máte možnost nastavit jiné adresy pro každý OS zvlášť (to u IPv4 nebylo).
    Privát bych také moc neřešil... prostě pokud to firemní politika zakáže tak to vypnete a hotovo.

  • 29. 9. 2010 8:48

    Ondřej Caletka (neregistrovaný) 147.32.30.---

    [14] Problém je v tom, že IPv6 neexistuje (a dlouho nebude existovat) samo o sobě, ale v kombinaci Dual Stack s IPv4. Existuje hromada backend systémů, které dokážou udržovat v síti pořádek (vazbu MAC adresy a IPv4 adresy) a do jisté míry tento pořádek vynucovat (např. port security na switchi, IP filtr a statický ARP na routeru). A do toho přijde DHCPv6 s novými identifikátory, které se nedají odvodit z žádných existujících a navíc se mění nezávisle na ostatních (ať už reinstalací OS, nebo dualbootem). Pokud budu chtít stejnou míru zabezpečení i pro IPv6 sítě, nemám jak naplnit ani IP filtr, ani statickou ND tabulku na routeru, protože vazba mezi DUID a ostatními identifikátory neexistuje.

    Nebo dojde k bezpečnostnímu incidentu a já z logu DHCPv6 serveru zjistím DUID útočícího počítače, jenomže to je informace, kterou ze switch tabulek nevyčtu. Takže mi nezbude nic jiného, než ručně obejít všech třeba 253 stanic a zjistit, která z nich používá daný DUID.

  • 29. 9. 2010 9:41

    pet (neregistrovaný) 82.142.82.---

    Hmmm...., DHCPv6..... Takže když nabootuju bezdiskovou stanici, tak si při každém bootu vymyslí nějaký DUID, pokaždé jiný, a DHCPv6 server nebude vědět, kterou bootovací image jí předhodit. Tak to ať jdou s celým slavným IPv6 soudruzi někam!!

  • 29. 9. 2010 10:07

    Ondřej Caletka (neregistrovaný) 147.32.30.---

    Bootovací firmware nemá přístup k disku, takže buď bude používat DUID, který bude součástí toho firmware, nebo použije DUID typu 3, což je MAC adresa jedné síťové karty. Rozhodně si nemůže při každém bootu vymyslet jiný, to by odporovalo definici.

    V případě integrované síťové karty na základní desce, což je naprostý standard, mi DUID typu 3 (DUID-LL) připadá nejsympatičtější. Pokud přijmeme premisu, že počítač = základní deska, pak je DUID typu 3, odvozený z MAC adresy integrované síťové karty zároveň unikátní pro daný počítač, zároveň neměnný při výměně síťové karty (neboť ji nelze vyměnit bez výměny počítače) a k tomu všemu navíc jednoduše predikovatelný a stabilní proti multibootu a klonování.

  • 29. 9. 2010 14:03

    aaa (neregistrovaný) 15.203.137.---

    [17] no tvrdit ze zakladna doska=pocitac (uz mam tretiu zakladnu dosku, OS som nemenil), pripadne ze kazda zakladna doska ma integrovanu sietovu kartu je dost odvazne ;-)

  • 29. 9. 2010 14:23

    Ondřej Caletka (neregistrovaný) 147.32.30.---

    [18] Ano, může to tak být, pak ale navrhněte, co brát jako komponentu, která určuje počítač.
    Asi se shodneme, že při výměně skříně, napájecího zdroje, CPU, nebo paměti, zůstane zachován stejný počítač. Ale při výměně základní desky nebo HDD, je to co vznikne stejný, nebo nový počítač?
    Nebo snad ke změně počítače dojde při výměně nadpolovičního počtu komponent? Nebo ke změně nedojde, dokud zůstane alespoň jedna komponenta ze starého? Možností je spousta, základní deska mi připadá jako nejrozumnější kompromis.

    A k síťové kartě: Právě koukám na první dvě stránky se základními deskami na známém e-shopu, všech cca. 20 mělo aspoň jeden vestavěný ethernetový adaptér, takže pokud se ještě vyrábí nějaké základní desky bez integrovaného ethernetu, bude to spíše výjimka, než běžný stav.

  • 29. 9. 2010 17:02

    Karel (neregistrovaný) 93.90.162.---

    Možná to celé špatně chápu, ale tohle vypadá jako absolutně nepoužitelné. Máme ve firmě plno PC, u kterých je adresa víceméně ukradená. Ale u pár desítek je nutné, aby měly tu správnou IP adresu. Jedná se o průmyslová PC na testovacích linkách a je bezpodmínečně nutné, aby stanice XY měla neustále svou jednu pevnou IP adresu, protože ji podle toho ostatní počítače poznají a také jí na tuhle adresu "volají". Pokud některé z těch PC umře, vezme se jedno ze záložních předinstalovaných, připíchne se místo starého, podle MAC adresy (napsaná zezadu na počítači) se odklikne cosi v konfiguraci DHCP, počítač se spustí, dostane od DHCP serveru tu správnou IP adresu a běží. Výměna PC je tedy otázkou několika málo minut (<5) a nevyžaduje aby na tom PC někdo přepisoval konfigurační soubor s pevnou adresou (což by byl trochu problém, protože tam je speciálně upravená Linuxová distribuce bez roota).

    Podle tohohle blogu mi to přijde, že tohle je v případě IPv6 neřešitelné. Všechna PC jsou naklonovaná, tu správnou IP adresu jim přidělí DHCP server, konfiguraci software si obslouží sama aplikace podle toho, co jí řekne aplikační server (který ji pozná podle IP adresy). Zkrátka tahle PC nejsou anonymní, musí se hlásit tím jediným správným jménem a to se v čase mění (podle toho, kam je to PC fyzicky připojeno). Teď stačí naskenovat čárový kód ze stolu (IP adresa) a čárový kód na PC (MAC adresa) a software přenastaví DHCP tak, že počítač při bootu již naběhne správně. Je to tedy takto řešitelné i s IPv6? Zkoušeli jsme to řešit i přes DNS, ale to nefungovalo - po výměně PC ještě pár minut trvalo, než ostatní počítače pochopily, že počítač "LTEST28" už není 10.214.3.48 ale je to teď 10.214.3.92. S IP adresou ho našly okamžitě jak nabootoval.

  • 29. 9. 2010 18:19

    8an (neregistrovaný) 78.108.102.---

    [20]: U Linuxu to problém není, DUID může být i MAC adresa, můžeš tedy klidně před spuštěním DHCPv6 vygenerovat DUID skriptem z MAC adresy. Tohle jsem použil, když jsem implementoval IPv6 do jednoho klientského Wi-Fi routeru. Případně u klienta Dibbler se to dá přímo nastavit, jak psal kdosi přede mnou, ale tam mi zase nefungovala prefix delegation.

  • 29. 9. 2010 18:25

    8an (neregistrovaný) 78.108.102.---

    [20]: Mimochodem, druhá cesta, kterou jsem zvažoval, bylo upravit DHCPv6 server tak, aby u DUID porovnával jenom tu část odvozenou z MAC a tu proměnlivou ignoroval. Nakonec jsem to ale zavrhl, protože by to bylo aplikovatelné jen na klienty s jediným síťovým rozhraním. DHCPv6 klient je schopný si klidně odvodit DUID z adresy na VPN rozhraní, které má náhodně generovanou MAC.

  • 30. 9. 2010 1:24

    Jenda (neregistrovaný) 213.220.240.---

    „Zkoušeli jsme to řešit i přes DNS, ale to nefungovalo - po výměně PC ještě pár minut trvalo, než ostatní počítače pochopily, že počítač "LTEST28" už není 10.214.3.48 ale je to teď 10.214.3.92. S IP adresou ho našly okamžitě jak nabootoval.“

    Dlouhé TTL?

  • 30. 9. 2010 10:03

    Storm Dragon (neregistrovaný) 84.42.171.---

    [20]: Tomu se rika "solution in search of a problem". Nejjednodussi je na takovych strojich tu IP adresu nastavit napevno pri prvnim bootu, problem vyresen.

    Co se tyka privacy extensions, ty byly vytvoreny pro site kde probiha bezstavova autokonfigurace, aby bylo tezsi sledovat pocitac napric sitemi. Pokud se pouziva DHCP a to DHCP prideluje adresy jinak nez bezstavova autokonfigurace, tak nejsou privacy extensions potreba, a neni potreba je resit.

  • 30. 9. 2010 12:16

    tomfi (neregistrovaný) 193.222.130.---

    [15]
    Z toho co píšete přímo čiší, že je třeba zvolit jiný přístup... Zmiňujete "stejnou míru zabezpečení", ale přitom máte na mysli "stejný způsob zabezpečení". Ne všechny věci z ipv4 světa půjdou dělat stejně v IPv6, určitě je mnoho věcí, které bude třeba se spolu s novou rodinou protokolů IPv6 naučit... Myslím, že naopak DUID má lepší opodstatnění než vázání nastavení sítě na MAC adresu počítače. A v tomto směru chápu odpor k zavádění "berliček" z ipv4 do IPv6 proto, že si na to administrátoři zvykli.

    Incidenty chápu jako problém, ale bez znalosti konkrétní situace (prostředí, zařízení, politiky...) se dá těžko radit jinak, než logovat používané vazby IPv6-MAC (například pomocí NDPMon)... v tom logu to najdete stejně dobře jako v logu DHCP serveru, dokonce s jistotou, že tu adresu si zrovna ve chvíli incidentu neukradl někdo jiný.

  • 30. 9. 2010 15:36

    * (neregistrovaný) 80.95.121.---

    asi by nebylo od veci vydat rfc na novy protokol DHCYPv6
    prvni pole by byla mac. zbytek zpravy by odpovidal DHCPv6. funkce, ktere by byly volitelne nikoliv povinne by pak byly tu idecka.

    jinak multi-(interface/access-media) systemy se resi snad bridgem, ktery ma svoji mac a te se prideluje ip. akorat je potereba dat bacha, aby vsechno v siti umelo stp a byly spravne nastaveny dulezitosti switchu, aby se pak pri hledani minimalni kostry netahal traffic vsech lidi v siti co chodi mezi mezi AP a switchem a routerem skrz nejakyho chudaka co ma zapojeny drat i bezdrat a blbe nastavenou prioritu bridge.

  • 1. 10. 2010 1:40

    VS (neregistrovaný) 147.228.209.---

    Vida, o této "vlastnosti" DHCPv6 jsem nevěděl. Ono sice řešení vyvinutá pro IPv4 nebyla dokonalá, ale lidé se s tím naučili pracovat, a úplně na nic to taky nebylo. Takže u IPv6 to pro jistotu uděláme znova a hezky, aby se za pár let vynořily zas jiné problémy, kterých se nám ve fázi návrhu ani nezdálo...

    Zrovna MAC adresa a DHCPv4 je jednoduchá a jasná věc. Scénář s více rozhraními je problém, mnohem častějsí je scénář, kdy tohle nijak nevadí. MAC je dobrá jako identifikace počítače - ať ho přeinstaluji (třeba hromadně z image) nebo nabootuju ze sítě nějaký live systém, tak "sama" naskočí správná IP adresa. V tomto případě DHCPv6 řeší neexistující problém a navrch zavásí další. Sice řešitelný, ale je to práce navíc - můžu PC indentifikovat na "aplikační" úrovni, klidně to MAC adresou. Ale proboha proč, když do teď to chodilo "samo"?

    Můj pohled je možná ovlivněný tím, že se pohybuju v prostředí se stovkami pevně připojenými PC, kde nějaký útočník nehrozí, a kde výměna základní desky = PC vyhodit a dát nový, jehož nová MAC se jen zapíše do databáze.

  • 1. 10. 2010 15:07

    8an (neregistrovaný) 78.108.102.---

    [15]: Jsou situace, kdy je lepší vázat adresu na konkrétní hardware, i situace, kdy je výhodnější vazba na software (nainstalovaný operační systém). Do DHCP pro IPv4 byl také mechanismus DUID dodatečně zaveden. Problém je to, že DHCPv6 nedává možnost volby, vnucuje jedno řešení i tam, kde to není výhodné.

  • 2. 10. 2010 17:14

    petr_p (neregistrovaný) 88.101.50.---

    [11] se rozčiluje, že 802.1x řešící fyzickou/linkovou vrstvu neřeší síťovou. Jistě. Pokud chcete řešit síťovou, můžete použít IPsec.

    Já takhle dělám WiFi AP. Když už zabírám frekvenci, tak ať z toho mají užitek i jiní. Router nepřeposílá pakety z/do WiFi, ale na AP se může asociovat kdokoliv. Pokud někdo chce použít služeb routeru, musí si na něj natáhnout IPsec tunel. Správce pak má jistotu, co která IP adresa je zač.

    [28] Tvrdí, že DHCPv6 nedává možnost volby. Ale houbelec. Přečtěte si RFC. Máte tři různé automatické způsoby odvození DUID. Navíc nikdo vám nebrání DUID nebo rovnou IP adresu nastavit na stanici natvrdo.

    Souhlasím s [25], že ne všechny hrůzy, které se v IPv4 považují za normální, fungují v IPv6. Samozřejmě, že bezpečnostní nástroje pro IPv6 nejsou tak vyspělé, ale to je jen otázka poptávky a času. Rovněž souhlasím, že řešení bezpečnostních incidentů se liší případ od případu. Jsou sítě, kde je přístup k lince volný, jsou sítě, kde máte pro každou stanici vyhrazený nakonfigurovaný port. Jsou sítě, kde se pravidla vynucují třeba vnitřními směrnicemi, jsou sítě, kde chce majitel sítě vydělávat na tranzitu ať se děje, co se děje. Vinit z problémů IPv6 je dětinské.

  • 2. 10. 2010 17:25

    Ondřej Caletka (neregistrovaný) 83.208.77.---

    [30]

    <blockquote>„Ale houbelec. Přečtěte si RFC. Máte tři různé automatické způsoby odvození DUID. Navíc nikdo vám nebrání DUID nebo rovnou IP adresu nastavit na stanici natvrdo.“</bloc­kquote>

    Nejde o možnost manuálního nastavení, ta byla a je vždycky. Jde o to, že DHCP(v4) server dostane v požadavku od klienta vždy MAC adresu a někdy také DUID. DHCPv6 server dostane od klienta vždy DUID a _nikdy_ MAC adresu. Takže zatímco DHCPv4 server si může volit, zda použije k identifikaci klienta DUID, nebo MAC adresu, u DHCPv6 je tato volba zrušena.

  • 3. 10. 2010 17:04

    8an (neregistrovaný) 78.108.102.---

    [31]: jo, to je přesně jak jsem to myslel. Vím, že DUID si můžu nastavit jak chci a také to tak dělám, ale je to hack. Předpokladem pro nasazení nové technologie je maximální zpětná kompatibilita se stávající technologií - proto se IPv6 prosazuje tak pomalu.

  • 3. 10. 2010 21:06

    petr_p (neregistrovaný) 147.251.48.---

    [31] V čem je MAC adresa lepší než DUID? Všimněte si, že Media Access Control je z definice záležitost specifická pro lokální médium. DHCP relay skáče radostí. Pokud vám MAC adresa chybí, není nic jednoduššího než napsat návrh na přidání další DHPCv6 option. Nakonec MAC adresu najde DHCP server v hlavičce příchozího rámce (v IPv6 se nemusíte snižovat k Ethernetu, můžete si přečíst zdrojovou IP adresu).

  • 8. 11. 2010 7:53

    Mojža (neregistrovaný) 85.239.82.---

    S tvrzením "I když je bezestavová autokonfigurace zabudovaná v protokolu vcelku použitelná..." nesouhlasím. RA je neúplné a tudíž v zásadě samostatně nepoužitelné. Uživatel na síti jen s RA bude asi koukat, proč mu nejde www.seznam.cz.

    Postřehy a zejména diskuze je však fajn a jsem za ně rád. Ještě lepší to však bude, když text dáte jazykovému korektorovi (první odstavec o DHCPv6, problémy...se objevilY).

  • 8. 11. 2010 8:13

    Ondřej Caletka (neregistrovaný) 2001:718:2:----:----:----:----:----

    Díky za připomínku opraveno. Korektora nemám k dispozici, ale od toho jsou snad komentáře, ne?

Diskuze byla uzavřena.