Trend v přidělování routovaného /56 místo /48 doufám brzy vymře, resp. poskytovatelé používající /56. To pak mohou být dohady "a fakt by nestačilo /60? stejně máte jen pár sítí ..".
Samo o sobě /56 není špatné, pokud ISP dodá /48 bez příplatku, pokud ho o to zákazník požádá.
Zdá se mi to, nebo se zase šetří na špatných místech?
16 bitů, 8 bitů, 4 bity...
Podle mě je ideální, když se provider víceméně drží původních návrhů a dává /48 a /64, kde alespoň zákazník ví přesně, na čem je. Tyhlecty mezikousky jsou ze strany UPC čirá buzerace. Čeho se bojí, že na té jejich lince bude někdo provozovat ISP?
Firma když dostane /56 místo /48, tak se maximálně nějak přeadresuje, některé sítě zaswitchuje, ale těžko kvůli tomu bude vymýšlet nějaké ptákoviny.
Jako provozovatel herního portálu se musím často uchylovat k IP banům. IPv4 NAT je zlo, člověk zabanuje "kdoví co".
Pokud budou poskytovatelé přidělovat menší rozsah koncovým uživatelům na IPv6, bude tu zase stejná situace.
Jestliže větší, tak zde bude problém s identifikací, protože pro mě to bude znamenat, že se daný člověk připojuje odjinud a přijde o session. Jinak by to byla bezpečnostní díra.
Podle specifikace má každý uživatel dostat určitý rozsah. Tak se ho držme, pokud to nejde, tak je ten standard k ničemu a nic neřeší.
Standard to až tak moc jasně nedefinuje. Původně sice mělo být /48 na každého zákazníka, ale to byla takováta akademická představa, dnes se dá počítat, že /64 odpovídá jedné adrese /32 pro domácnost, ale větší rozsahy se používat budou. Situace zůstane prakticky stejná jako s IPv4 jen s posunutou hranicí.
Telefónica testuje pro ADSL/VDSL zákazníky skutečně pouze /64 pro LAN, ale další /64 zákazníkovi dá pro PPPoE spojení. Pokud bude zákazník šikovný, tak si těch dalších /64 může taky dát do LAN, i když to nejspíš bude znamenat že nebude moci použít ten oficiálně dodanávaný router (který toto nebude umět).
Myslím, že stačí odebrat IPv6 adresu PPP rozhraní a dát ji namísto toho LAN rozhraní. Vzhledem k tomu, že PPP je point to point, bude to fungovat i když tam žádná IPv6 adresa nebude.
Jediný problém by byl, pokud by O2 z propojovacího rozsahu omezila počet funkčních adres jen na tu jednu, kterou bude mít modem.
Neighbor proxy je něco jako bylo ARP proxy na IPv4? To se ale používalo obráceně - když se IP adresy ze sdíleného síťového segmentu (ne point-to-point) potřebovaly "vytáhnout" někam ven - pak ten router při ARP lhal že ty IP adresy jsou jeho a následně IP pakety routoval jinam.
Tady bohatě stačí ten blok /64 prostě z PPP odebrat a naroutovat někam do LAN. Na PPP stačí jen link local adresy (které se domluví pomocí IPV6CP).
Jinak s přidělováním větších bloků než /64 to možná nějak půjde, ale to není pro tu drtivou většinu uživatelů kteří potřebují jenom bezobslužné krabičky do kterých se zapojí různě barevné kabely (napájení, telefonní linka, ethernet) a ono to prostě funguje. Pro ty je jeden blok /64 pro vnitřní síť přesně to co potřebují.
Ano, zatím (pořád se testuje!) je na PPP globální IPv6 adresa (spolu s celým blokem /64, přiděleno přes RA) a ano, je to tam zbytečné (protože default route jde přes link local adresu která se domluví pomocí IPV6CP). Proto jsem napsal že je možno ten blok /64 odtamtud vzít a použít ve vnitřní síti (vedle toho druhého bloku /64 který je pro vnitřní síť přímo určený a je přiděnený přes DHCPv6 PD).
A proc by to mel delat (a platit za to dalsi penize), kdyz prevazna vetsina domacich uzivatelu si vystaci s /64 ?
Pravidla RIPE (http://www.ripe.net/ripe/docs/ripe-552) se vcelku jasne vyjadruji, ze pridelovat /64 koncovym zakaznikum je OK:
End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64.
Podobne se vyjadruje i RFC 6177, ktere rusi predchozi doporuceni (RFC 3177) automaticky pridelovat /48:
This document moves away from the previous recommendation that a single default assignment size (e.g., a /48) makes sense for all end sites in the general case. End sites come in different shapes and sizes, and a one-size-fits-all approach is not necessary or appropriate.
..
The above-mentioned goals of RFC 3177 can easily be met by giving home users a default assignment of less than /48, such as a /56.
/64 zvladne 2na64tu zariadeni doma, teda presne 18446744073709551616 zariadeni(ip adries per domacnost)...to by malo na jednu domacnost stacit nie? A diskusie o /48 a vyssie su podla mna zbytocne... to je skor pre mensich ISP, je to presne pre 65536 zakaznikov, ktorym moze pekne podla RFC pridelit kazdemu po /64 adries...z spokojny zakazik si moze kazdej svojej bunke v tele dat jednu IP adresu
:-)
Birthday paradox by byl aplikovatelny jen kdybys adresy prideloval nahodne. Pokud se budes drzet standardni bezestavove autokonfigurace bez privacy extensions, tak muzes bez potizi pridelis nekolidujici IPv6 adresu vsem ethernetovym zarizenim s korektni MAC adresou (a tech je az 2^48).
Zase taková blbost to není. Sice doma 50 zařízení nemám, ale jsou to 4 routery, 2 televize, 7 počítačů (některé mají 2 adresy - wifi a lan), tiskárna, 3 mobily. Plus může přijít návštěva takže ve dvougeneračním domě dneska není problém využít až 30 adres. A to nemluvím do budoucna, kdy po renovaci vytápění, vodovodu atd. přibudou další zařízení a s nimi spojené routery.
JJ. Souhlas a bude hur.
Pro inteligentni dum bych potreboval 34 adres. A to jen pro automatizaci. Za ip adresou se nemusi schovavat fyzicke zarizeni ale treba sbernice kotle namapovana na ip adresu, na dalsi ip adresy ovladani oken atp.
A to nepocitam beznou domaci elektroniku+jeste virtualy na fyzickych pocitacich atp.
Tak faktem je, že aplikace jednoho kontroleru můžeš bez problémů adresovat porty jako se to dělalo vždycky. Je otázka, jestli potřebuješ adresovat každou roletu zvlášť nebo jen kontroler, který zvládne rolety, světla, topení a příslušná čidla na sluneční světlo, teplotu a podobné nesmysly.
Každopádně problém není s počtem zařízení, to je u IPv6 de facto neomezené (2^64), stejně tak asi nebude úplně nutné k jednotlivým roletám přistupovat zvenčí, takže i kdyby měly být samostatnými jednotkami, tak si klidně vystačí s link-local adresama a nemusí vůbec otravovat router.
Zajímavější situace nastane, když chceš na routeru striktně oddělit jednotlivé sítě a adresovat je samostatně.
Tak pocitejme:
1) interni LAN pro "internetovani" (PCcka ...)
2) oddelena sit pro jiny domaci HW (lednice, pracka, ...)
3) WiFi pro znama zarizeni (vlastni mobil ...)
4) WiFi pro kolemjdouci, navstevy ...
5) Chci pripojit pres wifi pribuzneho, ktery neni v dosahu zadne rozumne site, krome te moji
6) ten pribuzny chce pouzivat stejne rozdeleni siti 1-4
7)
8)
9)
Takze pri 16ti subnetech se do toho tak tak vejdu, neb samo chci routy zaagregovat (i kdyz samo kazda krabka zvladne 16 samostatnych, ale z hlediska spravy uz je to bordel).
Podotykam, ze vyse uvede presne v teto konfiguraci provozuju.
Takze tyhle zvasty o tom jak staci to ci ono si strcte kamsi, neb RFC jasne rika, ze enduser ma dostat /48.
A jsme zase u toho ..
domacnost, ktera preprodava svoji konektivitu jine domacnosti neni bezna domacnost ... pripojeni dalsi domacnosti uz je jina domacnost (enduser) a ma dostat svoje ..
ale to je uplne fuk, protoze pri /64 tam muzete pripojit 18446744073709551616 zarizeni .. tak nevim k cemu vam bude /48. Navic kdyz uz to RFC neplati.
> Podotykam, ze vyse uvede presne v teto konfiguraci provozuju. <
jste asi prvni v CR kdo ma na inet pripojenou lednici a pracku. :)
A mozna i zustanete, rozumny clovek ji ponecha v lokalni IPv6 a neprideli verejnou IPv6 :)
Jo ted ctu nize (pokud to neni kec), ze /64 je nejmensi subnet a dal se to neda delit .. WTF?!? .. no to je mi zase hovadinka od autoru IPv6 .. lol .. proc zase nejaky debilni omezeni .. pak chapu, ze nekdo tech subnetu chce vic jen z duvodu tech subnetu i kdyz objem jednoho subnetu by mu stacil na pripojeni kazdeho atomu domacnosti .. lol.
Mimochodem, v tomto pripade by mohl stacit misto routeru firewall v bridge modu a muzu si oddelit cokoli od cehokoli bez ohledu na subnety.
Staci tu neplkat o hovadinach, a precist si jak IPv6 funguje, ze ... autokonfigurace zarizeni v IPv6 prideluje /64 prefix a zbytek adresy se dopocita (nebo nahodne vygeneruje, nebo prideli z DHCP ...).
A jelikoz normalniho cloveka naprosto nezajima jakou IP adresu bude zrovna ktery zarizeni mit, ale bude ho zajimat, zda je ve skupine zarizeni ktera chce mit pristupna naprosto volne nebo skupine kde chce pristup nejak omezit (napr pouze pro autorizovane uzivatele), tak to definuje prave pridelenym prefixem.
A (mimo jine) i prave proto je IPv6 tak velka, aby nejakej debil zase neresil jak nekomu prideli jednu adresu a jeste za ni bude chtit prachy.
Tohle doporuceni
http://www.apnic.net/policy/ipv6-address-policy#5.5
chapu napr takto
/48 malej ISP
/56 nejaka vetsi spolecnost
/64 obyc. home user
ale je mozne, ze to chapu spatne :)
Ctu prispevky v tomto vlakne a nestacim se divit. Mam pocit, ze tyto nazory pisou nactileti pubertaci, kteri ovladli svet a pritom vubec nevi, ktera bije.
Uvedomujete si vubec velikost prostoru /48? Prefix /64 je naprosta zbytecnost pro domacnost, ale je to prakticke minimum.
/56 bez vetsich problemu pokryje potrebu cele univerzity...
Neeee, odmitam ztracet cas vysvetlovanim... Ani nemusite reagovat na tento prispevek, protoze jsem se opet utvrdil o hlouposti verejnych diskuzi,na ktere nema smysl se ani divat.
Vim jak velkej je /64 prefix.
Tady nejde oto jestli ja si myslim, ze /64 je malo nebo moc.
Je to doporuceni pridelovani site.
Rozdelovani je doporuceni od IANA, tusim ze i v RFC je /64 udavan jako minimalni prefix.
A pro automatickou konfiguraci na siti pro IPv6 potrebujete take prave prefix /64 (jestli se nceco nezmenilo).
Ja ty RFC-cka a doporuceni pridelovani prefixu neurcuji :)
> /56 bez vetsich problemu pokryje potrebu cele univerzity...
No, to dost zavisi na tom, jak ma resenou sit. Vzhledem k tomu, ze /64 je standardni prefix pro jednu L2 sit (a delsi rozumne dat nejde), tak /56 je jen 256 L2 siti. Pokud by napr. mela znacne plochou sit (napr. jedna L2 sit na budovu), tak by se do toho asi vesla [*], pokud by mela sit kosatejsi (napr. L2 sit na katedru), tak tezko.
[*] I kdyz je otazka, kolik budov ma treba UK. Tipoval bych, ze vic nez stovku.
Nezalezi na budovach, jde o velikost broadcast domeny. Pokud poslu do site "255.255.255.255", tak mi odpovi vsechno co v ty siti je. Pokud toho bude dost ...
Nemluve o tom, ze vlastni subnety mivaji jednotlivy laborky, trebas proto, ze kdyz tam nekdo neco robi, tak se tomu daj nastavit extra pravidla a pokud neco podela, nesejme to sit cely skoly.
Ja zase nechapu, proc se do diskuze o IPv6 pletou lidi, kteri vubec netusi, jak IPv6 funguje. /64 neni rozsah, nelze jej routovat. /64 je (nejmensi) subnet pro fyzickou sit. Na mensi siti nebude fungovat autokonfigurace.
Takze jedinej hlupak v diskusi ses ty, protoze si nejses schopen zjistit ani zakladni informace. Ale (zcela zdarma) ti sdelim jeste jedno tajemstvi, univerzity kupodivu maji site (jak divne) odroutovane, protoze switchovana sit s tisici zarizenimi jednoduse nebude fungovat. Vis proc? Protoze broadcast domena. Oni to narozdil od tebe vedi. Dokonce vetsina univerzit nema (ani dnes) problem pridelit verejnou IPv4 cemukoli, co ma v siti, protoze prevazne maji alokovana ohromne IPv4 rozsahy.
IPv4 aplikací je velmá málo. Většina aplikací si řekne o připojení k hostname pomocí TCP nebo UDP nad libovolným IP protokolem a o IP vrstvu se vůbec nestará. Nicméně, pro těch pár rozbitých aplikací doporučuju zhlédnoout Michalovu přednášku o NAT64 a jeho projektu Wrapsix, který zahrnuje i klientskou stranu. Snad budou brzo videa na http://www.nic.cz/ipv6day/.
"IPv4 aplikací je velmá málo. Většina aplikací si řekne o připojení k hostname pomocí TCP nebo UDP nad libovolným IP protokolem a o IP vrstvu se vůbec nestará."
Téměř všechny příklady na BSD sockety, co jsem kdy viděl, počítaly natvrdo s IPv4. Typicky používají volání socket(AF_INET, ...), na převod adresy funkci inet_aton a za gethostbyname kontroly na .sin_family == AF_INET. Obávám se, že většina starších aplikací je psaná přesně takhle.
Nevim jak ve Windows, ale v normalnich operacnich systemech se bez nejakeho druhu socketu do site nedostanete (portalfs je dobry vtip, nepocitam). Takze kdyz interpretovane jazyky a VM budou umet address family vymenit "transparentne" pro uzivatele, porad vam zustane spousta kompilovanych programu.
Jestli pouzivam Boost nebo volam socket(2) primo je v tu chvili uplne jedno, pokud je muj program napr. vyrobeny na zakazku firmou, co uz davno neexistuje. Jeho kod je na disku pravdepodobne davno nekde na skladce a tvorit komplexni kod stylu getaddrinfo() na urovni assembleru dnes uz moc lidi neumi (a ani jim to nepreju). A bohuzel, takoveto "ipv4-only-forever" programy jsou prave ty, ktere nutne potrebujete - ucetni programy, systemy na zakazku, ruzne sofistikovane rizeni nejakych specializovanych stroju atd.
V tu chvili, nemate-li IPv4-to-IPv6 translation na localhostu, je Vam NAT64 k nicemu. Jo, a napsal tady uz nekdo jak krasne umi Windows XP resolvovat DNS po IPv6-only siti? XP budou, at se vam to libi nebo ne, jeste docela dlouho zabirat velkou cast trhu.
> A bohuzel, takoveto "ipv4-only-forever" programy jsou prave ty, ktere nutne potrebujete - ucetni programy, systemy na zakazku, ruzne sofistikovane rizeni nejakych specializovanych stroju atd.
Coz jsou ovsem typicky software, ktery nepotrebuje komunikovat po Internetu. Takze firme nebude kvuli tomu vadit, pokud jeji ISP nasadi IPv6-only a NAT64 - firma si klidne kvuli takovemu sw interne muze bezet na dualstacku s privatnima IPv4 adresama.
Normalne v diskuzich prilis nereaguji, ale tady jsem musel. Internet neni jen web a email. Naopak, divil byste se kde vsude muzou byt zavislosti na IPV4 zahrnuty. Pro inspiraci se podivejte na prednasku o problemech pri pouziti GridFTP protokolu po IPv6 (timto protokolem se rocne presunete odhadem alespon exabyte dat): http://www.mi.infn.it/ipv6/talks/hepix-20120426/
Dalsim mym oblibenym pripadem je AFS nebo NVFv4 s Kerberos autentizaci...
„Normalne v diskuzich prilis nereaguji, ale tady jsem musel. Internet neni jen web a email.“
Tak jestli jste mi chtěl vážně sdělit tohle, tak to jste se s reakcí nemusel namáhat :).
Z odkázaných slajdů jsem vyčetl, že rozšíření o podporu IPv6 není žádný zásadní problém, takže si údajné exabajty můžou putovat vesele dál. A ani druhý případ nijak zvlášť nepřekonává počet vyjádřený slovy „velmi málo“, zvlášť takto uvedeny bez jakýkoli podrobností či odkazů na bugreporty.
"Tak jestli jste mi chtěl vážně sdělit tohle, tak to jste se s reakcí nemusel namáhat :)."
Vzhledem k tomu, ze jste si vybral jen jednu vetu z peti - co myslite, snazil jsem se rict jen tu jednu vetu, nebo vsech pet? Naprosto zbytecna a hloupa narazka.
Ja si v te prezentaci naopak precetl, ze uchodit zminene sluzby na IPv6 vyvolalo necekane problemy jdouci od nepodpory v ruznych knihovnach pro autentizaci, po problemy s navaznosti na ORACLE a nutnosti jeho ruzne konfigurace. A az se podarilo rozjet IPv6, prestalo chodit IPv4. Podivejte se na odkazovane "all boring details". Dany clovek na tom pracoval nekolik mesicu a musel si klientskou stranu patchnout sam. Ano, neni to neprekonatelny problem (to ostatne technicke problemy byvaji malokdy), ale jen to ilustruje, jak hluboke muzou byt zavislosti na IPv4 a jak netrivialni problemy to muze vyvolat.
Ad dalsi protokoly.
AFS - pokud byste zkusil na 30 vterin pohledat, zjistite, ze na IPv6 supportu se nyni ani nepracuje hned na oficialnich strankach projektu.
NFSv4 - napriklad (treti odkaz v googlu) - http://is.muni.cz/th/255719/fi_b/?jazyk=en;info . Tady je situace lepsi, ale produkcni podpora bude trvat jeste dlouho.
Dle vasich komentaru vyse jsem pochopil, ze byste to do googlu mel zvladnout dat taky.
Samozrejme muzeme vest disputace o tom, kolik je "velmi malo". jedna sluzba? deset? tisic? Jiste uznate, ze to je hloupe. Mym cilem spise bylo ukazat, ze zavislosti na IPv4 adresach muzou byt velmi slozite a prohlasit, ze je jen velmi malo aplikaci, ktere IPv6 nepodporuji je velmi, velmi odvazne.
„Vzhledem k tomu, ze jste si vybral jen jednu vetu z peti“
Tohle vaše tvrzení si neumím vysvětlit jinak, než že prostě chcete prudit. V tom případě vám doporučuju si najít jinou oběť.
„AFS - pokud byste zkusil na 30 vterin pohledat, zjistite, ze na IPv6 supportu se nyni ani nepracuje hned na oficialnich strankach projektu.
NFSv4 - napriklad (treti odkaz v googlu) - http://is.muni.cz/th/255719/fi_b/?jazyk=en;info . Tady je situace lepsi, ale produkcni podpora bude trvat jeste dlouho.“
Vzhledem k tomu, že se jedná o aplikační protokoly, je doplnění podpory IPv6 spíše formalitou.
„Samozrejme muzeme vest disputace o tom, kolik je "velmi malo". jedna sluzba? deset? tisic? Jiste uznate, ze to je hloupe.“
Uznávám, že argumentovat proti mému tvrzení pouze AFS a NFSv4 je hloupé a doporučuju se tomu vyhnout.
„Mym cilem spise bylo ukazat, ze zavislosti na IPv4 adresach muzou byt velmi slozite a prohlasit, ze je jen velmi malo aplikaci, ktere IPv6 nepodporuji je velmi, velmi odvazne.“
Někdy je odvážné říkat i zcela zřejmé věci :).
Ad vytrhavani z kontextu - to delate s oblibou vy. Ja si taky neumel vysvetlit vase "pokud jste nechtel rict nic jineho, tak radeji nepiste" s odkazem na petinu casti meho prispevku jinak, nez naprosto zbytecne rypani.
Zda se mi, ze mate technicky velmi dobre (nejen) IPv6 zvladnute. Jenomze v praxi nelze prohlasit, ze "to je aplikacni protokol, tak to bude formalita prepnout na IPv4". Presne jak pise Santiago v prispevku vedle.
Tech zavislosti muze byt a je skutecne hodne. Mrknete se napr. na to AFS: https://lists.openafs.org/pipermail/openafs-devel/2010-December/018160.html . Tam skutecne prepsani na IPv6 neni moc jednoduche, protoze se s 32bity pocita ve vsech RPC volani.
Pokud jsem Vas doted na konkretnich pripadech nepresvedcil, ze situace neni tak jednoducha, jak si myslite, asi nema smysl v diskusi pokracovat.
„Ad vytrhavani z kontextu - to delate s oblibou vy. Ja si taky neumel vysvetlit vase "pokud jste nechtel rict nic jineho, tak radeji nepiste" s odkazem na petinu casti meho prispevku jinak, nez naprosto zbytecne rypani.“
Kde prosím píšu o vytrhávání z kontextu? Jak jsem říkal, pokud chcete na někoho útočit, vyberte si někoho jiného, já na vás postupně přestanu reagovat.
Pred odeslanim komentare do diskuse o IPv6 by mel root.cz v ramci eliminace duplicitnich prispevku a flamewaru zavest nutnost nejdrive spravne odpovedet na nekolik otazek.
Ke druhemu radku by patrila otazka "co to je privacy extensions?" a ke tretimu potom "mate zajem se na rozvoji ipv6 aktivne podilet, nebo to nechate na produktivnich clenech nasi spolecnosti a jdete sem jen tak placat?". ;-)
A produktivní člen společnosti je uhrovatý student z kolej.mff.cuni.cz ? Já bych třeba všem lidem s nedokončeným vysokoškolským vzděláním a bez nejméně pěti let praxe nedovolil psát do diskuzí. Nejlépe bych jim nedovolil ani veřejně mluvit, pěkně jako v Arabském světě, jsi mladej cucák? Tak mlč a šoupej nohama! :-) Ale asi ani jeden z nás neuspěje! :-D Bohužel!
Kdyby jen jeden; to byste se divil, kolik jich je. I po vice nez peti letech praxe. Vyzadovat "dokoncene vysokoskolske vzdelani" je v tehle zemi uz jen pro vysmech a verejne mluvit opravdu nikde nehodlam. Mlcet a soupat nohama zkousim, ale zadny zvlastni efekt to nema. Ale asi to nekam speje. Bohu dik!
Dozvim se, co chtel neuhrovaty nestudent z Brna s dokoncenym vzdelanim a > 5 lety praxe napsat puvodnim prispevkem, nebo mladi cucaci proste automaticky pozenou svet do zahuby jako v Arabskem svete?
No Privacy extension (PE) je sice fajn koncept, ale kdyz bude cely /48, /56 nebo /64 prefix prirazen jednoznacne Vasi domacnosti (cili v hypotetickem priklade bude mit O2 nekde zaznam, ze to je k Vasi ADSL lince), tak je Vam asi cele PE na houby, maximalne tak k obhajobe s "osobou blizkou", pokud by slo treba o nejaky warez...
Ono PE dela v nekterych pripadech vice problemu nez uzitku, zejmena pokud provider resi firewalling nebo Vy neigbour (NDISC) proxy, takze v nekterych sitich administratori natvrdo pozaduji (pozadovali), aby byla vypnuta.
„tak je Vam asi cele PE na houby“
Zřejmě bude problém spíše se špatným pochopením PE. Hlavním účelem PE je dodržet
alespoň stejné podmínky soukromí jako nabízí IPv4 za NATem, popřípadě IPv4 pohybující se mezi sítěmi. Obvykle člověku stejně nepomůže (protože cookies a podobné věci), ale bylo potřepa dodržet návaznost na IPv4 a v některých případech to může mít smysl.
„Ono PE dela v nekterych pripadech vice problemu nez uzitku, zejmena pokud provider resi firewalling nebo Vy neigbour (NDISC) proxy“
NDISC proxy je taková specialitka, že bych to sem vůbec netahal. Samo o sobě to na IPv6 funguje podstatně hůř než ARP proxy, protože solicited-node multicast. Sám to používám jen výjimečně, když to fakt nejde jinak, a i tak pouze na virtuálních sítích, kde mají všechny virtuální stroje statické adresy.
http://cs.wikipedia.org/wiki/Spojov%C3%A1_vrstva
Ve vztahu k UPC to znamená, kolik zařízení můžete připojit k UPC modemu přes switch (bez routeru), kolik zařízení modem pustí do sítě. Modem si připojená zařízení pamatuje podle MAC adres (identifikátor zařízení na druhé vrstvě), paměť vyresetujete rebootem modemu. Proto je např. při výměněně síťovky (změní se MAC adresa) u některých UPC služeb nutné restartovat modem.
Už dnes existuje omezení na 1/3/5 zařízení (podle toho, jak drahou službu si platíte), kdy každé takové zařízení dostane svou veřejnou IPv4 adresu. Tohle omezení zůstane. Pokud budete chtít mít volnost, budete potřebovat jejich router, na který vám přidělí /56 prefix (=256 IPv6 prefixů pro až 256 domácích podsítí).
No, pokud to omezeni bude opravdu na urovni MAC adres a ne rozdilnych IP adres, tak to pujde jednoduse vyresit tim, ze za UPC modem pichnu bridge, ktery bude delat MAC-NAT (neco podobneho dnes delaji wifi klientske krabicky kvuli limitacim puvodnich ramcu v 802.11).
A kdyby to omezeni bylo na urovni IP adres, tak bude kolidovat s privacy extensions.
Zajimalo by me, jaky presne linkovy protokol pouziva UPC od modemu ke svym routerum. Pokud PPP, tak dost dobre netusim, jak by to mohli kontrolovat na urovni MAC adres (ty se po PPP dal neposilaji). Ledaze by tu kontrolu delal primo modem. Ale UPC pokud vim netrva na tom, aby uzivatel pouzival jejich modem, tazke pak by snad to slo obejit vymenou firmware.
Tu kontrolu dela modem, on si jednoduse pamatuje prvnich X zarizeni ktera se objevi v jeho siti, proto (jak bylo receno vejs) je treba po vymene HW resetovat ten modem, tim to zapomene.
A samo, tohle "omezeni" je naprosta kokotina, neb prakticky neznam domacnost, ktera by za tim modemem nemela jeste vlastni router.
A samo, tohle "omezeni" je naprosta kokotina, neb prakticky neznam domacnost, ktera by za tim modemem nemela jeste vlastni router.
Přesně. Dokonce to tak kdysi někde doporučovali. Když jsem se ptal, jak to bude s IPv6 v tomto případě, jestli budou ochotni přidělit prefix na soukromý router za bridge mode modem, tak říkali, že s touto variantou nepočítají. Takže v této konfiguraci bude IPv6 končit na WAN rozhraní routeru, což je poměrně smutné.