Názory k článku Méně IPv4 v sítích: teoretický úvod aneb šetříme adresy

Díky za skvělý článek, těším se na pokračování :)

Víc takových článků

Co se tyce next-hopu, resp. viditelne gw napr. v traceroute, tak s tim mam trochu "zvyklostni" problem u ipv6. Narazil jsem na to prave u loopbacku jednoho noveho reseni. Jako standardne pouzivam FE80::1 jako gw, ale prave u loobacku vidim link-local adresu daneho routeru, ale ta jiz neni FE80::1, ale mismas. A pak si rikam, kudy to sakra zase leze.

"Nešlo by to ještě lépe?"

Cele to tak nejak tise predpoklada, ze ten v4 router je tataz krabka co v6 router, coz ale nemusi byt realita a velmi typicky neni. Kdyz si pustim trace z libovlne site ke ktere mam pristup tak ty pakety putuji dost jinak, a to vcetne prvniho hopu.

IMO je z pohledu ISP jednodussi (a bezpecnejsi) provozovat to oddelene, nez to mit na stejny krabici oboji, a resit interference.

ISPci pak typicky s nedosatkem adres problem nemaji. Ti maji totiz nahrabano. Problem maji enduseri pripadne provozovatele serveru.

Cele to tak nejak tise predpoklada, ze ten v4 router je tataz krabka co v6 router
Ano, to je presne princip tohoto reseni.

Mate v okoli nejakeho ISP, ktery ma oddelene routery pro kazdy protokol? Jak mu to funguje z pohledu provoznich a investicnich nakladu a slozitosti spravy?

Podle vzorku, ktery mam ja, bylo oddeleni IPv4 a IPv6 routeru spis otazkou predminuleho desetileti. Dneska je to spis tak, ze mate jednu fyzickou cestu a na jejich koncich dva routery, ktere routuji IPv4 i IPv6. (V pripade siti typu MPLS se bavime o PE routerech.)

Prave ze mam a ne jednoho. Fyzicka konektivita samozrejme konci na nejake jedne krabici, ale ta se chova jako bridge. V nekterych pripadech se to zvenku sice ponekud hur zkouma, ale v nekterych je zcela zjevne ze uz ten prvni hop neni jedna krabice.

Ono je to ve finale i celkem pochopitelne, pokud treba dotycny vyhledove uvazuje o tom, ze v4 zrusi, tak vypnout neco fyzicky je mnohem snazsi, nez to na hromade krabic odkonfigurovat.

Netvrdim ze to tak maji vsichni, ale neni jich rozhodne malo.

A co se tyce penez, jestli bude mit 100ks neceho v konfiguraici v4+v6 nebo 50ks v4 a 50 v6 ... bude to stat porad totez, a aministracne je to jednodussi. Navic kdyz neco umre, zustane ta druha moznost.

Proc byste mel 100 ks neceho v konfiguraci v6+v4, kdyz toho muzete mit prave tech 50 kusu (potrebnych podle vzorce 50ks v4 a 50 v6)?

Ano, tak se delalo mozna v dobe kamenny, kdyz se s IPv6 zacinalo a kdy clovek mel produkcni skatule, co podporu pro IPv6 ani nemely - nebo vagon penez stala licence, protoze holt historie pamatuje dobu, kdy to byla priplatkova feature. Nevim... dvacet let nazpet? :-) Jestli neco tak stareho provozuje dnes, tak je to sebevrah.

Nj, cenzor tu zas radi vid?

Takze soudruzi v tm a vf jsou proste uplny bridilove, mel bys jim rict, ze to delaj uplne blbe a vubec tomu nerozumej.

Mimocoudem, soudruzi v tm maji dokonce uplne jiny lidi ktery resej v6 vs v4 a uplne oddelene support. Bridilove ...

Soudruzi v TM, ktere znam ja, maji typicky jednu krabici pro oba protokoly.

TM, tedy presneji tehdy jeste GTS zrusila vyhrazeny port do NIX.CZ pro IPv6 nekdy kolem rijna/listopadu 2011, od te doby ma svuj peering na routeru reseny uz jen dualstackem... kdyz uz chcete vzpominat na tyhle "stary casy" :-)

Před více než třemi desetiletími jsme pomocí dvou krabic/PC řešili směrovaní IP (Internet, Unixy) a IPX (Novell). Hardwarový směrovač, notabene multiprotokolový, třeba Cisco AGS, byl pro nás snem.

V tomhle praveku jsem i IP a IPX zazil na jedne skatuli :-) Pravda, nebylo to od Cisca, ale od Bay (pozdeji Nortel) Networks... a je pravda, ze to stalo vagon penez - ale to byl mj. dane tim, ze tam bylo i ATM, ktere diky komplexite protokolu drahy proste bylo.

Centillion?

Aj ISPci maju problem s nedostakom adries. Nie vsetci mohli nahrabat. Napriklad taky Orange na Slovensku ich ma o dost menej ako Telekom( ktory sa k nim dostal este ked sa rozdavali vo velkom) a domove pripojky uz nejaky cas nedostavaju verejnu IPv4.

To v realu delaji i ti co "maji". Je jednodussi prekopat sluzby a setrit si omezene zdroje (co IPv4 proste jsou) nez do posledni chvile rozhazovat a pak resit... co pak :)

Pěkné těším se na pokračování.

Ďakujem. Viac takýchto článkov. :-)

My šetříme v naší malé ISP síti trochu jinak. Firemní zákazník nejčastěji chce na předávacím rozhraní nějaký veřejný IPv4 subnet a v něm jednu adresu. Nepřesvědčím ho k technikám podle tohoto článku nebo třeba aspoň k tomu RFC 3021. Prostě místo jedné adresy bychom měli vyplýtvat rovnou čtyři na rozhraní /30...

Vyberu si nějaký větší rozsah (třeba /24) a z něj "obětuji" 3 adresy (první, poslední a jednu pro bránu ISP) - tedy pro rozsah /24 je to .0, .255 a třeba .254. Tento rozsah pak používám opakovaně na všech rozhraních routerů, do kterých jsou připojeni zákazníci s veřejnou adresou.

Náš router (router ISP) má na rozhraní tu adresu .254/32 (nikoliv /24) a k tomu "onlink" záznam ve směrovací tabulce na tu jednu zákazníkovu veřejnou IP (třeba .100) - z pohledu ISP routeru je to obdoba toho RFC 3021, jen ty dvě adresy nejsou bezprostředně za sebou (.100 není o jedničku větší/menší než .254).

Router zákazníka je nakonfigurován tak, jako by byl připojen do celé sítě /24. Aby to fungovalo, musí router ISP provozovat na tom rozhraní funkci proxy ARP (odpovídá na ARP dotazy všech adres v rozsahu /24 svojí MAC). Router ISP ostatním routerům oznamuje (BGP a pod.) jen tu adresu .100, adresu .254 neoznamuje.

Takto pro jednoho zákazníka použijeme jedinou IPv4 a zákazník se tomu nemusí vůbec přizpůsobovat. Konfigurace routeru ISP je náročnější, ale to se dá automatizovat. Je potřeba použít routery, které umí ten proxy ARP a také (pro připojení více zákazníků) zvládnou mít stejnou adresu na více rozhraních (tu .254). Teoreticky by to šlo udělat i úplně bez té adresy .254, ale to je nepraktické: špatně se na takovém rozhraní konfiguruje třeba DHCP server.

Diky! To je taky pekne reseni. :)
Proxy ARP je obecne dost casta varianta, jak virtualne rozdelit vetsi blok adres mezi vic fyzicky oddelenych sitovych segmentu.
Rozumim spravne, ze tu samou .254/32 IPv4 adresu pouzivate na vice routerech? Jak to funguje, kdyz router sam potrebuje pristoupit k nejakemu zdroji venku, treba NTP serveru? Pouzije nejakou jinou adresu z loopbacku?

Přesně tak. Router neposílá do internetu žádné pakety se zdrojovou IP .254. NTP nebo třeba management routeru se vyřizuje přes adresu na loopbacku: ta je potřeba už kvůli tomu, aby měl router nějakou stabilně dosažitelnou "hlavní" IP adresu při použití dynamického směrování.

A ano, ta .254/32 není jen na více routerech, ale může být dokonce na více rozhraních jednoho routeru (pokud to router podporuje): pro každého zákazníka jedno rozhraní. Zákazníci jsou pak lépe oddělení a komunikaci i mezi nimi navzájem lze snadno řídit L3 firewallem.

Chtěl bych dodat, že podpora RFC8950 je v NIX.CZ nasazená a několik ASN již spojení používá.

Díky za popularizaci IPv6, věřím, že je to potřeba. Kolem IPv6 panuje obecně velmi mnoho mýtů (jako třeba, že nefunguje), nebo že je zbytečná, a je to škoda.

Pěkný článek. Takových jen více. Hodně lidí si imho představuje ipv6 jen jako "ipv4 s divnými adresami", ale takové různé vychytávky je ani nenapadnou.

Nejspis proto, ze nikdy nevideli veci jako treba ATM end system address... :)
39.203F8000267­4000001000100­.00A0000620F3­.48

Stejně se divím, že se tu ještě najde někdo, kdo ví co je ATM. Když jsem před pár roky, na nějaké linuxové konferenci, v kuloárech, o něm mluvil, tak se v podstatě nikdo nechytal. Maximálně si vzpomněl na bankomat.

Bohuzel nekteri technologicti dedkove vi moc dobre :-/

Dobrý článek, běžící zajíc pobavil. Dá se na to nahlížet 2 způsoby: existují 2 kategorie : počítače (mobily, koncové prvky) a routery a "homogenní přístup" každé zařízení kromě switche je prvek co může, ale nemusí forwardovat a principiálně je stejný . To by se taky dalo vypíchnot v nějakém pokračování. Příbuzná věc k tomu je, jestli si pamatuju, že "TCP/IP" bylo navrženo, aby právě běželo na běžném hardwaru a že i "skladník může routovat", takže router a pc nejsou nějaké 2 různé světy

co by mě zajímalo: jak je default gateway řešena na androidu a vůbec tam je to nějaké divné, nevím, zda jenom skryté za více route tabulkami (ip route add. table N)

řeší "peer" v příkazu ip addr add ... peer (narážím třeba na "nucený výpis" inet 172.17.0.1/16 brd 172.17.255.255) a tedy zda hláška "Do you want to ping broadcast? Then -b." není vyvolána tím, že se srovná právě hodnota brd a ne nutně číselně "nejvyšší IP adresa"

-> je tedy řešením při ip addr add ... /32 "přivařit" peer ...?

Routery při komunikaci mezi sebou ... a pro zjišťování, kdo má jakou hardwarovou adresu, ... ARP. Znalejší čtenáři toto zjednodušení" -. to se týká BGP

- taky by mohlo zmínit, ruční přidání "ip neighbor add " ... ale třeba nevím, který proces ty záznamy do ip neigh show" přidává automaticky

-narážím někdy na dvojí chování ip route add default via dev eth0 (hlásí to nějakou chybu, kterou teď nemám čas najít něco jako rt file not exists)), což někdy neprojde ,a je nutné rozepsat do ip route add 192.168.1.1 dev eth0;ip route add default via 192.168.1.1 ? jde o starší verzi kernelu , že došlo ke změně? (nebo jde o "device route"), popsané níž

(ale jak čtu dál, nešlo by to lépe) -článek se vyvíjí jiným směrem (k IPv6)

co by mě zajímalo: jak je default gateway řešena na androidu a vůbec tam je to nějaké divné, nevím, zda jenom skryté za více route tabulkami (ip route add. table N)
AFAICT je tam víc routovacích tabulek, typicky minimálně jedna pro VoLTE, jedna pro mobilní data, jedna pro Wi-Fi, a může tam být i jedna pro hotspot, příjem MMS, atp.

zda hláška "Do you want to ping broadcast? Then -b." není vyvolána tím, že se srovná právě hodnota brd a ne nutně číselně "nejvyšší IP adresa"
Přiznám se, že zdroják jsem neprohlížel, může to být i tak, jak píšete. Technicky je to ale totéž, hodnota brd je nejvyšší IP adresa, nebo...?

je tedy řešením při ip addr add ... /32 "přivařit" peer ...?
dvojí chování ip route add default via dev eth0 (hlásí to nějakou chybu, kterou teď nemám čas najít něco jako rt file not exists)), což někdy neprojde ,a je nutné rozepsat do ip route add 192.168.1.1 dev eth0;ip route add default via 192.168.1.1 ? jde o starší verzi kernelu , že došlo ke změně? (nebo jde o "device route"), popsané níž

Řekl bych, že nemůžete použít add default via dev eth0, protože za via chybí IP adresa brány. A že to takhle bylo vždycky.

To je varianta, pokud máte on-link /32. V Debianu v /etc/network/in­terfaces je pro to klíčové slovo pointopoint, ukázku použití má třeba Hetzner a funguje to tak, že se nejdřív přidá device routa pro gateway ( ip route add 192.168.0.1 dev eth0) a pak se přidá default gateway skrze tuto routu ( ip route add default via 192.168.0.1).

Což je mimochodem stejný zápis, jako jste pak dál uvedl v příkladu, který funguje.

ruční přidání "ip neighbor add " ... ale třeba nevím, který proces ty záznamy do ip neigh show" přidává automaticky
Automaticky přidává záznamy do tabulky kernel. :) Nebo si nerozumíme? Ruční přidání jde nejspíš skrze user-land utilitu (ip) a pak netlink v kernelu.