Názory k článku Bezpečné IPv6: zkrocení zlých směrovačů
-
ondro (neregistrovaný)
Po precitani tychto dvoch dielov mam pocit, ze soudruzi udelali pri navrhu IPv6 nekde chybu. Mam ten pocit sam?
Tento druhy diel je vyborny na odradenie od implementacie IPv6 na hocijakej urovni.
Kazdeho, kdo bude spominat a pretlacat IPv6 s radostou odkazem na tento clanok.
Necudujem sa, ze implementacia IPv6 je tam, kde je.Ako takyto protokol mohol vobec vzniknut? Keby to bol protokol zo zaciatkov internetu a lokalnych sieti, tak ani nepipnem.
Niektore techniky ma pobavili. Private VLAN Edge. Pasivne monitorovanie a byt utocnikom vo vlatnej sieti ma pobavilo. To myslia vazne?
Z toho mi vypliva aj narocnost na HW aby ten HW zvladal terajsie a nevyhnutne buduce ochranne mechanizmy. IPv6 povazujem za protokol, ktory nebude nikdy poriadne dokonceny(ustabilizovany) a cakam, ze niekto pride s navrhom urobit novy.Inac, dakujem za vyborny clanok.
-
j (neregistrovaný)
Spis nechapes jak site fungujou soudruhu. Pokud ma totiz nekdo pocit, ze potrebuje sit zabezpecit, musi to delat uz na linkovy vrstve a ne az na IPcku.
Kupodivu IPv4 taky nebyl nikdy stabilizovan, a porad se menil prostrednicvim desitek RFC. A drtiva vetsina zarizeni dodnes neumi drtivou vetsinu jeho funcionality.
Pokud mam sit pod kontrolou, tak me nejaky RAcko nemuze rozhodit, protoze mam typicky pod kontrolou i klienty, na ktery si nikdo nic nenainstaluje ani si na nich nic neautorizovane nespusti a nic si na nich nenastavi.
Zkusenosti s desitkami ISP pak ukazuji, ze prakticky vsichni stejne davaji kazdeho klienta do vlastni vlany (i na IPv4) a jaky bordel si bude delat sam sobe, je jim celkem u zadnice.
Takze popisovane veci nejsou ani zdaleka takovy problem, jak by se z clanku mohlo zdat.
A ve finale, IPv6 je protokol stary 20 let.
-
Jenda (neregistrovaný)
> Z clanku jsem pochopil, ze v IPv6 to tak neni. I kdyz nastavim vse, jak se uvadi, tak neziskam takovou bezpecnost.
Mně se zdá, že získáš. Místo DHCP snoopingu RA guard a/nebo DHCPv6 snooping, místo ARP/MAC filtru ND filtr. Je tam nějaký problém nebo vidíš způsob jak to obejít, který by u IPv4 nefungoval?
-
Ono je to především prakticky všecko o automatické konfiguraci. Něco jsou chyby implementací, něco je špatný návrh. V podstatě kdyby se udělal restart a používalo se jen DHCPv6 a revidovaly by se rozdíly od DHCPv4, bylo by na téhle frontě vyřešeno.
Zároveň by to výrazně zjednodušilo implementace, což by mělo další nepřímý pozitivní vliv i na bezpečnost. A přitom bychom mohli používat dlouhé adresy a všechny výhody z nich plynoucí.
-
j (neregistrovaný)
Kupodivu je RA na implementaci radove jednodussi, proto drtiva vetsina "blbych" krabek dhcp vubec nepodporuje ... ale to by chtelo aspon tusit.
Navic to resi problem, ktery s dhcp vyresit vubec nelze - vypadek primarni cesty. Na to je treba v pripade dhcp jeste nainstalovat, nakonfigurovat a spustit nejaky routovani, coz je radove slozitejsi, a chci videt, jak to bude nekdo implementovat do lednicky ...
-
Ivan (neregistrovaný)
Ok ,tak si predstavte, ze do site pripojim lednicku (anebo mainframe) a ta vec ma management interface, ktery pres dhcp dostane IPcko. Na IPv4 se proste kouknu do logu DHCP serveru a vim jak se na nove zarizeni pripojit.
Jak to same udelam na IPv6? DHCPv6 server nemam a na sitove prvky nemam pristup.
-
Pali (neregistrovaný)
Rovnaky problem je uz s telkami a tam to uz je vyriesene. Telka proste robi WIFI AP a na neho sa mas pripojit. Ked sa potom pripojis na tu WIFI siet, tak potom mozes cez proprietarny program od vyrobcu managovat veci co treba...
To ze je to to najdebilnejsie riesenie nie je pochyb, ale zial takto sa bude asi konzumny svet internet things uberat :-(
-
ondro (neregistrovaný)
Niesom expert na sietovanie ale ako vies mat pod kontrolou klientov? Pridem s mojim zariadnim a strcitm ho do pripojky v tvojej sieti a sfalsujem MAC adresu? Ako si poradis s tymto? Mne z toho vychadza, ze musis pouzit v clanku popisovane praktiky, ktore su ale aj tak nedostatocne a s roznou mierou implementacie vo switchoch.
ISP su jedna vec, ja som mal na mysli firemnu. Tam si nemozem dat kazdeho klienta do vlastnej VLAN. Teoreticky mozem ale vobec to nepovazujem za rozumne riesenie.
Rad sa necham vyviest z omylu.
Viem aky je IPv6 stary protokol ale aj pred 20 rokmi vedeli o bezpecnostnych hrozbach.
-
ondro (neregistrovaný)
mas to napisane v clanku.
Ak som spravne pochopil, tak s IPv6 neviem rovnako elegantne zabezpecit siet vynutenim pouzivania DHCP servera, nastavenim DHCP snooping a ARP poisoning ako v IPv4. Ak som to spravne pochopil, tak je to kvoli bezstavovej konfiguracii implementovanej v IPv6. -
MZ (neregistrovaný)
Nevím, jak příkazem na Ciscu ten Autonomous bit nastavit. Pro vynucení používání jen IP adres přidělených z DHCPv6 se mně spíše osvědčilo kromě nastavení bitu M a O neposílat v RA žádné prefixy. Router pak posílá jen svoji link-local adresu a OS není schopen si vygenerovat kompletní adresu podle SLAAC, protože nezná síťovou část IP adresy. Potom použije jen to, co dostane z DHCPv6. Funguje s defaultním nastavením Windows (asi i linuxu). Tím bude notebook fungovat i mimo firmu jako třeba doma nebo na služební cestě v hotelu apod., kde dostane IP podle místních podmínek. Ve firmě má IP podle DHCP serveru, kde se loguje jméno počítače, a IP se náhodně nemění v krátkých intervalech jako u SLAAC.
Na switchích/routerech Cisco pak je tato konfigurace:
ipv6 nd prefix default no-advertise ! router do not send any prefixes in RA messages
ipv6 nd managed-config-flag ! router sets M bit to 1
ipv6 nd other-config-flag ! router sets O bit to 1
ipv6 dhcp relay destination 2A00:XXXX:: ! definition of DHCP server. It uses UDP 546, 547. -
Pali (neregistrovaný)
V radvd (ne)nastavit Autonomous bit ide (moznost AdvAutonomous). Cisco v tomto smere nepoznam, ale internet hovori, ze by malo fungovat toto:
ipv6 nd prefix SOMETHING no-autoconfig
Neposkytovat ND prefix v RA ma jeden zasadny problem. Je to jedine miesto v IPv6 ako povedat prefix/rozsah (obdoba IPv4 masky) pre pocitace zapojene v sieti.
Spravne podla RFC-ciek by stroje nemali nastavovat ziadne /64 a pod. a to ani v pripade ked ND prefix v RA pakete nie je uvedeny... To ze to na windowse funguje je jedna vec, na linuxe to zavisi od userspacu a konkretne od DHCPv6 daemona (ktory nejaky prefix povie kernelu).
ISC dhcpv6 klient ma natvrdo zapisany "/64" v zdrojakoch (co je porusenie RFC3315) a uplne ignoruje prefix informaciu v RA.
Dibbler dhcpv6 klient porusje RFC3315 takiez, ak nie je zapnuta moznost "strict-rfc-no-routing".
dhcpv6 WIDE klient a aj dhcpcd 6 nastavi spravne prefix z RA a nepouziva ziadne hardcodovane veci ako "/64".
Btw, NetworkManager, ktory pouziva ISC dhcpv6 klienta prefix "/64" v novsich verziach uz zahadzuje a nahrazduje ho prefixom z RA.
Takze to ze ti to funguje na linuxe je dovod skor ten, ze pouzivas niektory z "nespravne nakodenych" (rozumej porusu rfc) dhcpv6 klientov a je dost mozne ze sa to v buducnosti opravi (ako v pripade najviac rozsireneho NetworkManager, ktory uz opravili).
-
Pali (neregistrovaný)
K tejto teme som nasiel este toto:
If you use the no-advertise, the prefix will not be included on the RA. What's the problem with that? Host not only use the prefix on an RA to generate addresses for SLAAC, but also to know which destinations are local and which ones aren't. Check RFC-4861, section 6.3.4. If the router advertise the prefix with the on-link flag set, hosts will consider destinations within the prefix as being present on the link - and will do NS to reach them, forward directly to destination. If you do NOT advertise the prefix, then the host has no clue that the prefix is local - and will forward packets to destination within its same prefix to the default router. Remember that DHCPv6 doesn't provide any information about the prefix length - just the address.
So unless you want to see a lot of redirects from your router to your DHCPv6 clients - advertise the prefix, but with no-autoconfig :)
-
Pali (neregistrovaný)
A tu je dost dobra tabulka pre vsetkych 8 moznych kombinacii Managed, Other a Autonomous flagov:
http://blogs.cisco.com/enterprise/ipv6-automatic-addressing
http://blogs.cisco.com/wp-content/uploads/IPv6-picture.jpg -
mz (neregistrovaný)
Zdá se, že to musím ještě trochu promyslet. IPV6 je ve zkušebním provozu pro pár lidí.
Ten Autonomous bit se nastavuje pro každý prefix, takže v konfiguraci rozhraní to nešlo zadat.
Určitě jsem ověřil, že pokud funguje SLAAC a DHCP, tak PC sice dostane IP podle DHCPv6, ale používají jen pro příchozí provoz a pro odchozí používá ty náhodně vygenerované. Nastavení prefix v RA jsem asi neměnil.Díval jsem se ted ve Wiresharku na to, co posílá DHCP server, a opravdu je tam jen IP adresa, prefix tam není.
-
Pali (neregistrovaný)
Ktora IPv6 adresa sa pouzije pre odchadzuje pakety je popisane v tom routovaciom IPv6 algoritme (trochu komplikovane). Ten algoritmus ma este dalsie systemove pravidla (v linuxe prikaz: ip addrlabel).
Ano Autonomous bit je sucastou prefixu, ktory je sireny v RA pakete. Do jedneho RA je mozne vlozit viacero prefixov a kazdy prefix moze mat (ne)nastaveny Autonomous bit (ci to nejaky SW vie robit, je uz druha vec, teoreticky RA paket je mozne vytvorit).
A ano DHCPv6 server nema v sebe nic ako prefix a jeho dlzku (obdoba masky v IPv4). Proste DHCPv6 nejde pouzivat bez RA. RA musi posielat informaciu o prefixe a DHCPv6 o adresach (priradene IPv6, DNS adresy, ...).
-
mz (neregistrovaný)
Odkazy viz výše a například kniha od Pavla Satrapy říkají to samé: nastavit bity M, O, a bit A. Protože přidělování IP adres fungovalo i pokud router posílal jen info o bráně a prefix ne, tak jsem už nad tím dále nehloubal. Po změně s posíláním prefixu s bitem A se počítač (Win 7) chová stejně - použije IP adresu z DHCP, SLAAC nepoužije.
Nastavení ve Windows je ve výchozím stavu - automatická konfigurace IP adresy i DNS. S tímto nastavením se podaří vyhnout se náhodným IP adresám podle SLAAC, aniž by bylo nutné něco nastavovat ve Windows. A pokud někdo přijde s notebookem mimo firemní síť, tak se připojí pomocí SLAAC. Pro větší společnosti je to asi ideální způsob - IP adresa se nemění, jednodušší hledání v logách, pokud běží DHCP na doménovém serveru, může jméno počítače přiřadit do DNS (ještě prakticky neprověřeno - DHCP běží zatím na serveru mimo doménu). A pokud zvládne (mě by) i zpětné DNS, bude v logách firewalu vidět jméno počítače ve tvaru pc.windomena.cz.
Konfigurace na routeru / L3 switchi Cisco:
interface Vlan100
ipv6 address 2A00:XXXX:/64
ipv6 enable
ipv6 nd prefix 2A00:XXXX::/64 30000 30000 no-autoconfig ! set A bit in the prefix in RA to 1
ipv6 nd managed-config-flag ! set M bit in RA to 1
ipv6 nd other-config-flag ! set O bit in RA to 1
ipv6 dhcp relay destination 2A00:YYYY:::X ! definition of DHCP server. DHCP relay uses UDP 546, 547.
endZajímavé je, že DHCP relay agent posílá informaci o MAC adrese klienta, ale v logu Windows DHCPv6 tam MAC adresa není, je tam jen DUID a IAD a jméno počítače. Jak si řada lidí stěžuje, že by chtěli na DHCP serveru přidělovat podle MAC adresy, tak by to možná šlo, ale DHCP server tuto MAC adresu nejspíše nijak nevyužívá.
Z odchytaných dat:
DHCPv6
Message type: Relay-forw (12)
Hopcount: 0
Link address: 2a00:XXXX::
Peer address: fe80::74f1:efb7:d17b:6693 (fe80::74f1:efb7:d17b:6693)
Relay Message
Option: Relay Message (9)
....
Client Identifier
Option: Client Identifier (1)
Length: 14
Value: 000100011b91ffe6705ab6b5345d
DUID: 000100011b91ffe6705ab6b5345d
DUID Type: link-layer address plus time (1)
Hardware type: Ethernet (1)
DUID Time: Aug 28, 2014 16:57:42.000000000 Central Europe Daylight Time
Link-layer address: 70:5a:b6:b5:34:5d -
JohnyRi (neregistrovaný)
Pokud mám správné informace (a zkušenosti), tak věc se má tak, že Windows berou náhodné přidělení IPv6 jako ochranu, a proto jako odchozí používají tu náhodnou, kterou ještě čas od času obměňují. Linux si myslím vezme jako primární tu od DHCP a Android jen SLAAC, protože nic jiného neumí.
-
j (neregistrovaný)
A pokud je to zaply, a aplikace to nepouziva, tak je spatne napsana. Kdyz sem to jen tak prozajimavot testil, tak trebas vadnej byl fillezilla klient pro widle, pouzival statickou adresu misto ty random.
Pouziva se to pak predevsim proto, aby neslo zarizeni identifikovat v jiny siti. Protoze jinak by melo poslednich 64bitu vzdy stejnych a bylo by jednoznacne identifikovatelny kdekoli.
-
mz (neregistrovaný)
Tomu Privacy extension rozumím. Pokud chodím do Internetu, tak at se IP adresa mení. Ale řešit v práci např. problém uživatele, kterému něco nefunguje a potřebuju ho dohledat v nějakém logu podle IP adresy, když se IP cca každých 10 minut mění, by bylo dost obtížné. Ne každý, kdo něco řeší s IP adresami, má přístup k ARP tabulce (Neighbor cache je myslím správný název pro IPV6), aby si našel aktuální IP podle MAC adresy.
-
Pavel (neregistrovaný)
Vynuceni DHCPv6 bez SLAAC adresy ma dva podstatne problemy:
- DHCPv6 je pouze volitelny, takze na takove siti jsou napriklad Androidi bez IPv6 konektivity.
- Staci jeden zbloudily paket s RA (napriklad z Windows z Internet Sharing), ktery nema vynulovany A Flag a razem maji vsichni klienti nakonfigurovanou adresu podle SLAAC.
-
Pali (neregistrovaný)
Jasne, dovody su uvedene v clanku. Treba si ale uvedomit, ze je to rovnako ako aj v IPv4. Ak proste nejaky klient nepodporuje DHCP (v4) tak proste adresu z DHCP (v4) servera neziska... A rovnako je to s RA od Windows Sharing. V IPv4 staci aby nejaky Windows zacal posielat DHCP offer pakety...
Ak uz raz clovek potrebuje pevne mapovanie IPv6 <--> MAC <--> stroj tak mu neostava nic ine iba 1) pouzit staticke IPv6 adresy alebo 2) pouzit DHCPv6. A zial stroje co nepodporuju ani 1) a ani 2) maju smolu.
-
k (neregistrovaný)
V IPv4 nestačí aby nějaký Windows začal posílat DHCP Offer. Klient kontaktuje původní server od kterého dostal adresu. Musel byste nabourat komunikaci při první výměně zpráv - bylo to popsané myslím i v minulém článku.
Mapování IPv6-mac-stroj u IPv6 pomocí DHCPv6 neuděláte. DHCPv6 klient nepoužívá jako identifikátor MAC adresu jako u IPv4 ale DUID. To je typicky buď náhodné nebo složené z časové značky a MAC adresy libovolného síťového rozhraní. Pokud byste si DUID rozparsoval na jednotlivé části (porušíte tím RFC, které to zakazuje), tak vám to taky nepomůže, protože MAC adresa nemusí být a často ani není toho rozhraní, přes které je zařízení do sítě připojeno.
Částečné řešení může být použít DHCPv6 relay, která tam tu informaci dokáže dostat, nicméně rozumná implementace zatím není (experimentální ji teď přidali do Cisco XE, ale na přepínačích, kde je třeba, není). -
Pali (neregistrovaný)
Mac adresu treba vycitat z ethernetovej hlavicky a v pripade, ze paket nebol poslany priamo klientom, ale cez DHCPv6 relay, tak treba zaistit aby bola pridana informacia o povodnej mac adrese. Takze bud relay nepouzivat, kym to nebude podporovat alebo sa uspokojit s mapovanim cez DUID. V teoretickej rovine riesitelne to je, len treba mat SW pre to :-( snad bude dostupny.
-
k (neregistrovaný)
Ale mapování přes DUID dnes právě nemůžete použít, protože neodpovídá realitě. Pokud si klient přeinstaluje systém, má jiné DUID. Pokud si klient přebootuje do jiného OS, má jiné DUID atp.
Na to, abyste mohl vyčíst MAC z Ethernet hlavičky musíte mít DHCPv6 server ve stejné L2 síti jako uživatele a DHCPv6 server to musí umět. Krom jedné opensource implementace v Pythonu, na kterou se půl roku nešáhlo, to nic jiného neumí. Navíc mít v každé VLAN vlastní DHCPv6 server je "poněkud" náročné.
Je moc pěkné, že to máte vyřešené teoreticky. Až někdy budete jako správce provozovat IPv6 síť, tak vám určitě teoretický plat za to bude taky stačit. Dostat něco prakticky na účet je přeci jedno, když víte, že to teoreticky na ten účet přijít může :)
-
Pali (neregistrovaný)
Pre ISC dhcpv6 server existuju patche co vytiahnu MAC adresu z ethernetovej hlavicky. Mam ale pocit ze je to neverejne... Osobne mam stroj pripojeny na sieti, kde takto opatchovany dhcpv6 server bezi, takze mozem potvrdit, ze patche nie len ze existuju, ale aj funguju. A co sa tyka DHCPv6 relay, tak mam pocit, ze som nejaku open source implementaciu videl co podporuje OPTION_LINK_ADDRESS (to by malo byt pouzitelne na vytiahnutie MAC adresy). Nepamatam si ale ako sa volala.
-
Spíše je otázkou, zda na ten protokol nekladete požadavky, které by se měly řešit na jiných vrstvách. To byste rovnou mohl nadávat tomu UTP kabelu, že přenesl data (v jeho případě v podobě různých napěťových stavů) o která nemáte zájem. Co je tomu kabelu do toho? ;-)
A navíc, kdybyste chtěl ten protokol zabezpečit, tak budete klást další požadavky, které jednak zkomplikují jeho implementaci a o to více znároční ten HW, což povede ještě k menší snaze na tento protokol přejít.
"Tento druhy diel je vyborny na odradenie od implementacie IPv6 na hocijakej urovni."
Asi jak pro koho. U spousty odstavců jsem si říkal: ehm, jak je možné, že správce sám sebe dostal do dané situace? Bezpečnost není (jen) o tom koupit switch za hromadu peněz a naklikat tam hromadu ochran a tvářit se, že je to ok. Bezpečnost je taky o tom ten switch s těmi ochranami vůbec nepotřebovat.
-
Ivan (neregistrovaný)
Myslim, ze se spravce do danne situace dostal tim, ze podepsal pracovni smouvu na vysoke skole. Kazde prostredi ma svoje specifika, a akademicka puda je v tomhle smeru asi nejnarocnejsi.
PS: IPv6 ma byt Internetem veci (a ne lidi a jejich desktopu), takze se tak nejak predpoklada ze se do site bude pripojovat spousta ruznych autonomnich krabicek, na kteryma nebude mit nikdo kontrolu.
-
j (neregistrovaný)
Ta krabicka se ale sama telepaticky do internetu nepripoji, ta krabicka se pripoji do nejak nakonfigurovane site a spravce te site je ten, kdo rozhoduje o tom, zda se vubec pripoji.
V typicky domaci siti, kdyz nejaka krabka zacne posilat RA, tak proste "internet prestane fungovat". Kdyz neco takovyho zacne delat trebas neci mobil, tak ten internet mozna fungovat bude ... par minut, nez se vycerpa fup.
Jenze soho stejne nema vubec smysl resit, soho switch stejne neumi resit ani arp poisoning ani dhcp na ipv4. => logicky se bavime o firemnich sitich. A do firemni site by asi nemelo jit pripojit kde co kdo prinese. A pokud, tak do striktne oddelene casti. A pokud se tedy bavime o firemnim prostredi, tak tam (pokud jsou dotycni alespon castecne pri smyslech) plati, ze admin kontroluje nejen sit, ale i zarizeni, ktera se do ni pripojuji.
V takovy siti pak nemusim resit ani dhcp na ipv4, proste proto, ze si ho nikdo nespusti, nebot nema jak. A v ty casti site, ktera je pro navstevniky, me to nijak zvlast nepali. Maximalne jim to nebude fungovat.
A ano, uz sem parkrat (v blbe postavene siti) hledal dhcpko. Kdo chce kam ...
Takze to vidim jako komara, ze kteryho se dela velbloud.
-
j (neregistrovaný)
A ve vsech teto pripadech to neni zadnej problem - respektive presne stejnej, jako na ipv4. Pokud trebas nechas lidi na wifine, a nevytvoris (protoze nemas jak) kazdymu vlanu, tak sou na stejnym "fyzickym drate" at chces nebo ne. Neexistuje zpusob jak bys moh zabranit tomu, aby ti tam nekdo poslal dhcpko. Co vic, dokonce ti jedinej klient to APcko muze klidne dosnout a taky stim nenadelas nic. Takhle to proste funguje.
Nehlede na to, ze se zase (prevazne) bavime o +-soho. Pokud nekdo provozuje wifi v kavarne, koupi si APcko za petikilo a tim to konci. Proste provozujes negarantovatelnou sit a tak to bylo je i bude. Pokud potrebujes provoz v siti garantovat, tak na to musis mit HW i prislusny paky.
-
Jenda (neregistrovaný)
> Po precitani tychto dvoch dielov mam pocit, ze soudruzi udelali pri navrhu IPv6 nekde chybu.
> Ako takyto protokol mohol vobec vzniknut?
Moc rád si poslechnu lepší řešení - sem s tím! Jak už jsem psal pod minulým článkem, podle mě tohle principiálně vyřešit nejde - chceš mít možnost připojit router, a současně do neodlišené zásuvky počítač, který nemá být router.
> Kazdeho, kdo bude spominat a pretlacat IPv6 s radostou odkazem na tento clanok.
Kazdeho, kdo bude spominat a pretlacat IPv4 s radostou odkazem na tento clanok.
Ne, naprosto vážně: článek jsem prolítl, o zmíněných problémech vím, ale vůbec nevidím, jak se to liší od stejných problémů v IPv4. Nebo znáš ještě nějaký další protokol, který to třeba řeší?
-
ondro (neregistrovaný)
Lisi sa to tym, ze u IPv6 to komplikuje bezstavova konfiguracia(Oznamenie smerovaca), ktora v IPv4 nieje a jej obratena logika.
Ak som spravne pochopil z clanku, tak zabezpecenie IPv6 je narocnejsie a siet lahsie napadnutelna. Ak zoberiem v clanku popisovany stav implementacie IPv6 v zariadeniach, tak v mnohych pripadoch nieje mozne rovnako zabezepcit siet s IPv6 ako pri IPv4.Ako som uz spominal(samozrjeme je to aj v clanku), tak v IPv6 neviem nastavit vynutenie pouzivat DHCP u klientov(a tym padom zakazat pouzivat pevne IP adresy v sieti) a uplne vylucit bezstavovu konfiguraciu(Oznamenie smerovaca), ktora je kamenom urazu tohto celeho.
Mne z toho vychadza, ze to mohli urobit opacne. V IPv6 malo byt DHCP primarnym sposobom konfiguracie klientov a bezstavova ako sekundarna/volitelna. DHCP bolo do IPv6 len dolepene a je len nadstavbou, ktora potrebuje k svojej funkcii Oznamenie smerovaca.
Vyzera, ze u tej bezstavovej konfiguracie soudruzi udelali chybu a nedomysleli nasledky.Tesim sa, na dalsie pokracovanie serialu. Je vybrone a zrozumitelne napisany. Tiez kvitujem to porovnanie s s IPv4.
-
Jenda (neregistrovaný)
> Lisi sa to tym, ze u IPv6 to komplikuje bezstavova konfiguracia(Oznamenie smerovaca), ktora v IPv4 nieje a jej obratena logika.
Zase tam není potřeba DHCP.
> Ak zoberiem v clanku popisovany stav implementacie IPv6 v zariadeniach, tak v mnohych pripadoch nieje mozne rovnako zabezepcit siet s IPv6 ako pri IPv4.
Ale to není problém návrhu IPv6.
> Ako som uz spominal(samozrjeme je to aj v clanku), tak v IPv6 neviem nastavit vynutenie pouzivat DHCP u klientov(a tym padom zakazat pouzivat pevne IP adresy v sieti)
Hmm… proč ti vadí pevné adresy? Považuješ adresu nastavenou pomocí autokonfigurace za pevnou?
> Mne z toho vychadza, ze to mohli urobit opacne. V IPv6 malo byt DHCP primarnym sposobom konfiguracie klientov a bezstavova ako sekundarna/volitelna.
DHCP má malou chybu v tom, že je to jeden centrální server, ne víc routerů, které propagují různé prefixy s různou prioritou.
-
Pali (neregistrovaný)
> Ako som uz spominal(samozrjeme je to aj v clanku), tak v IPv6 neviem nastavit vynutenie pouzivat DHCP u klientov(a tym padom zakazat pouzivat pevne IP adresy v sieti) a uplne vylucit bezstavovu konfiguraciu(Oznamenie smerovaca), ktora je kamenom urazu tohto celeho.
V postate to nevies ani v IPv4. Ani tam nedonutis klientov na 100% aby si ip adresy nevymysleli sami a boli nuteny pouzivat DHCP.
Avsak bezne Windowsy aj Linuxy donutit vies, vid moj prispevok: http://www.root.cz/clanky/bezpecne-ipv6-zkroceni-zlych-smerovacu/nazory/532669/
-
peci1Stříbrný podporovatelTak nevim, ale po precteni kapitoly ND-Snooping mam pocit, ze to proti nicemu nechrani. Kdyz totiz budu utocnik, tak si (snad) dokazu zajistit, abych zadne overovani u sousedu nedelal, a tedy se ani nedostal muj zaznam do tabulky na routeru. Nebo to bez tech zprav sousedum (nejak) nefunguje?
-
jc (neregistrovaný)
Diky za clanek. Ale osobne si myslim, ze dneska je porad jeste uzitecnejsi informace, jak IPv6 na switchich kompletne blokovat (treba pomoci ACL).
Ano, znamena to aktivne bojovat proti krasnemu novemu protokolu, ktery snad nekdy v budoucnu vyresi aktualni problemy internetu. Ale kdyz za ty dlouhy roky nebyli schopni se na pomerne zasadnich IPv6 vecech domluvit softwarovi i hardwarovi giganti a hazou si navzajem klacky pod nohy, at nechteji po nas, abychom zachranovali svet.
-
Honza (neregistrovaný)
Opět smekám nad fantastickým přístupem k článku. !!
Oceňuji konkrétní rady a upornění na možná úskalí. Super odrazový můstek a hlavně ukazatel toho na co se má člověk zaměit a o čem hledat informace pokud se chce do nějaké problematitky ponořit hlouběji.
Chápu a částečně souhlasím s příspěvky výše, že nemůžeme chtít po TCP/IP protokolu nemožné, ale doba si to bohužel žádá. Když se někdy v 60 letech spuštěl ARPANET taky nikdo nečekal takový rozmach a vznik internetu.
Dnes se taky nedá předvídat kam se v budoucnu síťová komunikace pohne... Třeba protokol TCP/IP úplně vymizí, ale nikdo nemá "křišťálovou kouli" takže proto si myslím, že by se měl při vývoji brát ohled na problémy které měl protkol IPv4.Vyvíjet něco co trpí podobnými neduhy jako předchůdce není princip "evoluce". Plán že IPv6 v budoucnu kompletně nahradí IPv4 je v nedohlednu a díky autorům se přestávám divit, že je to tak jak to je...
Díky a těším se na pokračování
-
Na jednu stranu souhlasím s tím, že mnohé kroky v návrhu autokonfigurace IPv6 byly šlápnutím vedle, včetně samotného bezstavového protokolu, ale na druhou stranu bych rád slyšel názor lidí, kteří se s tím snažili něco aktivně udělat. Přecijen ten proces snad nebyl až tak uzavřený a kdyby se jenom trochu chtělo, mohla přijít konstruktivní kritika a třeba i náprava.
