Názory k článku Severní Amerika bez IPv4 adres: ARIN hlásí „zero“
-
Ondřej CaletkaZlatý podporovatelŽádné takové pravidlo neexistuje.
Jednak je k získání adres potřeba nějaký smluvní vztah (například členství v RIPE NCC), který zadarmo není, takže ty adresy úplně zdarma nejsou.
Dále pak nikde není psáno, že přiřazování (assignment) adres zákazníkům (což není totéž co prodávání - je to pouze určení účelu použití dané adresy) nemůže být zpoplatněno. Dokonce ani opravdový prodej, tedy převod alokací z jedné osoby na jinou, není zapovězen, jen je zatížen několika omezujícími podmínkami.
-
Petr StehlíkZlatý podporovatelJen aby se naši ISP nebránili slovíčkařením, že nesaleují, ale rentují za měsíční poplatek...
-
Ondřej CaletkaZlatý podporovatel
Vytrháváte z kontextu. Uvedená citace je odpověď na otázku: „Can I buy IP addresses from the RIPE NCC?“
Navíc jde pouze o informativní sdělení, nikoli závazný předpis, ten má v současné době jméno ripe-649. A ten předpis rozhodně nezakazuje požadovat úplatu za pronájem IP adres. Stejně tak to platí i pro placení za převody adres mezi členy, tedy nákup a prodej adres. -
Ondřej CaletkaZlatý podporovatel
Tohle by byl validní argument, pokud by skutečně existoval operátor, který by IPv6 zprovoznil pouze za měsíční příplatek*. Ale o žádném takovém nevím, většina nemá IPv6 vůbec, ti co ho mají ho naopak dávají zdarma všem a platí se maximálně za statickou alokaci IP prefixu.
Ono to taky nedává smysl, aby operátor, který IPv6 zavede toto nenabízel všem svým zákazníkům bez příplatku. Zavedení IPv6 je především v zájmu operátorů, zákazníky to obvykle nezajímá.
*) Pouze si vzpomínám, že se tak v raných fázích se tak chovala O2, ale velmi rychle tento přístup opustili.
-
petr_p (neregistrovaný)
Že by O2 dobrovolně odháněla potenciální zákazníky, když v ceníku na straně 15 stále tvrdí, že za 64bitový prefix chce 119,79 Kč měsíčně?
-
Ondřej CaletkaZlatý podporovatel
To je platba za pevný prefix, tedy pokud si přejete, aby se vám za žádných okolností nezměnil. Možnost získání dynamického prefixu je v ceně všech xDSL přípojek od O2, stačí mít jen kompatibilní koncové zařízení.
O účelnosti a oprávněnosti takové částky se dá pravděpodobně pochybovat, rozhodně to ale neznamená, že by takovou částku bylo nutné zaplatit pro aktivaci IPv6 na přípojce.
-
Stan (neregistrovaný)
Teď jsem si pronajal dedikovaný server v USA. V ceně mi vnutili /29 subnet ipv4, ale ani jednu ipv6. Takže je nějaký nedostatek asi fakt nepálí.
Naopak čeští 4smart.cz mají celkem pěkný systém mapování portů a reversních proxyserverů, takže VPS se u nich velice dobře bez ipv4 obejde.
-
Jenda (neregistrovaný)
(nepoužívám to) Protože nemají dost IP adres (IPv4 ti pronajmou za 40 Kč měsíčně, což může být víc, než kolik stojí celá VPS), dají ti server za NAT, a umožní ti nastavit si port forward a na jejich HTTP proxy nastavit aby provoz pro nějaký host předávala na tvoji VPS za NATem.
-
Ondřej CaletkaZlatý podporovatel
Úplně stejně, jako se rozlišují virtuální servery u Name-based virtual hosts. Je to opravdu velmi elegantní způsob, jak adresy ušetřit.
Podobnou službu nabízí CloudFlare, kdy backend server můžete mít IPv6 only a CloudFlare vám mimo jiné přidá IPv4 konektivitu, takže vy už ji na svojem serveru nepotřebujete.
-
Ondřej CaletkaZlatý podporovatel
4smart pokud vím HTTPS nepodporuje. Pokud by podporoval, skutečně byste mu musel dát privátní klíč. Což není tak hrozné jak to zní, když uvážíme, že všechny u nich hostované virtuály jsou OpenVZ kontejnery, takže root na hostitelském stroji přímo vidí veškerá data všech virtuálů. Tedy není to žádné narušení bezpečnosti proti běžnému stavu.
U CloudFlare to funguje tak, že jim musíte nadelegovat doménu druhého řádu a hostovat u nich DNS. Oni vám pak zdarma obstarají DV certifikát. Samozřejmě, u CloudFlare je veškerý obsah rozšifrován a případně znovu zašifrován na cestě k vašemu serveru, ale opět to není o nic horší než jejich standardní služba. Ostatně, dáváte jim celou doménu, takže jim musíte důvěřovat, že neprovedou nic špatného.
-
Petr M (neregistrovaný)
Za dobu existence IPv6 už ten hardware dožil několikrát.
ISDN-ADSL-ADSL2-VDSL
802.1 standardy a rozšíření z 2,4GHz na 5GHz a výš
Optika z 1Gbps na 100Gbps, začíná 400Gbps
GPRS-EDGE-...-LTETakže tohle jako argument neberu. To by vedlo akotát na ContinentalNAT, CorporateNAT, National NAT, CityNAT,...
Co konečně přestat s kryplením a občůráváním a dělat věci pořádně?
-
Ondro (neregistrovaný)
Ten hardware nedozil niekolko krat. Mam kvalitny plne funkcny ADSL2+ router bez IPv6 a na kabloch, co su vedu ku mne nic rychlejsie(VDSL) nebude fungovat a preco by som ho mal menit. Takych je kopa.
Vo firme mam switche, ktore nam plne dostacuju a IPv6 podporuju len ciastocne. Preco by som ich mal menit. Takych bude tiez kopa.
Pridajme k tomu SW, ktory nepozna alebo ma problem s IPv6.Kolko zariadeni naozaj poriadne zvlada IPv6? Vela z ich ma len papierovu podporu alebo im chyba podpora urcitych vlastnosti IPv6.
IPv6 nepovazujem za vec, ktora bola urobena poriadne. IPv6 je zastaraly protokol s vyhodou "neobmedzenenho" poctu IP adries.
-
Sten (neregistrovaný)
To by mě zajímalo, jak se vám povedlo koupit ADSL2+ router v roce 1998, když ADSL2+ je o rok mladší. A stačí vám ve firmě ty 100 Mbps switche?
Btw. asi jste nikdy neslyšel o 464XLAT. To je technologie, která umožňuje provozovat IPv4-only aplikace v IPv6-only sítích. Běží na tom třeba mobilní síť T-Mobile US.
IPv6 má mnoho optional features, které většinou musí umět jen end nodes, které je chtějí využívat. Zařízením po cestě mohou být ukradené, a tak je neumí.
No vidíte, a naprosté většině lidí, kteří IPv6 kritizují, naopak vadí, že IPv6 se nedrží toho, jak fungovalo IPv4, ale dělá spoustu věcí jinak.
-
Petr M (neregistrovaný)
No, doma mám taky switche a IPv4 projde v pohodě. I co jsem zkoušel L2 s IPv4 managementem od TPLINKu, kde není o IPv6 ani slovo, není sebemenší problém. Možný tak WiFi APčka, nevím, já mám WiFi na routeru s OpenWRT a tam to s IPv6 šlape jak hodinky. I klasický APčka se mění podle standardu a přidávají se pásma, takže tam je životnost postatně menší, než u drátovýho swiště. A kolika BFU měnilo krabky třeba UPC v rámci jejich hotspotové akce a zrychlování provozu? Byl problém jim ta hoit 6ku? (UPC u nás nemá natahaný dráty, nevím, jestli to udělali nebo ne)
Linux bez problémů, Widle XP s doinstalací protokolu ručně, vyšší nativně.
Sr..ky jako Skype se dají protunelovat...
A IPv6 není horší, je jiný... Mám víc IP adres a veřenou IP může mít třeba i vyhřívání prkýnka na WC, takže na jednu stranu jsou na něho větší nároky ohledně bezpečnosti, na druhou stranu odpadne šmíruňkzrcadlo na serveru 3. strany, když s ním chci komunikovat... :D TSL+IPv6, vlastní klíče a trhněte si nohou.
Btw. "kvalitní router" je cedník od ZyXelu?
-
Filip JirsákStříbrný podporovatelSamozřejmě, že poskytovatelé obsahu klidně IPv4 vypnou, i když přes něj budou mít daleko větší provoz, než 5 % – pokud se jim to vyplatí. Stejně, jako vypínají podporu třeba pro slabé šifry v HTTPS.
-
SB (neregistrovaný)
A jak si na tom ten router ADSL stojí s bezpečností? Kdy měl naposledy měněn firmware z důvodů bezpečnostních chyb? Já bych byl s tou kvalitou a funkčností opatrnější. Mimoto jsem ještě neviděl žádné kvalitní krabičky 9v1.
Čistým switchům (L2) je u otvoru, co přes ně leze, na administraci vám zůstane dualstack.
Může být něco lepšího než IPv6, ale nic takového asi není (ne, IPv4 to fakt není).
-
Ondřej CaletkaZlatý podporovatel
K odložení problému došlo v roce 1993 zavedením CIDR, podařilo se odložit problém o 22 let. Myslíte, že dalších 5 až 10 let by něco zásadním způsobem změnilo?
-
Ano, napriklad sa poriadne utrasu rozne sluzby, vyhodia sa vylozene nezmyselne navrhy a mozno sa zavedu nejake nahradne tym spravnym sposobom - implementaciou resp. ignoraciou zo strany tvorcov softveru a hardveru. Napriklad ostatne tri roky znamenali velky pokrok. Este aspon dalsie tri roky a mohlo by to byt realne pouzitelne tym, ze sa spravi uzitocny subset vlastnosti IPv6 a tie zvysne pojdu do zabudnutia.
-
Ondřej CaletkaZlatý podporovatel
Ale proč ty poslední tři roky znamenaly značný pokrok? Právě proto, že IPv4 adresy začaly docházet. Kdyby se nějaké další IPv4 adresy uvolnily, veškerý pokrok to zase zamrazí, protože použití IPv4 bude zase jednodušší.
-
Filip JirsákStříbrný podporovatel
Protože někteří lidé holt špatně snáší, když se někdo snaží, aby věci fungovaly správně – mají raději své teplo a smrádeček, na který jsou zvyklí, a doufají, že jim to ještě nějak vydrží.
-
To nie su ani zeleni aktivisti, to je nieco este ovela horsie. Vid: "Protože někteří lidé holt špatně snáší, když se někdo snaží, aby jejich duše neskončila v pekle – mají raději své teplo a smrádeček, na který jsou zvyklí, a doufají, že jim to ještě nějak vydrží."
Zjavne tito IPv6 evangelizatori nechcu nic ine, len nase dobro a my sme proste hlupi, ze to nechapeme.
-
Petr M (neregistrovaný)
Tady nejde o dobro a zlo.
Pokud mám na výběr ze dvou možností, kde ani jedna není ideální, volím tu lepší. Tzn. s lepší perspektivou do budoucna a s míň občůrávkama. Věci by se totiž neměly dělat složitější, než jsou,
No a tady nastupuje jeden detail. Když chci zvolit lepší možnost, tak se najde vždycky banda zabedněnců, která dělá všechno pro to, aby mě natlačili do horšího řešení jenom proto, že "my to nechceme", "my to nepotřebujeme", "do teď to šlo bez toho",...
Raděj, než by prostě ISP zapli IPv6 v síti, se budou drbat s CGNATem, jeich zákazníky nuti bojovat s maškarádováním, DynDNS, budou zápasit s nemožností šifrování hlaviček, logovat přidělení IP adres za NATem pro úřady, ...
A na čem asi roste třeba M$ Azure? Na tom, že se napřímo nedá komunikovat, tak nabídli (pro spotřebitele) jednu zmála možností, jak jim můžou přístroje spolupracovat a (pro korporáty a vlády) prostředí, kde jde analyzovat komunikaci hraček BFU ve velkým a (pro vývojáře) celkem jednoduchý framework... S IPv6 by jim podstatně ubylo zákazníků.
-
S tym, ze nejde o dobro a zlo jednoznacne suhlasim. Prave preto neznasam prispevky evangelizatorov, ktori predostieraju ich aktualnu vieru za tu jedinu pravdivu.
Realny svet (a teda ani svet IT) nefunguje na bud alebo. Kludne moze spolocne a prakticky nezavisle fungovat IPv4 aj IPv6. Nechajte na ludoch, nech rozhoduju (v konecnom dosledku svojimi penazenkami), co chcu pouzivat. Su ludia, co budu silou mocou tlacit na dalsie pouzivanie IPv4 a tak isto budu existovat ludia, ktori budu tlacit na rozsirenie IPv6. Kym tym neobmedzuju tych druhych, je to fajn. Nechajte preto tu druhu skupinu na pokoji, nech si zije ako chce. Ako zastanca anarchokapitalizmu mam na tuto problematiku dost jasny nazor.
My sami napriklad teraz v nasom novom produkte pouzivame vyhradne IPv6 na internu komunikaciu. Ale to neznamena, ze teraz budem hejtovat ludi, ktori su stale ochotni investovat do IPv4 rieseni. Nakoniec aj tak rozhodne trh.
Ako embedded vyvojar mam na obe technologie vlastny nazor. Kazda ma svoje plus a minus a zalezi len od metriky, ktoru clovek pouzije. V niektorych aspektoch je IPv4 skvela a IPv6 odpad, v inych je to naopak. Preto ma tak vedia vytocit prispevky, ked tu ludia zacnu hulakat, ako je IPv6 vseliek na vsetko, lebo to zdaleka nie je pravda.
Preto aj dufam, ze sa IPv6 este utrasie, lebo je tam hromada nesystemovych blbosti, ktore su tak extremne specificke, ze by v ziadnom pripadne nemali byt sucastou nizkourovnoveho protokolu, ale riesit sa az na vyssich vrstvach.
-
Petr M (neregistrovaný)
No ona je hlavní výhoda IPv4 v tom, že blokuje trh. Když přijdu s novým výrobkem, který potřebuje být online a nemám kapitál na servery (a brzo i poměrně tučnou pálku na veřenou IP pro ně), tak je to hendikep proti molochovi s vlastí infrastrukturou a serverovou farmou, kde prostě jenom osadí další skříň, vymění kartu v routeru za rychlejší a na ročním rozpočtu to hodí jenom pár promile rozdíl.
Kdo chce, ať si používá IPv4 (na management a starý věci,...), ale nesmí to být jediný protokol dostupný v síti.
-
SB (neregistrovaný)
Máte recht, čtyřkaři nechť si nechají čtyřku, šestkaři šestku (která má taky chyby).
Opravdu jste zastáncem tohoto??? Root není místem pro rozbor vaší osobnosti, ale musím přiznat, že mě vyděsilo, že existuje ještě něco horšího, než je neoliberalismus. -
Honza (neregistrovaný)
Nebo ještě lépe, IP45 :D
http://www.fit.vutbr.cz/research/pubs/index.php.cs?id=10785 -
Ondřej CaletkaZlatý podporovatel
Jak určíte, kdo adresy potřebuje a kdo ne? I kdybyste všechny IPv4 adresy světa sesbíral a přerozdělil, stejně vám nevystačí na všechna současná internetová zařízení a to ještě vůbec neuvažujeme přepokládaný růst, jako třeba IoT.
-
Petr M (neregistrovaný)
Právě kvůli těm hračkám je public IP nezbytnost, bez ohledu na protokol. Budu dělat třeba elektronickýho vrátnýho s kamerou.
Pokud bude za NATem a zákazník chce zvonění do 1s a navázání komunkace s kamerou do 1s, tak i mobil i vrátný musí pinkat min. 1x za sekundu na server, jestli je tam požadavek druhé strany, autorizovat se,... A při požadavku na bezpečnost navíc s šifrováním a autentizací. Prodej v 10 státech, všude v průměru 20 000ks. To je 400 000 pingů/s (pokud budou spárovaný k baráku dva mobily, tak 600 000pingů/s) a musím mít odpovídající infrastrukturu (v každým z těch 10 států nějaký rack v datacentru s připojením na páteřní lajny,...).
Bez NATu zazvodí návštěva, pošle se na public IP aplikace v mobilu zpráva,... Chci se podívat ke dveřím, pustím appku, ta si z veřejné IP vyžádá video stream... A bez pinkání, bez sříně v datacentru.
Takže pokud chchi decentralizovaný řešení bez serverů, můžu použít IPv4, ale tam je na dnešní dobu moc málo volných adres na takový kšeft a navíc nepodporuje mobilitu klienta, takže bych se musel s mobilním klientem přihlašovat po každé změně sítě (přepnutí z LTE na WiFi,...)
Nebo můžu použít IPv6, kde je nejenom dostatek IP adres, ale dokonce je i podpora pro mobilitu, kde má zařízení několik IP adres a na jeho "domácí" IP adresu se protuneluju kamkoliv v rámci standardního řešení.
Nebo snad existuje kromě Public 4, Public 6 a Server nějaký čtvrtý, kouzelný řešení?
-
Petr M (neregistrovaný)
Nejde o zavření spojení. Problém NATu je v tom, že zvenku se na zařízení nedá dostat. Přijme paket zevnitř, zapamatuje si, od koho byl a pošle ho se svou hlavičkou. Pak si zase najde, od koho byl požadavek a předá mu odpověď a smaže záznam. Pokud pošlu z mobilu nebo z PC v práci povel "vypusť na tchýni pitbula", tak mám smůlu, NATem ten paket neprojde. NAT jednoduše neví, komu ho předat. Jedině zámku od kotce nechat zprávu na domluveným místě a doufat, že se zámek na tu zprávu mrkne dřív, než za sebou tchýně zavře dveře od baráku.
V praxi pak
- 99% komunikace probíhá jenom proto, aby zařízení bylo v obraze
- místo poslouchání ve stand-by a občasné synchronizace s WiFi se komunikuje trvale, u IoT na baterky a s WiFi je to zatím neřešitelný problém (ostatně, pinkání na server z aplikace na mobilu taky výdrži na jedno nabití nepřidá)
- překlenout NAT použitím dedikovanýho portu nejde bez spoluúčasti ISP (konfigurace NAT+Firewall), provozovatele služby (nastavení portu a IP) a klienta (konfigurace routeru).
- U mobilu má podstatný vliv nejenom na baterku, ale i na FUP
- Nutná podpora infrastruktury - servery poskytovatele služby, možnst sledování, SPoF pro celou oblast
- Zatěžuje zbytečně páteřní lajny - pokud si odběhnu do hospody v síti stejnýho ISP, tak stejně jdou požadavky x stovek km do jeho serverovny a zpátky - a nejenom moje požadavky... IPv6 by se odbavilo v rámci ISP. -
Obávám se pane, že o sítích toho moc nevíte a plkáním takových nesmyslů děláte IPv6 medvědí službu.
V praxi to funguje tak, že mobil (za NATem) naváže spojení se serverem (s veřejnou IP adresou) a toto spojení udržuje. Totéž udělá zámek od kotce. Pokud chce mobil komunikovat se zámkem, pošle zprávu na server a ten jí přepošle tím otevřeným spojením zámku - a naopak. Žádné "pinkání" není potřeba. Jediná nevýhoda je, že data nechodí přímo, ale delší cestou přes server.
Jinak, na přímé připojení zvenčí stačí jedna veřejná IP adresa pro celou domácí síť. A ta se u slušných ISP většinou dá zařídit. Svůj domácí router máte v moci, na jeho konfiguraci součinnost ISP nepotřebujete.
-
Petr M (neregistrovaný)
"V praxi to funguje tak, že mobil (za NATem) naváže spojení se serverem (s veřejnou IP adresou) a toto spojení udržuje. Totéž udělá zámek od kotce. Pokud chce mobil komunikovat se zámkem, pošle zprávu na server a ten jí přepošle tím otevřeným spojením zámku - a naopak"
Takhle to funguje na aplikační vrstvě, naprosto transparentně. Pod tím to chodí tak, že zámek kotce má IP 192.168.1.100, NAT to přeloží na svou adresu, řekněme 50.100.150.200 a pošle požadavek na otevření soketu na server 100.110.120.130.
Server 100.110.120.130 eviduje u spojení adresu 50.100.150.200, se kterým komunikuje. Namá šanci vidět, že je to ve skutečnosti spojení se zámkem. Kdyby server rovnou poslal v rámci spojení data na NAT, nedojde to nikam.
"Jinak, na přímé připojení zvenčí stačí jedna veřejná IP adresa pro celou domácí síť. A ta se u slušných ISP většinou dá zařídit. Svůj domácí router máte v moci, na jeho konfiguraci součinnost ISP nepotřebujete."
Jo, ale IoT má být pro lamy. Pokud bude něco potřeba rozvrtat v routeru, tak to bude v pr... Zkuste vysvětlit, že na ZyXelu se nedá použít návod pro OvisLink, nutit lamu k tomu, aby se hádal s ISPíkem, protože "ta krabička chce nějaký heslo"... A WiFi sítě za CGNATem jsou kapitola sama pro sebe...Už vidím to maškarádování na CGNATu.
-
SB (neregistrovaný)
„...naváže spojení se serverem (s veřejnou IP adresou) a toto spojení udržuje.“ Zapomněl jste upřesnit, jak klient se serverem udržuje spojení.
„...na přímé připojení zvenčí stačí jedna veřejná IP adresa pro celou domácí síť.“ Zde jste pozapomněl na administraci síťových prvků po cestě, často netriviální.
-
j (neregistrovaný)
Obavam se, ze kulovy vis leda ty. To spojeni je treba udrzovat orevreny => ta krabka musi byt neustale aktivni na siti. Pokud neni, neni ani zadny spojeni. Keepalive je pro tebe zjevne sprosty slovo ...
Kdyz krabka jen posloucha, tak staci kdyz je v nejakym sleep rezimu, a probudi se az v reakci na prichozi komunikaci.
A ad jedna IP ... jasne, on si kazdej jeden BFU bude konfigurovat porty, kdyz ani nevi co to je. Nemluve o tom, ze IPcek neni dost ani pro ty domacnosti.
-
SB (neregistrovaný)
Obávám se, že z vaší pozice můžete těžko určovat, čemu ještě stačí neveřejná adresa a čemu už ne.
Dovoluju si připomenout starší zajímavý článek o využití IPv6. -
Petr M (neregistrovaný)
"O IPv6 nikdo nestojí, přotože nepřináší nic nového, jen že to po vynaložení nějakých pěnez bude fungovat snad jako dosud." Japato? Máte důkaz?
Lepší multicast (mistrovství v hokeji bez sekání) - viz RFC2464
Můžu si povídat se zařízením na cestách (výhoda právě pro IoT) - viz RFC3775, RFC3776, RFC6275
- zmizne ten zavšivený NAT
- zjednoduší se routovací tabulky pro BGP, protože se dá hierarchicky členit podle geografických jednotek
- lidi budou mít fungující Internet, ne náhražku (tuhle jeden známý fňukal, že má doma jedno PC, chtěl hrát online gamesu a nedovovlilo mu to přihlášení, že limit 20 lidí z jedné IPv4 je vyčerpaný)Momentální situace je takováto:
- Operační systémy (Mac, Linux, Widle >XP) nemají s IPv6 problém
- Hardwarově není problém
- Open firmware (OpenWRT, DD-WRT,..) nemá problém
- Čínský firmware má většinou problém (ale ten někdy nedává ani IPv4)
- Některý aplikace jsou zprzněný tak, že IPv6 nedokážou používat (dobře jim tak)
- BFU o IPv6 nic neví a neřeší to.
- Osvícenější uživatel to přestane řešit v okamžiku, kdy zjistí, že by to znamenalo zahodit teprve desetiletý router za litr, nebo si pohrát s OpenWRT.
- ISP by musel updatovat firmware a někdy i hardware, za pětikilo měsíčně od uživatele se mu do toho kupodivu moc nechce.
- Ajťáci od ISP by se museli učit zase něco novýho (stejně tomu neutečou, jenom za pár let to do té hlavy poleze ještě hůř)
- Provozovatel starých služeb je rád, že nedostatek IPv4 omezuje konkurenci
- Provozovatel nových služeb nemá sílu na to, aby cokoliv prosadil
- Webhosting má vlastní řešení žonglování s portama a DNS, který bere jako konkurenční výhodu, investoval do něho love a nechce investici nechat vyletět oknem,
- Stát ani EU nijak (ne)používání IPv4 ani IPv6 nereguluje.Tak to vypadá jak to vypadá... Jo kdyby EET byla jenom na IPv6 nebo zavedli daň z NATu, to by byl najednou fofr... :D
-
Petr M (neregistrovaný)
Těžko pochopit a nezabřednout do konspiračních třípísmenných teorií... Spokojme se s imbecilitou jako univerzálním vysvětlením.
RFC1631:
Privacy, Security, and Debugging Considerations
Unfortunately, NAT reduces the number of options for providing security. With NAT, nothing that carries an IP address or information derived from an IP address (such as the TCP-header checksum) can be encrypted. While most application-level encryption should be ok, this prevents encryption of the TCP header.
Známo od r. 1994...
-
hugochavez (neregistrovaný)
@Petr M
zas takova konspirace to byt nemusi= IPv6 v puvodnim navrhu napr. mela trafik defaultne sifrovat - to potom ze specifikaci jakymsi zahadnym zpusobem vypadlo (a nikdo neumi vysvetlit proc). Uz samotny koncept ze by jednotliva zarizeni mela vzdy verejnou IP (ci jich dokonce nekolik) a navazovala spojeni P2P stylem (a nedejbuh jeste sifrovane) musi byt nocni murou vsech tajnych sluzeb... :o)
Navic je znamy problem ze 2 bittorrent klienti za NATem (obzvlast tim agresivnim) "se nevidi" cili si toho moc nevymeni, zarizeni za NATem muze "oslovit" pouze klienty kteri jsou "verejne na netu videt"= maji verejnou IP (pripadne se jim povedlo donutit sveho IP k portforwardu coz je spise vzacnost nez pravidlo) Nevim o klientovi ktery by delal tzv.relay server jako to umel v zacatcich Skype ci SIP VoIP.....
IPv6 by tohle spolehlive vyresila, ovsem Hollywood by z toho urcite nadsenej nebyl, tim spis ze uz dnes spousta Bittorrent klientu dokaze jet "trackerless" a spolehaji se (s pomerne dobrymi vysledky na DHT ci PEX. A "honit mravence po lese" je jaxi neefektivni :o) -
Sten (neregistrovaný)
IPv4 NAT je typicky stavový (více IP adres se mapuje na jednu, takže si ten, kdo mapuje, musí pamatovat, komu patří jaký port), IPv6 NAT je nestavový (site-wide: vymění se jeden prefix za jiný, druhá půlka adresy je pořád stejná). Nestavový NAT je mnohem méně omezující. Přesto se i tento NAT týká jen velmi malého množství případů, typicky multi-homing sítí.
-
Lebo mozno ma firma pobocky (alebo nejake zariadenia) po celom svete na sietach roznych providerov s roznymi podmienkami. Ak uvazujeme, ze teda vsade dostane firma aspon ten /64 prefix, tak proste vnutorna siet bude mat adresovanie z VPNky so spolocnym prefixom pre cely svet, s dalsim logickym delenim a smerom von pojdu vzdy cez prefix, ktory im provider prideli.
Ano, je vela moznosti, ako to zriesit inak, od roznych IPv6 moznosti az po pouzitie dvoch IP adries, ale naco si to cele komplikovat?
-
Sten (neregistrovaný)
Taková typická situace je multi-homing. Máte více ISP s více různými veřejnými IPv6 prefixy. Uvnitř sítě použijete ULA (lokální) adresy a podle toho, přes kterého ISP to zrovna jde ven, to přeložíte do patřičného prefixu. Výhodu to má ve chvíli, kdy jeden ISP vypadne a je potřeba udělat rychlý failover (jde udělat faliover pomocí RA, ale to není tak super rychlé a problém je i s tím, že se celá síť přečísluje).
-
Filip JirsákStříbrný podporovatel
problém je i s tím, že se celá síť přečísluje
Myslím, že u IPv6 se počítá, že zařízení budou mít více IP adres. Takže ta zařízení by spíš měla mít alespoň 3 IP adresy (lokální a od obou ISP) a při výpadku jedné linky se pouze do sítě oznámí změna routeru. IP adresy tedy zařízením zůstanou, pouze začnou preferovat jiný router a tím pádem i jinou odchozí adresu. Mělo by tak fungovat i přehození na jinou linku bez výpadku – nová spojení se začnou navazovat přes druhou linku, ale stávající spojení se dokončí na té první (protože zařízením ty IP adresy zůstanou). -
Santiago (neregistrovaný)
> IP adresy tedy zařízením zůstanou, pouze začnou preferovat jiný router a tím pádem i jinou odchozí adresu.
Je casty omyl spojovat default router s pouzivanou odchozi adresou. AFAIK ale specifikace takove chovani nepredepisuje. Klient ma proste seznam prefixu a seznam default routeru, kde jak prefixy tak default routery timeoutuji zvlast. Preference jednoho default routeru neznamena pouzivat 'jeho' prefixy. Vytimeoutovani default routeru neznamena prestat pouzivat adresy jim pridelene.
Postupny prechod na druhou linku tim jde zaridit, akorat router (ci routery) musi korektne routovat i podle zdrojove adresy. Stejne tak zmena prefixu pri precislovani. Ale neni to vhodne reseni pro okamzitou zmenu uplinku v pripade vypadku primarni linky. Tam by bylo treba okamzite vytimeoutovani prefixu asociovaneho s primarnim uplinkem, ale to taky moc dobre nejde (Valid lifetime neni obecne akceptovan mensi nez 2 hodiny, maximalne je mozne ty adresy okamzite udelat deprecated). Takze prakticky je ten NAT66 pro tenhle case asi nejlepsi reseni.
-
Filip JirsákStříbrný podporovatel
Nevadí, že specifikace takové chování nepředepisuje. To chování je logické. Např. linuxové jádro se takhle pokud vím chová - pokud nejsou určena zvláštní pravidla, zdrojová IP adresa se nastavuje podle routovací tabulky (tj. ne nutně podle výchozí brány, ale podle sítě, se kterou chci komunikovat).
-
Santiago (neregistrovaný)
Zaprve, v pripade heterogenni site tezko spolehat na to, ze konkretni implementace se chovaji nejak nad miru danou specifikaci.
Zadruhe, z implementacniho hlediska i z hlediska toho, jak je psane RFC 4861, to chovani logicke neni. Ten text je vcelku jasne formulovan tak, ze ruzne zaznamy z RA se zpracovavaji nezavisle (router list, prefix list), takze nema moc smysl si tu informaci (od ktereho routeru je tento prefix) vubec pamatovat. Nehlede na to, ze ty propagovane prefixy nejsou primarne kvuli autokonfiguraci, ale kvuli urceni toho, ktere adresy jsou onlink, takze pri korektni konfiguraci routeru by kazdy router na lince mel propagovat vsechny prefixy, ktere se na te lince vyskytuji, ne jen 'kazdy svuj prefix'.
Zatreti, Linux voli zdrojove adresy podle routovaci tabulky v IPv4. Co se tyce IPv6, tam AFAIK Linux pouziva primocare chovani dle RFC 3484, tedy sekvencni sada pravidel v zasade koncici vyberem podle longest matching prefix, kde 'dostupnost routeru propagujiciho dany prefix' nehraje roli (krom pripadu, kdy host sam ma vic interfacu, ale to neni ten use case, ktery tu resime).
-
j (neregistrovaný)
IPv6 ma spoustu vyhod - predevsim pro uzivatele. Pro ISP to zadne zasadni vyhody nema, pro ne to znamena dalsi konfiguraci v siti.
Procpak si i BFU zprovoznujou 6tkovy tunely treba za ucelem pouzivani torrentu? Protoze pak skutecne p2p komunikace funguje. Jen po ne zcela optimalnich trasach.
-
Santiago (neregistrovaný)
> Lepší multicast (mistrovství v hokeji bez sekání) - viz RFC2464
Multicast ma mnoho praktickych problemu, IPv6 multicast sice oproti IPv4 multicastu par (jednodussich) odstranuje, ale ty vyznamne porad zustavaji.
> zjednoduší se routovací tabulky pro BGP, protože se dá hierarchicky členit podle geografických jednotek
To se realne pouzivat nebude. Jednak sitova topologie neodpovida geografickym jednotkam a jednak se od jakekoliv agregace nad urovni AS spis upousti kvuli bezpecnosti (zabezpecujici technologie jako RPKI a BGPSEC jsou nekompatibilni se super-AS agregaci, AS-SET v BGP jsou deprecated). Vyhoda je tak akorat v tom, ze kazde AS bude mit v globalnich tabulkach jen par velkych prefixu a ne mnoho malych.
