Vlákno názorů k článku Pohnou se hranice v IPv6 adresách? od Michal Krsek - ... odkud vitr vane :-) Vcera na RIPE...

... odkud vitr vane :-) Vcera na RIPE meetingu na address policy working group a castecne na IPv6 working group prezentovali panove, ze jde skutecne o dohodu mezi RIRy. Pkud si spravne pamatuju, ARIN uz to schvalil.

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.

Lobby vyrobcu smerovacu ma rozum. Multihoming si delejte dle libosti prekladem nejake abstraktni adresy. Je lepsi kdyz si stavove informace bude uchovavat klient (bude to jen jednou), nez router (bude to duplicitni, zbytecne, drahe).

Jeden z duvodu, proc zavadet IPv6, je vymyceni jednoho znejvetsich nesvaru soucasneho Internetu - preklad adres :-)

Bezte uz s tou politikou do haje.

Dobry den,
netusim, jak muzete nazyvat politikou vec, ktera nici zakladni paradigma Internetu - end to end konektivitu.
MK

Nezavisle logicke adresovani nad IP adresami nijak end-to-end konektivitu nenarusuje, a bezne se pouziva. HTTP adresuje zejmena pres DNS cnames. IRC adresuje pres nicknames. MAIL adresuje podle e-mailovych adres. Co se vam na tom nelibi?

Druhe zasadni paradigma Inetu je myslenka prepinani packetu, nejlepe velmi jednoducheho, rychleho a bezstavoveho. Adresy ktere chvili patri jednomu ISP a chvili druhemu jsou s tim samozrejme v rozporu, podobne jako routovane multicasty apod. Ja bych to vsecko zahodil.

Pokud se dva lide hadaji, a jeden je z univerzity, a druhy z praxe, ma pravdu ten druhy. Pokud se hada programator s clovekem, ktery navrhuje HW, ma pravdu take ten druhy.

Kecy o end-to-end konektivite, nat considered harmful a podobne jsou mimo realitu, lidi na to jednpoduse kaslou. Chteji levnou a rychlou konektivitu bez nadbytecne funkcionality. Staci kdyz nebude aplikacim zbytecne hazet klacky pod nohy. Kdyz bude opravdovy tlak na veci jako sifrovani, mobilita, milticast streaming apod, jednoduse se to (nejlepe zivelne) realizuje na aplikacni urovni.

Doporucuji Vasi laskave pozornosti fakt, ze koncept Internetu prisel z akademickeho prostredi a firmy (jako napriklad IBM) odpovedely na vyzvu DARPA, ze takova sit _NENI_ mozna ...

Mimochodem, nadbytecna funkcionalita je pekny oxymoron :-)

> Doporucuji Vasi laskave pozornosti fakt, ze koncept Internetu prisel z akademickeho prostredi

Ano, fakt ze puvodni navrh IPv4 byl znacne pochybeny je dostatecne znam. Praxe z toho musela vyhazet hromadu balastu a pridat potrebne veci. Dalsi hromada balastu tam zustala a jen se nepouziva. IBM nezasluhuje komentar, ty opil rohlikem i mladej Gates. :)

> nadbytecna funkcionalita je pekny oxymoron

Proc? Kdyby to nekdo pouzival, tak by to nejakou konkretni funkci melo, proto lze mluvit o funkcionalite. No a nadbytecna je protoze se nepouziva.

Mozna Vas prekvapi, ale IP(v4) nebyl puvodni protokol ARPANETu :-)

NCP? No bože, no.. středověk už je pod mou rozlišovací schopností.. Bylo to ještě oskurnější než původní IPv4?

Nějak nevidím ten rozpor mezi směrováním paketů a adresami nezávislými na poskytovateli.

Jen tak pro zajímavost: Web vznikl ve švýcarském výzkumáku. První rozšířený grafický klient (Mosaic) také pocházel z nekomerčního prostředí. Naproti tomu Microsoft se v první polovině 90. let snažil protlačit MSN jako konkurenční síť proti Internetu. OSI rodina protokolů pochází od komerčních telekomunikačních společností, které do nás horem dolem hustily X.25. Ale rozhodně si nenechte nabourat svá jednoduchá pravidla posuzování pravdivosti nějakými fakty ;-)

Myslim ze multihoming muze byt docela dobre vyresen pres shim6:
http://www.ietf.org/html.charters/shim6-charter.html

Adresa nezávislá na poskytovateli implicitně vyžaduje stavovou informaci, kam se má zrovna routovat. Tuto stavovou informaci lze považovat za jistý druh virtuálního okruhu, což je se směrováním paketů zjevně v rozporu. Ale rozhodně si nenechte nabourat své zažité formalismy nějakými fakty. ;-)

Kecy o end-to-end konektivite, nat considered harmful a podobne jsou mimo realitu, lidi na to jednpoduse kaslou. Chteji levnou a rychlou konektivitu bez nadbytecne funkcionality. Staci kdyz nebude aplikacim zbytecne hazet klacky pod nohy

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.

Ale adresy závislé na poskytovateli také vyžadují "stavovou" informaci, kam se mají zrovna routovat - směrovací tabulky. Pořád nějak nevidím ten problém.

Jenže ty směrovací tabulky budou 1) statické 2) hrubě agregované, takže velikostí budou odpovídat lokální složitosti sítě (jak je v paketové síti obvyklé), nikoliv počtu mobilních adres, které tam zrovna jsou, fakticky degradujíc paketovou síť na virtuální okruhy pro každou takovou mobilní adresu.

Přímé telefonování mezi dvěma NATy bez proxy není problém, pokud je alespoň jeden z nich rozumný, tj full cone, address-restricted cone, nebo port-restricted cone. IPSec je dosti šílený i bez NATu.

To není tak úplně pravda.

1. full cone nebo restricted cone nejsou zrovna obvyklé. Nejčastějším příkladem u domácích uživatelů je překlad 1:N.

2. zbytečně to komplikuje protokol nebo bránu, protože ta tomu protokolu obvykle musí rozumět.

A jestli si myslíte, že IPSec je šílený, tak je to vaše věc, ale žádný bezpečnostní protokol není tak jednoduchý, aby ho pochopil úplně každý. Ostatně takové SSL nebo TLS taky nepatří mezi nejjednodušší protokoly a mám pocit, že jsou i složitější a přesto je dnes používá téměř každý.

Ono to hlavně s těmi mobilními adresami není tak, jak si to představujete. Mobilní IP používá tzv. home agenty a těm, kteří se chtějí spojit s mobilním IP poskytnou adresu toho pohybujícího se počítače v jiné síti. Tím pádem si IPv6 stack automaticky upraví komunikační adresu a pak komunikuje s počítačem na jeho nové IPv6 adrese. No, doufám, že jsem to vysvětlil ve zkratce správně a srozumitelně.

Diky za pochopitelne vysvetleni. Jde tedy o dvoji adresovani, s tim ze jedna pevna "mobilni" adresa se preklada na tu dynamickou, a samotne routovani se provadi pouze podle te dynamicke. To je rozumne reseni, jen nevim jake vyhody prinasi jeho integrace do IPv6.

1. Pojmy full cone, port restricted a host restricted vůbec nesouvisí s tím jestli je 1:N nebo ne.

http://www.abclinuxu.cz/slovnik/full-cone-nat

2. Pokud je protokol rozumný, tak běží i přes NAT, a brána mu rozumět nemusí. SSL i TLS běží bez problémů.

Jediná výhoda integrace do IPv6 je ta, že IPv4 tuto možnost neposkytuje :-)

(tedy možná už jo, ale implementace v IPv6 je starší než v IPv4)

ad 1: ano, přesně z tohoto zdroje jsem čerpal. Ovšem to mapování N:N je pak logickým důsledkem definice. "vždy překládám stejnou vnitřní adresu na stejnou vnější adresu (a naopak)". Když budu mít tedy vevnitř 2 počítače nemohu mít jenom jednu vnější adresu.

ad 2. já považuji IPSec za rozumný protokol a přesto normálně přes NAT neběží. SSL a TLS jsou protokoly vyšších vrstev a uživatele zajímá integrita obsahu, nikoliv integrita celého datagramu, což třeba u některých protokolů typu UDP nemusí být pravda.

IMHO prostě přes dva NAT 1:N bude mít IP telefonie děsné problémy.

Ad zaver - no oni ti dva bez spolecneho stredobodu budou uplne v pr...:)

Aha, a jak jste na to přišel? Nápověda: zkuste třeba dyndns.org

No jo, jeden o voze a druhý o koze. Vy vůbec netušíte o čem je řeč. Konektivita v internetu přece nesmí být závislá na DNS systému. Když se chci spojit se strojem 1.2.3.4, tak nevidím důvod, proč bych měl znát jeho doménové jméno.

Jsou to dva úplně odlišné mechanismy, ikdyž připouštím, že výsledek může být v podstatě stejný.

To jste pochopil moc doslova :) Ta persistence je jen dočasná. Full cone může být N:1, NAT prostě provádí kompresi jednoho adresního prostoru do druhého. Když zjistí že všechny vnější porty jsou obsazeny, tak nové connection co jdou zevnitř ven prostě zahazuje. Pokud ale ve vnitřní síti neřádí nějaký worm, nehrozí to ani pro řádově stovky až tisíce hostů za jednou vnější adresou.

Ale to je omyl, ta perzistence u full cone nemůže být dočasná, protože vnitřní stroj musí být dosažitelný zvenku navazovaným spojením. Tj. full cone NAT musí být natrvalo nebo musí existovat jiný způsob signalizace, že se vnější adresa vnitřního uzlu změnila.

"Libovolný počítač ve vnější síti může poslat UDP paket na počítač v lokální síti jednoduše tak, že pošle UDP paket na namapovanou vnější IP adresu."

Ne, je to urcite jen docasne, STUN ostatne v pozadavcich primo pozaduje, aby okno bylo alespon dve minuty, aby se zevnitr nemuselo posilat prilis mnoho keep-alive packetu.

Ta zminka o docasnosti tam sice neni, chybi i v popisu full cone NATu v RFC3489, ale z kontextu vyplyva ze jde o docasný mapping. 1:1 NATy se to RFC vubec nezabyva.

Pokud má být možno navázat spojení zvenčí, tak jak je to v popisu, tak to prostě nemůže být dočasné přiřazení. To jsou prostě dva protichůdné požadavky.

> Konektivita v internetu přece nesmí být závislá na DNS systému.

Ano, slunce nesmí svítit. :)))

> dyž se chci spojit se strojem 1.2.3.4, tak nevidím důvod, proč bych měl znát jeho doménové jméno.

Copak vaše verze gethostbyname() neakceptuje numerickou IP adresu? Co máte za systém? Neměl byste to reklamovat?

Já svůj systém reklamovat nehodlám, funguje přesně tak, jak chci. Jenom mi vysvětlete, jak tedy pomocí toho dyndns.org přesměrujete spojení z 1.2.3.4 na 5.6.7.8.

Nejsou, akorát je to složitější.

1) host uvnitř alokuje socket a pošle UDP na stun server, který je venku. STUN server mu řekne z jaké vnější adresy (a portu, pokud z pochybených formálních důvodů port natruc nepovažujeme za součást adresy) packet přišel.

2) host uvnitř krz nějakého prostředníka (lze i STUN server) tuto adresu předá peeru, který je také za NATem, a udělal to samé.

3) Aniž by vytvářel nový socket, začnou hosty za NATem komunikovat se svým peerem, jehož adresu se právě dozvěděli.

Protože se nezměnila vnitřní adresa, NAT použije pro odchozí packety stejnou vnější adresu, jakou použil když routoval packety pro STUN server. Oba NATy se tedy navzájem budou strefovat do správných portů, a traffic projde dovnitř.

Špatně chápete mobilitu. Locality dependent adresu udělat mobilní nejde, lze jen zavést locality independent adresy, a s nimi pracovat jako s normálními. Přeju hezký zbytek dne.

no jo, prostě naprostá prasárna. Dá se to udělat transparentně tak, aby to fungovalo bez zásahu do aplikace v případě, že STUN nemám a funguji normálně bez NAT a i pro situaci, kdy je stroj za STUN strojem?

Opravdu? Jenom jestli vy náhodou nekecáte. V IPv6 je IMHO možné udělat téměř libovolnou adresu mobilní.

ze koncept Internetu prisel z akademickeho prostredi

On Vladimir Odoevsky byl akademik?

Ano, dokonce i Odoevsky byl akademik:

Vladimir Odoevsky (1804-1869) was a fascinating and encyclopedic figurein nineteenth-century Russian culture, who in his day was mentioned in the same breath as Pushkin and Gogol. Thinker, pedagogue, musicologist, amateur scientist and public servant, he is now undergoing a revival as a virtually rediscovered writer of Romantic and Gothic fiction.

To dost těžko. Router si určitě nebude pamatovat nějakou globální řídkou bitmapu pro celý adresní vektor. A udělat to jako redirekt taky nepůjde, když stará lokace bude nedostupná.

Viz článek P. Satrapy nebo přímo RFC 3775.