Vlákno názorů k článku Pohnou se hranice v IPv6 adresách? od Michal Kubeček - Pokud trpíte amnézií, zatočte kolečkem myši nahoru. Zkuste si...

Pokud trpíte amnézií, zatočte kolečkem myši nahoru.

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ě…

Možná jste to přehlédl, ale nepranýřoval jsem vás za TCP/IP

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.

Problém je, že vy kromě nápadů, jak by to (podle vás) mohlo být lépe, prezentujete i ty dojmy, o tom, jak to funguje - nebo přesněji jak si myslíte, že to funguje. Ty ovšem mají se skutečností velmi málo společného.

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).

Dovoluji si vás upozornit že informace o tom jak by něco mohlo fungovat lépe se nenazývají "dojmy", nýbrž "nápady".

Dále pokud nepodstatná formální zjednodušení opravdu považujete za "zásadní neznalosti", čeká vás možná zářivá kariera ve Svaté inkvizici. Živě vás vidím jak nebožáky co řekli "TCP/IP" vedete na hranici za herezi :) Takže se zkuste realizovat tam a neotravujte prosím na (kdysi) odborném webu. Děkuji uctivě.

Dojmy (jak si myslíte, že to funguje nebo že by to asi tak mohlo fungovat) tu prezentujete jen vy. V této diskusi jste byl nachytán při zásadních neznalostech tolikrát, že kdokoli soudnější už by se raději šel podívat, jak to s těmi protokoly je ve skutečnosti.

Vaše dojmy mne nezajímají.

Standartni socketove API (RFC 3493) definuje adresu pro soket (sockaddr_in6) jako strukturu obsahujici jak IP adresu, tak 16-bitove cislo portu pro TCP ci UDP. Tim maji tyto protokoly v ramci IP vysadni postaveni.

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.

Třeba v tom, že povinnou součástí implementace IPv6 je implementace IPsec. A to vylučuje překládání adres. Navíc neexistuje rozumný důvod, proč si maškarádou komplikovat život, a snad ani prefabrikovaní síťoví "odborníci" si nebudou přidělávat práci s něčím, co působí jen komplikace a nic pozitivního nepřináší.

"ping na port 80" je samozřejmě ověření dostupnosti HTTP serveru příkazem telnet nebo netcat, a neshledávám v tom nic špatného nebo nepřesného.

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…

Tohle ciste rozdeleni vrstev je jen prani, nefungujici ani na papire. Standartni socketove API (RFC 3493) definuje adresu pro soket (sockaddr_in6) jako strukturu obsahujici jak IP adresu, tak 16-bitove cislo portu pro TCP ci UDP. Tim maji tyto protokoly v ramci IP vysadni postaveni. Takze pokud zavedete novy protokol, ktery bude rozlisovat aplikace jinak nez 16-bitovymi cisly, budete muset API vyresit jinak a v adresach porad budou strasit nepouzita cisla portu.

Ani to, ze IP modul nezajima to co za nim nasleduje, neni pravda. To by pak bylo mozne napsat jednoduchou NAT, ktera by pouze prepisovala adresy v IP hlavickach (pokud by stacilo 1:1 mapovani adres bez sledovani stavu). Bylo by mozne i udelat takovou NAT pro preklad IPv4 paketu na IPv6 ci naopak. Ale to prave nejde, protoze TCP i UDP pakety maji ve svem kontrolnim souctu zahrnutou pseudohlavicku obsahujici IP adresy (RFC 793 odst. 3.1) a tuto je treba pri prekladu adres menit (RFC 2663). Takze NAT fungujici v IP vrstve _musi_ rozumet paketum z vyssi vrstvy, a to i kdyz se vubec nesnazi prekladat cisla portu nebo sledovat stavy. Take to znamena ze neni pravda ze "je mozne s IPv6 pouzivat stejne TCP, UDP ...", protoze tato pseudohlavicka je pro TCPv6 a UDPv6 samozrejme jina nez pro TCPv4 a UDPv4 a kontrolni soucty jsou povinne.

No, jestli vám někdo řekl že respekt vám přinese upozorňování druhých na formální nepřesnosti, tak vás tahal za nos. "ping na port 80" je samozřejmě ověření dostupnosti HTTP serveru příkazem telnet nebo netcat, a neshledávám v tom nic špatného nebo nepřesného. Něco "pingnout" prostě znamená na dálku ověřit že to nechcíplo, nikoliv nutně posílat ICMP ECHO requesty.

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.

ze si nebyli jisti, ze jim RIPE NCC bude ochotno i nadale pridelovat tak velke baliky IP adres, aby to odpovidalo rustu poctu klientu.

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.

Zase kecy, zase kecy, spoustu omylu uz nemam silu ani komentovat, snad jen ten Eurotel - a jakpak asi na tom samem APN pridelovat konkretni adresy a nesouvisle subnety mi asi nevysvetlite, vidte? Vzdyt prece mel jen hloupy software, ktery to neumel...:-)

Mimochodem, víte proč třeba Eurotel začal NATovat GPRS konektivitu? Protože hloupý software, který klientům dynamicky přiděluje adresy, umí alokovat jen z jedné subnety. Adres pro klienty měli sice dost, ale ne v souvislém bloku. Tak tam šel NAT.

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 :-)

To je o pohodlnosti. Když víc adres potřebujete, dostanete je. Dnes už ale, když nějaké chcete, musíte prokazovat že ty staré používáte, a že budete opravdu používat i ty nové. Chtějí statistiky, grafy současně aktivních uživatelů, několik měsíců do historie, atd.

Je s tím práce, a proto se někteří ISP na to vybodli, předhazujou zákazníkům privátní adresy, a tahají z nich extra peníze za každou veřejnou adresu.

Adminům často NAT ušetří práci, nemusejí konfigurovat firewall, ten NAT je nic nestojí, protože už v jejich AP/ADSL/Cable routeru stejně je, takže to zapnou, a nemusejí komunikovat s ISP a platit za další adresy. Všiměte si že jde o minimalizaci nákladů, nikoliv o skutečný nedostatek adres. Ale svádět vše na IPv4 a umělý nedostatek adres je tak jednoduché.

Mimochodem, víte proč třeba Eurotel začal NATovat GPRS konektivitu? Protože hloupý software, který klientům dynamicky přiděluje adresy, umí alokovat jen z jedné subnety. Adres pro klienty měli sice dost, ale ne v souvislém bloku. Tak tam šel NAT.

Další lež.

Jak se do lesa...

Proc se domnivate ze prumerny NAT nema conntrack?

V IPv6 samozřejmě budou i nadále existovat paketové filtry, ale budou sloužit skutečně jako filtry.

Kde berete ten optimismus?

UDP pres prumerny NAT (bez connection trackingu a pochopeni protokolu) nema sanci smerem dovnitr projit - muzete mi rici, na zaklade ceho by mel probihat ten demultiplexing?

Vaše věta "Slušně jsem přiznal svůj omyl..." je snadno prokazatelná lež. O slušnosti nemůže být řeč ani náhodou.

Dokonce i uvnitř sítě není end-to-end konektivita, protože kdeco je "z bezpečnostních důvodů" filtrováno

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í.

A IPv4 neni v zadne klinicke smrti, adres je dost.

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?

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.

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.

NAT boxy, jak jste nazval bez vetsich problemu zpravidla nic jineho nez TCP streamy neprojdou (a to jeste radsi neuvazuji inspecni filtry) a proto vsichni pouzivaji TCP aby mohli v tomto zkriplenem svete koexistovat. UDP je pro mnoho aplikaci daleko vhodnejsi, stejne jako spousta jinych protokolu...

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

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.

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.

Správně. Přece nebude dělat práci za Sedm Trpaslíků.

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á

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.

Ale kulovy, port nesouvisi s identifikaci rozhrani (pokud tedy pouzivame stejne pojmy pro stejne veci, predmety). Vasi logikou bychom mohli dojit k tomu, ze soucasti kazdeho datagramu je certifikat (coby pruvodni atribut nejake vyssi vrstvy a tedy ho zahrneme take do IP). OSPF neni vubec vyjimka, to ze v dnesni dobe se pouziva TCP/UDP na milion zpusobu, ruzne zmrvene, zbastlene, do vyssich vrstev se cpou veci, ktere v cistem navrhu a pri zdravych smyslech tam nikdy nepatrily je pouze a jen dusledek NAT - tedy veci, kterou taktez branice... Dusledkem NAT je totiz to, ze NAT boxy, jak jste nazval bez vetsich problemu zpravidla nic jineho nez TCP streamy neprojdou (a to jeste radsi neuvazuji inspecni filtry) a proto vsichni pouzivaji TCP aby mohli v tomto zkriplenem svete koexistovat. UDP je pro mnoho aplikaci daleko vhodnejsi, stejne jako spousta jinych protokolu... - ze zajimave, ze tam, kde je skutecne realne dostupna END-TO-END konektivita je neco jako TCP daleko v zazemi a pouziva se pouze pro rozsahle souvisle prenosy - vsude jinde je to mamut, ktereho netreba a jsou efektivnejsi cesty jak dosahnout vysledku. A pokud si myslite, ze jine nez TCP protokoly jsou spise servisni zalezitosti (OSPF, ICMP, ARP, BootP, DHCP atd.), co treba jiz nakousnuta IP telefonie? Vzdyt ta je krasnym kandidatem na neco takoveho, stejne tak prenos proudovanych multimedialnich dat - zadny zamrzavajici TCP stream, ktery je nam na houby, pokud packet XY nedorazi vcas a OOO packety a funkcionalitu skoro nikdo neresi a neimplementuje...:-(

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...

Porty nesouvisejí ani s identifikací rozhraní. Ke slovu přijdou až ve chvíli, kdy paket přijde na to rozhraní, dostane ho IP modul, usoudí, že je koncovým příjemcem, podívá se do hlavičky na pole protocol, najde tam šestku nebo sedmnáctku a předá ho TCP nebo UDP modulu. Teprve pak se ten TCP nebo UDP modul začne zabývat nějakými porty, aby zjistil, kterému socketu ten paket patří. Do té doby se o porty nikdo nestará a na tom není důvod nic měnit.

Porty nesouvisí s IP adresou, ale s identifikací rozhraní v podsíti. Délka podsítě je variabilní, tedy i identifikace rozhraní v podsíti je variabilní. Zahrnutí portů do této variabilní části je logické. Samozřejmě že adresa jako celek by měla mít pevnou délku.

Ano, OSPF démon používá vlastní číslo IP protokolu, komunikace je pak mírně efektivnější. Je to výjimka. Jiní routovací démoni používají TCP/UDP a well known porty. Stejně je legrační jak routovacímu démonu říkáte "aplikace". :)

Proč se vyjadřovat nepřesně? Protože když napíšu "IP porty", je to podstatně kratší než "TCP porty nebo UDP porty", a pro NORMÁLNÍ lidi, kteří nejsou moroni, i pochopitelnější.

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šší…

Proč se vyjadřovat nepřesně? Protože když napíšu "IP porty", je to podstatně kratší než "TCP porty nebo UDP porty", a pro NORMÁLNÍ lidi, kteří nejsou moroni, i pochopitelnější. Rozumíte??? Dále sekvenční čísla a čísla portů si pletete maximálně vy, ale nemám silu vám to vyargumentovat. Jestli máte opravdu snahu, tak si prosím moje příspěvky přečtěte znovu.

End to end konektivita je důležitá, a stejně jako vám se mi nelíbí že k jejímu dosažení jsou často potřeba velmi ošklivé hacky, jako například port forwarding, UDP NAT traversal, UPnP, nebo IPv6a. Na rozdíl od vás ale to poslední nepovažuji za konečné řešení, pouze za poslední hack v řadě, s velmi nevýhodným poměrem cena/výkon.

IP stack cisla portu neresi a vubec neni zodpovedny za "routovani" packetu do aplikace!

Jako plýtvání považuji fakt že NAT box i váš desktop používají pro číslo portu stejný počet bitů. Když subnety přidělujeme po bitech, a různě velké, proč jsou porty napevno?

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.

Součástí IPv6 paketu mohou být čísla TCP portů a také nemusejí. První možnost nastává v případě, že je to TCP paket, druhá v ostatních případech (pomineme-li specifické případy, kdy půjde např. o GRE paket obsahující další TCP paket). Podstata je ale jinde: v tom, že vzhledem k rozdělení vrstev IP modul (v4 nebo v6) vůbec nezajímá, co to vlastně následuje za IP (v4 nebo v6) hlavičkou. Pro něj jsou to jen data, jejich vnitřní struktura je pro něj nepodstatná a zajímají ho jen do té míry, že v (IP) hlavičce v poli protocol (resp. next header) má informaci o tom, komu celý ten zbytek paketu předat, je-li uzel cílovým příjemcem.

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é.

Porty jsou napevno stejně jako délka IP adresy je také napevno. Variabilní délka čehokoliv zbytečně komplikuje situaci.

Čísla portů rozhodně také nejsou potřeba k tomu, aby se aplikace dozvěděla, že s ní někdo chce komunikovat. Názorným příkladem může být třeba OSPF démon. Tam se žádné číslo portu nepoužívá. Co teď?

Jaký skvělý myšlenkový obrat vás vede k tomu, že jsem něco takového tvrdil? Slušně jsem přiznal svůj omyl že jsem mluvil o portech v souvislosti s IP, místo explicitního vyjmenování UDP a TCP, neboť jsem netušil že po takové drobné nepřesnosti půjdete jak slepice po flusu.

Jako plýtvání považuji fakt že NAT box i váš desktop používají pro číslo portu stejný počet bitů. Když subnety přidělujeme po bitech, a různě velké, proč jsou porty napevno?

Tím posledním odstavcem jste mne vážně pobavil. Vzhledem k tomu že čísla portů jsou nezbytná k tomu, aby se stack rozhodl do kterého socketu a tedy do které aplikace data půjdou, bude pro takovou probuzenou aplikaci opravdu velmi obtížné je ignorovat :)

No nevím, ten smích van Jacobsena pochází z roku 1997. Dnes by se asi moc nesmál. A jak nadšeně by se tvářil na NAT si taky dovedu živě představit :-)

Van Jacobson - to je ta sama osoba, ktera na konci 80-tych let navrhla nekolik vylepseni plovouciho okna a celkoveho throughputu TCP pres mizerne site? (dneska to obsahuje v podstate kazdy TCP/IP stack)

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...

Člověk nemusí být příliš velký puntičkář, aby mohl říct, že něco čemu říkáte TCP/IP neexistuje. Už to vámi zmiňované RFC 1180 jasně říká, že je to nepřesné označení. Není mi tedy jasné, proč bych se měl vyjadřovat nepřesně.

Dále ve svém původním příspěvku pletete sekvenční čísla s čísly portů (což překvapivě není to stejné). Obojí sice patří do TCP hlaviček, ale každé plní úplně odlišnou funkci.

IMHO máte prostě jinou představu o Internetu. Zatímco vy jej považujete za strukturu typu klient-server, kde jsou klienti, kteří nepotřebují rozumné adresy a servery, které jsou na veřejně dostupných adresách. Já osobně považuji Internet za síť spíše typu peer to peer a end to end konektivita je pak jedním z důležitých parametrů takových sítí.

Ostatně by mne třeba zajímalo jakým jednoduchým způsobem přimontujete disky 2 serverů za 1:N NAT bez použití nějaké třetí strany.

Uděláme dohodu- já vám nebudu kecat do toho koho považujete za kapacitu, a vy mi jejich názory přestanete předhazovat jako argument. Jinak pokud chcete znát názor kapacit na IPv6, přečtěte si příspěvek který linkuju.

http://slashdot.org/comments.pl?sid=165528&cid=13810089

One audience member rose his hand and said, "What about IPv6?" The response to this was the entire audience broke into laughter - it was the funniest thing they had heard that week.

Ale Van Jacobson nebo Paul Vixie asi podle vás nebude ta správná autorita, žejo...

Aha, takže byrokrat. A puntičkář. Protocol suite u mne znamená skupinu souvisejících protokolů. V příspěvku na který jste ragoval jsem psal, cituji: "Copak TCP/IP není součástí IP protokolů?" Povšimněte si prosím kroužku nad posledním písmenem. Děkuji za pozornost.

K třetímu problému: proč bych měnil providera, když IPv6 nepotřebuji? IPv4 adres je nadbytek, a sponzorovat Cisco na rozdíl od bulíků co jim skočí na každou hloupost nehodlám.

Jen jestli ta chyba neni na Vasi strane, kdyz o stejne veci nehovori ani neuvazuje velke mnozstvi kapacit, ktere jsou daleko uznavanejsi nez Vase..:)

Jaky to skvely myslenkovy obrat Vas dovedl k implikaci, ze kdyz ICMP patri pod IP (on jednak nepatri "pod IP", on to je jeho servisni protokol - rekneme sluzebnik), tak ma znat porty? Ve Vasem zmateni by mne zjimalo, kam byste zaradil chudaka BootP nebo ARP, pripadne RARP...:-0

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:)

ad 1.: dobře, předložte mi jeho rodný list a pověřovací listiny a uvěřím vám.

ad 2.: RFC 1180: This RFC is a tutorial on the TCP/IP protocol suite. Všimněte si rozdílu mezi "protocol" a "protocol suite".

ad 3.: no pokud chcete mít IPv6 ve stejném AS, tak budete muset patrně změnit providera, jinou možnost nevidím.

1. Jak víte že galaktický prezident neexistuje?

2. RFC1180

3. Cesnet poskytuje 6to4 tunely? A zdrama? Od kdy? Sice jiný AS a 20ms ping odporuje mé definici "blízko", ale dost lidí za NATem by to uvítalo jako náhradu různých SOCKS relays.

Google: 413 000 hits for "Zaphod Beeblebrox", na neexistujícího dvouhlavého galaktického prezidenta docela vysoké číslo. Máte pocit, že to znamená, že Zaphod Beeblebrox ve skutečnosti existuje?

Pokud máte pocit, že protokol TCP/IP skutečně existuje, tak mi dejte odkaz na nějaké RFC, které tento protokol definuje. To bude dostatečný důkaz.

Co se týká tunelu, zkuste se domluvit třeba s někým na CESNETu.

Google: 1,570,000 hits for "TCP/IP protocol", na neexistující věc docela vysoké číslo, nemyslíte? Můj ISP IPv6 jej nepodporuje, a nevím o vhodném providerovi tunelu, který je a) blízko b) spolehlivý c) zdarma. Jestli vy ano, tak se pochlubte.

Ono hlavně TCP/IP vůbec neexistuje. Existuje protokol IP a protokol TCP, které jsou na sobě nezávislé. Směrovače se zabývají pouze IP protokolem, koncová zařízení se zabývají pak zpracovávají protokoly vyšších vrstev.

Mimochodem, když dokážete takto hlubokomyslně argumentovat, proč si to IPv6 nezkusíte? Já ho normálně používám a nezdá se mi, že by mi nefungovalo.

Myslím že se mýlíte. Copak TCP/IP není součástí IP protokolů? A když si vezmu IPv6 TCP packet, nebudou v TCP hlavičce čísla portů? Zajímalo by mne jestli se v IPv6 (pokud někdy bude používáno což není vůbec jisté) budou používat identické UDP a TCP hlavičky, jen za jinými IP hlavičkami? Mám pocit že chtěli natáhnout sekvenční čísla na 64 bitů, takže stejné asi nebudou- pak je příležitost zbavit se současně těch zbytečných portů.

Dobře, nesmysl jménem ICMP pod IP patří a porty nezná.

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í.

Neni mi jasne jak jste z toho ze rozeznam chyby urciteho reseni vyvodil ze jsem genius, ale i tak dekuji. Jestli to byla ironie tak nefunguje.

Jeste vetsi radost by mi vsak udelalo kdybyste misto me inteligence, inteligence lidi z IETF, nebo nazvu dokumentu ktere produkuji, jen vecne komentoval muj predchozi nazor ze identifikace aliasovaneho sitoveho rozhrani a sitoveho portu je semanticky totozna vec, jejich domeny lze tedy ztotoznit, a ziskat tak minimalne vyhodu lepsi skalovatelnosti, o jednoduchosti nemluve.

Vite obavam se, ze proste nejste informovan. Predpokladam, ze nevite, co je IETF draft a jak vznika. Pokud byste to vedel, jen tezko byste se mohl dopustit hodnoceni toho, zda lide v IETF nad problemy premysli, na zaklade publikovanych draftu :-)

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.

Pravdepodobne jste ji neminul. Pri zkostnatelosti zminovane instituce by moje postovani tezko melo nejaky smysl, tak se jim nezabyvam. Uz jsem se naucil ze prizpusobit se chybam druhych je nejrychlejsi cesta k interoperabilite.

Dale podle kvality ruznych draftu ktere z IETF padaji silne pochybuji ze nad problemy opravdu premysli, a o vas, vzhledem ke zpusobu argumentace ke kteremu jste zklouzl, si to pomalu myslim take.

Hm ... Skoro bych cekal, ze budete jednim z nejcastejsich prispevatelu do IETF mailinglistu. Zkuste nadhodit nejake zajimave vlakno z posledni doby, kde konfrontujete sve vykriky s lidmi, kteri nad tim problemem opravdu premysleji. Priznam se, ze uz sleduju jen par listu, takze je mozne, ze jsem Vasi argumentaci proste minul.

Dobře, nesmysl jménem ICMP pod IP patří a porty nezná. Spokojen, herr proffesor? Aplikace samozřejmě rozlišovat musíme, ale vyhradit natvrdo 16 bitů byl špatný nápad, jak jistě uznáte. Pro desktopy kde je 3-10 otevřených spojení plýtvání, pro velké NAT boxy je to zase málo.

IPv6 by si mělo přestat hrát na porty, číslo portu je jen další individuálně neroutovaná součást adresy, takže je zrušíme, ať si každý socket jednoduše alokuje nové rozhraní.

Žádné IP porty neznám. Pokud máte na mysli TCP a UDP porty, pak bych si dovolil nesouhlasit, že jsou pro legraci. Identifikují aplikace, což je docela důležitá věc.

Fakticky nejde o 64 bitů, ale 80 bitů, protože sémantika 16-bitového čísla IP portu je velmi obdobná. Navíc musíme násobit dvěma (src, dst), takže každý packet bude mít minimálně 160 bitů pro legraci.

Puvodni myslenka spis byla ta, ze tato cast adresy by mela byt svetove unikatni a sitovych casti muzete mit libovolne mnozstvi. Pak by protistrana nemela problem identifikovat komunikaci se stejnym strojem prave na zaklade teto adresy. Samozrejme toto je nezarucena cesta k identifikaci ;).

Vyuziti je tu i pro mobilni stanice, kterym se meni pouze sitova cast IP.

Máte samozřejmě pravdu, ale stejně se nemohu zbavit pocitu, že požívat 64 bitů na identifikaci rozhraní v JEDNÉ PODSÍTI je katastrofálně neefektivní.

Nota bene adresy se buď přidělují zvenčí (statická konfigurace, DHCP) a pak mohou být jakékoli, nebo si je zařízení volí samo bezstavovou autokonfigurací. V tomto druhém případě by jistě nebyl problém se strefit do podstatně menšího prostoru. Např. RFC 3041 doporučuje vybírat náhodné dočasné adresy, u nichž se objevováním sousedů ověří jednoznačnost. I kdyby se prostor pro náhodný výběr zúžil ze 64 bitů na 48, stejně by byla pravděpodobnost kolize při náhodné volbě zanedbatelná.

Ja bych to spis videl tak, ze ne vsechny identifikatory jsou 48 bitove (napr. ieee1394). A protoze EUI-64 ma nahradit MAC-48, tak byl vymyslen jednosmerny prevodni algoritmus.

Podrobnosti lze najit na IEEE nebo Wikipedii.

Obavam sa, ze za 64-bitovymi identifikatormi rozhania je v skutocnosti schovany uplne iny problem - ak by mali iba 48 bitov ako MAC adresa, potom by vsetky routre museli pracovat s 80-bitovymi prefixami. A 80 bitov sa dost tazko zmesti do 64-bitovych registrov v ASICoch, takze kazda operacia by sa musela robit na dva kroky.