Na SLAAC mam jednu odpoved:
isc-dhcp-server + radvd + ndppd
nastaveno, overeno, provozovano. A muzu mit subnetu kolik chci. I s vlastnimi statickymi IP pro dany stroj (ne pro danou sitovku, tzn vyhori sitovka, koupim novou a zmeni se mi IP pro masinu, u me vyhori sitovka, zmenim nastaveni DHCP static leases a stroj ma stejnou IP dal).
ta funkce SLAAC kdy prideli ip podle MAC adresy mi je proti srsti od samotneho pocatku a i kdybych mel pro sebe rozsah /6, volil bych tohle reseni.
Ach jo... Např. http://tools.ietf.org/html/rfc5375#appendix-B.1
Ano, může, do jedné sítě. Pokud bude chtít síť rozdělit na podsítě, bude muset prodloužit prefix nad /64, čímž se řada věcí zkomplikuje.
Citací z dříve zmíněného RFC 5375:
Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes.
Ano, s několika omezeními se dají provozovat i podsítě s delším prefixem, ale takové workaroundy bych uznával jen pro případy, kde to z nějakých technických příčin jinak nejde. Spíš bych doporučil hlasovat peněženkou pro operátora s rozumným adresním plánem.
To je jak u blbejch na dvorku... Chápete, že lidi nemají jen jednu síť? Např. je zcela normální oddělit WiFi a normální LAN. Někdo má krom té WiFi ještě hotspot pro návštěvy, který je nastavený jinak (např. nezaheslovaný nebo s nějakým proklikávacím captive portálem a s omezenou rychlostí). Pokud chci mít něco přístupného z venku, to tak většinou píchnu do DMZ. Pokud mi nějaký "chytrý" provider dá jednu /64, tak odcházím vytvořit /48 tunel u HE, protože nativní IPv6 od ISP je v takovém případě k ničemu.
Protoze i pomerne velky blbci vedi, ze /32 v ipv4 taky jaksi nejde routovat, protoze neni jak.
V ipv6 siti proste eixtuje /64 routovatelnych segmentu, ani o jeden vic. A jelikoz neexistuje na tyhle planete provider, kterej by nemoh pro naprosto kazdej pripojenej pocitac ve svy siti pridelit minimalne /56 .... neexistuje ani zadnej duvod, proc delat takovou picovinu jako pridelovat mensi.
FYI /32 se v ipv4 běžně routuje pomocí NATu, sice to funguje jen pro ICMP, UDP a TCP ale to v praxi nevadí protože ipv4 NAT je braný jako standard dnešního internetu.
V ipv6 existuje i bez NATu routovatelných segmentů mnohem více než 2^64 pokud přistoupíme na to že subnety mohou být i menší než /64 - ano, nebude pak fungovat SLAAC a pár dalších detailů, ale praktický základ opět funguje - takže horší než dnes běžný NAT s ipv4 to není (dokonce je to lepší).
Pokud DHCPv6 klient přiděluje na rozhraní masku /64 bez ohledu na RA, je to jednoznačně chyba implementace. Jediná správná maska pro adresu získanou z DHCPv6 je /128.
Ono je to trochu složitější a pro pochopení doporučuji přečíst RFC 5942: IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes. Ve zkratce: V IPv6 vlastně neexistuje nic jako síťová maska. Úkolem koncového systému je pouze obstarat si IP adresu. Pro určení routerů slouží ohlášky (RA), které mohou, ale nemusí obsahovat informaci o prefixu s tagem L, který říká, že daný prefix je dostupný přímo na lince. Pokud koncový systém žádnou takovou informaci nedostane, jednoduše všechen svůj provoz předává routerům. Je to poměrně šikovný framework, který perfektně pasuje třeba na NBMA topologie, které dominují přístupovým sítím.
Protože k adresování routeru stačí použít LL adresy, není žádný problém mít na koncovém systému nastavenu jedinou globální IPv6 adresu s maskou /128. Nastavíme-li ručně jinou masku, vlastně tím ručně přebíjíme část informace, která by jinak měla přijít z RA (nic proti, ruční konfigurace má v odůvodněných případech smysl, jen to asi nebude případ domácí sítě).
EUI-64 bylo od počátku neskutečná kravina(tedy přidělování "veřejných" IP adres na základě fyzické adresy rozhraní). Pak se to začalo flikovat třeba pomocí privacy extensions atd..... Zkuste v takovém prostředí třeba udržovat nastavení filtru ve firewallu, který má rozlišovat konkrétní IP adresy...
A vůbec, proč by měl router přidělovat prefixy? Proč vymýšlet hovadiny, když svým způsobem totéž už roky dělá DHCP?
A to už raději ani nepíšu o blbostech s "link local" adresami, kde je problém u více rozhraní rozlišit subsíť... a opět se to flikuje tím, co je v RFC4007 - pochopitelně nesystémově a tedy neúspěšně...
Záležitost s prefixem /64 to je taky půvabná věc... Který zákazník bude kdy schopen využít bezmála 2^64 adres? Proč tolik bitů, když se tím pak už z principu plýtvá?
Atd...
IPv6 je podobná záležitost jako je teď v Linuxu systemd. Pochybný návrh, dělaný lidmi, odtrženými od reality, vnášení komplikací tam, kde být nemusejí. A to nejhorší - příšerně uřvaná komunita zvěstovatelů světlých zítřků kolem, která nakonec dosáhne silového prosazení...
Ale co už. Karty jsou rozdány, změnit už to nelze a tak nezbývá než se v těch exkrementech hrabat.
A vůbec, proč by měl router přidělovat prefixy? Proč vymýšlet hovadiny, když svým způsobem totéž už roky dělá DHCP?
Proč by měl protokol aplikační vrstvy konfigurovat nastavení vrstvy síťové? Jestli je něco flikované, tak je to právě DHCP v IPv4, které zcela popírá vrstvový model síťové architektury. Jenomže IPv4 nic jiného než ruční konfiguraci neuměl a bylo potřeba najít nějaké řešení.
A to už raději ani nepíšu o blbostech s "link local" adresami, kde je problém u více rozhraní rozlišit subsíť... a opět se to flikuje tím, co je v RFC4007 - pochopitelně nesystémově a tedy neúspěšně...
Co konkrétně vám připadá nesystémové na omezení dosahu IP adres? Myslíte, že je lepší situace z IPv4, kde se například musí provozovat samostatný protokol ARP a všechno se musí řešit broadcasty?
Záležitost s prefixem /64 to je taky půvabná věc... Který zákazník bude kdy schopen využít bezmála 2^64 adres? Proč tolik bitů, když se tím pak už z principu plýtvá?
Dvě slova: horizontální skenování. V IPv4 běžná praxe, v IPv6 velmi obtížné, až nemožné (bez postranních kanálů).
Jen bych dodal, ze delegace reverzniho DNS mozna nakonec je. Nejedna se ovsem o "standardni" feature, tedy nenaklikate si to na webu.
Jak na to? Je potreba pozadat skrz infolinku (nechat se prepojit na technickou podporu datovych a DSL sluzeb) s informaci, kam prefix oddelegovat. Infolinka (resp. podpora datovych sluzeb) to pak preda dal k samotnemu nastaveni.
(Mozna jednodussi bude pozadavek popsat podpore na socialnich sitich, ktera jej muze dale predat rovnou popsany, aniz by doslo ke ztrate informaci vlivem lidskeho faktoru.)
Tak já tedy nevím, diskuse na téma prefixy je dost dlouhá, ale... proč T-M píše na odkazované stránce tot: "Proč přidělujeme pro zákaznická zařízení prefix /56?
Prefix o velikosti /64 je vhodný pro jednu malou domácí počítačovou síť, což neodpovídá požadavkům našich zákazníků. A protože nechceme naše zákazníky omezovat, rozhodli jsme se poskytovat prefix o velikosti /56, který vystačí až na 256 sítí za DSL modemem."
Ty jsou na obou stranach. Spis v tom vidim lenost Nemcu. Nemci jsou tak lini, nebo spis opatrni, ze nez aby vymysleli jak to orezat a porusili ordnung, tak daji stejny prefix. Nastavi stejnou sablonu jako v nemecku a cech to dostane rozkazem. Nikoho to nic nestoji, proze je z ceho rozdavat.
Obcas to funguje v zakosuv prospech.
U O2 se domnivam ze to dopadlo nasledovne:
Udychany manazer dorazil k technikum jez se soustredene pripravuji v labu na brouseni konfigu a vzdaleny "looonch". A testuji konfigurace
M: Pribehne cely udychany a propoceny z fitka ktere ma ve sve kancelari. A proc musej dostat celej /48?
T:Sefe nas to skoro nic nestoji!
M: Stoji nas to majlant! Videli jste posledni hospodarske vysledky Telefonicy? Kdo neco rekne, tak leti v nasi 115te cistce. A budete delat s cinanama v hujaja.
T: Ale...
M: Pratele ja to s vami myslim dobre. Chybi vam obchodni duch. To je to! Mate tady spoustu tech serepeticek... co to je? Opticke vlakno?
T: Ne to je snura od lampicky.
M: Aha. No. Hehm. Kde jsem to... Jo. Mate tady tech spoustu blbosti ale chybi vam obchodni duch.
T: Technik si zacpe nos a zamyslene se podiva na kolegy. Obchodniho ducha jako by clovek v tu chvili primo citil.
M: Panove my z toho udelame dalsi sluzbu! Vetsi prefix bude za priplatek.
T2: Tyjo on snad udela kseft i z tech IPv4 adres co nam dochazeji.
M: Tak se mi to libi mlady muzi! Jde videt ze vam to pali. S takovou to muzete dotahnout daleko... jeho pohled se kratce zastavi na testu IPTV u zahranicnich zprav o KLDR,
M: Co by za to dali deti v Jizni koreji.
T3: Ti to maji v ucte za elektrinu! Ti by se nam vysmali!
M: To neni pekne delat si legraci z ciziho nestesti. Budeme prodavat staticke IPv4 adresy novym zakaznikum. Ja udelam prezentaci v powerpointu a spustime mnohafazovy proces schvaleni a implementace. S usmevem na tvari odchazi...
Po chvilce prorazi ticho nejstarsi technik. Je cca o 20 let starsi nez M ktery prave odbehl zpatky tyrat telo.
T: No ne ze bych se tomu divil. Akorat mne porad nebavi byt doma pred synem za blbce.
T2: To mas fuk. Do dalsi cistky to nak dotahnem... Ja uz jsem skoro zapomnel ze jsi nasim sefem ty.
T3: Se podiva vycitavym pohledem na T2 a jde si na zachod prohlednout servery s nabidnou pracovnich prilezitosti...
Pobavil jste, diky. :-)))
Ale jeste k tem Nemcum - do navrhu IPv6 na DSL koncern nemluvil vubec, nastesti. Lenost tomu muzete rikat, kazdopadne dat vsem /56 davalo smysl technicky (zakaznik ma prostor pro sadu podsiti) a nakonec i ekonomicky (prilis mnoho moznosti k vyberu = slozita a draha implementace a podpora).
/64 spojovací prefix je na uživatelské infostránce tiše ignorován; stránka zmiňuje jen /56 prefix, který je přidělen přes Prefix delegation. Prakticky samozřejmě můžete použít /64 z WAN i v rámci LAN. WAN je PPPoE, která může fungovat jen na link-local adresách (podobně jako to mnozí hackují u O2, kde je k dispozici /64+/64).
Nebo je v tom popisku něco špatně?