» »

Naslovi IPv4 bodo pošli prihodnje leto

1
2
»

ABX ::

Če želiš pregledati 2^64 IP6 naslovov na enem prefiksu in, če vsak poskus traja samo 1E-6s (eno mikrosekundo) boš potreboval "samo" 583344 let, tri mesece in nekaj dni.


Ouch

Ampak imam občutek da bojo pisci virusov našli work-around.
Vaša inštalacija je uspešno spodletela!

Zgodovina sprememb…

  • spremenilo: ABX ()

Bakunin ::

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


DNS ? ;)
http://ipv6.si/

rolihandrej ::

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?
http://www.r00li.com

arjan_t ::

lahko ti port forwarda nek program ali pa trojanec

MrStein ::

Če imaš trojanca je popolnoma vseeno, ker lahko vzpostavi outgoing povezavo in prenese kaj 'če.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

BlueRunner ::

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.

JanZorz_go6 ::

Ne rabiš ti z firewallom blockat porta, če ta port hladilnik itak ignorira. Kira bedarija imeti firewall pred tem pametnim hladilnikom in potem odpreti ta port, da lahko gledaš kaj maš v hladilniku. In doseše samo to, kar si imel že na začetku. Prost dostop do tega porta in igrnore/block za vse ostalo.


Moj Rade Končar toaster po potemtakem moral imeti dodatni proc in dodaten ram za firewall. Prav tako hladilnik in vsak senzor v mojem akvariju. Poleg tega tudi vse moje IPv6 kamere in vsaka komponenta pametne hiše in na vsakem od 445.973 senzorjev in naprav bom imel in vzdrževal svoja pravila.

Komaj čakam.

Firewall mora biti na rezidenčnem koncu povezave v internet. Period.

Jan Žorž
--
http://go6.si/

Zgodovina sprememb…

nekikr ::

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

JanZorz_go6 ::

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?


Kaj pa če aplikacija zahteva port, katerega je pred tem zahteval že drugi host?

Ne trudi se z odgovorom, na to smo jih že opozorili na UPnP forumu in se sedaj praskajo po glavi, kako to rešit.

Ni vse tako "universal".

Jan
--
http://go6.si/

JanZorz_go6 ::

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


:)

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ž
--
http://go6.si/

Bakunin ::

a ni praksa /64 per user/org ? a usmerjalo naj bi se pa to preko /127 ?
http://ipv6.si/

BlueRunner ::

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.

ABX ::

Ne rabiš ti z firewallom blockat porta, če ta port hladilnik itak ignorira. Kira bedarija imeti firewall pred tem pametnim hladilnikom in potem odpreti ta port, da lahko gledaš kaj maš v hladilniku. In doseše samo to, kar si imel že na začetku. Prost dostop do tega porta in igrnore/block za vse ostalo.


Moj Rade Končar toaster po potemtakem moral imeti dodatni proc in dodaten ram za firewall. Prav tako hladilnik in vsak senzor v mojem akvariju. Poleg tega tudi vse moje IPv6 kamere in vsaka komponenta pametne hiše in na vsakem od 445.973 senzorjev in naprav bom imel in vzdrževal svoja pravila.

Komaj čakam.

Firewall mora biti na rezidenčnem koncu povezave v internet. Period.

Jan Žorž


Če se želiš pogovarjat z hladilnikom bo tako. Lahko pa še vedno zaupaš klasiki. Your choice.
Vaša inštalacija je uspešno spodletela!

JanZorz_go6 ::

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
--
http://go6.si/

JanZorz_go6 ::


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.


To debato sva na debelo cez pregonila z Ole Troanom iz Cisca, ki je med drugim tudi avtor nekaterih doticnih RFCjev in draftov.

http://www.ietf.org/id/draft-ietf-v6ops... - specifikacija zahtev za IPv6 capable CPE
http://www.ietf.org/rfc/rfc3633.txt - IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6

Ne vidim cisto natancno, kje se tebi tukaj prikrade DPI zraven. Z DHCPv6 opcijo, opisano v teh dokumentih dodelis naslovni prostor CPE-ju, katerega uporabi za naslavljanje lokalnega omrezja (ali omrezij), avtomatsko razdeli segment na /64 subnete in jih dodeli ETH portom. Siple ko pasulj, predvsem pa potrjen standard. No DPI involved, no magic involved.

Zakaj ne alocirati manj kot /64 na eth port? Veliko razlogov. Tukaj so zbrani nekateri:
http://tools.ietf.org/html/draft-narten...

Jan
--
http://go6.si/

BlueRunner ::

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?

JanZorz_go6 ::

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?


Paketom v RT prometu definiras vrednost "flow label" polja v IP headerju. Ravno zato se je to polje uvedlo. QoS je sedaj standarden v stacku (TOS polje) in v povezavo s flow label poljem imamo krasno kombinacijo in mehanizem za kontrolo RT prometa. Najlepse pri vsem skupaj je pa to, da se mora tega zavedati kompletna infrastruktura, saj je to del standardnega stacka (kot flow se definira in obravnava na podlagi tripleta src.addr-dest.addr-flowID)

FlowLabel je nekaj najboljsega, kar se je lahko zgodilo "novemu" protokolu :)

/jan
--
http://go6.si/

BlueRunner ::

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.

jl ::

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?

JanZorz_go6 ::

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
--
http://go6.si/

Zgodovina sprememb…

JanZorz_go6 ::


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.


True. To se pa dogaja zato, ker ISP-ji pozabljajo, kaj je njihova naloga. Network ima nalogo, da prenese paket iz hosta A na host B. Ali iz serverja k uporabniku, ce hoces tako. Nic vec, nic manj. Mi pa vtikamo vmes neke pametne naprave, ki samo ovirajo paket na svoji poti. Dajmo spravit pakete do uporabnika in nehajmo komplicirati.

Vem, da tako to ne gre v modernem business svetu, kjer je treba narediti sistem tako, da bos lahko zaracunal vsako malenkost... a kaj cmo, vcasih je treba zadevo pogledati iz distance.

/jan
--
http://go6.si/

jl ::

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

BlueRunner ::

Vem, da tako to ne gre v modernem business svetu

Včasih so razlogi tudi za stranko pozitivni. Tipičen primer je npr. zagotavljanje delovanja telefonije. Če na za drugo, pa zato, da bo lahko navaden smrtnik poklical 112, ne da bi moral prej ustaviti torrente. Včasih pa razlogi izhajajo tudi iz kakšnih zakonskih predpisov...

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.

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.

JanZorz_go6 ::


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
--
http://go6.si/

Zgodovina sprememb…

BlueRunner ::

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.

JanZorz_go6 ::

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
--
http://go6.si/

BlueRunner ::

Ni pa to nevtralnost...

JanZorz_go6 ::

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
--
http://go6.si/

BlueRunner ::

Od tega, da ISP privilegira svoje storitve do tega, da penalizira konkurenče je zelo, zelo majhen premik. Nekateri menimo celo, da v bistvu razlike sploh ni. Nevtralnost je smiselno zagotoviti samo na nivoju prepovedi samovoljne in prikrite cenzure vsebine komunikacije s strani operaterjev. Sicer pa je tista najbolj široko pojmovana "nevtralnost" že dolgo mrtva.

Kar se tiče cenzure, pa je že tako, da se bo v kratkem sprejel prvi zakon, ki jo bo zapovedoval, moč pa bo dal navadnim uradnikom, brez kakršnega koli sodnega nadzora. Začuda ne za "zaščito otrok", za čemer se običajno skrivajo takšne ideje, temveč kot poskus omejevanja dostopnosti tujih iger na srečo. Kako zelo je to tehnično neizvedljivo, pa bolj ali manj ve vsak. Razen, če si tudi pri nas kdo želi postaviti Kitajski zid, s čemer bodo vsa omrežja v Sloveniji nenadoma postala en sam velik ograjen vrt.

Potem bomo pa varni... ;((

Zgodovina sprememb…

JanZorz_go6 ::

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
--
http://go6.si/

BlueRunner ::

Le kaj bodo pri nas naumili vrli uradniki?

NNNP!

Bakunin ::

Sploh
Ni
Moj
Problem
http://ipv6.si/
1
2
»


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Uber še vedno z izgubo

Oddelek: Novice / Rezultati
152189 (1234) WhiteAngel
»

Google presenetil z ogromnim dobičkom, delnica rekordno

Oddelek: Novice / Rezultati
3411691 (9394) BaToCarx
»

Google z rastjo prihodkov in dobička

Oddelek: Novice / Rezultati
114140 (2991) next_byte
»

Microsoft rekordno, a Bing še vedno prideluje izgubo

Oddelek: Novice / Rezultati
104694 (4028) cleanac
»

Apple krepko presegel pričakovanja

Oddelek: Novice / Rezultati
489825 (8135) Matek

Več podobnih tem