Předchozí ročníky jsou nahrané, takže se dá předpokládat, že bude i tento.
Dělám pro obří německý korporát a oni mají IPv6 vypnutou by default, což mě neskutečně štvalo. Jenže jsem našel dobrý důvod jak je donutit aby to zapnuli. WSL2 se totiž neumí připojit k síťi, když je člověk na VPN od Cisco. Existuje však snadné řešení a to zapnout mirroing sítě, ale to funguje jenom, když není IPv6 vypnutá. Takže jsem jim to hodil tak, že buď to zapnou nebo ať vyřeší síť ve WSL2 a najednou to šlo.
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...
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".
Konstatování, že je něco overengineered opravdu nijak neimplikuje to, co píšete. To je vaše další klasická (a obvyklá) demagogie. Ostatně už ta vaše neuvěřitelně a uboze tupá "úvaha" -- dá-li se to tak vůbec nazvat -- že každý, kdo neadoruje to, co vy má názor "dělníka z montovny" a "mozkovny" jsou jinde je vyloženě hloupá jakkoliv to odpovídá tomu, co obvykle píšete.
Jediné štěstí, že to celé svědčí především o vás.
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.
Minulý měsíc jsem nainstaloval aktuální Ubuntu. Počítač umístil do sítě, kde IPv6 funguje. A přestal mi chodit apt, protože se snažil stahovat balíky po IPv6 a po cestě něco nefungovalo (a ani to neházelo žádnou rozumně dešifrovatelnou chybu, jen timeoutoval). Inu, bylo mu domluveno, aby používal funkční technologii.
Kolem IPv6 se dle mého pozorování pohybují 3 skupiny lidí:
1) ti, kterým je nějaký IPv# úplně jedno (většina)
2) ti, co IPv6 tlačí (hlasitá menšina)
3) ti, co se setkali se záhadnými potížemi IPv6 a jsou rádi, že existuje IPv4 (a tváří se obvykle jako skupina 1 a vyhýbají se skupině 2)
Pokud administrator systemu nedokaze provest zakladni diagnostiku, mel by si najit jinou praci :-) Aneb to "neco" jednak jde identifikovat... a druhak to same se muze stat stejne na IPv4 i IPv6. Aneb situace, kdy se mi rozpadla komunikace po IPv4, zatimco IPv6 chodila bez potizi jsem uz taky zazil pomerne dost...
Danny v korporatu (resp. dvou) primo pracoval. Ono je to taky dost o lidech.... pokud vam tam informatice sefuje sedesatiletej dedek, co ten flek ma za zasluhy z dob, kdy vrcholem slavy byly osmibitove architektury, tak ten se moc novy veci holt ucit nechce. Ale vymysli vam tisic duvodu, proc neco nejde.
No rekneme, ze drtiva vetsina koncaku si to neadminuje. Dostane krabici od sveho poskytovatele, ta si zije svym zivotem... a kdyz krabice shori, tak se zvedne telefon, zavola se na podporu a je donesena nova krabice, kde se maximalne zmeni heslo k wifi... a nekdy ani to ne. Akorat ze tahle skupina lidi v realu ani neresi to, jakou verzi protokolu ma... ba dokonce jim je fuk, ze dostanou jen jednu /64. Ono zas tolik lidi skutecne segmentovane domaci site nema, zeano. A spousta (zvlast) levnych domacich krabicek resi "guest" wifi tak, ze do stejne L3 site se strci druhe SSID a cela izolace se resi jen na L2 bridge. Nicmene to se soucasne bavime o lidech, co se nebudou chodit vyjadrovat na root, zeano ;-)
Chtěl jsem napsat:
ping eset.cz IPv4
ping eset.com IPv4
ping www.eset.cz IPv4
ping www.eset.com IPv6
Tak velká společnost a IPv6 nasazená napůl.
Muj nazor je takovy, ze prechod na IPv6 poskytovatelum nikdo nezaplati takze na nej prdi dokud ho realne nepotrebuji. Dokud je moznost schovavat vse za devatero NATu, dokud v DE dostane poskytovatel dotaci na vymenu technologie zatimco v CR ne, dokud samotny stat ktery se zavazal k implementaci IPv6 na svych serverech pred dvaceti lety na to prdi tak do te doby budou v CR na to poskytovatele prdet bez ohledu na to co si o tom Danny mysli. Ze jsou lidi odtrzeni od reality a mysli si ze ten prechod je zdarma a poskytovatele to nic nestoji chapu, ale to je uplne jina diskuse.
Tak treba Netbox umel jenom tunel a i ten je aktualne vypnut a uvidi se zda O2 jednoho pekneho dne IPv6 zprovozni nejakym jinym zpusobem. Situaci u jinych ISP uplne neznam. V mobilnich sitich byla absence IPv6 donedavna bezna. U malych ISP bych se vubec nedivil, kdyby ho mnozi neresili, protoze zakaznici to nepotrebuji a je to zbytecna prace. Jestli O2 nebo jiny operator, ktery aspon v casti site IPv6 nema, musi vylozene do neceho investovat nevim, HW asi maji pripraven, ale minimalne musi platit lidi, kteri to budou resit, takze naklady s tim samozrejme jsou.
Ted se divam na clanek na Lupe a zda se, ze uz vsichni tri mobilni operatori maji IPv6, uvadeji tam roky 2020 u O2, 2023 u Vodafone a 2025 u T-mobile, to mi skoro ani nepripada jako 10 let ;-)
Tam je spis problem to, ze nektere kusy infrastruktury jsou "legacy". V tom scale velkych ISP je nerealne ocekavat vsecko hned a vsude. Aneb jo, taky bych tel vsude vlaky, co jedou 200+, ale holt zivot neni pohadka, kde otocime kouzelnym prstynkem a ten zazrak se prihodi vsude hned. Ano, nejaky cas se marne promrhal... mohlo to byt drive... ale konecne se to hybe kupredu...
Všechno je to ale infrastruktura Cetinu nebo Vodafone na kabelové televizi (staré UPC). Plus něco málo co koupili např. GTS jestli jim to tam ještě běží.
Sami to i tvrdí:
IPv6 ve fixním světě je zatím dostupná pouze zákazníkům pevného internetu na technologii xDSL a Cable internet. Na zpřístupnění pro další nabízené fixní technologie stále pracujeme. IPv6 nově podporujeme také v mobilní síti
29. 5. 2025, 13:18 editováno autorem komentáře
Osobně bych chtěl požádat, aby se taky probralo možné řešení implementace Plug & Play pro konzumní sféru (běžný lid), pro který jakékoliv nastavovaní nepřipadá v úvahu.
V současné době, když zapojíte 3 routery za sebe tak sice je tam 3x NAT ale všem pojede facebook/youtube/tiktok u IPv4. To samé když očekáváte od IPv6 tak první bude možná fungovat 50/50, druhý nebude fungovat na 100% a třetí nebude fungovat na 300%.
Pro toho kdo nechápe tak konzumenti fungují striktně binárně tj. Funguje / Nefunguje. Pokud něco nejede najde si na nejbližším fórum "řešení = vypnout IPv6 a zapni IPv4 only + popis" a zařízení poběží takto dalších 5 Let i když to chtělo celou dobu pouze restartovat. Rozšíření wifi taky jedou stylem: "Toto má nejvíce tykadel za nejlepší cenu" a zapojení poslezé "drátek co dělá cvak zapojit do modré dírky než udělá taky cvak, ledka už je zelená, jedem selfie #IT_guru".
Zní to jako fór než se s tím setkáte.
Nadhodtě tam aspoň zmínku co by se pro to mohlo udělat.
Vysvetli mi, proc zapojujes 3 routery a delas 3x nat. A ja ti pak ukazu milion veci ktery za tim nikdy fungova nebudou - fckbok included.
Normalni konzument si poridi jednu krabici (pokud mu ji nedoda rovnou ISP) a nic na ni nenastavuje, protoze netusi proc by mel, a vsechno mu funguje. Ma to samo takovy detaily jako verejne dostupny porty widli a tak ... (a to samozrjeme i za tim NATem)