James Bottomley’ s random Pages

a Linux Plumbers Conference egyik legutóbbi tapasztalata meggyőzött arról, hogy ha egy igazi nyílt forráskódú WebRTC-alapú peer-to-peer audio/video interakció része akarsz lenni, akkor olyan internetcímre van szükséged, amely nem áll a NAT mögött. A valóságban, a protokoll továbbra is működik, amíg kapcsolatba léphet egy kábító szerverrel, hogy elmondja, mi a külső címe, és esetleg egy kiszolgáló a csomagok proxyjához, ha mindkét végpont nált, de mindez a külső szerverek keresése időt vesz igénybe, mint azok, akik panaszkodtak a talált echo teszt miatt. A megoldás minderre az IPv6-on keresztüli csatlakozás, amelynek címtere elég nagy ahhoz, hogy támogassa a bolygó minden eszközét, amelynek saját címe van. Minden modern Linux disztribúció támogatja az IPv6-ot a dobozból, így valószínűleg véletlenül használta anélkül, hogy észrevenné, ami az IPv6 automatikus konfigurálásának egyik szépsége (állítólag csak működik).

azonban nemrég költöztem, és így elvesztettem a szálas internetkapcsolatomat a kábelhez, de a kábelhez IPv6 cím tartozik, így ez az én történetem, hogy mindent működtessek. Ha nem igazán érdekel a protokoll alapjai, ugorhat le a Hogyan. Ez az útmutató egy “kettős verem” konfigurációra is összpontosít (amely IPv6 és IPv4 címmel is rendelkezik). Tiszta IPv6 konfigurációk lehetségesek, de mivel az internet egyes részei továbbra is csak IPv4-esek, nem teljesek, hacsak nem állít be egy IPv4 beágyazó hidat.

az IPv6 alapjai

az IPv6 már régóta érett protokoll, ezért tévesen feltételeztem, hogy rengeteg jó Hogyan lesz róla. Miután elolvastam 20 különböző leírást arról, hogyan működik az IPv6 128 bites címtér, és nem sok mást, kétségbeesetten feladtam, és inkább az RFC-ket olvastam. Feltételezem, hogy elolvasta legalább az egyik ilyen Hogyan, így nem kell bemennem az IPv6 cím előtagokba, utótagokba, interfészazonosítókba vagy alhálózatokba, így ott kezdem, ahol a legtöbb HOWTOs véget ér.

hogyan működik az IPv6?

az IPv4-ben van egy Dynamic host configuration protocol (DHCP) nevű protokoll, így mindaddig, amíg megtalálja a DHCP szervert, megkaphatja a csatlakozáshoz szükséges összes információt (helyi cím, útválasztó, DNS-kiszolgáló, időkiszolgáló stb.). Ezt a szolgáltatást azonban valakinek be kell állítania, és az IPv6-ot úgy tervezték, hogy anélkül konfigurálja a hálózatot.

az első feltételezés IPv6 hontalan cím AutoConfiguration (SLAAC) teszi, hogy ez a /64 alhálózaton (így minden alhálózat IPv6 tartalmaz 1010-szer annyi címet, mint a teljes IPv4 internet). Ez azt jelenti, hogy mivel a legtöbb valós alhálózat <100 rendszert tartalmaz, egyszerűen kiválaszthatnak egy véletlenszerű címet, és nagyon valószínű, hogy ütköznek a meglévő rendszerekkel. Valójában három jelenlegi módja van a cím kiválasztásának a /64:

1. EUI – 64 (RFC 4291) alapján a MAC-cím, amely alapvetően a MAC egy kicsit tükrözött és FF:Fe közepén elhelyezett.
2. stabil privát (RFC 7217), amely statikus kulcson, interfészen, előtagon és számlálón alapuló hash-ból generál (a számláló növekszik, ha összecsapás van). Ezeket előnyben részesítik az EUI-64-esekkel szemben, amelyek megadják a MAC-címhez társított konfigurációkat (például, hogy milyen típusú hálózati kártya van)
3. Adatvédelmi kiterjesztési címek (RFC 4941), amelyek nagyon hasonlítanak a stabil privát címekhez, kivéve, hogy idővel változnak az IPv6-cím elavult mechanizmusával, és olyan ügyfélrendszerek számára készültek, akik meg akarják őrizni az anonimitást.

a Linux következő problémája az, hogy ki konfigurálja az interfészt? A Kernel IPv6 verem valójában úgy van megtervezve, hogy ezt megtegye, és hacsak nem mondják meg, de a legtöbb modern hálózati vezérlő (mint például a NetworkManager) vezérlő őrült, és kikapcsolja a kernel automatikus konfigurációját, hogy maguk is meg tudják csinálni. Alapértelmezés szerint a stabil privát címzést is használják a fájlrendszerben fenntartott statikus titok használatával (/var/lib/NetworkManager / secret_key).

a következő dolog, amit meg kell érteni az IPv6-címekről, hogy hatókörökre vannak osztva, a legfontosabb a link helyi (nem routeable) címek, amelyek hagyományosan mindig fe80::/64 előtaggal rendelkeznek. A link helyi címét először a fenti módszerek egyikével konfigurálják, majd a hálózat szondázására használják.

Multicast és Neighbor Discovery

az IPv4-től eltérően az IPv6-nak nincs sugárzási képessége, így minden felderítést multicast végez. A hálózaton érkező csomópontok bizonyos multicast címekre iratkoznak fel, a kapcsoló által elfogott speciális csomagokon keresztül, és nem kapnak olyan multicast-ot, amelyre nincsenek feliratkozva. Hagyományosan az összes link helyi multicast cím előtaggal rendelkezik ff02::/64 (más típusú multicast címekről lásd RFC 4291). Minden csomópont feliratkozik az “összes csomópont” FF02::1 multicast címre, és fel kell fizetnie a saját kért csomópont multicast címére is az ff02::1:ffXX:XXXX címen, ahol az utolsó 24 bit a csomópont IPv6-címének legalacsonyabb 24 bitjének felel meg. Ez utóbbi célja, hogy elkerülje az IPv4-ben az ARP-adásokból eredő zavarokat, mert most a csomópontok egy meghatározott részhalmazát célozhatja meg a címfelbontás érdekében.

az IPV6-címfeloldási protokoll neve Neighbor Solicitation (ns), amelyet az RFC 4861 ír le, és az RFC 4862-ben leírt SLAAC-val használható, és úgy történik, hogy egy multicast-ot küld a felfedezni kívánt csomópont neighbor solicitation címére, amely tartalmazza a teljes IPv6-címet, amelyet tudni szeretne, egy csomópont, amelynek megfelelő címválaszai vannak a link layer (MAC) címével a Neighbor Advertisement (NA) csomagban.

miután egy csomópont kiválasztotta a link helyi címét, először elküld egy ns csomagot a választott címre, hogy megnézze, válaszol-e valaki, és ha senki sem teszi, akkor feltételezi, hogy rendben van megtartani, különben az adott címformához társított ütközéselkerülési protokollt követi. Miután megtalálta az egyedi címet, a csomópont konfigurálja ezt a linket helyi cím és keres egy útválasztót. Ne feledje, hogy ha nincs IPv6-hálózat, a felfedezés itt leáll, ezért a legtöbb hálózati interfész mindig helyi IPv6-címet mutat.

Router Discovery

miután a csomópontnak megvan a saját egyedi link helyi címe, arra használja, hogy routert kérő (Rs) csomagokat küldjön az “all routers” multicast címre ff02::2. Minden router a hálózaton válaszol egy router reklám (RA) csomag, amely leírja (többek között) a router élettartama, a hálózati MTU, egy sor egy vagy több előtagok a router felelős, a router link címét és egy sor lehetőség zászlók beleértve az M (Managed) és O (Other Configuration) zászló és esetleg egy sor DNS szerverek.

minden hirdetett előtag tartalmazza az előtagot és az előtag hosszát, egy sor zászlót, beleértve az a-T (autonóm konfiguráció) és az L-t (link local), valamint egy sor élettartamot. A Link helyi előtagok megmondja, hogy milyen globális előtagokat a helyi hálózati felhasználók (lehet, hogy több mint egy), és hogy megengedett, hogy nem SLAAC a globális előtag (ha a zászló egyértelmű, meg kell kérni a router egy címet DHCPv6). Ha az útválasztó élettartama nem nulla, akkor feltételezheti, hogy ez az alhálózat alapértelmezett útválasztója.

most, hogy a csomópont felfedezett egy vagy több útválasztót, konfigurálhatja saját globális címét (vegye figyelembe, hogy minden IPv6 routeable csomópontnak legalább két címe van: egy link local és egy globális). Hogyan működik ez függ a router és előtag flags

Global Address Configuration

az első dolog, amit egy csomópont kell tudni, hogy az SLAAC a globális cím vagy DHCPv6. Ezt Teljes mértékben az RA csomag bármely link helyi előtagjának a zászlója határozza meg. Ha A be van állítva, akkor a csomópont használhatja az SLAAC-ot, ha a tiszta, akkor a csomópontnak DHCPv6-ot kell használnia a cím megszerzéséhez. Ha az a be van állítva, és az M (Managed) zászló is, akkor a csomópont használhatja az SLAAC – ot vagy a DHCPv6-ot (vagy mindkettőt) a cím megszerzéséhez, és ha az M zászló tiszta, de az O (Other Config) zászló jelen van, akkor a csomópontnak SLAAC-ot kell használnia, de a DHCPv6-ot használhatja a hálózattal kapcsolatos egyéb információk (általában DNS) megszerzéséhez.

miután a csomópontnak globális címe van a now-ban, alapértelmezett útvonalra van szüksége. Ez képezi az alapértelmezett útvonallistát a nem nulla útválasztó élettartamú RA csomagokból. Mindezek alapértelmezett útvonalakként vannak konfigurálva a link helyi címére az RA által megadott ugrásszámmal. Végül a csomópont specifikus előtag útvonalakat adhat hozzá az RA csomagokból, nulla útválasztó élettartammal, de nem kapcsolódik a helyi előtagokhoz.

a DHCPv6 egy meglehetősen összetett konfigurációs protokoll (lásd RFC 8415), de nem adhatja meg sem az előtag hosszát (vagyis az összes kapott cím /128-ként van konfigurálva), sem az útvonalakat (ezeket RA csomagokból kell beszerezni). Ez a kimenő cím kiválasztásának finomságához vezet, mivel mindig a legspecifikusabbat részesítik előnyben, tehát ha mind az SLAAC, mind a DHCPv6 konfigurálja, akkor az SLAAC-cím /64, a DHCPv6-cím pedig /128 lesz, ami azt jelenti, hogy a kimenő IP-cím mindig a DHCPv6 lesz (bár ha egy külső entitás ismeri az SLAAC-címet, akkor is el tudnak érni rajta).

A Hogyan: Saját otthoni útválasztó konfigurálása

az egyik dolog, amit a fentiekből gondolhat, hogy az IPv6 mindig automatikusan konfigurál, és bár igaz, hogy ha egyszerűen csatlakoztatja laptopját egy kábelmodem ethernet portjához, akkor csak automatikusan konfigurálja, a legtöbb embernek összetettebb otthoni beállítása van egy útválasztóval, amely speciális koaxingot igényel, mielőtt működni fog. Ez azt jelenti, hogy további szolgáltatásokat kell beszereznie az internetszolgáltatótól speciális DHCPv6 kérések segítségével.

ez a rész a saját szemszögemből íródott: Meglehetősen összetett IPv4 hálózatom van, amely teljesen nyitott, de sávszélessége korlátozott (nem megbízható ügyfelek számára) wifi hálózattal, valamint számos védett belső hálózattal rendelkezik (egy a laboromhoz, egy a telefonomhoz és egy a háztartási videokamerákhoz), így legalább 4 alhálózatra van szükségem ahhoz, hogy minden otthoni eszköz IPv6 címet adjon. Az OpenWrt-t is használom router disztribúcióként, így az összes IPv6 konfigurációs információ nagyon specifikus rá (bár meg kell jegyezni, hogy az olyan dolgok, mint a NetworkManager, mindezt megtehetik, ha készen áll a dokumentációba ásni).

Előtag delegálás

mivel a DHCPv6 csak egy /128 címet ad ki, ez nem elegendő, mert maga az útválasztó IP-címe. Ahhoz, hogy routerré válhasson, kérnie kell az IPv6 címtartomány egy részének delegálását a DHCPv6 Identity Association for Prefix Delection (Ia_pd) opcióján keresztül. Ha ez megtörtént, az útválasztó IP-címét az internetszolgáltató feltételezi az összes delegált előtag útvonalának. A finomság itt az, hogy ha egynél több alhálózatot szeretne, akkor külön kell kérnie (a kliensnek meg kell adnia a keresett előtag hosszát), és mivel ez egy előtag hossza, és az alapértelmezett alhálózatnak /64-nek kell lennie, Ha 64-es előtag hosszát kéri, akkor csak egy alhálózata van. Ha 63-at kér, akkor 2 van, és így tovább. A probléma az, hogy honnan tudod, hogy az internetszolgáltató hány alhálózatot hajlandó megadni neked? Sajnos ezt nem lehet megtalálni (internetes keresést kellett végeznem, hogy felfedezzem az INTERNETSZOLGÁLTATÓMAT, a Comcastot, hajlandó volt 60 előtag hosszúságot delegálni, ami 16 alhálózatot jelent). Ha a keresés nem mondja meg, hogy az internetszolgáltató mennyit hajlandó delegálni, akkor megpróbálhat 48-tól kezdve 64-ig dolgozni 1-es lépésekben, hogy megnézze, mi a legnagyobb küldöttség, amellyel megúszhatja (jelentések vannak arról, hogy az internetszolgáltatók az első delegált előtag hosszánál zárolnak, ezért ne kezdje 64-nél). A végső finomság az, hogy a delegált előtag nem biztos, hogy ugyanaz az előtag, mint az útválasztó által kapott cím (a jelenlegi comcast konfigurációm szerint az útválasztóm 2001:558:600A:…, de a delegált előtagom 2601:600:8280:66d0:/60). Megjegyzés: az odhcp6c-t manuálisan is futtathatja a-P opcióval, ha meg kell vizsgálnia az internetszolgáltatóját, hogy megtudja, milyen méretű előtagot kaphat.

az útválasztó konfigurálása Előtag-delegáláshoz

OpenWRT-ben a router WAN DHCP(v6) konfigurációját az /etc/default/network vezérli. Már rendelkezel egy WAN interfésszel (valószínűleg ‘wan’ – nak hívják) a DHCPv4-hez, így egyszerűen hozzáadsz egy további ‘wan6’ interfészt, hogy további IPv6-ot kapj, és kettős veremmé válj. A konfigurációmban ez úgy néz ki, mint

config interface 'wan6' option ifname '@wan' option proto 'dhcpv6' option reqprefix 60

az enyhe furcsaság az ifname: a @wan egyszerűen azt mondja a konfigurációnak, hogy ugyanazt az ifname-et használja, mint a ‘wan’ interfész. Az ilyen elnevezés elengedhetetlen, ha a wan híd, de egyébként is jó gyakorlat. A másik ‘reqprefix’ opció azt mondja a DHCPv6-nak, hogy kérjen egy /60 előtag delegálást.

delegált előtagok kiosztása

ez rendkívül egyszerűnek bizonyul. Először hozzá kell rendelnie egy delegált előtagot az útválasztó összes többi interfészéhez, de ezt megteheti anélkül, hogy mindegyikhez új OpenWRT felületet adna. A belső IPv4 hálózatom minden statikus címmel rendelkezik, így mindegyik interfészhez három irányelvet ad hozzá:

config interface 'lan' ... interface designation (bridge for me) option proto 'static' ... ipv4 addresses option ip6assign '64' option ip6hint '1' option ip6ifaceid '::ff'

az ip6assign’ N ‘azt jelenti, hogy a /n hálózat vagy (tehát ez számomra mindig /64), az ip6hint’ N ‘azt jelenti, hogy n-t használsz alhálózati azonosítóként, az ip6ifaceid’ S ‘ pedig azt jelenti, hogy S-t használsz IPv6 utótagként (ez alapértelmezés szerint ::1, tehát ha ez rendben van, hagyja ki ezt az irányelvet). Tehát mivel van egy 2601: 600:8280:66d0::/60 előtagom, ennek az interfésznek a globális címe 2601:600: 8280: 66d1:: ff lesz. Most az acid teszt, ha ezt helyesen kapta, ennek a globális címnek pingelhetőnek kell lennie az IPv6 internet bárhonnan (ha nem, akkor valószínűleg tűzfalprobléma, lásd alább).

hirdetés útválasztóként

egyszerűen nem elegendő egy delegált előtag delegálása a helyi útválasztó interfészen . Most meg kell, hogy a router, hogy válaszoljon a router kérések FF02::2 és adott esetben nem DHCPv6. Sajnos az OpenWRT-nek két mechanizmusa van erre, általában mindkettő telepítve van: odhcpd és dnsmasq. Azt tapasztaltam, hogy az /etc/config/dhcp egyik direktívája sem lép életbe, amíg teljesen le nem tiltom az odhcpd-t

/etc/init.d/odhcpd stop/etc/init.d/odhcpd disable

és mivel máshol széles körben használom a dnsmasq-t (osztott DNS belső/külső hálózatokhoz), ez megfelel nekem. Először leírom, hogy milyen opciókra van szüksége a dnsmasq-ban, másodszor pedig hogyan lehet ezt elérni az OpenWRT /etc/config/dhcp fájl bejegyzéseivel (ezt hasznosnak találom, mert mindig bölcs dolog ellenőrizni, hogy az OpenWRT mit tett a /var/etc/dnsmasq fájlba.conf fájl).

az első szükséges dnsmasq opció az ‘enable-ra’, amely egy globális paraméter, amely utasítja a dnsmasq-t a router hirdetések kezelésére. A következő paraméter, amire szükséged van, a per-interface ‘ra-param’, amely meghatározza a globális útválasztó hirdetési paramétereit, és egyszer meg kell jelennie minden olyan felületen, amelyen hirdetni akarsz. Végül a ‘dhcp-range’ opció lehetővé teszi az RA zászlók típusának részletesebb konfigurálását és az opcionális DHCPv6-ot.

SLAAC vagy DHCPv6 (vagy mindkettő)

sok szempontból ez személyes választás kérdése. Ha engedélyezi az SLAAC-ot, akkor azok a gazdagépek, amelyek Adatvédelmi kiterjesztési címeket akarnak használni (például Android telefonok), megtehetik, ami jó dolog. Ha engedélyezed a DHCPv6 címválasztást is, akkor lesz egy listád a címekről, amit a gazdagépekhez rendelsz, és a dnsmasq DNS-felbontást fog végezni helyettük(bár az SLAAC-címek DNS-ét is meg tudja csinálni, feltéve, hogy elmondják nekik). A ‘dhcp-range’ opcióhoz létezik egy speciális ‘konstruktor’ címke, amely azt mondja neki, hogy a megadott címet (RA vagy DHCPv6 esetén) a megadott felület IPv6 globális előtagjából készítse el, így adja ki a delegált előtag címeket. A ‘dhcp-range’ módok az ‘ra-only’ a DHCPv6 teljes letiltására, az ‘slaac’ a DHCPv6 címválasztás engedélyezésére, az ‘ra-hontalan’ pedig a DHCPv6 címválasztás letiltására, de más DHCPv6 konfigurációs információk engedélyezésére szolgálnak.

próba és hiba alapján (és végül az /etc/init parancsfájl vizsgálata alapján.d/dnsmasq) a fenti dnsmasq opciók eléréséhez szükséges OpenWRT opciók

config dhcp lan option interface lan option start 100 option limit 150 option leasetime 1h option dhcpv6 'server' option ra_management '1' option ra 'server'

a ‘ra_management’ kulcsopcióval, a ‘0’ jelentése SLAAC DHCPv6 opciókkal, az ‘1’ jelentése SLAAC teljes DHCPv6-Mal, a ‘2’ jelentése csak DHCPv6, a ‘3’ pedig csak SLAAC. Egy másik OpenWRT furcsaság az, hogy úgy tűnik, hogy nincs mód a bérleti tartomány beállítására: mindig alapértelmezés szerint csak statikus vagy ::1000-től ::ffff-ig.

tűzfal konfiguráció

az egyik dolog, ami feldobja az embereket, az a tény, hogy a Linuxnak két teljesen különálló tűzfala van: az egyik az IPv4-hez, a másik az IPv6-hoz. Ha valaha is írtál nekik egyéni szabályokat, akkor valószínűleg az OpenWRT /etc/tűzfalban tetted.az iptables parancsot használta, ami azt jelenti, hogy csak a szabályokat adta hozzá az IPv4 tűzfalhoz. Ha ugyanazt a szabályt szeretné hozzáadni az IPv6-hoz, meg kell másolnia az ip6tables paranccsal. Egy másik jelentős probléma, ha kapcsolatkövetést használ a portkopogás észleléséhez, mint én, az, hogy a Linux kapcsolatkövetésnek nehézségei vannak az IPv6 multicast használatával, így azok a csomagok, amelyek multicastra mennek, de unicastként térnek vissza (mint a legtöbb felfedezési protokoll), rossz conntrack állapotot kapnak. Ennek kijavításához végül kellett egy bemeneti szabály csak elfogadja az összes ICMPv6 és DHCPv6 (udp portok 546 és 547). A tűzfal másik szempontja, hogy most mindenkinek megvan a saját IP-címe, nincs szükség NAT-ra (az OpenWRT meggyőzhető arról, hogy ezt automatikusan gondoskodjon, de ha manuálisan másolja az IPv4 szabályokat, ne másolja a NAT-szabályokat). Az utolsó valószínűleg jobban alkalmazható rám: a wifi interfészemet úgy tervezték, hogy a helyi internet kiterjesztése legyen, és az ahhoz csatlakozó összes gép várhatóan képes lesz megvédeni magukat, mivel olyan ellenséges környezetekbe vándorolnak, mint a repülőtéri wifi, így a wifi-hez csatlakoztatott eszközök teljes kitettségét az összes portra, beleértve a portszondákat is. A belső eszközökhöz van egy kapcsolódó, megalapozott szabályom, hogy megbizonyosodjak arról, hogy nem vizsgálják meg őket, mivel nem úgy tervezték, hogy áttelepüljenek a belső hálózatról.

most az OpenWRT problémái: mivel a NAT-ot az IPv4-en szeretné, de az IPv6-on nem, két külön Wan-zónával kell rendelkeznie számukra: ha megpróbálja kombinálni őket (ahogy először tettem), akkor az OpenWRT hozzáad egy IPv6 –ctstate érvénytelen szabályt, amely megakadályozza a szomszéd felfedezését az IPv6 multicast conntrack problémái miatt, tehát a wan-zónáim vannak (nos, ez hazugság, mert a tűzfalam most kézzel készített, de ezt ellenőriztem, mielőtt a kézzel készített tűzfalat a helyére tettem):

config zone option name 'wan' option network 'wan' option masq '1' ...config zone option name 'wan6' option network 'wan6' ...

és a LAN zóna útválasztási szabályai (teljesen elérhető) a következők:

config forwarding option src 'lan' option dest 'wan'config forwarding option src 'lan' option dest 'wan6'config forwarding option src 'wan6' option dest 'lan'

összerakva: Az ügyfelek IPv6 csatlakoztatása

most, hogy konfigurálta az útválasztót, mindennek csak működnie kell. Ha igen, akkor a laptop wifi interfészének globális IPv6-címmel kell rendelkeznie

ip -6 address show dev wlan0

ha ez üresen jön vissza, engedélyeznie kell az IPv6-ot a disztribúción. Ha csak egy link helyi (fe80:: prefix) címet, IPv6 engedélyezve van, de a router nem reklám (gyanús tűzfal problémák discovery csomagok vagy dnsmasq hibás beállítás). Ha globális címet lát, akkor kész. Most már képesnek kell lennie arra, hogy https://testv6.com – ra menjen, és biztosítsa a 10/10 pontszámot.

a puzzle utolsó darabja az új IPv6 kapcsolat előnyben részesítése, amikor a DNS IPv4 vagy IPv6 címek közül választhat. Minden modern Linux kliensnek előnyben kell részesítenie az IPv6-ot, ha elérhető, ha dual stack hálózathoz csatlakozik , ezért próbálja meg … ha Pingel, mondjuk, www.google.com és lásd az IPv6 címet. Ha nem, akkor be kell lépnie az IPv6 címcímkézés (RFC 6724) és a gai zavaros világába.conf.

következtetés

az IPv6 hozzáadása a meglévő IPv4 beállításhoz jelenleg nem egyszerű plug in and go művelet. Azonban, feltéve, hogy megértesz egy maroknyi különbséget a két protokoll között, ez sem leküzdhetetlen probléma. Azt is glossed át sok a probléma akkor találkozhat az internetszolgáltató. Vannak, akik arról számoltak be, hogy Internetszolgáltatóik csak egy IPv6-címet osztanak ki előtag-delegálás nélkül, ebben az esetben szerintem a legbölcsebb lenne új internetszolgáltatót találni. Mások arról számolnak be, hogy az internetszolgáltató csak egy /64 előtagot delegál, tehát itt vagy csak egy alhálózatot futtat (valószínűleg sok otthoni hálózathoz elegendő), vagy a /64-nél nagyobb alhálózatot, és tiltja az SLAAC-ot, ami határozottan nem ajánlott konfiguráció. Azonban, feltéve, hogy az internetszolgáltatója ésszerű, ennek a blogbejegyzésnek legalább segítenie kell az indulásban.