IPv6: adresy počítačů v praxi

5.3.2010 21:44 | Přečteno: 2274× | poslední úprava: 5.3.2010 21:44

Podle nějaké "košér" metodiky má mít každá IPv6 síť prefix /64 a adresy jednotlivých zařízení mají mít v dolních 64 bitech MAC adresu (nebo náhodné číslo). Zdá se, že to opravdu všichni velcí provideři dodržují...

traceroute to ..., 30 hops max, 80 byte packets                                                                             
...                 
 2  te8-2.v0702.hd-core01.ip6.mtl.iweb.com (2607:f748:0:1:0:9:1:2)  1.537 ms  1.609 ms  1.736 ms                                                                
 3  te8-1.v0709.cl-core04.ip6.mtl.iweb.com (2607:f748:0:1:0:1:4:2)  1.981 ms  2.123 ms  2.240 ms                                                                
 4  ix-9-1.icore1.MTT-Montreal.ipv6.as6453.net (2001:5a0:300:300::1)  2.558 ms  3.146 ms  3.160 ms                                                              
 5  if-10-0-0.19.mcore3.MTT-Montreal.ipv6.as6453.net (2001:5a0:300:100::19)  3.123 ms  3.107 ms  3.459 ms                                                       
 6  if-3-0.mcore4.MTT-Montreal.ipv6.as6453.net (2001:5a0:300:200::1)  3.460 ms  2.028 ms  2.145 ms                                                              
 7  POS3-0.core2.NTO-NewYork.ipv6.as6453.net (2001:5a0:300:200::6)  43.711 ms  44.804 ms  44.893 ms                                                             
 8  if-11-0-0.core3.NTO-NewYork.ipv6.as6453.net (2001:5a0:a00::9)  9.587 ms * * 
 9  2001:5a0:600:300::46 (2001:5a0:600:300::46)  10.034 ms  10.272 ms  10.430 ms
10  vl-51.car1.NewYork2.Level3.net (2001:1900:38:1::3)  18.292 ms vl-52.car1.NewYork2.Level3.net (2001:1900:38:2::3)  17.667 ms  17.900 ms                      
11  vl-4061.car2.Washington1.Level3.net (2001:1900:4:1::105)  18.386 ms  18.041 ms  18.496 ms                                                                   
12  vl-4085.sar1.Washington1.Level3.net (2001:1900:4:1::251)  17.021 ms  16.248 ms  16.971 ms                                                                   
13  tu-645.sar1.London1.Level3.net (2001:1900:6:1::9)  86.016 ms  85.977 ms  85.400 ms                                                                          
14  tu-613.sar1.Amsterdam1.Level3.net (2001:1900:5:1::a)  94.077 ms  93.775 ms  93.863 ms                                                                       
15  Volny.tu-658.sar1.Amsterdam1.Level3.net (2001:1900:5:2::13a)  118.709 ms  118.679 ms  118.249 ms                                                            
16  ge1-1.bb3.prg2.ipv6.vol.cz (2001:1508:1:16::2)  138.995 ms  136.063 ms  119.343 ms                                                                          
17  e2-1.c10.prg.ipv6.vol.cz (2001:1508:1000::12)  126.377 ms  122.932 ms  122.950 ms                        
...

       

Komentáře

[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.