Vlákno názorů k článku Android po letech nabídne podporu pro DHCPv6, bude ale vyžadovat úpravu sítě od kamui - Zásadní chyba byla, že DHCPv6 nebylo vedle SLAAC...

mDNS v domaci siti neni zadny rovnak na ohejbak. To jen vy zas nerozumite nejakemu protokolu :-) Ono jen tak mimochodem mDNS je definovane bez ohledu na address-family.

Ano, nerozumím. Protože mi naprosto stačí ta fixní adresa, kterou znám :-D To je furt dokola

To je reseni, ktere ma znacne problemy, co se skalovani tyce. Fungovat muze mozna na vasi zaprdene domaci LANce. Ale u cehokoliv vetsiho... badum ts... koncite. Z hlavy ty adresy proste nedate. Ostatne to se vedelo take uz pred vic jak padesati lety, kdy se prislo s RFC 608.

Je to prostě standardní dotaz v lokální síti. "Je tady někdo, kdo ...?" Místo těch tří teček může být jméno zařízení, podporovaná služba,...

Pro začátek bych doporučil přednášku od Petra Krčmáře na LinuxDays https://www.youtube.com/watch?v=NDu5sWf8iyI

A musím říct, že petr-desktop.internal se pamatuje líp, než fd43:....

Tiez si vyberas odchodzi port v prehliadaci ked browsujes internet?

Myslím, že to je něco jiného. Ten port je pouze odchozí a nikdo jiný než protistrana tam nic nedostane.

Ne. Za to si vybírám, jakou chci IP adresu pro konkrétní zařízení ve vlastní síti. A to zcela běžně.

23. 9. 2025, 23:23 editováno autorem komentáře

Ten TCP port bola nadsadzka z mojej strany. Ale chcel som tym poukazat na to ze tie adresy v IPv6 su tak trochu ako odchodzie TCP porty. Vo vacsine pripadov ta nezaujima aku adresu ake zariadenie ma - okrem ineho aj preto ze zariadenia maju bezne niekolko IPv6 adries.

Samozrejme mozes vo vacsine pripadov proste nastavit IPv6 rucne v ramci prideleneho rozsahu namiesto toho aby si pouzil SLAAC. Vela ludi pouziva staticke adresy pretoze sa lahsie pamataju. Na to sa skor hodi DNS - kludne aj v kombinacii so SLAAC kde DNS namieris na tu mac-based IPv6 adresu.

Tiez mas k dispozicii ULA rozsah fc00::/7, ktory je asi najblizsie privatnym adresam z IPv4 sveta. Takze mozes si nahodne vybrat nejaky /64 blok v tom rozsahu a ten pouzit pre lokalne adresy a lokalne sluzby (s rucne pridelenymi IP ak na tom trvas) zatial co providerom prideleny rozsah nastavujes cez SLAAC a ten sa pouziva len na pristup do internetu.

Mě to u části mých zařízení zajímá dost. A nastavit na nich ta IP adresa staticky nejde protože žádné rozhraní pro její nastavení jednoduše nemají. DNS je sice hezké, ale IPv6 má problémy řešit, ne vytvářet. Fakt nepotřebuju řešit ve své minisíti ještě DNS, rovnák na vohejbák mDNS nebo cokoliv jiného obdobného. No a pak najednou to DHCPv6 začne tak nějak dávat smysl.

Tyhle "argumenty" mi připomínají podobně nesmyslný způsob "argumentace" kolem Waylandu.

Ale IPv6 problemy riesi. Moderne mobilne zariadenia uz maju by default zapnutu MAC randomization. Ked take zariadenie pripojis do IPv4 siete, bude ti postupne alokovat cely /24 IPv4 rozsah az zrazu zistis ze nie je volna adresa pre nove zariadenia. Plus samozrejme musi DHCP server niekde ukladat pridelene lease, inak bude pridelovat uz obsadene IP adresy.

Naproti tomu SLAAC ma /64 rozsah, kde si klienti proste vyberu adresu nahodne a kludne mozu pouzivat nieco ako privacy extensions (alebo aj tu nahodnu MAC) a nie je to problem. Router si nemusi nic pamatat, jedine co robi je router advertisements. Podla mna omnoho jednoduchsie riesenie.

Prinajhorsom vymenis DHCP za DNS server ak sa nechces spoliehat na mDNS. Pre vacsinu pouzivatelov ktori ani netusia co je IP adresa je SLAAC omnoho jednoduchsi mechanizmus.

Ak by to tak bolo ako pises o MAC randomziation, tak IPv4 siete by kolabovali. Co nieje pravda.
DHCP odjkaziva uchovaval pridelene leases a zeby to bol problem som si nevsimol.

To omnoho jendoduchsie riesenie ma svoje uskalia. Odporucam si precitat serial Bezpečné IPv6 tu na root.cz. Rovnako je to uhol pohladu, ktory zalezi o co ti v danej sieti ide.
Inac Router si ani v IPv4 nemusi nic pametat. Router nemusi plnit aj rolu DHCP servera :)

Pre pouzivatelov, co netusia, co je IP adresa je jedno, co je v pozadi. Ci DHPC alebo SLAAC.

Snazis sa naznacit, ze MAC randomization neexistuje alebo co? Ja som nedavno riesil problem kedy znamemu nesla IPv4 v sieti. Stacilo na to chvilu pracovat s telefonom vo vrecku na zahrade kde uz obcas nedotiahne wifi signal. Mobil sa pripojil na siet par desiatok krat a ten rozsah ~50 adries co mal vyhradene pre DHCP mu dosiel.. (nutno dodat ze 50 adries by inak bolo niekolkonasobne viac ako pouziva zariadeni)

Tie uskalia su mi zname a v podstate vsetky maju nejaku alternativu vo svete IPv4. Plus povacsinou predpokladaju nejakeho zaskodnika priamo v sieti. Co je myslim trochu mimo kontext diskusie.

Inac Router si ani v IPv4 nemusi nic pametat. Router nemusi plnit aj rolu DHCP servera :)

To samozrejme viem, ale opat bavime sa v kontexte beznej domacnosti. Plus prave ten router vacsinou ma obmedzene prostriedky a bezne najdes router co si po restarte leases nepamata.

Nie to nenaznacujem.
Skor to, ze MAC randomization implementovana v tvojom mobile asi nebude s tych najdokonalejsich.
Aky je dovod takto randomizovat/tak sa spravat a leasnut vsetky adresy?
V reale ale potreba pre tu randomizaciu taka nieje a prinasa dalsie problemy.

Bavime sa o tom, ze ty si pisal ze DHPC je zlozite a SLAAC easy, co nieje pravda.
Beznemu cloveku je to jedno a na urovni protokolu vymienas nieco za nieco.

Router robi len RA ale pri SLAAC sa cast logiky/manazmentu presuva na hosta kvoli absencii DHCP.
Tazke DHCP vs SLAAC nieje v zlozitosti/na­rocnosti nejaky principialny rozdiel. Su to len odlisne pristupy.
Duplom ak sa bavime v kontexte beznej domacnosi. Bezna domacnost pozna len dva stavy, ide internet alebo nejde internet a netusi, co je za tym, lebo to nepotrebuje.

Este som nezazil aby router limitovali jeho prostriedky, aby nezvladal DHCP. Co je zle na tom, ze si po restarte nepameta leases?

SLAAC je jednodusi nez DHCP. Zatimco u DHCP to mame v client-server modelu, tedy rezim dotaz klienta - server se zamysli a nejak odpovi - kazdemu klientovi jinak, u SLAAC se jen periodicky oznamuje jedna stale stejna informace a protistrana se podle toho sama rovnou zaridi.

Nieje nijak jednoduchsia.
Pri SLAAC mu IP adresu nepovie DHCP ale klient si vyberie nejaku sam a nasledne si musi u susedov overit, ci uz si nahodou niekto taku uz nevybral aby sa vyhol kolizii.
Pri DHCP tie adresy menezuje DHCP server ale klienti medzi sebou.
Opakujem nevidim tam principialne jednoduchsi sposob. Je len iny.

Treba Windows vam tu detekci konfliktu bezne delaji i u adres pridelenych z DHCP. Delaji to treba i nektere Linuxy, pojednava vam o tom treba i RFC 5227. Takze neni pravdive vase tvrzeni, ze klient slepe funguje s tim co dostane, zeano ;-)

Pisal som niekde, ze klient s tym slepo funguje? Bavime s ao principoch.
SLAAC nieje o nic jednoduchsie a na druhej strane DHCP zlozitejsie.
Su to dva odlisne pristupy, ktore niesu nijak zlozite.

Ale ano, DHCP je zlozitejsi, aj ked na prvy pohlad nevyzera.

Napriklad vyzaduje broadcast. Co moze byt sakra problem, pokial potrebujem uzamknut port na konkretnu mac adresu.

To je jeden z tych dopadov, ktore pri povrchnom porovnani nevidno.

U obojího je broadcast od klienta. U DHCP žádost o příděl, u SLAAC kontrola, že adresa je volná. Takže na klientovu zhruba stejná složittost.

Ale implementace na routeru se liší - u DHCP musím po obdržení žádosti zkontrolovat, jestli je ve static leases, pak jestli už nějakou adresu má a obnovit ji, pak najít volnou v poolu, poslat mu ji, po odpovědi zaevidovat... A u SLAAC jenom router pošle broadcastem parametry pro autokonfiguraci a nic neřeší.

No u DHCP klienta jsou realne ty broadcasty prave dva - prvni je ta zadost o pridel a druhy overeni, ze ta pridelena adresa cirou nahodou uz neni nekde pouzita.

Skor to, ze MAC randomization implementovana v tvojom mobile asi nebude s tych najdokonalejsich.

Nejedna sa o _moj_ mobil. Apple zariadenia to maju standardne zapnute uz cca 10 rokov. Android to ma k dispozicii od verzie 10, niektore distribucie (ako Graphene) to maju standardne zapnute.

Co je zle na tom, ze si po restarte nepameta leases?

Klient musi taku adresu odmietnut s DHCPDECLINE a potom absolvovat nove kolo DHCP. Celu dobu je server (ktory si nepamata, ze prvych 50 adries z rozsahu uz pridelil) ten ktory urcuje dalsiu adresu ktora sa prideli, takze cerstvo po reboote takych kol mozes absolvovat niekolko v zavislosti na situacii. Ciastocne moze pomoct ak zariadenie uz bolo predtym v sieti a v ramci DHCP discovery spravy posle aj pozadovanu IP ktoru malo predtym, ale to sa uz ruca tvoja idea ze DHCP je nejak jednoduchsie pre klienta, lebo pri SLAAC si nemusi klient pamatat ziadne adresy.

Vseobecne mi pride cudne argumentovat ze SLAAC je nejak zlozitejsi protokol. Na rozdiel od DHCPv4 vyzaduje len dva packety medzi routrom a klientom (RS a RA) a oba su nestavove. (DHCP ma discovery -> offer -> accept -> acknowledge) A nasledne si klient sam vymysli adresu a jedine co riesi je (extremne nepravdepodobny) adresny konflikt, ktory musi riesit aj DHCPv4..

Duplom ak sa bavime v kontexte beznej domacnosi. Bezna domacnost pozna len dva stavy, ide internet alebo nejde internet a netusi, co je za tym, lebo to nepotrebuje.

Presne tak a narozdiel od DHCP jej so SLAAC vela moznych problemov odpada.

Zalezi, jak je ta randomizace MAC udelana. Pokud se adresa zmeni s kazdym connect eventem (a nedrzi se nahodne-pevna pro konkretni SSID), pak se ten pool muze vystrilet pomerne rychle. Muzete to obchazet leda tim, ze zkratite lease-time, ale to zas nutite klienta obnovovat tu adresu pomerne casto - aneb rovnak na ohejbak, zeano :-)

Niektore zariadenia, zvlast vsimnutelne to bolo na androide, si sice pamatali aku mac adresu pouzili s danym ssid, ale uz si nepamatali, ze dhcp adresu mali pridelenu, este neexpirovala a namiesto renew si vyziadali novu.

No a niektore dhcp servery, ako napriklad mikrotik, im novu adresu radi poskytli.

Jo, to je dalsi.... vtipne je, kdyz na tohle narazite treba na nejakem vetsim eventu, kde ten lokalni IT smudla neni schopnej ani zvetsit subnet, i kdyz mu vysvetlite proc...v lete jsem narazil na smudlu, co to vylepsoval jeste tim, ze v te siti "pro hosty" bezel soucasne treba i mistni kamerovy system :D A pritom tam byly prvky, co L2 segmentaci umely... ale asi to bylo "moc prace" :D

"DHCP odjkaziva uchovaval pridelene leases a zeby to bol problem som si nevsimol"

Videls nekdy aspon jednu sit? Kdyz ti device slusne rekne, ze konci, tak dhcp lease zrusi. Ale zdaleka ne vzdy device dostane tu sanci, a zceleka ne vzdy se chova slusne.

Takze se to "resi" tak, ze se nastavi velice kratky lease, coz pak prozmenu vede k tomu, ze dhcp dosne samo sebe.

A prokracovat muzes treba tim, jak uzasne funguje dhcp v clusteru... zatimco RA zadny takovy problem nema.

K čemu je to dobrý? IP adresa není na hraní. Ta je od toho, aby se dal zařízení doručit paket. Nic víc, nic míň. Asi se moc nudíš, když řešíš, co nemusíš.

Jinak argument "já chci" je fakt super. Teď zrovna v práci kontroluju shodu našeho výrobku s ETSI EN 18031:2024. Nesplníme -> nedostaneme CE -> nemůžeme prodávat. Easy. A když je v normě, že nesmí být defaultní heslo pro všechny výrobky stejný, je úplně jedno, že se to tak dělalo vždycky a že jsem na to zvyklý a že to tak chci. Můžu brečet, můžu nadávat, můžu autory normy proklít, aby jim zčernaly a upadly některý části těla, ale to je tak všechno co se svým "chci" zmůžu.

K tomu, abych nemusel řešit navíc ještě DNS.

To je ale reseni, ktere je vesmes prekonane. A vase starecke nadavani na tom nic nezmeni :)

Co jste překonal vy je celkem irelevantní. Nic jako "překonané" neexistuje. A nikdy neexistovalo.

Mně se určitě líbí víc, když jsou zařízení v síti rozříděna, lze dlouhodobě sledovat statistiku provozu, nastavovat vyvažování zátěže...to vše se s náhodnou adresou dělá dost špatně. Když pak vyměním webkameru za jinou, stačí jí dát původní adresu a vše funguje automaticky dál.

Vsak to trideni jde provadet ruznymi zpusoby. Jen kdyz vezmu moznosti z doby kamenne, tak mame v DHCP option 82, kdy konkretni zarizneni ztotoznime uz na zaklade toho, kde je pripojene. Samozrejme to nechce mit switch, ktery jste poridil "vyhodne za kilco" :-)

Roztřídí se podle skupiny s 64bitovým identifikátorem - prefixem /64. můžu zakázat skupinám "počítače na dílně"a "počítače v účtárně" přístup ke skupině "bezpečnostní kamery". A vidím, jak často se z které skupiny leze do skupiny "tiskárny". Úplně stejně, jako kdybych kamerám dal 192.168.20.x, komplům na dílně 192.168.30.x a účtárně 192.168.31.x...

Ale chápu, že kdo nemá dost rozumu na používání VLAN a podobně, bude mít s tímto poněkud problémy.

Tohle je vcelku v pohodě.
A pak, když to máte hotové, přijde nějaký výrobce OS do mobilů s tím, že chce celý 255.255.255.0 rozsah pro jeden každý přístroj, přičemž se dá předpokládat, že těch mobilů/tabletů máte po baráku něco přes tisíc...
Rázem můžete s těmi rozsahy pro PC, kamery, účtárnu... jít do Paďous.

Kdyz to narubete do 10.0.0.0/8 a furt tam mate 65536 siti s maskou /24 :) A zadarmo, fnukale. Samozrejme to neni jediny prostor pro privatni uziti, k dispozici jsou i dalsi. Nicmene tohle vase porovnani nesedi - u IPv6 je snaha NATy (tedy kurvitko v ceste navic) odbourat, v IPv4 si to s temy NATy klidne doklepejte.

Jasně, že s 10.0.0.0/8 není problém. Jen to jaksi musíte vědět dopředu - a o to (mi) šlo.
Prostě postavíte síť na nějakém fungujícím a v podstatě good practise modlu, a následně to musíte celé předělávat kvůli věci, která nemá z pohledu vašeho využití nijak vysokou prioritu. (Taky můžete říct: Fajn, žádné tablety a mobily v síti nebudou, stejně to není v pro práci potřeba a jen to snižuje výkonnost zaměstnanců!)
A nejde mi o to, že s tím je práce - ale že je to práce zbytečná.

Uprava konfigurace site s ohledem na zmenene pozadavky opravdu neni nic neobvykleho. Meni se v case technologie, meni se koncova zarizeni, ba i obecne potreby - a je zadouci se cas od casu logicky prizpusobit. A pokud se skutecne drzite nejakych bestpractise modelu, pak zcela urcite nemate zapraskanou celou /8 a urcite tam nejaky ten blok na tu tisicovku ci dve tabletu najdete, zeano :-) Debata je to beztak vicemene akademicka, neb standardni reseni v IPv4 svete je tam proste naprasit NAT (a neosivat se nad jejich retezenim) :D

Víte, ono se to sice v čase mění, ale některé věci, si prostě na začátku definujete, a pak už jen držíte krok s dobou.
Takže na IPv4 si nastavíte VLANy, rozdělíte rozsahy, nadefinujete pravidla - a pak už to jen udržujete. Přijít takovýhle zásek do konfigurace, musíte to opravdu začít budovat od začátku, a to za provozu nebude nikterak jednoduché.
Vrátím se k IPv6.
Uděláte přesně to samé: nastavíte si VLANy, rozdělíte od ISP dodaný rozsah, nadefinujete pravidla pro síť, a - kromě těch Androidů, které si to dělají trochu po svém a je radno je nějak isolovat - všechno funguje.
Pak konečně (!) začnou i ty Androidy umět DHCPv6, takže v první chvíli zajásáte, že se konečně nechají integrovat do prostředí - a zjistíte, že je to udělané způsobem, který by znamenal zbořit a od začátku přenastavit celou síťovou infrastrukturu.
Takže se budete držet dosavadního řešení: prostě je ignorovat a udržovat bezpečně mimo základní síť. Protože za provozu tohle měnit fakt nechcete.
Jenom si povzdechnete, že kdyby tam byla možnost udělat to rozumně, bylo by to tak krásně jednoduché a funkční...!

No, pokud to opravdu musite zborit a zacit znovu, pak ten design nebude zas az tak povedeny :-)

Předpokládám, že málo kdo počítal s tím, že koncová zařízení budou jednou potřebovat celý síťový rozsah.

Jako ze ma adresni plan tak zpraseny, ze tam fakt nic nevyskrabne? :-)

Vraťme se k IPv6.
Pokud máte /56 rozsah, a můžete si definovat nějakých 250 subnetů, případně méně, ale s nějakou další hierarchií. Potud žádný problém. A v každé podsíti může být poměrně hodně koncových zařízení různých typů.
Ale pokud si jeden z typů zařízení usmyslí, že každé zařízení potřebuje svůj subnet, a navíc jsou těch zařízení stovky, bez totálního překopání adresního plánu, VLAN, pravidel, a podobně, se neobejdete (a /56 rozsah vám nebude stačit).
Což znamená, že - nechcete-li to řešit příliš složitě - potřebujete alespoň /48 rozsah, rozdělení na podsítě posunete o osm bitů nahoru, a doufáte, že v každé síti nebude příliš mnoho mobilů. (A stejně budete muset vyměnit adresu těch sítí...)

Tady nejde o vyškrábnutí několika adres, ale o podstatný zásah do počtu podsítí. (Teda pokud nemáte v síti třebas jen tři ty mobilní zařízení: svoje, šéfovo, a jeho sekretářky).

28. 9. 2025, 21:46 editováno autorem komentáře

Diskutovane tisice zarizeni budou korporatni sit, ktera by nemela problem mit v pohode si sahnout na /48. Sem fakt nepatri srovnani toho, co ISP davaji na sluzbach pro domacnosti. A jestli nekdo na pripojeni tak velke firmy pouziva sluzby cilici na jiny segment, tak je... ehm... mongol :-)

No, já mám tenhle postřeh z jedné menší (střední?) firmy: něco přes 300 lidí v jedné budově (plus několik detašovaných pracovišť), převážně kancelářská práce... Není to zrovna korporát.

V tomhle scale tech /48 ukecate klidne i nekolik - protoze kazda pobocka (end-user site) muze mit klidne svou /48 a zadne politice se to protivit nebude, staci mit pricetneho providera (coz ale u business-oriented sluzeb zas takovy problem neni). A nerealisticke neni to ani mit v ramci jedine /48. Nevim co mel ten vas postreh presne demonstrovat, ale porad mi nejak do tech vasich poctu nevychazi, proc by se to nemelo vlezt... spis mi prijde, ze hledate problem tam, kde ani teoreticky neni - natoz prakticky. V jedne /48 mate k dispozici 65536 siti s maskou /64... i kdyz prihlednu k nejake vnitrni rezii a preciznejsi segmentaci, tak jeden uzivatel vam tam se stovkou zarizeni po kapsach asi neprijde, zeano :-) Ze pocitam s opravdu velkou rezii okolo si muzete spocitat z podilu cisla vyjadrujici pocet sit a cisla vyjadrujici pocet uzivatelu.

Předně: když to připojení do budovy dělali, když zařizovali IPv6, bylo to ještě v době, kdy zmlsaný Číňan ani nedostal chuť na netopýra. Naplánovali segmentaci sítě, a vyšlo jim, že 256 podsítí je o dost víc, než potřebují, a tak nějak to odpovídalo nabízenému /56 rozsahu.
Oněch 256 podsítí nemají, ale tak velký rozsah využili na logičtější vrstvení zón (systém matrjoška).
A takhle to spokojeně běží odhadem 10 let.
Teď, pokud by chtěli použít DHCPv6 pro Androidy, by bylo nejjednodušší vyžádat si /48 rozsah, posunout celý ten síťový model o osm bitů doleva, a doufat, že v každé koncové síti (nyní /64, nově /56) se těch Androidů neobjeví více, než cca 200 - což se jeví jako splnitelné.
Málem bych zapomněl: zahrnuje to rekonfiguraci těch několika routerů a firewallů, které tam jsou. Hlavě neudělat chybu a neohrozit provoz.

Nabizi se zajimava otazka... a ptal se nekdo vubec, jestli to z te /56 na /48 nejde proste posunout/zvednout? :-) Ano, ono se cele hodiny da filosofovat o netopyrech... ale neni jednodussi poslat email svemu providerovi? A nebo at vam proste soupne dalsi bloky - nikde neni psano, ze tu alokaci musite mit kontinualni - kdyz uz se tedy bojite a nechcete precislovavat to, co uz mate. Jeden problem, co ma vzdy vicero reseni...

Jenže tady nejde o to, že by to nešlo (to taky nikdo netvrdil), ale že s tím bude - tak či onak - spousta práce.
Spousta zbytečné práce (pokud se rozhodnou ty Androidy do sítě pustit!), kterou by nemuseli dělat, kdyby existovala ona možnost je to koncové zařízení.

A protože práce není zadarmo, troufnu si odhadnout, že to (tam) nikdo dělat nebude. Tedy ve výsledku je tento typ podpory DHCPv6 poněkud nedokonalý.

Definujte spoustu :-) Ja bych rekl, ze vic casu jste uspesne prokrastinoval. Mozna namisto psani slohovek "jak to nejde" byste se mel soustredit jak to udelat.

Předně: není to moje starost, já pracuji úplně jinde.
Každopádně jsem ale nikde nepsal, že by to nešlo, dokonce jsem opakovaně uvedl, jak to řešit lze. Jen tvrdím, že to je zbytečná práce, která by při příčetnějším návrhu vůbec nebyla potřeba.
Ostatně: předpokládám, že v té síti budou chtít mít pod kontrolou (DHCPv6) všechna koncová zařízení, takže situace, že by za Androidem byla připojená další zařízení, nejspíš nikdy nenastane. I z tohoto pohledu jde tedy o práci zhola zbytečnou.

Ja chci jezdit rolsem, kazdy den chci dostavat kafe na zlatym podnose v diamatama vykladanym kafaci ... a chci to vsechno za cenu jednoho piva.

Pokud si kupujes devices ktery nesplnujou tvy pozadavky, asi bys mel navstivit lekare.

Mimochodem, podporu ipv6 (a slaac) mam jako must have u vseho co kupuju ja. Kdyz to neumi, tak dodavatele vyhodim. Je to ... 1/2 roku kdy se mi nekdo snazil natlacit krabku, ktera neumi ani na v4 dhcp ... a ipcko se na to nastavuje dipama ... a to jen posledni 2 bajty, ty prvni jsou tam fixne ... neuveritelny.

Jiste, "funguje". Tak ja vas necham parkrat precislovat nejakou vetsi sit citajici tisice zarizeni a pak nam muzete popovidat o tom, jake to bylo :-) Ve velkych infrastrukturach se tenhle pristup nepouziva. Dokonce i parovani IP na MAC je vicemene obsolentni - s tim, jak si zarizeni kvuli ochrane soukromi meni i L2 adresu.

Je mi úplně jedno co se používá nebo nepoužívá ve velkých infrastrukturách. Žádné velké infrastruktury v tomhle vlákně neřeším tak proč je sem taháte?

24. 9. 2025, 20:47 editováno autorem komentáře

Vsak nic vam nebrani se na vasi zaprdene LANce uchylit treba k IPX. Ten protokol je primitivni, mohl by se vam libit :-)

V tom případě nechápu požadavek na nastavování adresy mobilu se Srandoidem. To když přijde návštěva a chce se připojit na WiFi pro hosty, tak se připojíš na router a naklikáš do DHCP fixní adresu?
Pro takový jednání jsou jenom dvě vysvětlení - buďto to nařídí manažer, který tomu nerozumí, nebo jde o psychickou poruchu.

Přesně toto jsme řešili při přechodu na VLAN. Ano, je s tím trochu práce, prostě se z jedné tabulky rezervací adres v Excelu udělá jiná tabulka a ta se naimportuje zpět. A fixace IP / MAC je nutná třeba u tiskáren - tiskové fronty jsou stále vázané na IP adresu.

"tiskové fronty jsou stále vázané na IP adresu"

Fakt? Sakra jak ja to jen delam ...

"prostě se z jedné tabulky rezervací adres v Excelu udělá jiná tabulka"

jj, a pak chodis po forech a vymejslis tam, jak nastavit tisicero NATu, aby se dala pouzivat zalozni konektivita ...

Tak pristup tenhle konzerv taky vypovida o skutecnem stavu v tomhle segmentu. Jednou se to nainstalovalo, pak na to sto let nikdo nesahne... derave je to jak reseto a vsichni kolem toho chodi po spickach a boji se na to sahnout. Dit se mozna neco zacne az v monente, kdy nastane fakt pruser... jakoze to fakt nekdo zacne ovladat nezavisle na vuli provozovatele. Spousta tehle veci je ve skutecnosti jen tikajici bomba...
IPv6 tady fakt prekazka neni - aneb se standardnimi mechanismy mate adresu odvozenou od MAC, takze argument "nastavim napevno" odpada. Link-local ani nastavovat nemusim, proste tam je. A svete div se, v ramci jednoho segmentu ji jde normalne pouzivat, zeano. Bez jakehokoliv nastavovani.

Průser obvykle nastává naopak tehdy, když má někdo neodbytnou potřebu zbytečně zasahovat do spolehlivě fungujícího systému, aniž by to mělo reálný benefit.

Mno. Když ten update má potenciál zastavit výrobu a způsobit škody ve statisících až milionech? Máte po ruce stejnou záložní fabriku, na které by se to dalo vyzkoušet?
Jakou dáte vedení záruku, že se nic nerozbije?

Mimochodem, když řešíte bezpečnost pořádně, tak je ven stejně připojené jen to nezbytně nutné. Najednou máte zalepené všechny díry včetně těch, na které se zatím ani nepřišlo.

O stavu v našem oboru vypovídá třeba i to, jak jeden update crowdstriku rozbil co potkal.

Fabrika, ktera se cas od casu nezastavi kvuli (planovane) udrzbe se jednoho dne zastavi neplanovane sama.... a neni to jen o tech IT castech. A tady se zjevne popisuji situace "nesahame na to vubec", ktere jsou bud vytrzene z reality... a nebo si tim nekdo ospravedlnuje vlastni lenost :-)

Hurvínek si válku představuje realističtěji, než jak si vy představujete technologické provozy.

A ktery technologicky provoz mate na mysli? Papirnu, ci snad tepelnou, nedejboze i jadernou elektrarnu? :-) Opravdu nam budete tvrdit, ze tam k zadnym odstavkam nedochazi. Ale jdete, vy breptale.

Dochází a stojí to velké peníze - zvláště ty neplánované výpadky. U těch se standardně vyšetřuje, kdo za to nese odpovědnost - v případě externích dodavatelů v první řadě hmotnou. Týká se to i překročení plánované doby na údržbu v rámci plánované odstávky, když bych si z poslední doby měl vzpomenout na jeden nepovedený upgrade jednoho renomovaného dodavatele automatizačních systémů. Nakonec se to vždycky láme na otázce "dá se bezpečně provozovat - ano/ne?" Pak si můžete nad fakturou za způsobené škody i od plic zanadávat, jaké jsou v tom průmyslu konzervy, když po vás chtějí zaplatit vaše nepovedené pokusy s "moderními" (nebo spíš módními?) technologiemi.

A vy dokazete na 100% rict, ze nejaka existujici chyba v software vam to neplanovane neshodi? :-) At uz jde o skutecne nahodily jev a nebo treba i umysl nejakeho zaskodnika? Ten problem mate v zasade porad stejny.. v momente kdy vam to sestreli zdokumentovana/o­pravena chyba, pak si na vas ukazou prstem a s tou skodou po vas pujdou, zeano.