IPv6 pro 2.0.x ?

Juraj Rehak glip na napri.sk
Středa Září 9 15:38:26 CEST 1998


On 9 Sep 1998, Tibor Pittich wrote:

> Dňa Wed, 09 Sep 1998 ste napísali:

Dna 9.9.1998 ste ZASA pouzili diakritiku v newsoch...

Btw. ked ten postovy soft nema tolko inteligencie aby nazov dna a mesiaca
prelozil, tak naco preboha tam rve diakritiku???

> >> Ak napriklad paket s sieti LAN typu ethernet ma charakteristicku dlzku
> >> 1024bajtov, po ceste k adresatovy je "mozne" ze sa objavy linka ktora ma nizsiu
Aha... a to odkedy??? Pokial viem MTU ethernetu je 1500 a konkretne to MTU
znamena Maximum Transmision Unit, teda aky najvacsi paket je mozne do tej
siete poslat.
> >> velkost uzitocneho obsahu (prip. zle nastavenu metriku:-) ), napr. prepinac ATM
Metrika s tym nesuvisi ani omylom, ta sa da skor najst v suvislosti s TTL
ale o to tu teraz nejde ;]
> >> rozkuskuje paket na drobnejsie, a posiela dalej, niektori z tychto
> >> rozkuskovanych sa dalej strati a kedze je sucast vecsieho paketu nemoze byt
> >> zostaveny spet, dokonca ked nedorazi chybajuca cast dostatocne rychlo, tak bude
> >> zahodeny cely paket, co urcite nieje prijemne...
To je pri vacsine sieti naozaj pravda ;]
> >> V pripade IPv6 sa zisti aky najmensi paket po ceste je mozne poslat a vsetky
> >> budu poslane s touto velkostou, cize po ceste uz nedojde k "rozkuskovavaniu"
Path MTU discovery existuje aj na IPv4, ale to stale nic neznamena, kedze
pakety nemusia ist stale tou istou cestou (aj ked je pravda, ze vacsinou
idu ;)

> >To je dobry, kdyz bude po ceste ATM prepinac, tak se IP paket rozkouskuje
> >na 53 bytove pakety :-) Opravdu velmi uzitecne. Obavam se ze pletete hrusky 
> >s jabkama.
Presne tak... ATM sice detailne nepoznam, ale pokial viem, tak robi s 53
bajtovymi paketmi, z coho 5 bajtov je hlavicka. Takze keby sa paket na ATM
fragmentoval, tak taky bezny TCP paket ma 20 bajtov IP hlavicku, 20 bajtov
TCP hlavicku, cize 53-(5+20+20)=8 bajtov na data ;]]] Hmm... a to si uz
vobec neviem predstavit paket s IP options ;] Btw. ak tu nahodou niekto
nevie o com tocim, odporucam nastudovat RFC791, RFC792, RFC793. Takze moj
skromny odhad je, ze kedze je blbost nabalovat na kazdych 8 bajtov dat 40
bajtov hlavicky, tak sa to na druhej strane ATMka rovno sklada a dalej sa
posielaju az cele pakety. Ake je skutocne MTU ATMka neviem a momentalne mi
je to jedno ;] Mozno sa na ATM nejaka IP fragmentacia robi, ale len kvoli
obmedzenej dlzke prijmacieho buffra v ktorom sa skladaju ATM pakety ;]
Co sa tej IP fragmentacie tyka, najlepsie je nastudovat si RFC1063 ;]

Btw. tym padom je toto tu cele blbost ;]
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> prave to je problem, totiz, ze tie 53bytove pakety su sucastou dakeho paketu
> vacsieho, ktory sa ma poskladat na stanici dorucitela a ked chyba jeden z tych
> 53 bytovych paketov, tak samozrejme, ze sa neposklada povodny, cize treba
> ziadat znovu o paket... to su hrusky a jablka??;)
asi hej.

> >Vase teorie navic nezahrnuje veci jako load balancing & vypadky smerovacu.
Presne tak...
> asi Vas sklamem, ta teoria nieje moja, ale z casopisu PC Magazine 6/98, kde bol
> dost obsiahly clanok na tuto temu...
Esteze dotycny casopis nekupujem ;]

--
                                .  ,           Glip
                              . ,`o--.                                    --
      ____.....------.'      .,' ,,~''   `,------.....____   
  ''''`    `---.:: ,':       ; ,'         ;`. ;;.---'    '```` 
              `   `:__`-._   `.`.,    _,-'__;'   '    SysAdmin NAPRI s.r.o. 
                   `  `---`---'`'`---'---'  '        Phone: +421-7-5250959  
glip na cyber-wizard.com_______ \`--'/`,,_____________http://glip.planet.sk/
                            ```  '''



Další informace o konferenci Linux