IPv6 /64 subnet szétosztása konténerekre

Adott egy host /64 IPv6 alhálózattal, amiben szeretnék IPv6-only LXC konténereket indítani, ugyanabból az alhálózatból kiosztva a címeket. Megörökíteném a későbbiekre a számomra legegyszerűbbnek tűnő megoldást. Egy Hetzner VPS-en kísérletezgetés közben szedegettem össze a lentieket, ott egyszerűen reprodukálható a folyamat.

( arpi_esp v | 2022. 03. 31., cs – 09:50 )

koszi, erdekes megkozelites ez is.  masik lehetoseg, ha csinalsz "brouter"-t (v4 router+v6 bridge), vagy csak siman a hostot is berakod a bridge-be.

nekem 1db v6 cimem volt az egesz hostra (servergarden), az lxc vm-jeim meg kulon v4 subnetekben mentek (hogy egymast se lassak). igy maradt a local v6 subnetek osztasa aztan v6 nat-olas :(

A szolgáltatótól miért nem kértél IPv6 prefixet? Elzárkóztak tőle, technikailag nem volt lehetséges, vagy valami olyan költségtétele lett volna, amit nem lehetett felvállalni?

Azért kérdezem, mert a szolgáltatók az egyes szolgáltatás-csomagjaikat úgy alakítják ki, hogy az az átlagjúzer átlagfeladatára jó legyen, és ha te olyat akarsz csinálni, amivel nem kalkuláltak, akkor lehet, hogy egy egyszerű kérés elegendő a probléma megoldásához. Az IPv6 prefix olcsó, sőt, egy /64 vagy /56 szinte ingyen van. Csodálkoznék, ha komoly pénzeket akarnának kérni érte.

kertem ipv6 tartomanyt, erre adtak 1db static cimet, azon is gondolkoztak 1 hetig. server hosting amugy, ipv4-ert is komoly penzeket kertek cimenkent...  mivel egyelore csak tesztelesre kellett, eleg volt az 1 is.

egyebkent amikor korulneztem par honapja a magyar server hosting / vps szolgaltatoknal, a nagy tobbsege csak 1-1 v6 cimet ad (vagy azt se), nehany ad /64-et es talan 1 volt csak aki nagyobbat.  meglepo modon kulfoldon se sokkal jobb a helyzet, tobb nagy szolgaltato valaszolta azt hogy naluk nincs ipv6. de olyan is volt aki ad /48-at, szoval eleg nagy a szoras.

IPv4 egyre drágább, mert nagyjából elfogyott.

IPv6 szerintem kb. mindenhol ingyen van. Rackforest /56-ot ad, AWS VPC is /56, Hetzner-nél a default a /64, de egyszeri 15 EUR-ért ad /56-ot (csak fizikai gépekhez).

Ha egy mód van rá, én már új projekteknél csak IPv6-ot használok, és ahol nagyon kell (pl. webes rendszereknél), ott a Cloudflare beforgatja az IPv4 látogatókat.

igen vegtelen sok v6 cim van, de olyan bokezuen szorjak, hogy ilyen tempoban az is el fog fogyni 10 even belul :)

1-1 isp kap /32-t, abbol ha 56-ot ad minden ugyfelenek eleg hamar elfogynanak, felteve hogy nem egy garazsceg par 100 ugyfellel (de azok nem is kapnak /32-t csak /48-at)

Amikor elkezdtem ismerkedni IPv6-tal, én is pontosan így gondoltam. A legnagyobb hülyeségnek tartottam, hogy a legkisebb subnet az a /64, mi a búbánatnak osztunk ki 18.446.744.073.709.551.616 db címet egy alhálózatba, ahol adott esetben csak néhány tucat végpont lesz. De így lehet minden szutyok eszköznek, sőt minden vhostnak, minden alkalmazásnak külön címe anélkül, hogy mindenféle trükköket kellene alkalmazni. 

Ha egy ISP /32-t kap, abban konkrétan annyi /64 méretű subnet van, ahány címből áll az egész IPv4 internet (hiszen az is 32 biten leírható). Ha pedig "csak" /56-ot oszt ki mindenkinek, akkor is lehet 134 millió ügyfele. 

Elég lesz.

Egyébként ha valaki RIPE tag, ott tényleg /32 az alap, de /29-et is lehet kérni, még csak megindokolni sem kell.

Ha már RIPE, a 4.2 alfejezeteit célszerű elolvani: https://www.ripe.net/publications/docs/ripe-690
Sajnos egyelőre örüljön egyetlen /64-nek. Még sokmindennek ki kell alakulnia ahhoz, hogy ezt a RIPE ajánlást tudják tartani a szolgáltatók. Szándék és technikai oldalról egyaránt.

Ha pedig véletlen tényleg több tízmillió ügyfele van, akkor már rég igényelt a /32 helyett/mellé további tartományokat.

Vagy /32-nél szélesebbet igényel, ha tényleg olyan nagy és nem egy átlagos kis szolgáltató.
DIGI Tavkozlesi es Szolgaltato Kft.  /29-et igényelt. Abból szórja szét a magyar előfizetőinek az IPv6-ot, egyelőre még csak /64 prefix delegációval.

"igen vegtelen sok v6 cim van, de olyan bokezuen szorjak, hogy ilyen tempoban az is el fog fogyni 10 even belul :)"

Óhh erről egy régi kollégám posztulátuma jut eszembe. :) Neki voltak ilyenjei, amiről tudtad, hogy nem lehet igaz, de mikor kérte hogy cáfold meg, valahogy baromi nehéz volt.

Ő úgy mondta:

"Az IPv6 már elfogyott. Csak senki nem vette észre, mert igazán senki nem használja."

Félig igaza volt. Az IPv6 top level /3-as subneteknél 8-ból 3 van használva (0, 2, e), úgyhogy nem fogyott el (van még pár dobásunk, ha ezt elcsesszük). Viszont a 2-vel kezdődő publikus címtartomány szinte teljesen szét van már dobva a RIR-eknek. Aztán, hogy az egyes regionális blokkok mennyire telítettek, az jó kérdés.

Régóta vágyok én, az androidok mezonkincsére már!

Az IPv4 lassan drágább, mint a heroin. Ne keverd bele, itt konkrétan IPv6-ról volt szó.

a nagy tobbsege csak 1-1 v6 cimet ad

Mondom: feltételezem, főként azért, mert arra gondol, hogy az neked úgy jó. Merj kérni többet! Konkrétan, úgy kérj, hogy "kérek egy /64-et", vagy "kérek egy /56-ot".

( XMI | 2022. 03. 31., cs – 14:28 )

Dockernél régebben (mikor még foglalkoztam vele), az volt a javaslat, hogy egy /80-as tartományt jelölj ki a konténereknek. Gondolom, hogy a 48-bites virtuális interfész MAC címeket 1:1 be tudja mappelni az IPv6-os cím suffixbe. De emlékeim szerint simán ment sokkal kisebb tartománnyal is.

Ahogy elnézem itt is valami hasonló magic van a háttérben. A konténerek címei gyanúsan mind

2a01:4f9:c011:3bf:216:3eff:fe00::/104

prefixet használnak. Viszont a konfigban csak

2a01:4f9:c011:3bf::/64

kerül említésre. Vajon honnan jön a 216:3eff:fe? Konfigurálva van, vagy random választotta magának?

Régóta vágyok én, az androidok mezonkincsére már!

Ez a SLAAC, stateless Address Auto-configuration.

pl. a konténer MAC címe: 00:16:3e:7d:97:34

Beteszünk a közepére egy FF:FE-t: 00:16:3e:ff:fe:7d:97:34

Ezt átírjuk IPv6-szerű formába: 0016:3eff:fe7d:9734

A hetedik bitet átfordítjuk, 00-ból lesz 02: 0216:3eff:fe7d:9734

Ez lesz a /64-en belül a prefix után a cím host része. 2a01:04f9:c011:03bf:0216:3eff:fe7d:9734

Itt gyönyörűen le van írva az egész, érthető ábrákkal:

https://www.networkacademy.io/ccna/ipv6/stateless-address-autoconfigura…

Sajnos ez a vendor prefix az LXD esetében nem "igazi", az OUI adatbázis szerint a 00:16:3e prefix a Xen-é, de ezt használja más virtualizációs/konténeres megoldás is. Hivatalosan az első octet utolsó előtti bitjével kellene jelölni, hogy lokál adminisztrálású MAC cím, és nem globálisan egyedi. De sajnos valamiért az LXD nem így csinálja, és nem is kért magának saját tartományt.

De igazából majdnem mindegy, mert az IPv6 prefix része úgyis egyedi lesz, úgyhogy mögötte nem gond, ha a cím host részét véletlenül egy olyan MAC címből generáljuk, ami egy másik szerveren is létezik.