IPv6: adresy počítačů v praxi (diskuse)

[fissie]

Podle jake presne koser metodiky to je? Takhle funguje autokonfigurace podle EUI64, ale nikde se nerika, ze je to povinne. Adresni plan si muzes preci zvolit jaky chces, pokud nechces pouzivat autokonfiguraci. Nikdo nerika, ze musis zredukovat sve adresy z 2^64 na 2^48 jen kvuli EUI, nikdo nerika ze to vzdycky bude ethernet a ze to tudiz nejaky MAC adresy vubec bude mit... Pokud autokonfiguraci mas, tak je asi moudre mit na danem subnetu _jenom_ EUI64 kvuli pripadnym kolizim, ale na peer to peer spojich routeru autokonfigurace? To preci ne

[trekker.dk]

Nikdo nerika, ze musis zredukovat sve adresy z 2^64 na 2^48 jen kvuli EUI,

MAC adresu (nebo náhodné číslo)

[fissie]

Znovu, kde se to pise? .

[thingie]

Hele, a kde se podle tebe píše jak by ty adresy vůbec měly vypadat a jaká je politika pro jejich přidělování a utváření?

(Pak si otevři RFC 4291.)

[pht]

Neříkám, že to je povinnost; i když ten /64 subnetting povinnost je a co jiného s tím. Pouze to je všude zdůrazňováno jako že to tak "má být" a dokonce se hovoří i o tom, že díky tomu se zamezí horizontálnímu scannování sítí (i když o tom pochybuju). Jo a nejsou to jen peer to peer spojení.

www.isc.org.            600     IN      AAAA    2001:4f8:0:2::d
ftp.sh.cvut.cz.         86400   IN      AAAA    2001:718:2::222
ipv6.l.google.com.      275     IN      AAAA    2a00:1450:8001::67
...

Pokud to každej používá takhle tak je povinný /64 subnetting zbytečný (a spousta lidí ho i obchází).

[danysek]

Zbytecne to urcite neni. EUI64 samo o sobe nerika, ze adresa nutne musi byt odvozena z MAC, zpusob ziskani identifikatoru muze byt i jiny. Samotne "setreni" muze vest k rozbiti dalsich veci.

[pht]

EUI64 samo o sobe nerika, ze adresa nutne musi byt odvozena z MAC

Neříkám že to tak je nutně, viz příspěvek, na který reagujete...

Samotne "setreni" muze vest k rozbiti dalsich veci.

Např.?

[xurfa]

Dobrej unik informaci: aspon budeme vedet, jakou sitovku pouziva druha strana...

[pht]

A budeme zase o krok před nimi. Bude to stačit myslíš?

[houska]

tak tohle me fakt dost rozesmalo ... moc pekne :D

[fissie]

A bude nam to k cemu presne?

[xurfa]

noo.. třeba teroreticky když bude nějaká díra třeba v driveru pro příslušnou síťovku :). nebo abych odhad, jak moc nadupaná mašina to je, tj. jestli je to síťovka za 300,- nebo za 3000,-? ;) nevím, kreativitě se meze nekladou

[fissie]

To je security through obscurity a ta jak znamo moc v realnym prostredi nefunguje. Je proste mnohem jednodussi rovnou sypat nejakej exploit, kterej se bud chyti (deravej driver) nebo ne (jinej driver), nez nejdriv testovat, jestli vubec ten exploit zabere a pak ho bud poslat nebo ne. To by ostatne bylo neefektivni pro utocnika, protoze by pak "obrance" mel snadnou cestu, jak se i s deravym driverem utoku vyhnout. A btw, musel bych hodne vzpominat, abych si vybavil jediny bug popisovaneho druhu.

V jednom obdobi bylo treba hodne popularni menit reportovanou verzi BINDu, protoze si nekdo myslel, ze ta verze snad nekoho zajima. Nezajima, vubec. Proste se to tam nasype a ceka se co z toho vypadne. Jinak jo, odhalit ze clovek ma crappy sitovku se da, ale uzitecnost te informace je take dost nizka.

[trekker.dk]

A btw, musel bych hodne vzpominat, abych si vybavil jediny bug popisovaneho druhu.

V jádře 2.4 byl IIRC nedávno opraven ovladač e1000 pro síťovky Intel, chyba umožňovala obejít netfilter.

[Limoto]

Přesněji spíš výrobce základní desky...

[Jary]

Myslím, že ta část IPv6 s MAC adresou by neměla obsahovat přímo MAC, ale jen její nějak upravenou, řekněme, hash tak, aby nebylo možné podle IPv6 jednoznačně říct, o kterého výrobce karty a myslím ani o kterou MAC jde.

[fissie]

Vyborne. Jeste jednou, cim presne je tohle nebezpecne?

[Vašek Lorenc]

Obvykle se uvádí, že nebezpečné je to tím, že můžeš sledovat uživatele -- prefix se mu měnit bude, posledních 64 bitů ne. Seznam, Google či někdo, ke komu chodí víc uživatelů, tak následně teoreticky může zkoušet zjistit, jak kdo s notebookem pochoduje v rámci různých IPv6 sítí.

Ostatně z toho pochází i doporučení dávat tam náhodné číslo, které se případně ještě časem (či po protočení určitého množství dat) mění.

[fissie]

Ano, tohle je popsano v RFC 4941 (privacy extensions) a vsechny podstatne operacni systemy vcetne windows to podporuji. Jen je trochu opruz, kdyz ti kvuli tomu kazdou chvili maji uhnivat konekce (ssh, jabber, ...).

[trekker.dk]

kdyz ti kvuli tomu kazdou chvili maji uhnivat konekce (ssh, jabber, ...).

Pravděpodobně by neměl být problém nahodit novou adresu, preferovat ji pro všechna nová spojení a starou adresu zahodit ve chvíli, kdy ji už žádné staré spojení nepoužívá. Tím neříkám, že jsem to viděl implementované, ale soudím, že by to nemělo být tak těžké.

[Josef Kufner]

IMHO by bylo efektivnější přemigrovat existující spojení na novou adresu. Podobně jako se zavírá spojení by se poslalo "měním svou IP". Jak a jestli se něco takového používá, nevím.

[pht]

Aneb únos spojení v nové dimenzi ;)

[the.max]

Ne, primo MAC adrsa se tam primo nepise. Nechce se mi to ted hledat, ale je to tak, ze se vezme MAC adresa, neco se v ni prehodi, doplni se tam nejakej FF a to se pouzije. Tohle je doporuceni popsane v RFC. ale je to DOPORUCENI, takze to jeste neznamena ze se to tak MUSI BEZPODMINECNE pouzivat. Treba mykro$oft to resi nejak jinak, odduvodnuji to (tusim) tim, ze se prave podle toho da zjistit puvodni MAC adresa, podle ktere se da zjistit jeji vyrobce a typ. Proto pry zavedli jiny system pro pridelovani adres pro autokonfiguraci.

[snajpa]

Ať si doporučujou, co chtěj. Já si vždycky z toho rozsahu, co máme, přidělím něco, u čeho mám aspoň trochu reálnou šanci na zapamatování.

[Opičák]

konečně něco s čím se ztotožňuji :)

[the.max]

asi tak nejak

[Ondrej 'SanTiago' Zajicek]

Pridelovani adresy zpusobem, ktery jsi popsal, je jenom jedna z moznosti, vhodna tak akorat pro uzivatelske stanice s autokonfiguraci. Pro servery nebo routery je mnohem rozumnejsi pridelovat pevne (na MAC adrese nezavisle) adresy.