Vlákno názorů k článku
Konference Den IPv6 2025 se blíží, registrace je otevřena do 30. května od Heron - Já teda nechci zbytečně provokovat, ale co kdo...

Já bych všechny ty internety zakázal!
(To je, ostatně a mimochodem, dost podobný způsob uvažování.)

Ok, tak podme :)

Aby sme tu neriesili slovicka, mozu byt problemy a) navrhu IPv6 a b) implementacie IPv6. V dalsom texte riesime b), problemy implementacie, ci uz na strane ISP alebo na ich CPE. Voci a) nic nemam.

1) Kolko diskusii aj tu na roote bolo venovane ISP, ktori daju zakaznikom jednu /64? Ako si ma potom zakaznik segmentovat siet? Ako si spravi guest wif[1] alebo vpn? Takze ISP musia davat vacsi adresny rozsah, co nie je pravidlo. (Ano, su taki, co davaju rozumne rozsahy, ja viem. Ale je naprd, ked prave ti ISP, ktori obsluhuju vasu oblast to nerobia).

2) Aj ked ma vacsi rozsah ako /64, ma funkcne DHCPv6-PD? Vie CPE nejako rozumne tieto rozsahy pridelit tak, aby to kazdom reboote nemala kazda VLAN uplne nahodny prefix, iny ako predtym? (V IPv4 toto riesila staticka alokacia z privatnych rozsahov a NAT).

3) Ako na to nastavim firewall, aby pravidla zostali platne pre dane prefixy, ked zoberiem do uvahy bod 2?

4) DSLite - IPv4 je stale potreba a povedzme, ze DSLite postacuje. Niektori nemenovani ISP ho maju implementovany tak, ze B4 musi byt ich CPE a nejde cez to vlak. Samozrejme, ich B4 ma napevno nejaky subnet, ktory moze kolidovat, resp. ku ktoremu treba prihodit dalsie lokalne IPv4 subnety (napriklad pre spominany VPN tunel), staticku routu tam nedas, vlastny B4 kde by sa to dalo riesit si dat nemozes, takze zase zbytocny problem.

5) Co v pripade ze DSLite nepostacuje a treba realny dualstack s verejnymi IPv4 adresami? Mimo podnikovych pripojok vec v podstate nevidana.

6) Mikrotik. Az tento rok implementovali fastpath pre ipv6, takze bezne lacne krabicky konecne zvldaju v ipv6 to, co zvladaju s ipv4 po dekady.

Takze ano, ked mam na vyber medzi takymto niecim a klasickym ipv4, beriem klasicky ipv4. Nie preto, ze ipv6 je zle navrhnuty alebo komplikovany, ale preto, ze mi sposobuje prakticke problemy. To, ze je iny mi nevadi.

[1] no, su narovnavaky na ohybaky, ako to dat do jedneho lan segmentu, ale chceme to urobit korektne a poriadne, vsak?

ad 1] problem isp, ne ipv6. v ipv4 u isp jste radi, ze dostanete 1 verejnou, dostat /24 nehrozi. Nemluve ze pro rfc1918 mame ekvivalentne LUA.
ad 2] opet to nesouvisi s ipv6, ale implementaci adresace, opet k dispozici ULA.
ad 3] stejne jako v ipv4 rfc1918, v ipv6 ULA
ad 4] nebudu resit, neni obecne problem ipvX, to je problem implementace u isp
ad 5] nebudu komentovat, jako homeuser se k public ipv4 temer nedostanu (max placene a omezeny pocet)
ad 6] problem HW vendora, nema to nic spolecneho s ipv6

Obdobne problemy, kterymi trpelo ipv4, kdyz se rozbihalo, nemluve o tom ze tam se MUSELO uz davno implementovat NAT, aby ten internet jeste nejak fungoval.

1) V dalsom texte riesime b), problemy implementacie, ci uz na strane ISP alebo na ich CPE. Voci a) nic nemam.

2) V dalsom texte riesime b), problemy implementacie, ci uz na strane ISP alebo na ich CPE. Voci a) nic nemam.

3) V dalsom texte riesime b), problemy implementacie, ci uz na strane ISP alebo na ich CPE. Voci a) nic nemam.

4) V dalsom texte riesime b), problemy implementacie, ci uz na strane ISP alebo na ich CPE. Voci a) nic nemam.

5) V dalsom texte riesime b), problemy implementacie, ci uz na strane ISP alebo na ich CPE. Voci a) nic nemam.

6) V dalsom texte riesime b), problemy implementacie, ci uz na strane ISP alebo na ich CPE. Voci a) nic nemam.

1) pridelovani rozsahu koncakum JE pravidlo, ktery ISPci nedodrzuji. Precti si pravidla ripe. Je tam jasne receno, ze uzivatelum se ma pridelovat /48, a mininalne /56. Za nedodrzovani pravidel pridelu ti taky muze byt pridel odebran, coz by se melo delat idealne zcela automaticky.

2) dhcppd vubec nepotrebujes, adresa se da kupodivu nastavit rucne. Neni zadnej duvod co hodinu pridelovat jinej rozsah. Naopak, presne proto aby se to nedelo ma Ipv6 tech 64bitu na adresu site. Nemluve o tom, ze dhcp nemeni prideleny rozsah.

3) ty nemas iface?

4) ipv4 neni potreba nanic

Ze nekteri vyrobci krabic jsou dmentni na veci nic nemeni, mikrotik neumi hromadu veci ani v ipv4, ktery jsou jinde zcela samozrejmy.

1) Vsak ja netvrdim ze nie je. Ale nerobia tak. To sposobuje rozdiel medzi "malo by to fungovat a nefunguje" vs "funguje to". Ako koncak to nijako neovplyvnim, ale problem mi to sposobi.

2) Pokial dostavam info o subnete dynamicky, tak ho dynamicky dalej pouzivam. Pokial by som ho mal staticky, kludne ho pouzijem staticky. Mixovat to je koledovat si o problem, ktory sa zvycajne prejavi vtedy, ked je najmenej casu na jeho riesenie.

Podla RIPE pridelene prefixy pouzivatel nevlastni, a je mozne ich precislovat. Niektori ISP to beru dalej a prefix je po kazdom boote iny, ini prefix drzia. Ja sa na to nemozem spolahnut. Bolo to aj s IPv4 a DHCP, mam pripojku, kde sa IP adresa nezmenila 15 rokov, aj ked zmluvne to je dynamicka adresa a prideluje ju DHCP.

Ako alokovat mensie rozsahy z jedneho velkeho je zalezitostou konkretneho CPE a ten to menit po kazdom boote moze. Bohuzial.

3) Nie vzdy je to mozne.

4) Dovolim si nesuhlasit. Nie vsetko je Facebook a Netflix.

To je bohuzel hojne rozsireny omyl, to uz nejaky cas povinne pravidlo z pohledu RIPE neni. Prectete si ty pravidla. A nebo vam to odcituju... End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a value of "n" x /64. . A hodnota X neni pevne urcena. Druhy navazany dokument rika, ze ta praxe je durazne nedoporucena. Ale zakazana neni. Toliko k formalnim pravidlum. Ze v praxi to neni uplne stastne reseni nikdo nerozporuje - ale v rozporu s pravidly (jak tvrdite) to neni - tedy nic tim poruseno neni, tudiz to ani nemuze byt trestano. Ba naopak predchozi verze te politiky explicitne pripoustela pridel i jedne jedine /64 - a plus minus v ty podobe to tam bylo od listopadu 2007. Povinnost opravdu pridelit /48 byla jen mezi roky 1999 az 2002... a nasledne se uz pridel te jedne /64 zacal pripoustet. Takze "koreny" toho setreni co se assignmentu tyce je treba hledat uz v dobe pred triadvaceti roky...

Bylo by docela na místě, kdyby tam ta povinnost (/56+) byla. Neexistuje jediný rozumný důvod, proč by se mělo přidělovat jen /64.

Ono toho je vic, IPcka jsou pridelovana zdarma a povinosti ISP je pridelovat adresy zakaznikum dle jejjich potreb, nikoli dle jejich penezenek. Mozna bys obhajil poplatek za jednorazovy ukon, ale rozhodne ne mesicni vypalne.

A tak policy development je otevreny kazdemu, ani neni potreba byt clenem, mailing-listy jsou otevrene uplne kazdemu. Ono "samo" se nic neudela, zeano :)

Řeším nasazení IPv6 v síti řekněme střední organizace (300 workstations). Chceme dosáhnout shodné security úrovně s IPv4. Problémy, na které jsme narazili:

- Reálný stav implementace IPv6 v síťových prvcích (a vůbec ne levných). Konkrétní příklad je RA-guard, řeklo by se triviální věc, IPv4 DHCP-snooping funguje na switchích podnikové kategorie 20 let. Ale např. HPE CX6100 - funkce úplně chybí, přestože je v dokumentaci deklarovaná jako podporovaná. U HPE reportováno roky, nezajímá, v dokumentaci je to dodnes. Šlo by to řešit pomocí ACL, jsou tam dostupné potřebné classifiers. Kdyby ovšem nebyl stále relevantní problém s rozšířenými hlavičkami a fragmenty, popsaný např. i zde na rootu v roce 2015: https://www.root.cz/clanky/bezpecne-ipv6-vicehlavy-utocnik/ -- classifier "undetermined transport" umí Cisco (někdy, někdy to dokonce nic nerozbije), řada dalších velkých vendorů vč. HPE CX vůbec. Mezitím k řešení této kategorie problémů vznikla řada dalších RFC, např. 6980, ale jejich podpora v dostupných zařízeních je minimální nebo nejistá.

http://6lab.cz/rogue-router-advertisement-attack/

Takže než říkat, že problémy nejsou a stačí to zapnout, by mohlo být fajn šířit např. osvětu co vše je obvykle v reálných imlementacích špatně/chybí a jak postavit nákupní requirements tak, aby se tomu člověk vyhnul.

- DHCPv6-relay s identifikací endpointů podle MAC adres. V případě pevné sítě a managed workstations je to logický požadavek. Existuje na to RFC6939 z roku 2013. Počet OSS implementací = nula. Takže na Linux routeru to neudělám.

- Nevyhneme se ani SLAAC, protože Wi-Fi a Android - OK. Nevyhneme se ani Privacy Extensions - OK. Compliance nám ale ukládá, že máme mít flow monitoring s identifikací zařízení/uživatele. Máme Radius/WPA-Enterprise. Identifikaci toků ale nelze řešit podle IP adresy (jako u IPv4 s nasazeným IP-source-guard), ale musím buď být schopen z netflow dostávat MAC adresy, což v mnoha případech nejde / třeba Fortigate vůbec neumí / nebo nemám sondu v každé L2 síti, a nebo musím spolehlivě logovat vazbu IP-MAC z neighbor-discovery (zase v každé L2 síti), což je komplikované udělat spolehlivě, nejsou na to standardní mechanismy, a komplikuje to integraci ve flow collectorech.

I přes poměrně intenzivní předběžný průzkum je dojem z této akce "past vedle pasti".

IPv6 samo o sobě nijak nehodnotím a v tomto ohledu na něj nemám žádný názor. Ale děkuji za starost. Je mi, jak už jsem mnohokrát napsal, stejně jako většině uživatelů víceméně jedno.

28. 5. 2025, 13:18 editováno autorem komentáře

Timto muzeme diskuzi o IPv6 povazovat za oficialne zahajenou nebot se nam zde objevil pan Poljak, samozvany odbornik na libovolne tema alias moralni majak.

Já bych spíš řekl, trolle, že až tím, co jste právě napsal protože tím spamujete prakticky všude. A musím uznat, že je celkem zábavné sledovat, jak se pokoušíte o stalking jen proto, že vám někdo někde šlápl na bebí. Děláte to tak i v běžném životě? Kolik vám je, člověče? A ze které věznice píšete?

Za to, že píšete nesmysly vám opravdu nikdo nemůže. Fakt ne.

28. 5. 2025, 14:53 editováno autorem komentáře

Podla mna IPv6 je overengineered.
Pride mi, ze ho robili akademici trochu odtrhnuty od reality, ktory chceli urobit "dokonaly" protokol a nevydalo.
Prisiel cas, ze sme potrebovali nahradu za IPv4 a nic lepsie sme nemali, tak sme to pouzili.
Pricom ak by sa zobrali hostoricky prdelene velke rozsahy niektorym instituciam/firmam aby sa ziskal cas a prekopalo sa IPv6, tak by to mohlo vyzerat inac.

Spominam si na dobry serial clankov tu na root-e o IPv6 a jeho nedokonalostiach.

https://www.root.cz/serialy/bezpecne-ipv6/

p.s. rovnaky pocit mam aj pri Slovencine. Je to technicky skoro dokonaly jazyk(niekto sa na nom poriadna vyradil) ale strasne blbo sa spisovne pouziva/uci.

Ten cas se ale ziskava uz od roku 1994, kdy se mj. prislo s NATem - protoze uz tehdy bylo jasne, ze 32bitovy identifikator zarizeni nebude dostacovat. Jak si predstavujete takove to "dokonale"? V prvni rec je o tom identifikatoru - no, tak se prislo s tim, ze se natahnul na 128 bitu, coz by melo zajistit nejake "dlouhodobejsi" preziti. Se zmenou delky identifikatoru musite tak jako tak prekopat hromadu veci - vsak se staci podivat, jak bolestivy je utek od 32bit unixtime. Porad tu nikdo nerekl, co ze je tam tak overengineered - kdyz v realu se bavime o tom, ze hlavicka IP paketu se znacne zjednodusila, oproti IPv4 zmizela spousta priznaku - o kterych dost mozna ani nemate tuseni, ze tam vubec jsou... ja bych rekl, ze vsechny ty "kecy" stoji a padaji s tim, ze lidi resi ten zapis 128bit cisla v sestnackove soustave. Ale jak jinak byste to teda resil?

Precitaj si ten serial. Su tam pekne vysvetlene vlastnosti/neduhy IPv6, ktore su tam podla mojho nazoru vdaka overengineeringu.
Osobne mi prislo, ze IPv6 nikto poriadne neotestoval a nezamyslel sa nad moznymi rizikami a realitou.
Precitaj si ten serial a uvidis.

K hlavicke.
IPv6 ma jednoduchsiu hlavicku ale ma aj extension header, co je jedna z chyb navrhu IPv6, ktora tam nemala byt.
Zly navrh extension headers alebo presnejsie to, ze na zaciatku nezadefinovali jasne pravidla/strukturu extension headers povazujem za skolacku chybu a trvalo velmi dlho kym vydali RFC, ktore to nejak riesi/zavadza pravidla,ktore tam mali byt od zaciatku. Pricom to mala byt jedna z vlajkovych veci IPv6.

Chyby v navrhu jsou i v IPv4 a i tam se hromada veci ladila s tim, jak vyplouvaly na povrch ruzne problemy. Ba, co hur - jsou veci, co tam vlastne moc nefunguji - treba path MTU discovery (protoze spousta jelimanu svym firewallem zahodi vsechny ICMP). Ale jak u IPv4, tak u IPv6 je potreba take pracovat s casovou osou a dobu vzniku kazdeho RFC je potreba si umet zasadit do prislusne doby vzniku a zamyslet se nad tim, jak vypadaly veci okolo - treba i samotny internet. Ono pred 20-25 roky kdeco kolem nas vypadalo jinak a kazdy, kdo tu dobu prozil mi jiste da za pravdu. Aneb vas komentar je primarne z kategorie "po bitve je kazdy general". Skoda, ze jste tu nebyl pred ctvrt stoletim ;-)

Jak uz to tak byva, vse dobre jde i k necemu zneuzit. Myslenka extensions headers sama o sobe spatna neni... jenom holt prisli take nejaci "skodici", co to zacli zneuzivat. Ale tim nastrojem, co vam uskodi muze byt cokoliv... nozem si muzete nakrajet steak... ale taky muzete zabit. Je snad proto validni rict, ze noze jsou spatna vec? Nebo sroubovak, ci treba i dlazebni kostka, to je fuk... plati na cokoliv. Paralelou z IPv4 sveta muzou byt treba IP fragmenty, ty jsou u "skodicu" take popularni, protoze se holt po ceste hur paruje, co k cemu patri...

Nevytahuj IPv4 Ja netvrdim a tusim ani nikto tu, ze IPv4 je lepsi.
Je to strasi protokol zo zaciatkov spocitacovych sieti, tak je jasne, ze bude mat svoje neduhy.

Ano beriem a vnimam, ze aj IPv6 je stary protokol a jeho prvotny navrh bol pred rozmachom internetu.
Preto tvrdim, ze sa nemal pouzit IPv6 ale jeho vylepsena verzia lebo bolo zrejme, ze nieje dobry a priestor tu na to bol.
Presne ked si pozries ako vypadali veci okolo, tak mne z toho vychadza overengineering.
Boli tam skupiny roznym pohladom na vec a "puristi/idealisti" si presadili niektore veci, ktore nedozrkadlovali realitu/prax a vyustili k niektorym nedokonalostiam IPv6.

Myslenka extension nieje zla ale primarny problem tam nieje, ze prisliel niekto, ktoto zacal zneuzivat. Primarny problem bol, ze ta specifikacia bola velmi vseobecna a neustrazili sa tie hlavicky. TVL tam malo byt od zaciatku a rozum mi neberie preco. Pride mi trivilana vec, ktora by ma napadla hned.
Tie hlavicky je potrebne spracovat, tak ak bude kazda ina(strukturou), tak to moze byt problem nielen z pohladu narocnosti spracovania ale aj moznosti zneuzitia.
Ked sa to prislo(IETF uznala, ze je to problem), tak podla mna bol priestor urobit razny krok a vramci neho aj zahodit existujuce hlavicky nesplnajuce TVL. A tak ludia zacali zahadzovat packety s extension headers aby sa vyhli problemom. IETF to nevyriesila, tak to vyriesila prax/realita po svojom.

A,jako vy mate sva tvrzeni... ja mam sve, jen nevim jak vy, ale ja IPv6 defacto pfodukcne pouzivam pres patnact let. Sitarine se venuju aktivne jeste dyl... a co to vy placate je ciste teoretizovani nad RFC u veci, co zjevne moc neprovozujete.

A sve neznalosti dokazujete uz tim argumentem o zpracovani hlavicek - jo, je to dilci problem, ale ten trapi jen koncove uzly.

IETF nejsou zadni bohove, naopak je to vcelku otevrena komunita. Mate-li pocit, ze to umite lepe, nic vam ve finale nebrani se do toho standardizacniho procesu zapojit... nabizi se otazka, proc tak necinite, kdyz jste tak skalopevne presvedcen, ze to delaji az tak blbe.