Zpusob me argumentace je umerny tomu, co pada z druhe strany. Nicmene pokud Vam to udela radost, zkusim konstatovat: Ano, IETF je banda pitomcu, IP je silene zmatlany protokol a pouze Vase genialita a genialita lidi, ktere pripadne oznacite, muze zachranit IPv6 od stejneho osudu. Oooo velky Mogule.
Pokud ano, je mozne, ze se jistym nesmazatelnym zpusobem zapsal do historie, ale asi Vas zklamu - pokud udelam jeden pocin, fine, ale pokud z toho hodlam zit a pobirat slavu cely zivot (jako spousta akademiku), tak to je princip, ktery se mi prici... clovek je tvor tvorivy, mate-li pocit, ze tvorivost jedne lidske entity konci s jednim resenim, nebudeme si v tomto rozumet...
A stejně tak i většina dalších protokolů přenášených pomocí IP paketů.
IPv6 by si mělo přestat hrát na porty
IPv6 si na porty přestat hrát nemusí, protože si na ně hrát ani nezačalo. V tom se od IPv4 nijak neliší. Porty jsou záležitostí protokolů vyšší vrstvy - a to ještě jen některých - a IPv6 vůbec nezajímají.
Problém je v tom, že normální lidi toho o TCP/IP obvykle moc nevědí, takže jsou schopni psát věci typu: "Zkoušel jsem na ten počítač ping na port 80 a taky to nešlo." (skutečný citát). Že jsou pro ně IP porty srozumitelnější, mne proto příliš nepřekvapuje. Čím méně toho člověk ví, tím je život jednodušší…
Zjistěte si třeba co dělá tnsping (oraclovská utilita, ověřuje dostupnost db, běží nad TCP), případně arping (ověřuje dostupnost hostů pomocí ARP requstů). Jste asi první, komu ten název vadí.
Čím méně toho člověk ví, tím je život jednodušší…
..a tím více má zapotřebí hledat u druhých formální chyby.
Tak to je smutné že neshledáváte a přesto nás tady poučujete, jak tomu Internetu vlastně vůbec nerozumíme. Navíc vězte, že ten člověk to takhle nemyslel…
Možná jste to přehlédl, ale nepranýřoval jsem vás za TCP/IP, ale za skutečně podstatné neznalosti fungování protokolů z této rodiny a jejich implementace. Takže vás pro změnu prosím, abyste si na toto téma něco málo nastudoval a pak se můžeme začít bavit o tom, co by šlo nebo nešlo vyřešit lépe. Ono je totiž dost naivní snažit se vylepšit něco, co ve skutečnosti moc dobře neznáte (jak jste v této diskusi několikrát názorně demonstroval).
Pokud trpíte amnézií, zatočte kolečkem myši nahoru.
..ale za skutečně podstatné neznalosti fungování protokolů z této rodiny a jejich implementace.
Trochu soudnosti při formulování Vašich přání, prosím. Nejsem neomylný a rád změním názor, stačí mne konfrontovat s fakty. To se vám ale zatím nepovedlo.
Takže vás pro změnu prosím, abyste si na toto téma něco málo nastudova
No, knihovničku už mám přečtenou. Richard Stevens, TCP/IP Illustrated Volume 1-3; Richard Stevens, UNIX network programming, volume 1-2; Richard Stevens- Advanced programming in the UNIX environment; Inside TCP/IP 2nd edition (různí autoři), Donald Lewine- Posix programmer's guide. Myslíte že je to málo? Když mi dáte vhodný tip, rád se poučím.
Zkuste si to také. A při tom točení se nezapomeňte dívat na jména autorů jednotlivých příspěvků…
Nejsem neomylný a rád změním názor, stačí mne konfrontovat s fakty.
Stalo se. Několikrát. Marně.
No, knihovničku už mám přečtenou.
Nezbyde než to zkusit ještě jednou a tentokrát pozorně…
Právě proto je možné s IPv6 používat stejné TCP, UDP a další desítky protokolů jako s IPv4. A nejen že je to možné, ono se to tak už nějakou dobu používá - i když zatím bohužel proklatě málo. Zrovna tak není nutné měnit protokoly aplikační vrstvy, samozřejmě kromě těch, které předávají informace o (nějakých) IP adresách.
pak je příležitost zbavit se současně těch zbytečných portů
Porty samozřejmě nejsou zbytečné, vám jde spíš o to, jak je přesunout do IP hlavičky. Nemyslím si, že by to byl dobrý nápad. Jednak tím nic neušetříte, zabraly by přesně stejně místa (někdy dokonce více, např. u tunelů) a zbytečně by obtěžovaly všechny hopy po cestě, přestože ve skutečnosti zajímají jen cílového příjemce. Navíc je spousta protokolů, které nic takového jako port nepotřebují (GRE, OSPF, většina ICMP, IGMP, …), jiné pro změnu mají něco jako porty, ale funguje to jinak. Právě proto je lepší nechat rozlišení konkrétní cílové aplikace (pokud vůbec) až na transportní vrstvě a necpat to do síťové.
Děkuju za věcný přístup, už mne unavuje odhánět ty vzteklé psy. Takže v současné době se uvažuje, že vše za IP hlavičkou bude v IPv6 stejné, resp IPv6 stacky obsahují pro TCP a UDP stejný kód. To je myslím dobrá zpráva.
Zrovna tak není nutné měnit protokoly aplikační vrstvy, samozřejmě kromě těch, které předávají informace o (nějakých) IP adresách.
Myslím že v tomto nemáte pravdu. Právě tímto mne IPv6 nejvíc znechutilo. Rozhraní v netinet/in.h používá abstraktní 'struct in_addr', a celé API kolem je na tom co je uvnitř nezávislé, což je pěkné. Pokud by IPv6 byla náhrada, kompatibilní se starým API, ale jinou implementací, docela bych to vítal. Ale ne, oni musejí aplikacím předhodit úplně jiné API, zavést in6_addr, a všechny funkce duplikovat na verze s šestkou na konci. Nejde tedy z principu o náhradu, ale o odlišnou, duplicitní věc.
Jednak tím nic neušetříte, zabraly by přesně stejně místa (někdy dokonce více, např. u tunelů) a zbytečně by obtěžovaly všechny hopy po cestě, přestože ve skutečnosti zajímají jen cílového příjemce.
Payload ale také obtěžuje. Podívejte, porty jsou formou adresy, v tom se shodneme. Obvykle nemá význam pro routing, takže v hlavičce obtěžuje. Ale představte si NAT, který má fůru portforwardů. Ten interpretuje porty jako routovanou součást adresy! Pokud bychom akceptovali porty jako součást adresy, zmizely by některé NATy, protože by již formálně šlo o běžný routing. Hlavní výhodu vidím pak v tom, že by šlo jemněji a lépe subnetovat. Pokud máte omezení A+B+C <= 128 && D <= 16, je to mnohem restriktivnější než A+B+C+D <= 144.
Navíc je spousta protokolů, které nic takového jako port nepotřebují (GRE, OSPF, většina ICMP, IGMP, …), jiné pro změnu mají něco jako porty, ale funguje to jinak.
Toto dělá zlomek trafficu. Na druhou stranu jsem si všiml že třeba regulace vysílacího výkonu mezi WiFi kartou a AP-čkem běhá velmi často na UDP.
Právě proto je lepší nechat rozlišení konkrétní cílové aplikace (pokud vůbec) až na transportní vrstvě a necpat to do síťové.
Myslím že by to bylo efektivnější. Síťová vrstva by vždy pracovala s rozhraními, které obsluhují celý adresní BLOK, transport by pak obdržel ty nejnižší bity adresy, které ukazují dovnitř bloku, a tedy se nepoužily. Je to obdobné jako nyní, kdy nižší vrstva ukousne svou hlavičku a pošle zbytek té druhé. Akorát by se ukusovalo ne po bajtech, ale bitech, no.
Opravil bych vás: o tom se neuvažuje, tak to je, tak se to už nějakou dobu používá. Samozřejmě je možné, že časem se ukáže, že pro značnou část aplikací dnes využívajících TCP bude vhodnější jiný protokol, třeba SCTP. Ale stejně jako je IP paketům jedno, jsou-li přenášeny pomocí ethernetu, PPP nebo jiného linkového protokolu, je jedno, zda TCP paket, UDP datagram nebo ICMP message přenášíte pomocí IPv4 nebo IPv6. Dokonce je možné i to, že by paket část trasy putoval jako IPv4 a část jako IPv6.
Ale představte si NAT, který má fůru portforwardů. Ten interpretuje porty jako routovanou součást adresy!
To je špatný příklad. Ta vaše maškaráda má smysl pouze jako berlička, která má za úkol vytvářet ve světě s nedostatkem IP adres uživatelům zdání konektivity. Budete-li používat IPv6, není absolutně žádný důvod, proč sobě i uživatelům komplikovat život maškarádou, takže maškarády nebudou. Chápu, že pro lidi, kteří nepamatují dobu, kdy Internet skutečně fungoval jako síť spojující počítače, je taková představa těžko stravitelná, ale on opravdu neexistuje rozumný důvod, proč u IPv6 dělat maškarády.
Toto dělá zlomek trafficu.
Ano, dnes, kdy se, jak správně podotkl Pavel Janoušek, z nouze kvůli maškarádám, portforwardům a dalším šílenostem používá TCP i pro účely, pro které se ani trochu nehodí. Stejně jako on očekávám, že až se IPv6 začne masověji využívat, podíl TCP komunikace klesne a bude se mnohem více využívat nejen UDP, ale i další protokoly.
Pane, problém je úplně jinde. Já si dobu bez NATu pamatuji. Dokonce i dnes NEJSEM za NATem, máme veřejnou /26 subnetu, ale na routeru je stavový firewall. Dokonce i uvnitř sítě není end-to-end konektivita, protože kdeco je "z bezpečnostních důvodů" filtrováno, takže ani na většinu serverů neudělám ssh přímo.. Jsem si jist že přechod na IPv6 tyto problémy sebeméně nevyřeší. Naříkáte pěkně ale nad špatným hrobem.
Filtrování (ani stavové) není v rozporu s end-to-end konektivitou, to je pouze administrativní opatření, které propouští pouze schválenou komunikaci. Maškaráda je v rozporu s end-to-end konektivitou, protože principiálně neumožňuje obecnou IP komunikaci. V IPv6 samozřejmě budou i nadále existovat paketové filtry, ale budou sloužit skutečně jako filtry. Pro maškarádu tam ovšem opodstatnění není.
Chybná úvaha. Socket (aspoň ty druhy, o kterých mluvíte) je objekt, který se používá coby interface mezi implementací TCP nebo UDP a procesem. Se zpracováním paketu při jeho putování Internetem nic společného nemá. Objevuje se před tím, kdy paket dostane první IP modul a poté, co ho odevzdá poslední. To je jako kdybyste z vlastností třídy std::ofstream v C++ standard library chtěl vyvozovat něco o formátu, ve kterém jsou data ukládána filesystémem na disk.
Ani to, ze IP modul nezajima to co za nim nasleduje, neni pravda.
Ne, to ho opravdu nezajímá. Implementace případného NATu (jakéhokoli) není součástí modulu implementujícího IP protokol. Takže svou úvahou jste odvodil pouze to, že nelze udělat překlad adres, který by modifikoval pouze IP hlavičku a zbytku si nevšímal, což není v rozporu s ničím, co jsem tvrdil.
Mimochodem muj desktop udrzuje nekolik desitek az stovek otevrenych spojeni a NAT box jich pravidelne eviduje okolo 7.000 - vzhledem k moznostem reprezentace 2^16 variant mi to neprijde jako plytvani, natoz neuvazeny navrh...
A proc by se mel transportni protokol zatezovat balastem protokolu vyssich vrstev, ktere stejne velke mnozstvi aplikaci nikdy nebude schopno pouzit a tim naprosto nehorazne plytvat - tto mi hlava fakt nebere....to bude ficak:)
Dnesni Internet je pouze dusledek toho stavu, kdy misto systemoveho reseni se stale drzi vklinicke smrti IPv4, ktere doslouzilo, jeho zivotnost je u konce - zejmena s ohledem na to, ze adresni prostor byl davno vycerpan - a presto se kazda sluzba snazi ho udrzovat dalsi davkou zivotabudice v teto klinicke smrti...
Vse co bezi v userlandu JE aplikace, je-li libo, muzeme ji nazyvat aplikaci systemovou...
UDP pres prumerny NAT v pohode projde. A TCP neni zadny extra velky mamut. VOIP pouziva temer vyhradne UDP, divim se ze to nevite. A IPv4 neni v zadne klinicke smrti, adres je dost.
$ links -dump www.iana.org/assignments/ipv4-address-space| grep Reserved
IPv4 adres vůbec není dost. Kdyby jich bylo dost, nemuseli bychom používat maškarády. Nebo si myslíte, že by ta čísla o zaplnění adresního prostoru IPv4 vypadala tak optimisticky, kdyby každý, kdo si myslí, že je připojen k Internetu, měl skutečně IP konektivitu?
Tak tohle vime naprosto presne. Jeden z hlavnich duvodu, proc sel ET do prekladu adres, byl fakt, ze si nebyli jisti, ze jim RIPE NCC bude ochotno i nadale pridelovat tak velke baliky IP adres, aby to odpovidalo rustu poctu klientu.
Mimochodem, AFAIK uz ten jejich software umoznuje pridelovat z vice bloku.
To, jak bude vypadat jeden alokacni prostor rozhoduje jeho LIR. ET mel jednu /16 a pokud by to, o cem pisete, byl hlavni problem, jiste by dokazali ty adresy presoupat. Prece jen neplanovali tu sit tyden :-)
ochotno != schopno. Takže politické, nikoliv technické rozhodnutí. Zřejmě se jim nechtělo investovat do přípravy argumentů.
pokud by to, o cem pisete, byl hlavni problem, jiste by dokazali ty adresy presoupat. Prece jen neplanovali tu sit tyden :-)
Zřejmě ten nedostatek zjistili na poslední chvíli, a NAT tam dali jako nouzovku. Přecejen přečíslovat síť není úplná sranda.
Uz vice jak deset let mame neco jako classless smerovani... - takze se obecne neda rici, kolik bitu prestavuje "adresa site/ti" a kolik bitu predstavuje "adresa v siti". A z hlediska portu - to je ovsem omyl, protoze smerovat informaci o portu nijak nezpracovava - on ji totiz vubec neresi, protoze veskera jeho prace konci na vrstve IP, nikoli vyse! V IP vrstve zadny port neni... - taky se zlobite, ze puvodni navrh HTTP nemel obsazenu funkcionalitu v podobe chunkovani? Taky se zlobite, ze na 1TB dat v systemu BitTorrent prenesete (download) okolo 10% dat (zbytecne) navic? Proste problemy a chyby vyssich vrstev nesvadejte na vrstvy, ktere za neoptimalni navrh (nebo zamer/prijatelnou rezii vyvazenou jinymi vlastnostmi) naprosto nemohou.
Nove je to, ze by byly pridelovany adresy, ktere by ISP neagregovali do svych prefixu - jde de facto o stare zname Provider Independent adresy zname z IP. Nicmene i nadale se podita s tim, ze tyto adresy budou pridelovany pres LIR.
Stejne tak tomu bylo doposud u IPv6 a nepochybne tomu bude i nadale.
Jinymi slovy - vyvozovat cokoliv o tom, kolik adres dostanete, na zaklade v clanku uvedenych dokumentu, je zcestne.
Pokud by se objevila nejaka fakticka poptavka na trhu, urcite by to ISP nabizeli - tedy oni to nabizeji i dnes, jen to neni v tech nejlevnejsich tarifech.
Co je mozna zajimavejsi, zintenzivnily se prace na pridelovani "provider independent adres", coz by vyresilo problem s multihomingem. Nicmene lobby vyrobcu smerovacu pracuje usilovne na zachovani hierarchizace.
On Vladimir Odoevsky byl akademik?
Právě těm aplikacím třeba NAT děsně vadí. Taková IP telefonie je toho zářným příkladem. Pokud bych chtěl telefonovat mezi sebou za dvěma NATovanými sítěmi, tak to snad ani nejde. Možná ovšem IP telefonie není ta správná aplikace...
Rovněž tak třeba normální bezpečnost - IPSec s NAT je šílená komplikace.
Pro skoro každou takovou aplikaci aby měl člověk tu správnou aplikační bránu nebo connection tracking, aby mu to začalo fungovat.
ČLÁNKY DO MAILU