Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: pepak 17. 09. 2012, 07:22:11
-
Zdejší flamovací vlákno "IPv6 - Pověry a fakta" mě znovu upozornilo, že bych pomalu měl řešit nový protokol. Dosud to vždycky vypadalo tak, že jsem se pustil do studia podkladů a následně došel k závěru, že problém buď vyřešit nelze, nebo vyřešit lze, ale zatím pro to nejsou k dispozici zařízení, která by to uměla.
Mám tyto požadavky "ze světa IPv4 a NAT", které bych chtěl nějakým způsobem splnit "ve světě IPv6":
1) Struktura vnitřní sítě musí být absolutně nezávislá na tom, co mi přidělí poskytovatel. Na IPv4 dostanu nějakou adresu A, kterou zná akorát router a za routerem si používám svoje neveřejné adresy, které jsem si sám určil a sám si je spravuji. Pokud mi poskytovatel přidělí novou adresu B, nebo dokonce přejdu k jinému poskytovateli a dostanu adresu C, tak o této změně informuji pouze router a celá vnitřní síť zůstane nezměněna.
- Jde tohle udělat ve světě IPv6? A pokud ano, jak?
2) Struktura vnitřní sítě nesmí být vypozorovatelná zvenku. V IPv4 to NAT docela uspokojivě řeší - všechny vnitřní počítače se se svými požadavky obrátí na router, který "svým jménem a na svůj účet" provede požadavek směrem ven, přijme odpověď a tu pak odešle původci požadavku. Pokud pominu případy, kdy použitý protokol vyšší úrovně sám leakuje informaci o vnitřní síti, a odhady na bázi specifik operačních systémů ("Windows XP normálně dovolí jen 10 odchozích spojení, takže pokud jich před lokální sítí vidím sto, tak to spíš signalizuje víc počítačů za routerem než jeden počítač s hacknutými Windows"), tak zvenku nelze poznat, jestli je moje vnitřní síť tvořena jedním počítačem nebo desítkou počítačů.
- Jde tohle udělat ve světě IPv6? Jestli jsem to dobře pochopil, mělo by to jít jiným mechanismem, ale se stejným koncovým výsledkem, pomocí Privacy Extensions - akorát nevidím, jak to spojit s požadavkem 1 výše.
3) Musí být možné jednoznačně rozpoznat, jestli požadavek nebo odpověď příchází z vnitřní nebo z vnější sítě. Ve světě IPv4 to dokážu dost snadno podle vnější adresy, protože mám zaručeno (aspoň tomu u svého routeru věřím), že router zahodí veškeré packety přicházející z vnější sítě, které mají adresu spadající mezi privátní rozsahy. Naopak ve vnitřní síti používám jedině privátní rozsahy. Tzn. pokud mi přijde packet se zdrojovou adresou v privátním rozsahu, vím, že jde o vnitřní komunikaci, a pokud přijde packet se zdrojovou adresou mimo privátní rozsah, vím, že jde o vnější komunikaci.
- Jde tohle udělat ve světě IPv6? Zdá se mi, že by to mohlo jít, kdybych na routeru zahazoval veškerou komunikaci, která přichází z vnější sítě a současně má zdrojovou adresu v rozsahu, který jsem uvedl jako privátní. Ale opět nevidím, jak to spojit s požadavkem 2. Plus dále nemám představu, jestli to nějaký levný*) router umí.
*) "Levný": Chci to domů. Nemám problém za to zaplatit nějaké rozumné peníze, ale při vědomí, že průmyslový router za desítky tisíc pro domácí použití za rozumnou investici nepovažuji. Tzn. řekněme v ceně do 5K Kč.
Možná by to celé šlo zařídit tak, že i pro svět IPv6, který to "nepotřebuje", implementuji NAT? (Tentokrát skutečný NAT, ne NAPT.)
Prosím, v zájmu diskuse, vyhněme se diskusi o užitečnosti, smysluplnosti, nahraditelnosti apod. těchto požadavků. Pro tuto diskusi je chápu jako konstantu, která musí být plně splněna, i kdyby se stokrát jevila jako nesmyslná. Děkuji.
-
První požadavek jde vyřešit celkem obstojně, u druhého jsou určitá omezení a třetí se dá vyřešit také, jen není mnoho routerů na výběr.
1) Zde se dá využít běžé vlastnosti, že jedno rozhraní může mít více adres a tuíž krom globální adresy se může síť oadresovat unikátními lokálními adresami (obdoba lokálních adres v IPv4) které zůstanou stejné i při změně poskytovatele. Při propojování uvnitř sítě se pak použijí tyto adresy a není nutné je měnit. Při změně poskytovatele se ale změní globální adresy, takže to asi neni řešení na 100%.
2) privacy extension pouze znemožní spočítat hosty v síti, protože ti si pravidelně mění identifikátor rozhraní (posledních 64 bitu IPv6 adresy) ale nezamezí rozpoznání například subnetů. s požadavken 1 se to pojí právě tím, že v IPv6 je běžné mít na jednom rozhraní více IPv6 adres zároveň, proto tam můžete mít jak ULA tak adresu s privacy extension
3) toto se dá řeši na firewalu routeru, požadavky z prefixu vnitřní sítě přijaté na wan se zahodí. Důležité je vybírat router, který umí IPv6 firewall, což bohužel není samozřejmé. nápomocný by mohl být například náš katalog routerů, který je na domací routery zaměřen (http://katr.labs.nic.cz (http://katr.labs.nic.cz))
Nejsou to řešení dokonalá a přesně padnoucí na popsané požadavky. Největší slabinu má řešení v bodě 2, ale to je obecně problém s IPv6, kde je přímá adresovatelnost (a z toho plynoucí i viditelnost sítě) jeden ze základů. Snad to i tak bude nápomocno.
Petr Černohouz
Laboratoře CZ.NIC
-
1) Zde se dá využít běžé vlastnosti, že jedno rozhraní může mít více adres a tuíž krom globální adresy se může síť oadresovat unikátními lokálními adresami (obdoba lokálních adres v IPv4) které zůstanou stejné i při změně poskytovatele. Při propojování uvnitř sítě se pak použijí tyto adresy a není nutné je měnit. Při změně poskytovatele se ale změní globální adresy, takže to asi neni řešení na 100%.
Pokud se pro konfiguraci IP adres ve vnitřní síti použije bezestavová konfigurace, ani přístup do internetu není problém - prostě jen router začne ohlašovat nový prefix a všichni ve vnitřní síti se přizpůsobí. Snad by to samé šlo i s DHCPv6, ale to nemám vyzkoušené - DHCPv6 totiž v porovnání s bezestavovou konfigurací považuji za zbytečně složité a nepřinášející žádné reálné benefity.
-
Díky za odpověď, Petře. Je dobré vědět, že ty požadavky aspoň nějak řešit jdou.
1) Zde se dá využít běžé vlastnosti, že jedno rozhraní může mít více adres a tuíž krom globální adresy se může síť oadresovat unikátními lokálními adresami (obdoba lokálních adres v IPv4) které zůstanou stejné i při změně poskytovatele. Při propojování uvnitř sítě se pak použijí tyto adresy a není nutné je měnit.
To je mi jasné. Nechápu ale, jak se při odesílání požadavku určí zdrojová adresa v TCP packetu (tzn. adresa, na kterou přijde odpověď). Dejme tomu, že mám pro počítač nadefinované dvě adresy, jednu globální (G) a jednu lokální (L). Dále mám webový prohlížeč, ze kterého přistupuji ke dvěma serverům, jednomu ve vnitřní síti, druhému ve vnější síti. No a já bych chtěl, aby packet směřující do lokální sítě měl jako zdrojovou adresu L, zatímco packet směřující na externí server by měl G. Myšleno speciálně na Windows, pokud se to mezi různými OS liší.
(Měl jsem totiž představu, že na externím interfacu budu zahazovat všechno, co má cílovou adresu z lokálního rozsahu, a na interním interfacu budu zahazovat cokoliv, co má zdrojovou adresu z lokálního rozsahu.)
2) privacy extension pouze znemožní spočítat hosty v síti, protože ti si pravidelně mění identifikátor rozhraní (posledních 64 bitu IPv6 adresy) ale nezamezí rozpoznání například subnetů.
Tak to by mi až tak nevadilo, chci to na doma, takže bych vystačil i s jedním subnetem.
3) toto se dá řeši na firewalu routeru, požadavky z prefixu vnitřní sítě přijaté na wan se zahodí. Důležité je vybírat router, který umí IPv6 firewall, což bohužel není samozřejmé. nápomocný by mohl být například náš katalog routerů, který je na domací routery zaměřen (http://katr.labs.nic.cz (http://katr.labs.nic.cz))
Díky, ten odkaz si důkladně prostuduji.
-
To je mi jasné. Nechápu ale, jak se při odesílání požadavku určí zdrojová adresa v TCP packetu (tzn. adresa, na kterou přijde odpověď). Dejme tomu, že mám pro počítač nadefinované dvě adresy, jednu globální (G) a jednu lokální (L). Dále mám webový prohlížeč, ze kterého přistupuji ke dvěma serverům, jednomu ve vnitřní síti, druhému ve vnější síti. No a já bych chtěl, aby packet směřující do lokální sítě měl jako zdrojovou adresu L, zatímco packet směřující na externí server by měl G. Myšleno speciálně na Windows, pokud se to mezi různými OS liší.
Postup volby adresy je poměrně složitý a nejlépe se tomu věnuje kapitola 3.12 na straně 84 knihy o IPv6 (http://www.root.cz/knihy/internetovy-protokol-ipv6-treti-vydani/). Ve zkratce: Nejprve se vybere cílová adresa, mimo jiné i tak, aby byla preferování ta s kratším dosahem. Pak se k tomu vybere odpovídající zdrojová adresa tak, aby se k sobě nejlépe hodily. Pokud tedy z DNS vypadne globální adresa a ULA adresa, měla by být vybrána ULA, protože má menší dosah. Při navazování spojení na ULA adresu se vždy vybere zdrojová ULA adresa, protože má shodný dosah a nejdelší společný prefix.
Další možností je použití split DNS, kdy do vnitřní sítě budou hlášeny pouze ULA adresy, zatímco do Internetu pouze globální adresy.
-
Já jsem si postavil router s VIA procesorem který jsem sehnal levně a na něm provozuji Pfsense 2.1 Beta.
Umí už IPv6 a má i DHCPv6. Funguje v pohodě, přístupy z venku na vnitřní IPv6 blokuje.
Zatím jsem spokojen.
-
Přesně na ten problém v bodě 1) jsem se už několikrát ptal. Všechny navrhované mechanismy vyžadují "spolupráci" klientů. Má to své výhody i nevýhody. Další možností (i když kontroverzní) je použití nějakého mapování 1:1, například tuším netfilter umí target NETMAP i pro IPv6. Pak se dají použít site-specific adresy a mapovat je na routeru. Má to své výhody i nevýhody, zastánce i zuřivé odpůrce, ale rozhodně by to mělo být funkční řešení (sám jsem zatím ještě nezkoušel).
-
A ještě k tomu routeru, vcelku dobrou implementaci mají Mikrotiky, třeba http://www.i4wifi.cz/rb750-32-mb-ram-400-mhz-5x-lan-vc-l4_d1499.html . Stojí to pár stovek, je to poměrně robustní, komfortní a žere to 00nic. Nevýhodou je, že co tam není, to se tam nedostane, ale zase co tam je, to většinou funguje bez problému a dobře....
-
A ještě k tomu routeru, vcelku dobrou implementaci mají Mikrotiky, třeba http://www.i4wifi.cz/rb750-32-mb-ram-400-mhz-5x-lan-vc-l4_d1499.html . Stojí to pár stovek, je to poměrně robustní, komfortní a žere to 00nic. Nevýhodou je, že co tam není, to se tam nedostane, ale zase co tam je, to většinou funguje bez problému a dobře....
Jo, to je dobrá krabička, zrovna jsem jednu kupoval. Jenom to má jednu zajímavou feature, že první port je jakoby wan a nejde dát do switche.
-
Jo, to je dobrá krabička, zrovna jsem jednu kupoval. Jenom to má jednu zajímavou feature, že první port je jakoby wan a nejde dát do switche.
Co? Kterej Mikrotik? Mám RouterBoardy 433 a 750 a na obou si můžete porty poskládat, jak uznáte za vhodné
-
Co? Kterej Mikrotik? Mám RouterBoardy 433 a 750 a na obou si můžete porty poskládat, jak uznáte za vhodné
There are five individual Ethernet ports. Ports 2-5 are connected to a switch and can be switched together by
an option in the RouterOS software.
http://routerboard.com/pdf/356/rb750gl-ug.pdf
-
There are five individual Ethernet ports. Ports 2-5 are connected to a switch and can be switched together by
an option in the RouterOS software.
http://routerboard.com/pdf/356/rb750gl-ug.pdf
Aha, beru zpět, používám všude bridge a ten funguje
-
Jo, to je dobrá krabička, zrovna jsem jednu kupoval. Jenom to má jednu zajímavou feature, že první port je jakoby wan a nejde dát do switche.
Ale jde dát do switche. Je to konfigurovatelné, zda ether1 jde přímo do CPU svou vlastní linkou (což je default stav a vhodné pro funkci routeru, kde je ether1 WAN a zbytek LAN) nebo všech pět portů je zapojeno do jednoho switch chipu (a s CPU spojeno jendou linkou).
Viz volba /interface ethernet switch set switch1 switch-all-ports=yes
-
2pepak
ad 1) taky si muzes poridit PI adresy, coz v pripade IPv6 asi nebude nikterak zasadni problem => mas svuj vlastni rozsah verejnych adres, provideru muzes mit kolik chces, jen jim oznamis, jaky rozsah adres maji routovat.
ad 2) ono lze schovat strukturu site za NATem? Vazne? To by me zajimalo jak ... protoze kazdej prohlizec s aktivnim scriptovanim vyzvani svoji privatni adresu. K privacy extensions asi toliko, ze zdaleka ne kazda aplikace to pouziva spravne - aktualne vim napr o ftp klientech (v TC a fillezilla) ktere pouziji fixni IPv6 adresu misto te random.
ad 3) tady jen pozor, ze pokud bys chtel resit nejakou rozsahlejsi sit, tak stav, kdy ti prijde zvenku paket se zdrojovou adresou "uvnitr" muze byt normalni - napriklad pokud mas dva subnety, kazdy ma nejakyho jinyho providera, a doslo k preruseni primeho spoje.
Ad HW: Mikrotik je sice pouzitelnej, ale v nekterych ohledech je to ... dobrou zkusenost mam trebas s linksysem (coz je levny cisco). Dodavany softik taky nic moc, ale da se to (ve vetsine pripadu - treba overit predem) snadno flashnout trebas na openwrt/ddwrt/... => dostanes prakticky plnohodnotnyho tucnaka.
Na NAT na IPv6 zapomen. Naprosty nesmysl. Mam tu dualstack - sit o cca 150 zarizenich. Firewall IPv6 ma 1/10 pravidel => desetinova pravdepodobnost ze je nekde chyba.
-
ad 2) ono lze schovat strukturu site za NATem? Vazne? To by me zajimalo jak ... protoze kazdej prohlizec s aktivnim scriptovanim vyzvani svoji privatni adresu. K privacy extensions asi toliko, ze zdaleka ne kazda aplikace to pouziva spravne - aktualne vim napr o ftp klientech (v TC a fillezilla) ktere pouziji fixni IPv6 adresu misto te random.
To je v podstatě správně, protože FTP standardně navazuje datové spojení zpět a do té staré dočasné by se už třeba nemusel trefit. (ikdyž to je spíš tak na jistotu, protože zaniknout u existujícího kontrolního spojení by neměla)
-
ad 2) ono lze schovat strukturu site za NATem? Vazne? To by me zajimalo jak ... protoze kazdej prohlizec s aktivnim scriptovanim vyzvani svoji privatni adresu.
I kdyby skutečně vyžvanil, tak nevím, kde jsi přišel k závěru, že mám zapnuté aktivní skriptování.
Každopádně tvoje názory na problematiku NATu nejsou předmětem otázky. Otázka se týká toho, jak dosáhnout efektů, které pro IPv4 dosáhnu pomocí NATu.
Na NAT na IPv6 zapomen. Naprosty nesmysl.
Proč? Pokud to má nějaký objektivní technický důvod (tzn. ne "nemám NAT rád" nebo "tak nebyl IPv6 zamýšlen"), rád si ho poslechnu, ale bez argumentace je to bezcenný výkřik.
-
Až budu donucen přejít na IPv6, tak také půjdeme přes NAT.
A to už jen k vůli plné kontrole vnitřního rozsahu IP adres.
Naštěstí se dobrá NAT řešení pro IPv6 začínají objevovat.
Nicméně to nebude NAT typu 1 adresa ku N adresám vnitřním, ale Y:N.
-
Až budu donucen přejít na IPv6, tak také půjdeme přes NAT.
A to už jen k vůli plné kontrole vnitřního rozsahu IP adres.
Naštěstí se dobrá NAT řešení pro IPv6 začínají objevovat.
Nicméně to nebude NAT typu 1 adresa ku N adresám vnitřním, ale Y:N.
No jistě, NATem toho totiž můžete hodně kontrolovat (sarcasm sign) :-)
Jinak to už jste slyšel, že v IPv6 má jedno síťové rozhraní více IP adres?
-
ad 1) taky si muzes poridit PI adresy, coz v pripade IPv6 asi nebude nikterak zasadni problem => mas svuj vlastni rozsah verejnych adres, provideru muzes mit kolik chces, jen jim oznamis, jaky rozsah adres maji routovat.
PI adresy rozhodně není snadné získat, pokud k jejich použití není objektivní důvod (a to, že někdy v budoucnu možná budu měnit providera a nechce se mi přeadresovávat síť, objektivní důvod není). Kdyby všichni používali PI adresy, globální směrovací tabulka by narostla do astronomických rozměrů a Internet by měl dost problémů zůstat pohromadě.
Pokud jde o jednorázovou a trvalou změnu providera, jediným správným řešením je síť přeadresovat. Taková změna se neděje příliš často a vždy je spojena s náklady navíc. Pokud jde o zálohování občasného výpadku a při výpadku vystačí síť s nouzovým režimem, kdy nejde navazovat spojení dovnitř, pak bych volil po dobu výpadku bezestavový NAT, který dočasně přeloží původní nefunkční prefix na nový, funkční.
-
Pokud jde o jednorázovou a trvalou změnu providera, jediným správným řešením je síť přeadresovat. Taková změna se neděje příliš často
Tak a teď jsem z toho jelen. Pokud vím, tak hlavním smyslem zero conf v IPv6 je to, aby se nějaké adresy vůbec nemusely řešit. Dokážu si tedy představit, že mám síť, kde všechny počítače mají automatickou konfiguraci s tím, že prefix získají od routeru. Dále pak mají pevné lokální adresy, tak, aby dokázaly přistupovat na služby uvnitř sítě bez nutnosti řešit prefix. Taková síťová tiskárna nebude používat automatickou adresu, ale bude ji nastavena statická lokální adresa.
U strojů, které mají mít pevnou adresu avšak s konfigurovatelným prefixem bych si dokázal představit nastavení ze dvou částí prefix+pevná část. Stejné nastavení by mělo být v DNSku. Případně tedy to DNS reloadnout při každé změně prefixu.
A to ještě nevidím do systému hledání sousedních uzlů. Co když vůbec nebude potřeba hledat tiskárnu podle IP adresy? Co když si ji nějakým multicastem nechám vyhledat a najdu ji pod jejím NetBIOS jménem např? Pak je mi úplně jedno, kolikrát za den se mi změní prefix sítě díky přecházení mezi providery.
Na mobilu jsem co chvíli připojen k jinému poskytovateli. Neznám aplikaci, které by to vadilo.
-
Tak a teď jsem z toho jelen. Pokud vím, tak hlavním smyslem zero conf v IPv6 je to, aby se nějaké adresy vůbec nemusely řešit. Dokážu si tedy představit, že mám síť, kde všechny počítače mají automatickou konfiguraci s tím, že prefix získají od routeru.
Ano, tak taky proběhne přeadresace, router prostě oznámí nový prefix. Pokud nechcete, aby se adresy měnily, tak kromě globálních můžete použít ještě ULA.
Dále pak mají pevné lokální adresy, tak, aby dokázaly přistupovat na služby uvnitř sítě bez nutnosti řešit prefix. Taková síťová tiskárna nebude používat automatickou adresu, ale bude ji nastavena statická lokální adresa.
Síťová tiskárna určitě bude používat i automatickou adresu (nebo rovnou několik, třeba ULA). Lokálně se k ní ale bude přistupovat hlavně přes lokální adresu, a to nejspíš ještě přes mDNS, takže konkrétní adresa vás vůbec nebude zajímat.
U strojů, které mají mít pevnou adresu avšak s konfigurovatelným prefixem bych si dokázal představit nastavení ze dvou částí prefix+pevná část. Stejné nastavení by mělo být v DNSku. Případně tedy to DNS reloadnout při každé změně prefixu.
Takhle se chová automatická adresa odvozená z MAC adresy, tj. vypnuté Privacy Extensions. O implementaci, kdy si zvolíte druhou část pevnou a první se použije z prefixu, nevím, ale teoreticky je samozřejmě taky možná.
A to ještě nevidím do systému hledání sousedních uzlů. Co když vůbec nebude potřeba hledat tiskárnu podle IP adresy? Co když si ji nějakým multicastem nechám vyhledat a najdu ji pod jejím NetBIOS jménem např? Pak je mi úplně jedno, kolikrát za den se mi změní prefix sítě díky přecházení mezi providery.
Ano, lokální adresy se dají vyhledávat přes mDNS (alias zeroconf nebo Avahi), třeba na počítači „domaci“ zobrazíte web zadáním „http://domaci.local/“ nebo tisknout přes něj můžete pomocí „ipp://domaci.local/tiskárna“.
Na mobilu jsem co chvíli připojen k jinému poskytovateli. Neznám aplikaci, které by to vadilo.
-
Pokud jde o jednorázovou a trvalou změnu providera, jediným správným řešením je síť přeadresovat. Taková změna se neděje příliš často
Tak a teď jsem z toho jelen. Pokud vím, tak hlavním smyslem zero conf v IPv6 je to, aby se nějaké adresy vůbec nemusely řešit. Dokážu si tedy představit, že mám síť, kde všechny počítače mají automatickou konfiguraci s tím, že prefix získají od routeru.
Jasně, přeadresování jedné koncové sítě, kde se používá automatická konfigurace je jednoduchý případ. Můj příspěvek mířil na složitější topologie, kde je routerů a koncových sítí více a přeadresování bude pravděpodobně vyžadovat rekonfiguraci každého routeru.
-
přeadresování bude pravděpodobně vyžadovat rekonfiguraci každého routeru.
Proč? Tak tam dejte switche ;D
Si myslím, že IPv6 routery by se měly umět překonfigurovat sami, když dostanou oznámení o změně prefixu. Představa, že budu při každé změně prefixu posílat pracovníka do terénu mi přijde naprosto ujetá. Snad proto to oznamování vzniklo ne?
-
Si myslím, že IPv6 routery by se měly umět překonfigurovat sami, když dostanou oznámení o změně prefixu. Představa, že budu při každé změně prefixu posílat pracovníka do terénu mi přijde naprosto ujetá. Snad proto to oznamování vzniklo ne?
Tak to budete muset asi ty routery vybavit nějakou umělou inteligencí, aby dokázaly odvodit, jak ty koncové sítě mají přeadresovat. Zatím imho neexistuje protokol, který by mezi routery říkal, jaký je prefix celé sítě (asi by to šlo šoupnout do BGP nebo IS-IS jako rozšířený atribut a z toho potom odvozovat adresu koncové sítě)
-
Tak to budete muset asi ty routery vybavit nějakou umělou inteligencí, aby dokázaly odvodit, jak ty koncové sítě mají přeadresovat. Zatím imho neexistuje protokol, který by mezi routery říkal, jaký je prefix celé sítě (asi by to šlo šoupnout do BGP nebo IS-IS jako rozšířený atribut a z toho potom odvozovat adresu koncové sítě)
Cože? Já tedy nejsem odborník na současné programové vybavení routerů. A taky neznám vaši topologii sítě. Ale pokud to vezmu obecně, tak když budou routery od brány dostávat prefixy /56. je problém jim natvrdo nastavit ten další oktet aby dále oznamovaly prefix /64 s tím, že se nakonfigurují podle oznámeného prefixu /56?
Pokud je ta topologie ještě složitější, pak už to není o organizaci vnitřní / vnější síť a organizace by měla mít vlastní prefix, ne?
-
Tak to budete muset asi ty routery vybavit nějakou umělou inteligencí, aby dokázaly odvodit, jak ty koncové sítě mají přeadresovat. Zatím imho neexistuje protokol, který by mezi routery říkal, jaký je prefix celé sítě (asi by to šlo šoupnout do BGP nebo IS-IS jako rozšířený atribut a z toho potom odvozovat adresu koncové sítě)
Existuje, jmenuje se Prefix delegation (http://en.wikipedia.org/wiki/Prefix_delegation)
-
Tak to budete muset asi ty routery vybavit nějakou umělou inteligencí, aby dokázaly odvodit, jak ty koncové sítě mají přeadresovat. Zatím imho neexistuje protokol, který by mezi routery říkal, jaký je prefix celé sítě (asi by to šlo šoupnout do BGP nebo IS-IS jako rozšířený atribut a z toho potom odvozovat adresu koncové sítě)
Prosím seznam se s rfc3769, už 8 let není umělá inteligence potřeba. No dobrá, zařízení které ho implementují je jako šafránu.
-
Cože? Já tedy nejsem odborník na současné programové vybavení routerů. A taky neznám vaši topologii sítě. Ale pokud to vezmu obecně, tak když budou routery od brány dostávat prefixy /56. je problém jim natvrdo nastavit ten další oktet aby dále oznamovaly prefix /64 s tím, že se nakonfigurují podle oznámeného prefixu /56?
Triviální, použitelné pouze u malých sítí, kde si to správce může obejít i sám. Až budete mít síť, kde budete mít velkou lokalitu využívající 135 /64 prefixů, několik malých lokalit využívajících 40 /64 prefixů a pobočky s jedním routerem využívajícím 8 /64 prefixů, teprve potom to začne být s přidělováním zajímavé.
Pokud je ta topologie ještě složitější, pak už to není o organizaci vnitřní / vnější síť a organizace by měla mít vlastní prefix, ne?
Co je to vlastní prefix? Myslíte PI adresy? Ty se přidělují jenom za poměrně specifických situací.
-
Tak to budete muset asi ty routery vybavit nějakou umělou inteligencí, aby dokázaly odvodit, jak ty koncové sítě mají přeadresovat. Zatím imho neexistuje protokol, který by mezi routery říkal, jaký je prefix celé sítě (asi by to šlo šoupnout do BGP nebo IS-IS jako rozšířený atribut a z toho potom odvozovat adresu koncové sítě)
Prosím seznam se s rfc3769, už 8 let není umělá inteligence potřeba. No dobrá, zařízení které ho implementují je jako šafránu.
Jo, až na to, že dotyčné RFC je v jednotném čísle. Umožňuje nakonfigurovat 1 router, nikoliv celou síť. A sítí rozumím něco o více routerech.
-
Tak to budete muset asi ty routery vybavit nějakou umělou inteligencí, aby dokázaly odvodit, jak ty koncové sítě mají přeadresovat. Zatím imho neexistuje protokol, který by mezi routery říkal, jaký je prefix celé sítě (asi by to šlo šoupnout do BGP nebo IS-IS jako rozšířený atribut a z toho potom odvozovat adresu koncové sítě)
Prosím seznam se s rfc3769, už 8 let není umělá inteligence potřeba. No dobrá, zařízení které ho implementují je jako šafránu.
Jo, až na to, že dotyčné RFC je v jednotném čísle. Umožňuje nakonfigurovat 1 router, nikoliv celou síť. A sítí rozumím něco o více routerech.
No dobrá pán slovíčkaří, místo aby přiznal chybu. Takža nejdřív argumenty. Dané rfc má v scenario termín "Customer networks", to k jednotnému číslu. Brání něco mít prefix delegation i na těch ostatních routerech v síti? Mám pokračocat ad hominem nebo uznáš, že řešení tu je?
-
Jinak to už jste slyšel, že v IPv6 má jedno síťové rozhraní více IP adres?
Jistě, ale to šlo i u IPv4, a právě k vůli výjimkám pro firewall se mi to ale vůbec nelíbí.
-
No dobrá pán slovíčkaří, místo aby přiznal chybu. Takža nejdřív argumenty. Dané rfc má v scenario termín "Customer networks", to k jednotnému číslu. Brání něco mít prefix delegation i na těch ostatních routerech v síti?
Ano, brání. A to konkrétně nehierarchická struktura sítě. Představte si jednoduchou síť se čtyřmi routery spojenými do čtverce, s jedním routerem připojeným k providerovi. V síti běží dynamický směrovací protokol (OSPF, IS-IS, ...). Od kterého routeru dostane prefix router ležící napříč? Jak zajistíte, aby při připojení dalšího routeru dostal nadřazený router další prefixy, pokud svoje už vyčerpal? Jak budete požadovat prefixy, když vypadne jedna z linek (ale síť je pořád funkční)?
Vámi navrhované dělení není možné - právě kvůli redundanci sítě a výpadkům jedné linky. Můžete oznamovat celý prefix. To už ale není prefix delegation podle RFC a víc se to podobá mému návrhu šířit celý prefix přes routovací protokol.
Mám pokračocat ad hominem nebo uznáš, že řešení tu je?
Asi budete muset pokračovat ad hominem, ale s někým jiným.
-
Jo, až na to, že dotyčné RFC je v jednotném čísle. Umožňuje nakonfigurovat 1 router, nikoliv celou síť. A sítí rozumím něco o více routerech.
Jeden prefix delegation konfiguruje jeden router, ale samozřejmě těch prefix delegations můžete poslat, kolik uznáte za vhodné, stejně jako ten nakonfigurovaný router může delegovaný prefix rozsekat jakkoliv podle své úvahy a použít pro prefix delegation na routery pod ním.
Ano, brání. A to konkrétně nehierarchická struktura sítě. Představte si jednoduchou síť se čtyřmi routery spojenými do čtverce, s jedním routerem připojeným k providerovi. V síti běží dynamický směrovací protokol (OSPF, IS-IS, ...). Od kterého routeru dostane prefix router ležící napříč? Jak zajistíte, aby při připojení dalšího routeru dostal nadřazený router další prefixy, pokud svoje už vyčerpal? Jak budete požadovat prefixy, když vypadne jedna z linek (ale síť je pořád funkční)?
Router ležící napříč se multicastem na obou vnějších rozhraních zeptá všech tam přítomných routerů na prefix přes DHCPv6, což se doručí oběma routerům na hranách, a oba ty routery přepošlou požadavek na delegaci na hlavní router, který prefix přidělí, a protože žádající je v obou případech ten stejný router, tak dostane v obou případech stejný prefix. Oba routery potom routeru napříč vrátí ten stejný prefix, takže zduplikováním se nic nestane. Pokud jedna linka nefunguje, prostě se to přidělí jen přes tu druhou. Pokud spadnou obě, prefix delegation selže, ale protože stejně nebudete mít přístup do internetu, tak ve výsledku k žádné škodě nedojde a lokálně bude fungovat jenom ULA.
-
Jo, až na to, že dotyčné RFC je v jednotném čísle. Umožňuje nakonfigurovat 1 router, nikoliv celou síť. A sítí rozumím něco o více routerech.
Jeden prefix delegation konfiguruje jeden router, ale samozřejmě těch prefix delegations můžete poslat, kolik uznáte za vhodné, stejně jako ten nakonfigurovaný router může delegovaný prefix rozsekat jakkoliv podle své úvahy a použít pro prefix delegation na routery pod ním.
Ano, brání. A to konkrétně nehierarchická struktura sítě. Představte si jednoduchou síť se čtyřmi routery spojenými do čtverce, s jedním routerem připojeným k providerovi. V síti běží dynamický směrovací protokol (OSPF, IS-IS, ...). Od kterého routeru dostane prefix router ležící napříč? Jak zajistíte, aby při připojení dalšího routeru dostal nadřazený router další prefixy, pokud svoje už vyčerpal? Jak budete požadovat prefixy, když vypadne jedna z linek (ale síť je pořád funkční)?
Router ležící napříč se multicastem na obou vnějších rozhraních zeptá všech tam přítomných routerů na prefix přes DHCPv6,
Jaký multicast? DHCPv6 používá buď link-local multicast, tj. i na všech okolních routerech by musely být DHCPv6 servery, nebo site-local multicast (FF05::1:3), ale site-local adresy byly zrušeny RFC 3879.
což se doručí oběma routerům na hranách, a oba ty routery přepošlou požadavek na delegaci na hlavní router, který prefix přidělí, a protože žádající je v obou případech ten stejný router, tak dostane v obou případech stejný prefix. Oba routery potom routeru napříč vrátí ten stejný prefix, takže zduplikováním se nic nestane. Pokud jedna linka nefunguje, prostě se to přidělí jen přes tu druhou. Pokud spadnou obě, prefix delegation selže, ale protože stejně nebudete mít přístup do internetu, tak ve výsledku k žádné škodě nedojde a lokálně bude fungovat jenom ULA.
připouštím, že by to tak do jisté míry fungovat mohlo (pomineme-li ten multicast na site-local adresy).
Ale mít jeden DHCPv6 server na routeru, který pouze přiděluje prefixy a druhý DHCP server, který přiděluje další parametry (předpokládám, že nebudete chtít pustit správce sítě do konfigurací parametrů pro IP telefony), mi přijde jako zbytečný overkill.
-
Sakra, to je zajímavá diskuse, taková pěkná směsice různých úrovní odborníků, teoretiků a haló-rádoby-odborníků (už si budu muset zase zakázat číst diskuse o ipv6 na rootu :D).
Jako haló-rádoby-odborník přidávám svou trochu do mlýna.
Pokud jde o jednorázovou a trvalou změnu providera, jediným správným řešením je síť přeadresovat.
To je právě problém. Náklady na změnu adresace, pokud větší firma takové náklady vyčíslí vyjde jím takové číslo, které je bude nutit zůstat u současného ISP, což se logicky nelíbí. Nesporná výhoda NATU v tomto smyslu je, že změna se realizovala vlastně na pár zařízeních a tím to haslo (relativně malá závislost na PA adresách). Z mnoha věcí zmiňme jenom nastavení paketového FW v síti kde používáte "security in depth". Samozřejmě někdo může navrhout způsob konfigurace filtrů pouze specifikací posledních /64 bitů adres, konfigurace filtrů pomocí DNS (nebo mDNS dokonce) apod... Zde se myslím čeká na nějaké doporučované postupy, best practice protože se dostáváme do nových neověřených postupů. A to vyřešením FW bude vyřešena jenom jedna z věcí.
Síťová tiskárna určitě bude používat i automatickou adresu (nebo rovnou několik, třeba ULA). Lokálně se k ní ale bude přistupovat hlavně přes lokální adresu, a to nejspíš ještě přes mDNS, takže konkrétní adresa vás vůbec nebude zajímat.
Styl administrace "ono to nějak funguje" nemají rádi všichni. Rovnou řekněte, že na to budeme mít supadupa web management, kde se přidá ikonka tiskárny a konfigurace se automaticky vygeneruje a rozpošle do všech dotčených zařízení.
stejně jako ten nakonfigurovaný router může delegovaný prefix rozsekat jakkoliv podle své úvahy a použít pro prefix delegation na routery pod ním.
.....
Router ležící napříč se multicastem na obou vnějších rozhraních zeptá všech tam přítomných routerů na prefix přes DHCPv6, což se doručí oběma routerům na hranách, a oba ty routery přepošlou požadavek na delegaci na hlavní router, který prefix přidělí, a protože žádající je v obou případech ten stejný router, tak dostane v obou případech stejný prefix. Oba routery potom routeru napříč vrátí ten stejný prefix, takže zduplikováním se nic nestane. Pokud jedna linka nefunguje, prostě se to přidělí jen přes tu druhou. Pokud spadnou obě, prefix delegation selže, ale protože stejně nebudete mít přístup do internetu, tak ve výsledku k žádné škodě nedojde a lokálně bude fungovat jenom ULA.
Až budete mít čas prosím, prosím připravte takový malý labáček, takový "proof of concept" jak to děláte, rád si to zkusím nastavit.
-
PI adresy rozhodně není snadné získat, pokud k jejich použití není objektivní důvod (a to, že někdy v budoucnu možná budu měnit providera a nechce se mi přeadresovávat síť, objektivní důvod není). Kdyby všichni používali PI adresy, globální směrovací tabulka by narostla do astronomických rozměrů a Internet by měl dost problémů zůstat pohromadě.
Pokud jde o jednorázovou a trvalou změnu providera, jediným správným řešením je síť přeadresovat. Taková změna se neděje příliš často a vždy je spojena s náklady navíc. Pokud jde o zálohování občasného výpadku a při výpadku vystačí síť s nouzovým režimem, kdy nejde navazovat spojení dovnitř, pak bych volil po dobu výpadku bezestavový NAT, který dočasně přeloží původní nefunkční prefix na nový, funkční.
Co ma lokalni provider spolecnyho s globalni routovaci tabulkou? Vyhoda IPv6 je prave v tom, ze prakticky vubec nic. Predpokladal bych (pokud v RIPE a spol nesedi banda totalnich idiotu) ze rekneme CR ma "pridelen" nejaky prefix, a providerum se prideluji rozsahy z toho prefixu => pokud budu mit PI adresy, tak to budou resit "mistni" provideri, ale v globani tabulce se vubec nic nezmeni.
Triviální, použitelné pouze u malých sítí, kde si to správce může obejít i sám. Až budete mít síť, kde budete mít velkou lokalitu využívající 135 /64 prefixů, několik malých lokalit využívajících 40 /64 prefixů a pobočky s jedním routerem využívajícím 8 /64 prefixů, teprve potom to začne být s přidělováním zajímavé.
Co je to vlastní prefix? Myslíte PI adresy? Ty se přidělují jenom za poměrně specifických situací.
Pokud budu mit takhle rozsahlou sit, tak je PI rozsah zcela bezna vec, protoze pri takhle rozsahly siti mam minimalne nekolik pripojek ven.
-
> Co ma lokalni provider spolecnyho s globalni routovaci tabulkou? Vyhoda IPv6 je prave v tom, ze prakticky vubec nic. Predpokladal bych (pokud v RIPE a spol nesedi banda totalnich idiotu) ze rekneme CR ma "pridelen" nejaky prefix, ...
To znacne precenujes realne moznosti agregace. Agregace probiha prakticky vyhradne na urovni LIRu (~ISP), tedy agreguji se PA adresy jednoho LIRa a propagovane s jednim AS number. PI adresy (stejne jako PA bloky pridelene ruznym LIRum) se obecne navzajem neagreguji. Agregace na 'narodni' urovni je nesmysl. Zaprve se tak adresy neprideluji a zadruhe se tak ani neroutuje (v zahranici neni jeden smer 'k CR', protoze ruzni mezinarodni tranzitni ISP mohou mit blize k ruznym lokalnim ISP).
-
Pokud budu mit takhle rozsahlou sit, tak je PI rozsah zcela bezna vec, protoze pri takhle rozsahly siti mam minimalne nekolik pripojek ven.
Tak třeba české univerzity, které mají mnohdy i komplikovanější infrastrukturu, žádného jiného providera než CESNET nemají.
-
Pokud budu mit takhle rozsahlou sit, tak je PI rozsah zcela bezna vec, protoze pri takhle rozsahly siti mam minimalne nekolik pripojek ven.
Tak třeba české univerzity, které mají mnohdy i komplikovanější infrastrukturu, žádného jiného providera než CESNET nemají.
"několik přípojek ven" != "více providerů"
Jeden solidní provider je určitě lepší než více nesolidních.
-
Pokud budu mit takhle rozsahlou sit, tak je PI rozsah zcela bezna vec, protoze pri takhle rozsahly siti mam minimalne nekolik pripojek ven.
Tak třeba české univerzity, které mají mnohdy i komplikovanější infrastrukturu, žádného jiného providera než CESNET nemají.
"několik přípojek ven" != "více providerů"
Jeden solidní provider je určitě lepší než více nesolidních.
To sice ne, ale pokud budete připojen jenom k jednomu providerovi, tak PI adresy patrně nedostanete.
-
Možná triviální dotaz. Momentálně je celá síť za NATem a jede přes IPv4. Pokud budu chtít dotáhnout IPv6 z routeru na koncový počítač, mohu použít současný switch (který nemá o IPv6 zmínku), nebo musí být nový, který "něco" splňuje.
Jaký je rozdíl mezi řiditelným a jiným switchem?
-
Možná triviální dotaz. Momentálně je celá síť za NATem a jede přes IPv4. Pokud budu chtít dotáhnout IPv6 z routeru na koncový počítač, mohu použít současný switch (který nemá o IPv6 zmínku), nebo musí být nový, který "něco" splňuje.
Switch funguje na ethernetové vrstvě a o IP nic neví. O IP musí něco vědět router.
Jaký je rozdíl mezi řiditelným a jiným switchem?
V tom, že se jeden se dá řídit a druhý ne :) Např. se u něj dá nastavit, že na nějakém portu může být jenom zařízení s určitou MAC adresou, že určitý port bude zařazený do nějaké VLANY apod. Jinak, obvykle se tomu říká "managovatelný". "Řiditelný" jsem ještě neslyšel, to je zas nějakej fikanej čechismus :)