Názory k článku
6to4: nejjednodušší cesta k IPv6

Moja skusenost so 6to4 for je, ze nie vsetky servery na realnom 6bone vedia koser route na 2002/16 prefix. Proste na niektore servery sa cez to neda dostat. Zmenil som na domacom OpenWRT routeri IPv6 na IPv6inIPv4 a ide vsetko. http://tunnelbroker.net/ dava 4 tunely zadarmo a per tunel je /64 prefix + moze cez neho byt smerovany aj dalsi /48 prefix. Reverzne DNS je samozrejme. To ze endpoint je vo Frankfurte nie je prob., lebo lokalne aj tak nie je nic na IPv6 a do sveta ide aj tak znacna cast smerovsani prave cez Frankfurt.
K tomu 6to4 chyba este zmienka o http://6to4.nro.net/ co je registrator reverznych DNS pre 6to4 IP adresy.

ip tunnel add sit0 mode sit remote any
ioctl: No buffer space available
ale presto se vytvori
ip –6 address add 2002:xxxx:xxx­x::1/16 dev sit0
RTNETLINK answers: Invalid argument
(misto xxxx:xxxx mam cisla, ktera tam maji byt)
a zajimave je potom:
ip tunnel del sit0
ioctl: Operation not permitted

buďto je chybka v zařízení, nebo ty příkazy nepíšeš jako administrátor (root), nebo je to chobotnice sedící na sběrnici s chapadlem k procesoru a síťovce :-) Případně se pletu a je to něco úúúúúúplně jiného

v jakem zarizeni? na tom pc normalne inet funguje, existuje tam eth0, lo
root jsem
chobotnici nevidim
asi neco jineho teda

Přidal jsem ještě „local 10.11.12.13“, tedy
ip tunnel add sit0 mode sit remote any local 10.11.12.13
a chyba „ioctl: No buffer space available“ se nezobrazila.
Zrušit interface se mi taky nepodařilo:
ip tunnel del sit0 ioctl: Operation not permitted
Pomohlo až odebrání modulu sit.

Přesně tohle mi dělá Ubuntu...

ip –6 addr add 2002:xxxx:xxx­x:1::1/16 dev eth0
ip –6 addr add 2002:xxxx:xxx­x:2::1/16 dev ath1
Nemá tam být /64 ?

Jj má, opraveno.

Je to tak, tohle je taky přes ADSL od TO2:
=============­========================­========================­======
1 1 ms 1 ms 1 ms 192.168.1.1
2 13 ms 10 ms 10 ms 88.103.200.42
3 15 ms 11 ms 11 ms 88.103.203.1
4 15 ms 11 ms 11 ms 80.188.33.245
5 26 ms 24 ms 24 ms fe0–0.cr1.PRG.CZ.con­tent-core.net [194.50.100.68]
6 26 ms 23 ms 25 ms ge2–1.cr1.NBG1.content-core.net [212.123.123.113]
7 26 ms 23 ms 28 ms 192.88.99.1
=============­========================­========================­======
1 1 ms 1 ms 1 ms 192.168.1.1
2 11 ms 9 ms 9 ms 88.103.200.42
3 15 ms 12 ms 12 ms 88.103.203.1
4 13 ms 11 ms 11 ms 80.188.33.245
5 13 ms 12 ms 12 ms nix-s.nic.cz [194.50.100.3]
6 13 ms 11 ms 12 ms 6to4.nic.cz [217.31.204.95]
=============­========================­========================­======
Je vidět, že 6to4.nic.cz má mnohem nižší latenci. Nemohli by tedy v TO2 nastavením svých BGP routerů zajistit, aby se 192.88.99.1 smě­rovalo raději k nic.cz?

Dobry den,
vyjadrim se k problemu traceroute, koukal jsem, ze se to objevuje ve vice prispevcich. Bohuzel BGP protokol nema prilis moznosti, jak zjistit, ktera cesta je lepsi. 6to4 je propagovano do NIXu nejmene ze dvou mist a delka propagovane cesty je vzdy nejkratsi mozna, tedy jen 1 autonomni system. Pak existuje par mechanismu, jak se BGP rozhoduje, prvni je v RFC 4271, konkretne v 9.1.2.2. Diky ruznosti autonomnich systemu se nepouzije bod c) tedy MED, takze rozhodnuti je pouze na bodu f) a g), coz nehraje prilis ve prospech CZ.NICu. Druhym mechanismem je RFC 5006 neboli preferenci „starsiho“ prefixu, coz opet hraje proti CZ.NICu nebot tuto routu zacal propagovat pozdeji. Takze suma sumarum, nejlepsi bude oslovit jednotlive ISP a pozadat je o nejakou „umelou“ preferenci cesty CZ.NICu, coz je v podstate v jejich zajmu. Za CZ.NIC tedy slibuji, ze se tomuto tematu budeme venovat a se jednotlivymi ISP se pokusime domluvit.

Jako dočasné řešení by možná šlo ipv6 relay NICu přidělit navíc nějakou unikátní IP adresu (jinou než 192.88.99.1). Pak by administrátor mohl nastavit routování přímo do CZ.NICu a preference v BGP vůbec neřešit.

No to bych radeji nedelal. 6to4 je reseno anycastem. Pokud tedy nejaky uzel vypadne, jeho funkci prebere prirozenym zpusobem nejaky jiny uzel site. Z techto duvodu neni reseni v CZ.NICu nijak redundantni, protoze vlastne k zaloze neni duvod. Kdybychom zacali publikovat IP cislo z naseho rozsahu, museli bychom zacit tu sluzbu garantovat a prejit tedy do stejneho rezimu, jako ma treba registracni system – vice instanci, v ruznych geografickych lokalitach a podobne. A jak uz jsem psal, v tomto rezimu ta sluzba u nas nebezi.

Máte nějak zabezpečeno abyste v případě nefunkčnosti vašeho 6to4 routeru přestali přes BGP ohlašovat že máte funkční 6to4 router? Jde mi o to, zda skutečně bude fungovat to proklamované „Pokud tedy nejaky uzel vypadne, jeho funkci prebere prirozenym zpusobem nejaky jiny uzel site.“

Ano, je to zabezpeceno tak, ze 6to4 prefixy jsou propagovany z te same masiny (pres iBGP), ktera provadi tu relay. Pouzity routovaci demon je nas vlastni BIRD. Hranicni routery CZ.NICu to pak siri dale. Pokud by tedy masina lehla, BGP propagace zmizi. Vse je samozrejme monitorovano 24×7.

Tak teď už zbývá jen dodělat monitoring toho zda proces realizující 6to4 server skutečně funguje jak má, a pokud ne tak notifikovat BIRDa že má zajistit že do BGP přestanou být ohlašované 6to4 adresy (a samozřejmě notifikovat administrátory že je to rozbitý a potřebuje to opravit). Prostě jsem perfekcionista a přestat ohlašovat přes BGP 6to4 adresy pouze v případě že by lehla celá mašina mi nepřipadá dost dobré. Moje představa je že například pokud ztratíte IPv6 konektivitu, ale zůstane vám IPv4 konektivita, měli byste radši přes BGP přestat ohlašovat dostupnost 192.88.99.1, a podobných případů by se určitě dalo vymyslet více…

Ano, to vsechno je, vzdyt jsem psal, ze to ma monitoring 7×24.

Hmm tak ono to asi s tím monitoringem nebude zase až tak horké. Z ADSL od TO2 mi to najednou začalo směrovat 192.88.99.1 k nic­.cz, což má za následek že jsem přišel o IPv6 konektivitu. :-(
traceroute to 192.88.99.1 (192.88.99.1), 30 hops max, 60 byte packets
1 88.103.200.42 (88.103.200.42) 13.092 ms 15.956 ms 19.384 ms
2 88.103.203.1 (88.103.203.1) 24.262 ms 27.179 ms 30.512 ms
3 80.188.33.245 (80.188.33.245) 34.321 ms 36.218 ms 39.091 ms
4 nix-g.nic.cz (194.50.100.13) 43.606 ms 46.441 ms 49.312 ms
5 192.88.99.1 (192.88.99.1) 91.200 ms 91.673 ms 92.410 ms
Přes 6to4 tunel se mi na všechny moje zaslané IPv6 pakety vrací z adresy 2002:c058:6301::1 ICMP6 destination unreachable.

Divne, me to jede bez problemu. Neni chyba u vas?

Dovolim si komentar:
Obecne lze s BGP udelat temer cokoliv. Neexistuje variabilnejsi routovaci protocol. Vzdy lze (i nekolika zpusoby) ovlivnit cestu z/do AS.
Staci se podivam na www.cisco.com a dokumentaci k jejich implementaci BGP.
- s MED lze porovnavat pro routy z 2 ruznych AS (defaultni podminka na 1 se da vypnout)
- nove IOS uz nepreferuji jen starsi prefix (lze vypnout)
Tom

To je jako učit orla létat :-) Feela se v tom vyzná patrně jako málokdo tady.

„6to4 je propagovano do NIXu nejmene ze dvou mist a delka propagovane cesty je vzdy nejkratsi mozna, tedy jen 1 autonomni system“ – nebylo by lepší ty 6to4 adresy propagovat přímo z AS NIXu (6881)? Když už NIX má vlastní AS který je stejně jen k vzteku (prodlužuje o 1 hop cestu mezi peerujícími partnery)…

> Když už NIX má vlastní AS který je stejně jen k vzteku (prodlužuje o 1 hop cestu mezi peerujícími partnery)
NIX sice vlastni AS ma, ale to se nepridava do cest pri peeringu mezi peerujicimi partnery.

Presne tak. NIX.CZ ma dokonce technicky 2 autonomni systemy, jeden svuj 6881, ktery pouziva pro svou vnitrni sit, intranet a hostovane DNS servery cizich domen a podobne. Tento AS je pripojen jako AS kazdeho bezneho clena i do peeringove VLAN. A pak pro route server pouziva 47200. Ale ten je v podstate neviditelny, Z kazde cesty je odstranen.

> Takze suma sumarum, nejlepsi bude oslovit jednotlive ISP a pozadat je o nejakou „umelou“ preferenci cesty CZ.NICu, coz je v podstate v jejich zajmu.
Ahoj, nezkousel jsi oslovit IP exchange GmbH (AS15598), aby pri peeringu v NIXu u 6to4 prefixu prependovali o jedno sve ASN do cesty navic? To me prijde jako rozumnejsi reseni, nez aby prekonfigurovavali svuj BGP router vsichni ostatni.

Ahoj! Tem uz jsme samozrejme psali, zatim nemame reakci. Ten prepending je otazkou, muze pak byt vyhodnejsi nejaka hodne vzdalena relay v pripade, ze to CZ.NIC vypne a pak pro kazdeho kdo nepeeruje s CZ.NICem. Uvidime. Nicmene tim, jak se do NIXu pripojuji velci hraci, da se predpokladat ze se 6to4 prijde nekdo dalsi. Coz to cele muze dale zamotat.

I z CESNETu i z Netboxu mi traceroute na 192.88.99.1 konci na Tenge1–3–57.cr2.FRA3.content-core.net.
BTW, existuji nejake best bractices k pridelovani adres? Doporucujete stateless dhcpv6, stateful dhcpv6 nebo neco jineho? A jak potom dostanete IPv6 adresy klientu do DNS?
Ja mam treba sit kde jsou pocitace vicemene staticke (a treba notebooky zamestnancu), a pak jinou sit, kde jsou ad-hoc notebooky a autentizuji se treba pres dot1×. Pripada mi ze minimalne ty prvni bych chtel mit v DNS.
Jak tohle resite?
-Yenya

Checht, tady ten komentarovy system pokazi retezec dot1× (ma byt s x, ne s ×).

Pane LOL-VOL, ptal se naprosto jasně a navíc uvedl, že firewall používá na routeru. Jestli vy si to neumíte představit, tak se k dané problematice nevyjadřujte.

Ja to riešim nejako takto:
ip6tables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT ip6tables -A FORWARD -d $LAN6 -j DROP
kde $LAN6 je vnútorná ipv6 sieť.

Akorat ze kdyz to takhle udelaji vsichni, tak si muzem usetrit praci a zustat u IPv4 a NATu, protoze vysledek bude stejnej – pocitace ze dvou takhle nastavenych siti se spolu nespoji, ani kdyby se rozkrajely.

To už je kompromis medzi bezpečnosťou a pohodlím – vybrané počítače majú povolené vybrané porty, a vo všeobecnosti BFU nemá dôvod púšťať si na pracovnej stanici server…

To pochopitelne zalezi na tom, o cem se presne bavime. Nekde ve firme nic nenamitam, tam admin vsechno potrebny povoli. Ale nekdy mi prijde, ze nekteri by takovyhle nastaveni nejradsi videli jako defaultni i na domacich routerech a tam tomu uzivatel vetsinou nerozumi, takze toho moc nenastavi. A rozhodne si chce poustet veci, ktery by idealne mely komunikovat primo (Skype, posilani souboru pres IM, …).

Počítače ze dvou zaNATovaných sítí se běžně spojují.

Dobre, upresnuju, spojit se sice muzou, ale zas tak uplne jednoduse jim to nejde. Pokud nemaj primo nejakej forwardovanej port, tak se ruzne domlouvaji pres prostredniky, snazi se prorazet diry v NATu, atd. To ma k idealnimu stavu daleko.

Netvrdil jsem nic o ideálním stavu, jen jsem reagoval na nepravdivé tvrzení.

Funkce firewallu se na IPv4 a IPv6 neliší.

Dakujem pekne vsetkym. Vela noveho som sa tu bohuzial nedozvedel.
Funkcia firewallu na IPv4 a IPv6 sa sice nelisi, ale na IPv4 moze (a casto aj byva) slusny firewall na routri a vo vnutornej sieti bud takmer ziadny firewall, alebo nejaky minimalny (napriklad akceptovat vsetko z lokalnej siete).
V IPv6 vsak firewall na routri nie je dobry napad (napriklad aj kvoli sifrovaniu ktore IPv6 umoznuje) a preto je teda firewall na kazdom z koncovych strojov potrebny. A potom sa lisi nie funkcia firewallu, ale jeho pouzitie.
Vo vacsine IPv6-propagandistickych clankov/navodov sa firewall vobec nespomina… takze mame fasa konkretne navody, ako si zapnut IPv6, ale nic konkretne k tomu, ako minimalne skontrolovat, ako je na tom firewall pre IPv6, aby aj sluzby chodili, aj bola masina bezpecna…

„Vela noveho som sa tu bohuzial nedozvedel.“
Jde taky o to, jestli ses snažil něco dozvědět.
„ale na IPv4 moze (a casto aj byva) slusny firewall na routri a vo vnutornej sieti bud takmer ziadny firewall, alebo nejaky minimalny (napriklad akceptovat vsetko z lokalnej siete).“
Na IPv6 taktéž.
„V IPv6 vsak firewall na routri nie je dobry napad“
Právě naopak.
„(napriklad aj kvoli sifrovaniu ktore IPv6 umoznuje)“
IPv4 šifrování rovněž nezakazuje, dokonce i IPsec se dá s IPv4 použít.
„A potom sa lisi nie funkcia firewallu, ale jeho pouzitie.“
Neliší.
„Vo vacsine IPv6-propagandistickych clankov/navodov sa firewall vobec nespomina…“
Tak nečti propagandistické články. Firewall funguje na IPv6 prakticky stejně jako na IPv4.

Pekný článok… Mám jednu otázku: dal by sa vytvoriť nejaký IPv6 tunel medzi 2 PC prepojenými cez IPv4? Mám doma „server“ na ktorý sú presmerované všetky porty – teda má verejnú IP, keby som si naň zabezpečil pomocou 6to4 IPv6 adresu a z neho by som ďalšie poskytoval ostatným PC v LAN, „server“ nebeží stále a preto musia mať všetky PC stále IPv4 – teda nemôžem si urobiť lokálnu IPv6 sieť (aj preto, že router je šmejd a IPv6 nepodporuje) Vedel by niekto ako sa dá toto vyriešiť?

Kup si router, cokoli rozumneho bude mit spotrebu minimalni a ipv6 to zvladne, pokud si chces dobre vybrat, tak se trebas koukni na cem bezi openwrt.

No lenže potom pôjde iba IPv6 nie? Ide hlavne o to aby som na počítačoch nemusel nastavovať IPv4 – t.j. keď príde niekto s ntb alebo pod. a bude sa chcieť pripojiť aby to hneď šlo (samozrejme po nastavení hesla k WiFi). Môžu fungovať oba protokoly naraz?

Jestli je na tom OpenWRT stejne jako DD-WRT, tak si dovolim upozornit ze pokud to bude router na kterem bezi pouze verze s 2.6 jadrem (napr Asus RT-N16), pak nebude k dispozici IPv6 netfilter.
Podpora vlastni IPv6 je, jen ten firewall neni.

Není na tom stejně, včera jsem zrovna OpenWRT kompiloval a IPv6 netfilter tam je.

Tak to je dobra zprava, Jdu se juknout.

Hmm, tak ja mam asi smolik, prze OpenWrt a RT-N16 si spolu moc nerozumi skrzeva wifinu :-(.

Na OpenWRT (kamikaze) s 2.6 jadrem uz pres rok a pul pouzivam ip6tables a mam pro IPv6 nastaveny firewall. Na jinem, kde musi byt kvuli Broadcom sitovce taky, s tim omezenim, ze firewall pro IPv6 je v tomto pripade bezestavovy, v cem by mel byt problem?

Omlouvam, se, nejak vypadl kus textu:
… musi byt kvuli Broadcom sitovce _jadro 2.4_ taky, …

[root@igw ~]# ip –6 route add default via ::192.88.99.1 dev sit0
RTNETLINK answers: No route to host
Na 192.88.99.1 si vklidu pingam, i kdyz je to ted smerovany kamsi na „Tenge1–3–57.cr2.FRA3.content-core.net“, to se snad vyresi a na test je to stejne jedno.
[root@igw ~]# traceroute6 ::192.88.99.1
connect: Network is unreachable
[root@igw ~]# ping6 ::192.88.99.1
connect: Network is unreachable
Nevite nekdo co s tim?
Diky. Zdenek

ip –6 route add ::/96 dev sit0
Pak uz jen pridat tu vychozi branu, coz mi porad neslo a uz si pingam.

Minimalne stabilni verze RouterOS (4.x) sice umi IPv6 routovat, ale SSH nebo WinBox po IPv6 nejede. U betaverze petky nevim, ale doufam, ze uz se jim to snad podari dodelat.

U me zatim jednoznacne vitezi tunel, jak z hlediska poctu hopu, tak z hlediska RTT. Navic je otazka, zda v budoucnu nedojde ke zmene IPv4 adresy.

ping + traceroute (posledni hop) na 192.88.99.1:
round-trip min/avg/max = 40.848/77.890/152­.809 ms
14 sl-bb1v6-bru-.sprintlink.net (80.66.128.67) 107.472 ms * 40.417 ms

ping + traceroute (posledni hop) na Amsterdam HE (byl vyhodnocen lepe nez Frankfurt pri tvorbe tunelu):
round-trip min/avg/max = 30.076/56.402/132­.404 ms
7 tserv11.ams1­.ipv6.he.net (216.66.84.46) 29.883 ms 32.599 ms 28.518 ms

Prosim o radu zkusenejsi. Mikrotik router jsem nakonfiguroval takto:

interface 6to4 add mtu=1280 name=ipv6-tunnel local-address=neco remote-address=192.88­.99.1 disabled=no
ipv6 address add address=2002:ne­co:neco::1/16 interface=ipv6-tunnel
ipv6 address add address=2002:ne­co:neco:1::1/64 interface=ether2 advertise=yes disabled=no
ipv6 route add dst-address=::/0 gateway=2002:c058:­6301::,ipv6-tunnel

Kdyz pak nastartuju PC, dostanu pridelenou IPv6 adresu a kdyz se snazim pingnout napr. ipv6.google.com, tak DNS mi AAAA zaznam da, PC odesila spravne ping na branu, ale dal to nedojde. Skoncim s Destination unreachable: Address unreachable. Ale kdyz se prihlasim pres ssh primo do Mikrotiku a zkusim ping tam, tak funguje.
Prekvapila me jedna vec. Kdyz zadam na Mikrotiku do default gw ::192.88.99.1 (jak je ve vsech navodech) tak nefunguje ani ping z Mikrotiku, ale s hodnotou 2002:c058:630­1::(jako je na poslednim radku me konfigurace) to jde.
Jedine, co me napada, ze by mohlo delat problem je, ze ether2 az ether5 rozhranni mam spojene do bridge a ze mezi mym PC a Mikrotik routerem jsou 2 AP. Ovislink 1120AP a jeste CC2204 nebo jak se ta noname potvora jmenuje. A jeste je mi divne, ze PC dostane gateway zacinajici fe80: a ne 2002:.
Nevite co s tim? Uz si pomalu myslim, ze tomu rozumim, ale stejne to porad nejde. Mam stejny uspech z Linuxu i Win (aspon vidite jak jsem zoufaly, kdyz jsem i rebootoval :))

Sem dej tohle:
ipv6 address add address=2002:ne­co:neco::1/3 interface=ipv6-tunnel
Neptej se proč, ale potom mi to začlo fachat. :-)
Pokud jako klienta máš Windows 7, Vista… je potřeba změnit preference prefixů.
netsh – interface – ipv6

viz: http://wiki.mikrotik.com/wiki/Setting_up_an_IPv6_tunnel_via_6to4

/3 u adresy se mi nezda. Byva 2000::/3 jako vychozi cesta, protoze ne komplet celej rozsah IPv6 je aktualne urcenej k pouzivani, takze ::/0 se nepouziva.
Adresa na 6to4 interfejsu by mela byt /16. A 192.88.99.1 jako brana byt muze, jen tam taky musi by interfejs, takze gateway=::192­.88.99.1%ipv6-tunnel (starsi verze maji jako oddelovac „,“, novejsi „%“).
A jinak by to melo jet. Jestli klient pingne 2002:neco:neco:1::1, tak by se mel dostat i dal, RouterOS ve vychozim nastaveni nic neblokuje. A brana jako fe80:neco je normalni, radvd hlasi linkovou adresu.

Nastavím na /16 = nejede, nastavím na /3 jede. Takže asi tak. Nechávám to ve funkčním stavu, jako je to ve WIKI. Route OS 5 beta3.

Tak bohuzel nepomohlo. Napada me uz akorat to, ze to opravdu neprojde pres ta APcka.

neprojde, pokud nebudes mit mezi s sebou radia v cistem bridge rezimu (napr. za pomoci WDS), podle toho co pises pouzivas rezim kteremu se nekdy rika pseudo-bridge (vicero IP adres schovano za jednu MAC adresu radia), v tomto rezimu IPv6 pakety neprojdou, minimalne u Mikrotika – udajne jde o jeden z limitu toho pseudo-bridge rezimu… adresy si koncovy pocitac vzit dokaze protoze to jde pres tusim pres multicast…

Mas pravdu, je to tak. Ovislink mam v rezimu Client Infrastructure a WA-2204A je v rezimu AP. Alespon jsem se naucil vzdalene odchytavani paketu na Mikrotiku. Opravdu tam IPv6 pakety nedojdou. Prolezou jen jednim smerem.

Bohuzel je AP na chodbe a nepouzivam ho jen ja, takze ho nemuzu prestavit do rezimu bridge. Sice umi point-to-multipoint, takze kdyby vsichni presli do rezimu bridge, fungovalo by to, ale to nemuzu po sousedkach chtit. A obsluhovat klienty i v rezimu bridge predpokladam WA-2204A neumi. Takze smula. Az nebude zbyti, tak se to nejak vyresi. Do te doby budu holt IPv6 disabled.

V článku to vypadá, že skutečně neexistuje více user-friendly cesta, než komplikované používání /sbin/ip a výpočty adres. Není tomu tak.
Na RedHatoidních systémech (Fedora, CentOS, Mandriva, nejspíš i další) je zprovoznění 6to4 otázkou zásahu do jednoho konfiguráku, konkrétně /etc/sysconfig/net­work-scripts/ifcfg-$rozhrani, kde $rozhrani je to, přes které chcete 6to4 provozovat. Tedy například do /etc/sysconfig/net­work-scripts/ifcfg-eth0 je třeba přidat:
IPV6INIT=yes (pokud to tam ještě nemáte)
IPV6TO4INIT=yes
IPV6TO4_IPV4AD­DR=a.b.c.d (jen pokud jste za NATem a tudíž se vaše externí adresa a.b.c.d neshoduje s tou na rozhraní)
Po restartu rozhraní (ifdown eth0; ifup eth0) se vám objeví nakonfigurované rozhraní tun6to4, přes které pak stačí natáhnout routu, například pomocí
IPV6_DEFAULTDEV=tun6to4 v /etc/sysconfig/net­work
Detaily najdete v /etc/sysconfig/net­work-scripts/ifup-ipv6 (hlavně možnost nastavit MTU)