Naslovi IPv4 bodo pošli prihodnje leto

Ampak imam občutek da bojo pisci virusov našli work-around.

DNS ? ;)

lahko ti port forwarda nek program ali pa trojanec

Ko se omenja plug&play mrežo - saj to imamo že danes. Zadevi se reče UPnP. Meni za večino aplikacij ni treba odpirat portov. Ko zaženem aplikacijo si ta sama forwardira port in ko aplikacijo ugasnem se port tudi lepo zapre. Kaj več bi še radi?

Z UPNP verjetno misliš IGD profil. Ta ne pozna IP6. Ravno tako ga tudi ne pozna NAT-PMP.

Plug'n'play omrežje obsega dodelitev ustreznega IP6 naslova, po potrebi nastavitev DNS strežnikov, razločevanje lokalnih imen brez centralnega DNS strežnika in šele nato morda tudi komunikacijo z omrežnega požarnega zidu, ki se bo verjetno nahajal na home gateway (oziroma residential gateway, kot ga poimenuje Wikipedija).

Kar se pa tiče tipov požarnih zidov (network based, host based), pa se bo vedno našlo dovolj primerov, zakaj sta koristna vsak zase in oba hkrati. Da pa se lepo živeti tudi brez kateregakoli.

Tako neumnega posta pa še ne. Več kot 412.800 senzorjev ne boš nikoli imel!

NAT bo šel adijo, kar je dobra stvar. Jan ( pozdravljen, pa srečenega in zdravega ;) ) pa me je presenetil. Očitno sem mu nekje vmes prišel malce do živega.

Tudi tebi enega srecnega pa zdravega :)

Tipičen zaplet pa bo, da bo potrebno požarnem zidu, ki pazi na robu domačega omrežja, še vedno pojasniti, da je na drugi strani računalnik, ki želi sprejemati povezave. Pri temu pa bo še vedno potrebno opletati s tem katera vrata, kateri protokoli, ...

Tu ti pomaga samo poceni rezidenčen L7 DPI firewall. Potem se ne ukvarjaš več s tem, ampak z aplikacijami. Kdaj bodo to uspeli narediti? Dajmo se pustiti presenetiti kakšnim kitajcem...

trenutna paradigma je, da se rezidentom iz več praktičnih razlogov podeljuje oziroma načrtuje podeljevanje prefiksov velikosti /64.

IETF še vedno vztraja na /48 za vsak CPE. Mogoče ima pa uporabnik dva ali več networkov zadaj, /64 je pa najmanj kar se assigna na en eth port...

Jan Žorž

IETF še vedno vztraja na /48 za vsak CPE. Mogoče ima pa uporabnik dva ali več networkov zadaj, /64 je pa najmanj kar se assigna na en eth port...

Mnjah. Tukaj pa ze že zadane ob filozofijo omrežij. Ali želimo široka ali globoka dostopovna omrežja. Ali želimo ločevati storitve na vrhu, potem pa CPE-jem pojasniti samo v katere /64 maske jim spadajo katere povezave, ali pa želimo uporabniku dati /48, potem pa z DPI ločevati in prioritizirati (QoS) različne storitve.

Sam bi osebno raje videl pristop, kjer se CPE-ju pojasni, katere disjoint /64 maske ima za katere storitve, potem pa se QoS prepusti 802.1p/q, MPLS, ... nizkonijoskim tehnologijam. CPE je potem nekoliko enostavnejši in cenejši, QoS potem deluje bolj ali manj neodvisno od naprave (nekateri uporabniki bodo pač želeli uproabljati svoje nadomestke za CPE), v omrežju pa ni potrebno dodajati dodatne DPI tehnologije samo za zagotavljanje QoS. Invaziven DPI je v moji knjižici pač še vedno bav-bav, ki ga odsvetujem, če obstajajo alternative. Čisto preveč enostavno ga je namreč zlroabiti, potem, ko je enkrat vgrajen v načrt omrežja.

Zato gonim svojo /64 zgodbo... amerosi pa, razumljivo, glede na to, da so IMHO totalno zafušali svoje storitve, turijo /48, ker vse gazijo v isti košček naslovov, potem pa poskušajo to smetje sortirati z DPI-ji in njim podobnim dodatnim balastom.

a ni praksa /64 per user/org ? a usmerjalo naj bi se pa to preko /127 ?

Dve varianti imas. Za tunele se daje /64 (ja, za dva IP-ja), v native access networkih se pa uporablja na WAN strani statefull provisioning, to pomeni DHCPv6, kjer lahko v eni od opcij delegiras prefix, katerega potem CPE uporabi za LAN(e). Klasika je /48, nekateri navirajo tudi za /56.

IETF si je zamislil simplifikacijo subnettinga z matriko /32-/48-/64. V vecini primerov je to ok.

Jan Zorz

Ne vidim cisto natancno, kje se tebi tukaj prikrade DPI zraven.

Kako najenostavneje zagotoviš QoS skozi celotno agregacijo za RT promet (V/VoIP, MCast, mgmt, ...), če ga ne ločiš že na L2/L3?

Da, da. To je že OK. Ampak kako pa veš katere labele imajo kater način prenosa? Ker label izbere vir podatkov, tako kot to velja tudi za TOS, to iz vidika ISP-ja pomeni, da ga lahko gleda zgolj informativno, sicer pride do neumnih napak, ki jih je nemogoče diagnosticirati in še težje odpravljati.

Če pa se zahteva pravilnost delovanja kritičnih storitev, pa to pomeni, da mora ISP TOS določiti na napravi, ki je pod njegovim nadzorom - i.e. CPE, in še to na način, da tega ni moč po nesreči zaobiti. To pa pomeni, da pristaneš na fiksno delitev vrat na CPE, kjer ni možno na katera koli vrata priključiti katero koli napravo. To, ali pa začneš uporabljati L7 DPI.

Fiksna delitev vrat pa pomeni, da lahko stvari realiziraš na L2/L3 tudi brez zanašanja na posebne lastnosti IP6, hkrati še vedno podpiraš dual stack, imaš bolj pregledno separacijo storitev, te storitve pa je tudi lažje varovati.

L7 DPI pa pomeni možnost napačne klasifikacije, možnost nehotne zlorabe storitev, več težav pri varovanju celotnega sistema storitev in čisto preprosto samo še eno stvar več, ki pakete zadržuje v vrsti, medtem, ko ugotavlja, ali to spada v bin 1 ali v bin 2.

Morda kdo ve, kaj je s KAME projektom oz kateri NAT-PT open source software se obstaja? NAT-PT je podprt le na Cisco routerjih, se kaj ve, ali je kaksen plan z Cisco ASA?

NAT-PT je poslan na smetisce digitalne zgodovine z RFCjem s strani IETF-ja.

http://tools.ietf.org/html/rfc4966

Pozabi na kakrsnokoli direktno translacijo paketov med IPv4 in IPv6. Ce bos prebral zgornji RFC ti bo jasno zakaj nikoli nobena translacija ne bo delovala pravilno.

Jan Zorz

Morda kdo ve, kaj je s KAME projektom oz kateri NAT-PT open source software se obstaja? NAT-PT je podprt le na Cisco routerjih, se kaj ve, ali je kaksen plan z Cisco ASA?

NAT-PT je poslan na smetisce digitalne zgodovine z RFCjem s strani IETF-ja.

http://tools.ietf.org/html/rfc4966

Pozabi na kakrsnokoli direktno translacijo paketov med IPv4 in IPv6. Ce bos prebral zgornji RFC ti bo jasno zakaj nikoli nobena translacija ne bo delovala pravilno.

Jan Zorz

Je potem se kaksna druga opcija, v primeru ko imam native IPv6 povezavo in dual stack ni mogoc? Cisto za test me je zanimala NAT-PT translacija (DNS-ALG mi deluje s TOTD deamon-om). Za http promet sem sicer testiral tudi tako, da sem imel proxy streznik na dual stacku in to dela OK...

Je potem se kaksna druga opcija, v primeru ko imam native IPv6 povezavo in dual stack ni mogoc? Cisto za test me je zanimala NAT-PT translacija (DNS-ALG mi deluje s TOTD deamon-om). Za http promet sem sicer testiral tudi tako, da sem imel proxy streznik na dual stacku in to dela OK...

pTRTd. To se mi je v go6 labu se najbolje obneslo v navezi s TOTd, a nikakor ne niti priblizno toliko, da bi lahko rekel da zares dela. JE nekako v stanju "it compiles". Razvoj se je nehal leta 2002, pomojem so pogruntali da s tega res nikoli ne bo nic.

http://www.litech.org/ptrtd/

Se enkrat, pozabi na translacijo. Sem sprobal vse, kar obstaja in tudi probal pomagat pri razvoju tega - no go. Get over with it. Jaz sem se ze sprijaznil kaksne dve leti nazaj.

Jan Zorz

vcasih je treba zadevo pogledati iz distance.

Gledano iz distance me pri omenjenju omrežne nevtralnosti vedno piči, da bi spisal nekaj na temu kako to praktično nikjer več ne obstaja. Tudi v Sloveniji ne. Pa še kaj na temo velikega brata se bi dalo dopisati.

Z veseljem bi to prebral :) Na go6.si ti lahko probamo zagotoviti diplomatsko imuniteto, ce to tam napises :D

Povezano s tem, me pa zanima, kdo si bo upal v Sloveniji celoten koncept storitve zastaviti čisto na novo. Nekako sem na to upal pri T-2, pa jim je nekaj zmanjkalo. Samo ne vem česa: idej ali cohones.

Mislim da ne enega ne drugega, pomojem jih je business driver in vlagatelji potiskal zelo hitro naprej levo desno skozi rapid deployment...

Jan Zorz

Pa ravno, ko se tukaj pogovarjamo, je preko ElReg prilezla tale novička o DDoS napadu na nek majhen ISP. Če imaš storitve pomešane med ostalim prometom, bo npr. obramba VoIP-a v primeru takšnega incidenta težja, kot pa, če celoten VoIP zapreš v npr. /34 ograjen vrtiček in takšne zunanje vplive odrežeš že na robu omrežja z usmerjevalnikom. Potem lahko smetje še vedno pride po "nevtralnem" omrežju, ločene storitve pa so še vedno učinkovito zaščitene in idealno tudi neodvisne od dogajanja v sosednjem MPLS tunelu.

Agree. Walled garden je za VoIP in za IPTV storitvi pri ISPju morda kar koristna izbira :)

/jan

Ni pa to nevtralnost...

Odvisno s kom moras komunicirati znotraj storitve. Ce je to znotraj walled-gardna, potem ti je "ves svet" na voljo, celo skoraj end2end :) :) :)

/jan

Tole o igrah na srečo mi je pa znano... le zakaj me to spominja na poskus Pakistana, da bi preprečil dostop državljanom na Youtube in je potem njihov telekom zelo nespretno "hijackal" Youtube /24 prefix? Cel svet je takrat kar nekaj časa pošiljal pakete namesto na Youtube serverje - v Pakistan...

Le kaj bodo pri nas naumili vrli uradniki?

Jan

Sploh
Ni
Moj
Problem