Vlákno názorů k článku
T-Mobile spustil IPv6 na xDSL přípojkách
od Tomáš Matějíček - Autorovi zprávičky přijde prefix /64 tak malý, že...
-
Andy_S (neregistrovaný)
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.
-
Ondřej CaletkaZlatý podporovatelAno, 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.
-
Lol Phirae (neregistrovaný)
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.
-
Ondřej CaletkaZlatý podporovatel
Ano, tohle jsem přesně vyjádřil slovním spojením „velmi obtížné“. Řešením z podobné kategorie je třeba přidělovat v domácí síti ULA adresy a ty pak NATovat do veřejného prefixu. Nebo Proxy NDP. Děkuji, nechci. Chci jednoduchý funkční systém bez nadbytečných složitostí.
-
hg (neregistrovaný)
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.
-
Praktik (neregistrovaný)
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ší).
-
Ondřej CaletkaZlatý podporovatel
Protože je to tak naschvál navržené, aby to bylo jednoduché. Představte si třeba, o kolik by musela být složitější bezestavová autokonfigurace (SLAAC), kdyby měla umět pracovat s proměnnou délkou prefixu.
-
Ondřej CaletkaZlatý podporovatel
Windows Vista a vyšší samozřejmě by default fungovat budou, mají vestavěného DHCPv6 klienta (horší to bude s některými linuxovými distribucemi, i tam se ale situace lepší). Podpora privacy extensions s tím vůbec nesouvisí, ta se týká jen mechanizmu SLAAC a ten na prefixu delším než /64 nefunguje.
-
Ondřej CaletkaZlatý podporovatel
Nenazýval bych to řešení, spíše workaround, ale ano, se stavovým DHCPv6 můžete provozovat podsítě s prefixem delším než /64.
-
Ondřej CaletkaZlatý podporovatel
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ě).
-
kozodoj (neregistrovaný)
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.
-
Ondřej CaletkaZlatý podporovatel
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ů).
ČLÁNKY DO MAILU