DNS-SD objevování a přímé propojení účastníků za NATem Wireguard tunelem

Nejak mi uchadza pointa toho celeho. Namiesto toho aby pouzili STUN server ako prostrednika, tak pouziju DNS server ako prostrednika s tym ze este musia navyse riesit mechanizmus akym vytvoria (a aktualizuju) ten DNS zaznam? Aku to ma konkretne vyhodu?

Přímo z článku:

As previously pointed out, STUN is not a complete solution. STUN provides a mechanism for an application to understand its external IP:port when behind a NAT, but STUN does not provide a method for signaling this to interested parties. If we were writing an application from the ground up that required NAT traversal capabilities, STUN is a component we should consider. We are not writing Wireguard, it already exists, and its not something we can modify (see goal about leaving its source untouched). So where does that leave us? We can certainly take some concepts from STUN and use them to achieve our goal. We clearly need an external, statically addressed host for discovering UDP holes that we can punch through.

Očividně se touto otázkou autor zabýval.

22. 5. 2020, 21:52 editováno autorem komentáře

Aha, tak to uz chapem. Cize nejde ani tak o to tunelovanie NATu, ako skor o ten discovery mechanizmus. To dava zmysel. Vo vela aplikaciach je ten kontakt uz beztak naviazany, ale je pravda ze sa najdu pripady kedy by bolo super proste zadat "adresu" (domenu?) a ono by to nejak fungovalo. Zaujimava idea.

Skvělý post, díky za odkaz! Jen škoda, že autor používá reálné IP adresy místo adres RFC 5737 a pak je také škoda, že zcela ignoruje IPv6. Ono totiž i v IPv6 je bohužel poměrně častým jevem dynamická IP adresa a nutnost propichování stavových firewallů (například tímto trpěly obě LTE přípojky s IPv6, které jsem zatím držel v ruce), takže tenhle princip se určitě osvědčí i po konci IPv4.

Je to velmi dobrý nápad, který se navíc dá zavést postupně – nejdřív všechy uzly propojit hvězdicově přes centrální bod obyčejným wireguardem a následně postupně za provozu migrovat jednotlivé dvojice uzlů na full mesh. Během čtení jsem měl jen výhradu k nutnosti provozovat nový DNS démon (a tím pádem tedy sehnat někde server s veřejnou IPv4 adresou, na které zatím žádný neposlouchá), ale poznámka na konci textu to uvedla na pravou míru, že vlastně signalizace nemusí probíhat po veřejném DNS, ale uvnitř wireguardového tunelu. Píšu si tedy na seznam věcí, co chci vyzkoušet ;)

Přišlo mi, že NAT tunelling je v dnešní době nefunkční, protože jsem si s tím hrál už před drahnou dobu a začaly se objevovat NATy, které pro každou čtveřici IP external:port:IP internal:port přidělí jiný port na NATu. Takže bubble packet neprošel a nebylo možné tedy otevřít přímou komunikaci.

Opravte mne, jestli to je jinak. Mám ale pocit, že N2N tohle dělá s tím, že má fallback přes centrální uzel a poslední dobou mi všechno běhá přes centrální uzel s tím, že se nepodaří prorazit cestu přes NATy

Je to možné. Já bych tedy předpokládal, že zejména velké hardwarově podporované NATy se budou snažit držet co nejméně stavu a tedy používat Full-cone. Proti tomu Linuxový plně softwarový NAT používá conntrack, který sám o sobě eviduje pětici adresa:port:a­dresa:port:pro­tokol, takže přes ten to nejspíš neproleze. Asi to chce vyzkoušet.

Zdá se, že normální upstream Linux full cone NAT nepodporuje, ale modul, který tuto funkcionalitu zprostředkovává existuje a je snad i nějakým způsobem podporovaný jako doplněk pro OpenWRT: https://github.com/Chion82/netfilter-full-cone-nat
Jistě existuje prostor nějaké obecnější řešení stabilizovat a do Linuxu poslat... možná je něco takového https://github.com/andrsharaev/xt_NAT krok tím správným směrem.

Ve FreeBSD nějaké pokusy snad taky byly: https://reviews.freebsd.org/D11137

Na druhou stranu musím říct, že full cone NAT z hlediska omezování příchozích spojení a tedy jakéhosi omezování provozu z venku je asi nejhorší řešení. Vím, NAT není firewall, ale realita je taková, že v praxi právě port restricted cone efektivně omezuje možnost dostat se za NAT nějakou "hole punching" metodou.
Jelikož CG-NAT asi full cone bude, tak při nasazení vlastního routeru je šance na úspěch poměrně vysoká.

Taky pokud router mám nějakým způsobem pod kontrolou, tak tam můžu přidat explicitní pravidla na port forwarding a potom nemusím řešit informaci o portu který nějak dynamicky musím zaznamenat, ale jen nějak kontrolovat, kterou IP router právě má - což je mnohem jednodušší.

A nejlepší řešení nakonec stejně zůstává mít správně a plošně nasazené IPv6 a částečně asi i nedělat ze zákazníka blbce a nechat jej např. v nějakém pokročilém nastavení skutečně něco užitečného taky nastavit. Potom bychom se nemuseli zabývat rovnáky na ohýbáky, ale něčím skutečně užitečným. Celý NAPT, STUN apod. by potom byly spíš takové akademické hrátky. Paradoxně myslím, že nás "řešení" NATu stálo víc času a námahy, než kolik by stál úplný přechod na IPv6 a vypnutí IPv4.
Myslím, že kdyby se usneslo, podobně jako s uhlím, že se v roce 2030 IPv4 přestane routovat mezi autonomnímy systémy, že by se situace celkem rychle zlepšila. 10 let je myslím na relevantní systémy času dost. Však nějaké firmy a instituce určitě ještě někde interně používají IPX, token ring apod. podobně by to měly s IPv4...

Jo, bylo by to dobrý, ale jak toho dosáhnout? Vlastní IPv6, které člověk mohl mít, i když na něj ISP z vysoka, SIXXS, skončilo a když jste za kdovíjakým NATem, tak si nepomůžete nijak. ISP možná můžete donutit nebo vyměnit (alespoň teoreticky), ale mobilní operátoři na IPv6 naprosto kašlou. Pikantní je to teď u Vodafonu, když v koupeném UPC máte veřejnou IPv6 adresu, na kterou se z mobilu nedostanete.
Jinak VDSL modem (co jsem potkal) má možnost IPv6 firewall nastavit, UPC modem taky.
Tady by pomohlo buď Lukašenkovo běloruské řešení (IPv6 je pro ISP povinné), nebo alespoň nařídit, že bez IPv6 se služba musí povinně nazývat "zmršený internet".

Edit: Se to nějak roztáhlo, jak jsem nad tím přemýšlel - asi budu muset psát na blog, nebo na to udělat Orgpage na https://orgpad.com/about :-)

Tak on celkem určitě během tak roku nebo dvou přijde určitý zlom, kdy i poměrně konzervativní operátoři do nějaké míry IPv6 nasadí. Ano, zjistili jsme jako komunita, že CG-NAT umíme a i když je drahý, není to tak zlé abychom opustili poměrně lukrativní trh. Částečná komoditizace v profesionálním síťovém hardwaru tomu finančnímu pohledu dost pomohla.

Problém je tak trochu v koordinaci přechodu - velmi podobné, jako když se kdysi všude muselo podporovat IE6 nebo "HTTPS si můžou dovolit jen banky a velké obchody", jenom tak nějak ve větším a složitějším. V podstatě je nějaký český operátor chybou zaokrouhlení ve světovém měřítku, takže chtě nechtě půjdou s davem. Jak tedy přesvědčit/ pohnout davem?

Např. kdyby AWS, Azure a GCP řekli, že budou promítat tržní cenu IPv4 do ceny VM a že VM můžete mít o x levněji když nebudete používat IPv4, tak by to byla určitá iniciativa. Oni tedy něco podobného tak trochu místy dělají, ale z mého pohledu to pořád ještě dost dusí.
V USA podobný nátlak vznikl znovu myslím poslední měsíc na federální úrovni - tam existuje nařízení a poměrně ambiciózní plán na realizaci přechodu/ implementaci IPv6, není to sice úplně poprvé, co někdo něco takového ustanovil, ale tentokrát to má podstatně vyšší váhu myslím. Každopádně to musí zohlednit všichni výrobci, kteří chtějí vládě nějak dodávat hardware a software. Ta kritéria jsou veřejná a dají se klidně v určitém rozsahu použít při výběrových řízeních i ve firmách - Proof of Concept klidně může požadovat, že se ten checklist musí předvést v demu nebo testovací fázi. Testovat objednávku je u větších zákazníků celkem běžné a prakticky vždy se pokračuje k finalizaci koupě. Někdy se ale dá aspoň zatlačit na cenu a pokud by to nešlo, tak od smlouvy ustoupit.
U služeb které IPv6 nepoužívají se může člověk aspoň dotázat, jaké jsou v tom ohledu plány. Takový postřeh se hodí třeba tehdy, kdy zrovna s někým už osobně vyřešil nějakou jinou chybu užitečným debuggingem - to mají lidi (často už trochu s lepším postavením ve firmě) tendenci poslouchat. U některých IT firem bývají lidi typu Radek Zajíc, kteří jenom čekají na obhajobu pro management, že zákazníci IPv6 chtějí.
V některých firmách se veřejné IPv4 nemůže prostě jen tak použít. Musí se objednat. U IPv6 pro to není tak moc důvod, protože obyčejně je k dispozici celý prefix aspoň /56 a za ten nebylo nutné platit, takže alokace je otázkou napsat do správného řádku v Excelu nebo ideálně IPAM (ale buďme realisti) na co že se to používá. V Německu např. něco pro interní zaměstnance, kteří ale v dnešní době pracují často i z domu by reálně tak 80-90% nemělo problém přistoupit na čistě IPv6 bránu z domu. Rozšíření IPv6 na domácích přípojkách je v Německu dost vysoké.

Killer feature taky rozhodně může být, že je to levnější. Podívejme se třeba na SpaceX - vystřelit něco malého na oběžnou dráhu si dnes může dovolit i hodně zapálený jednotlivec. Místo luxusního auta bude mít malý satelit... to by asi u jiných firem nebylo možné, tam by ani životní obrat nadprůměrného softwarového inženýra nemusel stačit.
Může ale taky být, že je to ve finále jednodušší. DHCP pool např. nikdy nedojde pokud rozdělujete z /64 prefixu, v prefixu /48, který firmy dostanou bez jakékoliv obhajoby je 64k takových podsítí, tedy něco ekvivalentního /16 v IPv4 akorát tedy podsítí/ administračních celků. Spíš bych to tedy připodobnil v reálu např. /8 v IPv4, kde by poslední oktet byl "nafukovací" a stále veřejně routovatelný. :-)
No a když jste LIR, tak dostanete /32 bez diskuze, když zvednete ruku, tak 8x tolik (/29) a když to rozumně obhájíte, tak v podstatě cokoliv, klidně i /19 nebo /20 pokud vím - většina firem ale není Deutsche Telekom nebo France Telekom a určitě ně US DoD (/13, tedy asi 50% toho, co aktuálně spravuje RIPE NCC pro celý region), AWS dává regionům pro EC2 podle všeho prefixy /36 až /33 (http://ipv6.ec2-reachability.amazonaws.com/) - když si to tak srovnáte v hlavě, tak při prefixu je to pořád 1 milion zákazníků s /56 prefixem na region. A to potřebujete už opravdu hodně velkou infrastrukturu, aby vám jeden /56 prefix nestačil - to už se nejspíš budete stejně bavit s nějakým zástupcem Amazonu, který vám bude s infrastrukturou radit. I těch nějvětších regionů by mohl Amazon mít 16k, pokud má /19 prefix. I takto velkých prefixů je možné přiřadit 64k a potom je ještě 7x tolik rezervovaných - Ondřej mě jinak rád opraví ;-)

Jinak firmy Amazon i Microsoft prý RFC1918 prostor už vyčerpaly - takže i na interní funkce musí asi používat teď taky NAT nebo se musí vyvarovat překryvům jinou technologií nebo organizací.

I pokud někdo má jen malou firmu a nějaké adresy a překryvy VPN apod. se ho netýkají, pro ty je v podstatě jedno, jestli použijí IPv4 nebo IPv6. Tam tedy IPv6 v současném stavu přinejmenším nevadí. Já si ale myslím, že IPv6 prostě v určitém ohledu dospělo. Už se nemluví ani tak o tom, proč nasadit a co je IPv6, ale kdy a jak nasadíme IPv6 abychom se zbytkem světa mohli komunikovat nativně. I když podpora IPv6 ještě není v některých produktech vůbec a jinde spíš druhořadá, renomovaní výrobci v podstatě 80% nebo tak funkcionality na IPv6 mají, rozumní poskytovatelé minimálně firmám IPv6 poskytnout umí a IPv6 je tak rozumně použitelná.

Asi uvidíme, kam se s IPv6 dobereme, ale poslední dva roky mám pocit se opravdu dost věcí posunulo. Jistě k tomu pomohl razantní růst cen IPv4/ problematika získání dostatečného počtu IPv4 a další nasazování IPv6 ve světě, které obloukem obhajuje další nasazování. Podle Googlu jsme si za poslední 2 roky pomohli ze ca. 20% na něco přes 30%. Poslední 2 měsíce jsou i výkyvy v používání IPv6 výrazně menší, jak lidi jsou víc doma místo v práci. Vím o institucích, kde se ještě nenasadilo, ale kde se tak posledních 6 měsíců podnikají konkrétní kroky k zavedení IPv6, jako školení, příděly prefixů nebo spojená administrativa s těmito příděly. Jedna z těchto institucí má něco jako /16 z IPv4 - takže srovnatelné např. s menším ISP. V regionu takové věci rozhodně zvyšují povědomí a tlak na další nasazování. O2 se možná taky v Čr v mobilní síti pochlapí na podzim (https://twitter.com/O2GuruCZ/status/1259368190901211138)

23. 5. 2020, 21:00 editováno autorem komentáře

Ipv4 neni problem, kdyby se vratili nepouzivane rozsahy a par US korporacim sebraly nesmyslne pridelene "A" class. Realne vyuziti neni ani 40%

Pro firemni nasazeni je NAT jednoznacne vyhoda, a ani nesmyslne sifrovani vsech webu (vcetne reklam) na tom nic nezmeni.

Ipv6 temer nikdo nepouziva, vubec nikdo nechce a jen malokdo opravdu potrebuje. A do internich siti firem se doufam nenasadi ani v pristich 10-ti letech. Nevyhody prime komunikace koncovych uzlu tam jednoznacne prevysuji jeho vyhody. Coz je i duvod, proc operatori typu UPC nasazuji ipv6 stylem "kockopes". I v cloudech ipv6 funguje, ale spis tak trochu okrajove.

A zadne "kupredu, leva" na tom jeste par let nic nezmeni, soudruzi.

Já třeba IPv6 používám velmi intenzivně a už ho dávno potřebuji. Mně přijde jako ohromná výhoda, že mám prostě dost adres na cokoliv a nemusím řešit, kde adresy vzít, když nejsou. Mám spoustu zařízení, která mají naopak jen šestkovou adresu, protože nechci řešit problém nedostatku IPv4 adres.

Kdybych neměl doma některá legacy zařízení, která šestku neumí, už bych čtyřku v síti vůbec neřešil. Ale je to na dobré cestě, nová televize třeba už šestku podporuje, takže se ta doba blíží. Některé kousky můžou dostat separátní síť a ostatní už dostanou jen šestku.

IPv6 je budoucnost a současnost, už velmi dávno je připravena většina internetové infrastruktury a k uživatelům se dostává také velmi rychle. Ke Google přistupuje už třetina lidí po IPv6. To je realita, IPv4 je druh odsouzený k záhubě.

Tak jestli to není tím, že jste hračička :-)
Chápu, že časem převládne IPv6 např. u živatelů pokud to ISP či operátoři zavedou. Ale nevidím důvod, proč by měl být IPv4 odsouzen k záhubě.

Např. ve firemním prostředí klidně v4 může v LAN fungovat. Co si pamatuji, tak IPv6 dost věcí komplikoval jako že DHCPv6 není ekvivalent DHCPv4, přepínače s různými ochranami na L2 byly na v6 taky problém apod. Ale nějakou dobu jsem to nesledoval, tak už se to možná zlepšilo.

A od pár správců jsem slyšel, že v6 ne, protože jim nepřináší nic navíc, co by jim teď nefungovalo. Ale asi to zaléží dle korporátu a velikosti.

Myslím, že pokud něco, tak "hračička" je asi to poslední označení, které by si kolegové ve spojení se mnou vybavili. Hluboký zájem o robustní technologie a jejich implementace, to spíš.

Ano, IPv4 jistě v LAN funguje a funguje v současnosti asi nejlépe bohužel i se zařízeními, která by se do sítě radši vůbec připojovat neměla.
Ano, DHCPv6 je jiné než DHCPv4, protože u IPv6 existuje SLAAC a tak část práce udělá každopádně zařízení a ještě trochu práce dělá router pomocí oznámením směrovače (RA) - dnes je možné postavit dynamickou IPv6 síť i úplně bez DHCPv6, když byste hodně chtěl, protože informace o DNS můžou být i v RA (https://tools.ietf.org/html/rfc8106).
Tzv. first hop security (FHS) ochrany jako RA guard, ND snooping, DHCPv6 snooping, ip source guard apod. jsou dnes na lepších managovatelných přepínačích např. jako HPE Procurve/ Aruba 5400R/ 3810M nebo typicky různé podporované Cisco Catalyst řady běžné. U těch levnějších/ méně známých je jistě ještě důkladnější testování resp. informace před koupí nejlepší rada, možná ty funkce budou dostupné až po updatu firmwaru nebo tak něco.

Ano, pokud řešíte jen opravdu připojení pár Windows stolních počítačů do domény a na internet, tak potom nejspíš IPv4 bude ještě dlouho stačit (když někdo za Vás vyřeší nějaký gateway na komunikaci do IPv6 světa). Jak začnete řešit mobilní/ home office a jiné přístupy a služby pro svoje zaměstnance a kolegy nebo pokud jste větší firma, která tu a tam nějakou jinou firmu koupí, tak rychle začnete výhody IPv6 přinejmenším chápat. Taky jsem slyšel (tuším na Packet Pushers, IPv6 Buzz), že např. v Číně už někde ani IPv4 nepřidělují a neumí s tím komunikovat ani nepřímo. Pokud máte tedy např. nákup/ prodej/ výrobu tam a potřebujete s nimi nějak komunikovat, tak IPv6 asi budete řešit. Pokud jsem to správně pochopil, tak v Číně je nasazení IPv6 politické zadání a firmy se tím mají radši řídit, jinak budou blíže nespecifikované problémy.

Z jiného soudku: Já měl to štěstí, že jsem se zatím překryvům v RFC1918 prostoru čistě šťastnou náhodou vyhnul. Ale zrovna tento měsíc jsem řešil jiný historický exces, jako že se pro interní potřeby jedné firmy, kterou můj zaměstnavatel koupil, kdysi používalo několik "class C" (před CIDR se to takhle dělilo) zhruba v rozsahu 1.1.0.0/16 no a i po letech tohle ještě viselo v routovacích tabulkách poskytovatele i když už se vše dávno přeadresovalo - takže quad 1 (Cloudflare) provoz z celé firmy (ne jen té nově koupené!) směřoval do routovací černé díry vtipně/ příhodně nedaleko jedné polské černouhelné pánve. Takové excesy s IPv6 sotva budete řešit, když si můžete hned říct o dostatek adresního prostoru.

V praxi nakonec různé korporáty dostihne to, že pokud zatvrzele budou jen na IPv4, že se svět kolem posune k IPv6 a oni budou na svém veselém IPv4 ostrově uprostřed moře IPv6.
Vtipné taky je, že pokud používáte něco jako VMware VSAN/ VxRail, že IPv6 už toto řešení interně používá a možná o tom ani nevíte pokud jste nemusel nastavovat věci spojené s MLD na switchi a dělal to někdo jiný/ má to dedikované switche např. příhodně od Dell/ EMC, když už dodali VxRail. Chápu ale taky, že ne každá firma si kupuje 3-4 servery ve 2U v dost nízké konfiguraci za 1 Mio. Kč+ a potom možná tak ještě 50% navrch za různé licence a support. Hardwarově je to tuším +- identické s tímto: https://www.qct.io/product/index/Server/rackmount-server/Multi-node-Server/QuantaPlex-T41S-2U-4Node

Tak to označení mělo pozitivní konotaci.

Chápu co píšete a některé problémy se už asi vyřešily. Co si tak matně vzpomínám, tak RA neumělo DNS a DHCP zase gateway. Nebo tak nějak. Ty L2 ochrany taky byly v plenkách, ale jak píšete, asi se to to dodělalo a zlepšilo.

Já to beru tak, že pokud firma o 10kách či stovkách stanic má odladěnou síť, doménu s DNS/DHCP, vyřešené logování a používají proxy, tak chápu, že se do IPv6 nehrnou. Tam jim stačí dual stack na proxy. Navíc by přechod mohl stát peníze za nové switche, routery, upgrady sw apod. což může být důvod to nedělat.

Ale udělám si znovu průzkum od známých, ať mám představu jak se kde postupuje.

Přidám se k Petrovi Krčmářovi. Můžu Vás ujistit, že IPv4 je skutečně nedostatek a že i kdyby se ještě nějak lépe příděly přerozdělit daly, tak že by to stejně vystačilo jen tak na pár měsíců a budeme zase tam, kde jsme teď. A z toho všeho by normální začínající podnikatel nebo ISP stejně neviděl nic - většina toho by se odehrála mezi už i tak velkými hráči. V současné situaci za adresní prostor, tedy pitomá čísla bez nějakého hlubšího významu nebo estetiky, všichni utrácíme zbytečně nemalé peníze navíc a řešíme mj. kvůli IPv4 a nedostatku adres organizační blbosti místo skutečného pokroku. Nějaké příklady jsem nastínil ve svém dlouhém komentáři.

V civilizovaném světě používá IPv6 denně nejspíš každý a ani o tom často neví. Že to naši operátoři a poskytovatelé připojení v Česku ještě úplně nepochopili je jiná věc. Že naše školy učí IPv4 jako něco opravdu aktuálního v době, kdy student po ca. dalších 3 letech studia vyleze z univerzity je podivuhodné. Nejsem proti IPv4 učit, ale principy routování a překladu DNS na IP apod. se dají zrovna tak vysvětlit na IPv6, což je rozhodně perspektivnější volba.

To, že firmy a mám pocit většina odborníků ještě tak úplně bezpečnost nepochopila, je smutné, ale řešit tohle jako vedlejší efekt na úrovni IP je přesně takový zlozvyk, jako když lidi srovnávají NAT s firewallem. V době, kdy realisticky každý druhý pracovník bez omezení může vykonávat nedůvěryhodný kód na počítači v interní síti (Javascript) a kdy jsme zjistili, že antivirus rozhodně není záruka 100% bezpečnosti, je dokonce i správné nastavení všech firewallů jen jedna z mnohých a stále poměrně účinných ochran. IT bezpečnost je ale mnohavrstvá a pokud to zazdíte např. tím, že interní aplikace posílá nezašifrovaně SQL dotazy přímo do databázového serveru, tak se trochu šikovnější hacker k datům firmy rozhodně dříve nebo později dostane, pokud bude chtít. Tahle situace je pokud vím poměrně běžná a je na IP protokolu zcela nezávislá. Btw. proto se taky různé ransomwary všude tak pěkně šíří. Jsem silně přesvědčený, že 99% případů jistě není dílem nějakého "hackera", ale spíše nějakého bota, uživatelské hlouposti a priorizaci úkolů/ podinvestování/ lenosti/ nekompetenci IT. Z mého pohledu je přechod na IPv6 příležitost, jak provést "jarní úklid" a obnovit postupně vše od infrastruktury až po firemní aplikace na aktuální úroveň z více pohledů, než jen adresování. Nakonec se totiž o všem důležitém dozvíte, nejpozději, když protokol IPv4 na firewallu a všech pracovních stanicích např. pomocí GPO zakážete ;-)

Ano, technologicky a na úrovni světové komunikace je ipv4 historií. Nicméně v malé podnikové síti je dhcp s ipv4 podle mne výhoda, protože zkuste se v síti s ipv6 kolegy z IT zeptat, jakou má adresu Radek. Kolega se zamyslí a pak řekne:
- "Ten má přece fe80::201:3ff­f:fe03:9c15."
- "Skvělé" , zajásáte a napíšete hned z hlavy do firewallu povolení této adresy pro určitou službu/server.

To myslíte vážně? Že tohle je rozhodující důvod, proč používat IPv4 a ne IPv6? Že tohle je vůbec nějaký důvod? Víte například o tom, že s použitím IPv6 se zařízení v té malé podnikové síti nerozmnoží, takže se jejich adresy budou stále – stejně jako u IPv4 – lišit jen v posledním bajtu?

Ahoj Petře, mrkni se prosím na https://knihy.nic.cz/#IPv6-2019 čte se to dobře a je tam všechno na aktuální úrovni. Dobrý (i když místy o facku starší) je i volně přístupný kurz od RIPE NCC: https://academy.ripe.net/enrol/index.php?id=2
Jak jsem psal, IPv4 v lokální síti je z mého pohledu v pořádku, ale dříve nebo později budeš chtít mluvit s vnějším světem a tam IPv6 už brzo nebude volitelným doplňkem, ale asi spíš nutným předpokladem.

V síti se obyčejně na lidsky čitelné věci používá DNS ;-) Radek bude mít např. pc42.example.com taky bys nejspíš chtěl až na výjimky používat GUA - tedy global unicast adresy. Firemní prefix si tam lze snadno zapamatovat a významné servery třeba právě jako DNS bude nejspíš něco jako 2001:db8:2468­:f000::1/64 protože nejspíš prvních 48 bitů budeš mít na pevno, dalších 16 si +- budeš moc zvolit, podle adresního plánu a posledních 64 u serveru můžeš (a asi bys i měl) nastavit staticky.

Na firewallu v ACL na routovacím switchi asi dává smysl řešit pravidla na úrovni /64 nebo kratším prefixu. Jedna /64 je jedna bezpečnostní skupina a obyčejně jeden "link" např. VLAN. Jelikož jich ve firmě úplně bez problému můžeš mít 64k, tak mi to přijde jako docela dostatečná granularita. (16x celý běžný VLAN prostor o 4094 VLAN?) Na vyžádání je jistě dobře možné dostat i víc prostoru, aby se dobře řešila organizační hierarchie apod.

Když budu chtít něco jen tak ad hoc na lince něco bez dalšího nastavování DNS, routeru apod. poslat, tak udělám ping na ff02::1%<iface> normálně mi odpoví všechna zařízení na lince (VLAN) a kolegy se zeptám na poslední 4 cifry adresy, což na 99% bude sedět.

https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#link-local