Portál AbcLinuxu, 5. května 2025 08:53
8.1.2011 11:44
Jendа | skóre: 78
| blog: Jenda
| JO70FB
2) Je nějaký dobrý důvod, proč nejmenší možná podsíť je /64? Chápu, že je potřeba předejít vyčerpání jako v IPv4, ale /64 je pro účely jedné jediné podsítě strašný overkill -- stejně dobře by stačilo /80 nebo dokonce /96. Na druhou stranu zbývajících 64 bytů pro číslování sítí už tak moc není, obzvlášt vzhledem k tomu, že i pro běžného smrtelníka není problém získat /48.Podle mě můžeš mít podsíť, jakou chceš, akorát pokud bude menší než /64, nebudeš moct používat autokonfiguraci s EUI-64, ne?
2.5.1. Interface Identifiers ... For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. ...
15.1.2011 20:50
MaSo | skóre: 15
| blog: MaSo
| Frýdek-Místek
16.1.2011 08:34
MaSo | skóre: 15
| blog: MaSo
| Frýdek-Místek
A tedy se ze serveru nedá PC donutit, aby používal prioritně mou IPv6 na místo z RA?Při správné implementaci a konfiguraci se na serveru volí, jestli součástí RA je svolení, aby si klienti volili adresy sami.
Je tedy nutné použít jak DHCPv6, tak bezestavovou konfiguraci pomocí RA.Není. Pokud používáte DHCPv6 k přidělování IPv6 adres, nemá smysl zprovozňovat zároveň bezestavovou konfiguraci, stačí pouze generovat RA pro nastavení směrování.
Pokud si k síti připojíte windows vista a vyšší, tak adresu z dhcpv6 serveru dostane. Taky si ale vygeneruje IPv6 adresu z RA. Díky tomu, že má adresu z RA, tak si vygeneruje náhodnou pomocí privacy extensions. Jelikož privacy extensions adresa má nejvyšší prioritu, použije se pro komunikaci tu a ne tu přidělenou DHCPv6.V tom případě to máte špatně nastavené. Chtete-li používat adresy z DHCPv6, musíte v RA u každého ohlášeného prefixu vynulovat příznak A. Tím se klientům zakáže použít daný prefix pro bezestavovou autokonfiguraci. Například v konfiguraci radvd:
8.1.2011 11:23
19.1.2011 22:49
17.1.2011 08:17
prefix 2001:1:2:3::/64
{
AdvAutonomous off;
...
};
17.1.2011 15:35
MaSo | skóre: 15
| blog: MaSo
| Frýdek-Místek
až vyřeším jeden problém s IPv6Snad ne konektivitu? :)
20.1.2011 09:23
MaSo | skóre: 15
| blog: MaSo
| Frýdek-Místek
ne, tu "mám" přes tunel he.net.
21.1.2011 09:21
MaSo | skóre: 15
| blog: MaSo
| Frýdek-Místek
21.1.2011 23:30
MaSo | skóre: 15
| blog: MaSo
| Frýdek-Místek
(no---ještě uvidíme). Fakt je, že tenhle FW má jak IPv4, tak i 6. FW6 potřebuji každopádně, co jsem si rozchodil IPv6 v celé domácí síti...
Není. Pokud používáte DHCPv6 k přidělování IPv6 adres, nemá smysl zprovozňovat zároveň bezestavovou konfiguraci, stačí pouze generovat RA pro nastavení směrování.Přijde mi to stejné jako jsem napsal já. Možná jsem to blbě formuloval, ale myslel jsem to tak, že nemůžu mít pouze DHCPv6 server, ale musím mít zprovozněného i RA démona.
V tom případě to máte špatně nastavené. Chtete-li používat adresy z DHCPv6, musíte v RA u každého ohlášeného prefixu vynulovat příznak A. Tím se klientům zakáže použít daný prefix pro bezestavovou autokonfiguraci. Například v konfiguraci radvd:
prefix 2001:1:2:3::/64
{
AdvAutonomous off;
...
};
Tj. dívám se, že jsem v předchozím příspěvku napsal blbě flag. ne onlink, ale autonomous. Je to tak jak říkáte. Akorát je pak problém, že dost často na macu nebo linuxu není defaultně dostupný dhcpv6 klient, ale to se snad změní a v domácí síti, kde si to můžu nakonfigurovat jak chci, to asi nevadí.
Souhlasí. Já poukazoval na to, že bezestavová konfigurace není totéž co RA. Jinými slovy: bezestavová konfigurace je jedna z (volitelných) funkcí RA, kteréžto je (zatím) povinné pro všechny ne-manuální konfigurace IPv6 na ethernetu.Není. Pokud používáte DHCPv6 k přidělování IPv6 adres, nemá smysl zprovozňovat zároveň bezestavovou konfiguraci, stačí pouze generovat RA pro nastavení směrování.Přijde mi to stejné jako jsem napsal já. Možná jsem to blbě formuloval, ale myslel jsem to tak, že nemůžu mít pouze DHCPv6 server, ale musím mít zprovozněného i RA démona.
RA = Router Advertisement, bezestavová konfigurace.Router Advertisement se překládá jako oznámení či ohlášení routeru. Bezstavová konfigurace související pojem, ale jako překlad je to nesmysl.
DHCPv6 je těžké v praxi použít kvůli tomu, že nedokáže přidělit default gw a prefixy.Citation needed.
Pokud si k síti připojíte windows vista a vyšší, tak adresu z dhcpv6 serveru dostane. Taky si ale vygeneruje IPv6 adresu z RA.Pokud je tomu tak, tak je někde chyba, a RFC to není. Osobně bych to hádal na špatně nakonfigurovaný server, na druhém místě bych se teprv zajímal o klienta.
Ve větší síti tedy dhcpv6 nemá téměř cenu.Spíš IMO nemá cenu v menší síti, kde stačí sesbírat MAC adresy dodatečně a nechat vše na automatice, ale to je jen můj názor. Mluvím o technologii, ne o chybách současných implementací.
V praxi se tak typicky nasazuje pouze RA a klienti si generují adresy sami. Pokud potřebujete jiné, tak buď staticky, nebo si je hodit do dns, nebo zkusit nějak rozchodit to dhcpv6. Bude to ale boj.Boj to bude, ale neviděl bych to tak černě.
Router Advertisement se překládá jako oznámení či ohlášení routeru. Bezstavová konfigurace související pojem, ale jako překlad je to nesmysl.Ach, dobře. Je to sice podle mě slovíčkaření, protože router advertisement slouží v současné době výhradně k bezstavové konfiguraci, takže z jednoduchosti, jsem to tak použil. Pokud budeme důslední, tak máte pravdu.
DHCPv6 je těžké v praxi použít kvůli tomu, že nedokáže přidělit default gw a prefixy.
Citation needed.Proč? DHCPv6 tyto možnosti konfigurace prostě v sobě neobsahuje a počítá se s koexistencí s RA. Pokud chcete tedy něco oficiálního tak problémy jsou třeba trochu popsány tady
3.10. Add Default Gateway/Prefix Options to DHCPv6 Adding Default Gateway and Prefix options for DHCPv6 would allow network administrators to configure hosts to only use DHCPv6 for default gateway and prefix configuration in managed networks, where RAs would be required today. A new draft has proposed such a default router option, along with prefix advertisement options for DHCPv6 [I-D.droms-dhc-dhcpv6-default-router]. Even with such options added to DHCPv6, an RA is in principle still required to inform hosts to use DHCPv6.Problém je prostě v tom, že RA mi podvrhne kdejaká trubka třemi řádky ve scapy a teď ho prostě nejde filtrovat. Snooping na L2 není, IPv6 ACL L2 prvky neumí. DHCPv6 nemůže fungovat samo. Stačí jeden upravený paket, který pomíchá flagy M/O a v síti je bordel jedna dvě.
...router advertisement slouží v současné době výhradně k bezstavové konfiguraci...s/výhradně/také/
Ach, dobře. Je to sice podle mě slovíčkaření, protože router advertisement slouží v současné době výhradně k bezstavové konfiguraciPokud by tomu tak bylo, tak ano... ale tohle je právě ten klíčový omyl. RA v současné době slouží k ohlášení routeru, což se používá jak k bezstavové, tak ke stavové konfiguaci. V obou případech je získání RA klientem (ať už čekáním nebo na vyžádání), první krok ke konfiguraci sítě.
Proč? DHCPv6 tyto možnosti konfigurace prostě v sobě neobsahuje a počítá se s koexistencí s RA. Pokud chcete tedy něco oficiálního tak problémy jsou třeba trochu popsány tadyDíky, tuhle část si budu muset ještě projít, moc jsem se soustředil na konfiguraci adresy... když se na to tak dívám, přijde mi konfigurace gateway v DHCPv6 v podstatě zbytečná.
Problém je prostě v tom, že RA mi podvrhne kdejaká trubka třemi řádky ve scapy a teď ho prostě nejde filtrovat.Stejně jako DHCPv4 a DHCPv6? Mě přijde z tohoto pohledu úplně jedno, jestli se první paket stavové konfigurace zabalí jako ICMP nebo jako UDP.
přijde mi konfigurace gateway v DHCPv6 v podstatě zbytečná.S tím jde do jisté míry souhlasit. V IPv6 je třeba trochu změnit zažité zvyky a nemám nic proti tomu. Každopádně mi ale nepřijde jako příliš velká výhoda tyto informace z DHCPv6 odstranit.
Stejně jako DHCPv4 a DHCPv6?To ano, ale jedním podvrženým paketem neovlivníte všechny na síti jako v případě RA (neberu bezstavové dhcpv6, kdy to do jisté míry jde taky). Teď prostě jedním odpojíte všechny od IPv6 internetu. A současnými prostředky tomu nelze skoro zabránit. SeND nemáme, acl většinou tohle moc neumí, snooping není. Já vím, časem bude, ale už aby to bylo.
Mě přijde z tohoto pohledu úplně jedno, jestli se první paket stavové konfigurace zabalí jako ICMP nebo jako UDP.To samozřejmě jedno je. Až budou dostupné možnosti filtrování, jaké jsou teď u IPv4, tak se těmto problémům budeme jen smát. Teď ale nezbývá než skřípat zuby a nasazovat obezličky, které fungují jen silou vůle a cílenému útoku neodolají.
S tím jde do jisté míry souhlasit. V IPv6 je třeba trochu změnit zažité zvyky a nemám nic proti tomu. Každopádně mi ale nepřijde jako příliš velká výhoda tyto informace z DHCPv6 odstranit.Tak pokud by se člověk na DHCPv6 díval jako na postup konfigurace, tak odstraněny nebyly. Spíš by se tomu ale mělo říkat stavová autokonfigurace, jejíž součástí jsou pak i data z RA. Podle mě to logiku má.
To ano, ale jedním podvrženým paketem neovlivníte všechny na síti jako v případě RA (neberu bezstavové dhcpv6, kdy to do jisté míry jde taky). Teď prostě jedním odpojíte všechny od IPv6 internetu. A současnými prostředky tomu nelze skoro zabránit. SeND nemáme, acl většinou tohle moc neumí, snooping není. Já vím, časem bude, ale už aby to bylo.Tak to rozbiju v další fázi, tedy ARP/NDP, a vyjde to na stejno, ne?
To samozřejmě jedno je. Až budou dostupné možnosti filtrování, jaké jsou teď u IPv4, tak se těmto problémům budeme jen smát. Teď ale nezbývá než skřípat zuby a nasazovat obezličky, které fungují jen silou vůle a cílenému útoku neodolají.Tak ony někde dostupné jsou :).
Ahoj, 1) Ano, chápete to správně. DHCPv6 je v IPv6 celkem k ničemu.Omyl. DHCPv6 je dobré řešení pro všechny, kterým vyhovovalo DHCP a nevyhovuje jim bezstavová autokonfigurace.
Koncový zákazník by měl podle RFC dostat /56Já měl za to, že /48 pro obecnou síť, /64 pro síť s jediným segmentem a /128 pro jediný stroj.
Omyl. DHCPv6 je dobré řešení pro všechny, kterým vyhovovalo DHCP a nevyhovuje jim bezstavová autokonfigurace.Ach. O tomto lze vést dlouhou debatu, proč je DHCPv6 zatím těžké použít, pokud chcete zachovat stejnou funkčnost jak s DHCPv4 - tedy mít fixní adresu pro uživatele. Teď to kvůli DUID jde velice špatně a navíc DHCPv6 klient není defaultně ve všech systémech.
Já měl za to, že /48 pro obecnou síť, /64 pro síť s jediným segmentem a /128 pro jediný stroj.Ano. Tak to je. Ale domácí uživatel je v tomto případě to, co vy nazýváte obecná síť, kde je původně navrhované /48 pro všechny viz. RFC3177. Teď to upravuje zatím draft. http://tools.ietf.org/html/draft-ietf-v6ops-3177bis-end-sites-01#page-4
The above-mentioned RFC3177 goals can easily be met by giving home users a default assignment of less than /48, such as a /56.
Motivací k takto velkorysému dimenzování podsítě byla snaha o maximální zjednodušení automatické konfigurace počítačů. Nicméně nelze přehlížet, že AppleTalk zvládal automatickou konfiguraci s jediným bajtem a IPv4 stačí čtyři bajty pro celosvětově jednoznačné adresy. Investovat osm bajtů na dosažení jednoznačnosti v jediné podsíti je zkrátka plýtvání.Také mi 64 bitů ze 128 přijde docela šílených na jednu podsíť a jsem rád, že s tímhle názorem nejsem sám, nicméně je to tak nějak houby platné… Každopádně člověka těžko může někdo donutit k tomu, aby dával takové nebo makové rozsahy. Je pak však otázkou, co s ušetřenými adresami, když už stejně byl příslušný rozsah alokován?
Pak má správce kontrolu co komu přidělujeOsobně mi nepřijde moc výhodné, když správce musí vytvářet celé mapování mezi MAC a IP, když to mapování může fungovat zcela samo.
funguje DNSDNS funguje nezávisle na způsobu přidělení adres.
Jakým způsobem se dá zprovoznit DDNS při IPv6 autokonfiguraci?Určitě se dá, ale autokonfigurace má na výstupu statické adresy, tudíž DDNS ani není potřeba. Místo DDNS ze záznamů na dhcp serveru bych zvolil statické mapování, což je podobná práce, jako by člověk měl s DHCP statickým mapováním. Místo DDNS ze záznamů ohlášených klienty bych třeba já osobně použil multicast DNS, případně nechal posbírat multicast DNS jména a ohlašoval je po klasickém DNS. Tahle možnost je mimo konfiguraci klientů úplně bez udržovacích prací.
11.1.2011 13:05
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Je nějaký dobrý důvod, proč nejmenší možná podsíť je /64? Chápu, že je potřeba předejít vyčerpání jako v IPv4, ale /64 je pro účely jedné jediné podsítě strašný overkillCelé IPv6 je strašný overkill (a to je taky důvod, proč se tenhle přebobtnalý moloch dosud nerozšířil...)
* blbe psany SW, ktery by mel bezet na aplikacni vrstve a vubec by nemel sahat do vrstvy L3 (coz u velke casti SW bohuzel neplati)
* miziva podpora od ISP
... a klidne se na mne sesypte... za timhle si stojim.
f.v.
Ano, pokud máte pár routerů/switchů, tak IPv6 dotáhnete. Pokud budete mít síť složitější, narazíte na problém - vyhodit relativně nové a drahé železo nebo čekat, až tam dopytlikujou IPv6, které bude fungovat bez negativních vedlejších efektů (obvykle omezena funkčnost)Postěžování hezké, ale obávám se, že to není můj problém. Jakožto zákazník si vybírám z nabídky, která na trhu je, a tedy IPv6 mám. Jestli některý poskytovatel má problém IPv6 zavést, to je mi vcelku jedno (aspoň z pohledu zákazníka). V pozici člověka z oboru pro mě potíže se zaváděním IPv6 obvykle znamenají možná přísun (často dobře zaplacené) práce. Nad tím taky brečet nebudu, že. A jako příznivec migrace na IPv6 jsem samozřejmě rád za každou službu či síť, která se součástí v6 Internetu stane. Ani z tohoto pohledu nebudu hořekovat nad vyhozeným IPv4-only hardware.
Ptal jste se, jestli je to problém. Pak řeknete, že vás to nezajímá.Neptal, viz:
Potom mi spíše vysvětlete, proč mnoho ISP včetně těch mých (jak domov, tak serverhouse) IPv6 mají.
Proč tedy reagujete?Abych to upřesnil, problémy s nasazením IPv6 mě zajímají u těch, kteří hledají řešení. U těch, kteří hledají jen výmluvy, mě opravdu nezajímají.
Neptal, viz:Což jsem udělal.Potom mi spíše vysvětlete, proč mnoho ISP včetně těch mých (jak domov, tak serverhouse) IPv6 mají.
Abych to upřesnil, problémy s nasazením IPv6 mě zajímají u těch, kteří hledají řešení. U těch, kteří hledají jen výmluvy, mě opravdu nezajímají.Ale řešení jsou 2 - počkat, až cisco udělá IOS s podporou anebo vyhodit několik set tisíc a koupit něco jiného (skvěle to bude pasovat mezi ostatní cisca). Na tom nic jiného nevymyslíte. Ale chápu, že máte progresivní tah na branku, proto je to pro vás jen výmluva.
Což jsem udělal.V podstatě ano, i když musím říct, že finanční náklady a problémy s výrobcem síťových prvků nejsou nějaká závratná novinka, která by mě zvedla ze židle.
Ale řešení jsou 2 - počkat, až cisco udělá IOS s podporou anebo vyhodit několik set tisíc a koupit něco jiného (skvěle to bude pasovat mezi ostatní cisca). Na tom nic jiného nevymyslíte.Jo já to chápu, každá sranda něco stojí.
Ale chápu, že máte progresivní tah na branku, proto je to pro vás jen výmluva.Tak je pravda, že já to nemusím příliš řešit. Starám se maximálně o technickou stránku, ne o finanční.
11.1.2011 15:25
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
13.1.2011 10:27
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Jenže já nemluvím o 128 bitech, ale technologii IPv6 jako takové.Tohle by měl člověk říkat jen z hluboké znalosti technologie, jinak ze sebe udělá osla... takže uvidíme, jak to dopadne u vás :). Nesoudím předem.
Prostě věci, které se u IPv4 řešily jednoduše, mají u IPv6 několik sobě si konkurujících a nekompatibilních standardůKomentáře na ABCLinuxu umožňují zadávat body. Zkuste aspoň tři skutečné věci, které mají několik nekompatibilních standardů (Autokonfigurace a DHCPv6 rovnou vylučuju, ty jsou mezi sebou dobře sladěné). Pokud mě nějaké napadnou u IPv6, vymyslím jich u IPv4 nejméně třikrát tolik.
případně některé věci pro jistotu nejdou udělat vůbec.Taky bych prosil tak tři skutečné příklady. Tohle je jak když Microsoft tvrdí, že (pan) Linux porušuje jeho patenty.
12.3.2011 21:36
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Celé IPv6 je strašný overkill (a to je taky důvod, proč se tenhle přebobtnalý moloch dosud nerozšířil...)Za nějakou dobu se tahle věta zařadí mezi slavné věty typu že 640kB musí každému stačit :). Přebobtnalé molochy jsou spousty manažery vychvalovaných systémů, IPv6 trochu volněji nakládá s adresním prostorem, ale to si myslím, že je jenom dobře. Jinak podle mě nevykazuje známky overkillu, a už vůbec ne v dnešních podmínkách.
.Pokud by autokonfigurace nebyla, úplně by stačilo 64 bitůNechci to zpochybňovat... ale pozor na to, že tady kupecké počty selhávají. Jedním z hlavních úkolů IP adresace (vedle unikátní identifikace, na kterou IPv6 opravdu 64 bitů používá), je hierarchický routing, díky kterému sítě nemusí udržovat informace o všech počítačích (či koncových sítích) na světě. Já považuju za dobrý pohled na IPv6 adresy to, že prvních 16 bitů se dá používat a opakované pokusy o lepší způsoby adresace bez změny velikosti adresního prostoru... následujících 32 bitů je IPv4 internet pro poskytovatele, místo dřívějšího pro všechny, dalších 16 bitů nahrazuje druhý a třetí bajt v lokálních sítích 10.0.0.0/8, a 64 bitů je tu pro samotnou identifikaci. Tzn... na IPv6 by mělo jít adresovat to, co šlo dřív na IPv4, s tím, že máme možnost zahodit NAT, začít používat automatickou konfiguaci a začít experimentovat s globálním multicastem. Vše ostatní jsou už takové drobné bonusy.
):3/ Celé se to hroutí pokud se v síti používají "rozšířené" možnosti dhcp - pxe boot apod., takže nezbude nic jiného než provozovat současně IPv4 - komunikaci uvnitř sítě a IPv6 - komunikace ven => RA + DHCP pro IPv4, DDNS pro IPv4, mDNS pro IPv6 ... no to bude hezkej bordelBordel v tom nebude, prostě se bude bootovat z IPv4 tak dlouho, dokud nezmizí IPv4-only zařízení bootovaná po síti. Za běhu už stroje IPv4 v podstatě nepotřebují (když se zvládne překlad mezi 4 a 6 pro spojení se stávajícími stroji na Internetu). Za nějaký čas se může i bootovat po IPv6, zcela jistě to půjde :). Zdánlivý bordel vzniká spíše potřebou přecházet postupně a tedy používat dvojí adresaci souběžně, ale tomu se nedá vyhnout.
No jenže takové nejčistší řešení pro IPv6 je RA. Ale i kdybych nemusel bootovat stanice přes ipv4, tak budu potřebovat ještě navíc DHCPv6 které by posílalo třeba "PXE konfig".Nevím jestli nejčistší, jen je jednodušší oproti všemu, co tu dřív bylo. Tak pokud se definuje pole pro RA, nebyl by problém poslat IP a jméno souboru stejně dobře v RA. No a pokud výjimečně potřebuješ různé stroje poslat na různé boot servery, tak nezbývá nic jiného než DHCPv6. Ale přiznejme si narovinu, tohle je lokální záležitost... takže zatímco v globálu je potřeba zavést IPv6 co nejdříve, tak i kdyby se bootování dělalo příštích dvacet let po DHCPv4 a TFTP/IPv4, tak se nic tak hrozného nestane. Na lokálních sítích IPv4 adresy nedojdou :).
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
10.1.2011 12:08