Vlákno názorů k článku Severní Amerika bez IPv4 adres: ARIN hlásí „zero“ od Oxymoron - Proč z toho všeho humbuku okolo docházejích IPv4...
-
Petr M (neregistrovaný)
"O IPv6 nikdo nestojí, přotože nepřináší nic nového, jen že to po vynaložení nějakých pěnez bude fungovat snad jako dosud." Japato? Máte důkaz?
Lepší multicast (mistrovství v hokeji bez sekání) - viz RFC2464
Můžu si povídat se zařízením na cestách (výhoda právě pro IoT) - viz RFC3775, RFC3776, RFC6275
- zmizne ten zavšivený NAT
- zjednoduší se routovací tabulky pro BGP, protože se dá hierarchicky členit podle geografických jednotek
- lidi budou mít fungující Internet, ne náhražku (tuhle jeden známý fňukal, že má doma jedno PC, chtěl hrát online gamesu a nedovovlilo mu to přihlášení, že limit 20 lidí z jedné IPv4 je vyčerpaný)Momentální situace je takováto:
- Operační systémy (Mac, Linux, Widle >XP) nemají s IPv6 problém
- Hardwarově není problém
- Open firmware (OpenWRT, DD-WRT,..) nemá problém
- Čínský firmware má většinou problém (ale ten někdy nedává ani IPv4)
- Některý aplikace jsou zprzněný tak, že IPv6 nedokážou používat (dobře jim tak)
- BFU o IPv6 nic neví a neřeší to.
- Osvícenější uživatel to přestane řešit v okamžiku, kdy zjistí, že by to znamenalo zahodit teprve desetiletý router za litr, nebo si pohrát s OpenWRT.
- ISP by musel updatovat firmware a někdy i hardware, za pětikilo měsíčně od uživatele se mu do toho kupodivu moc nechce.
- Ajťáci od ISP by se museli učit zase něco novýho (stejně tomu neutečou, jenom za pár let to do té hlavy poleze ještě hůř)
- Provozovatel starých služeb je rád, že nedostatek IPv4 omezuje konkurenci
- Provozovatel nových služeb nemá sílu na to, aby cokoliv prosadil
- Webhosting má vlastní řešení žonglování s portama a DNS, který bere jako konkurenční výhodu, investoval do něho love a nechce investici nechat vyletět oknem,
- Stát ani EU nijak (ne)používání IPv4 ani IPv6 nereguluje.Tak to vypadá jak to vypadá... Jo kdyby EET byla jenom na IPv6 nebo zavedli daň z NATu, to by byl najednou fofr... :D
-
Petr M (neregistrovaný)
Těžko pochopit a nezabřednout do konspiračních třípísmenných teorií... Spokojme se s imbecilitou jako univerzálním vysvětlením.
RFC1631:
Privacy, Security, and Debugging Considerations
Unfortunately, NAT reduces the number of options for providing security. With NAT, nothing that carries an IP address or information derived from an IP address (such as the TCP-header checksum) can be encrypted. While most application-level encryption should be ok, this prevents encryption of the TCP header.
Známo od r. 1994...
-
hugochavez (neregistrovaný)
@Petr M
zas takova konspirace to byt nemusi= IPv6 v puvodnim navrhu napr. mela trafik defaultne sifrovat - to potom ze specifikaci jakymsi zahadnym zpusobem vypadlo (a nikdo neumi vysvetlit proc). Uz samotny koncept ze by jednotliva zarizeni mela vzdy verejnou IP (ci jich dokonce nekolik) a navazovala spojeni P2P stylem (a nedejbuh jeste sifrovane) musi byt nocni murou vsech tajnych sluzeb... :o)
Navic je znamy problem ze 2 bittorrent klienti za NATem (obzvlast tim agresivnim) "se nevidi" cili si toho moc nevymeni, zarizeni za NATem muze "oslovit" pouze klienty kteri jsou "verejne na netu videt"= maji verejnou IP (pripadne se jim povedlo donutit sveho IP k portforwardu coz je spise vzacnost nez pravidlo) Nevim o klientovi ktery by delal tzv.relay server jako to umel v zacatcich Skype ci SIP VoIP.....
IPv6 by tohle spolehlive vyresila, ovsem Hollywood by z toho urcite nadsenej nebyl, tim spis ze uz dnes spousta Bittorrent klientu dokaze jet "trackerless" a spolehaji se (s pomerne dobrymi vysledky na DHT ci PEX. A "honit mravence po lese" je jaxi neefektivni :o) -
Sten (neregistrovaný)
IPv4 NAT je typicky stavový (více IP adres se mapuje na jednu, takže si ten, kdo mapuje, musí pamatovat, komu patří jaký port), IPv6 NAT je nestavový (site-wide: vymění se jeden prefix za jiný, druhá půlka adresy je pořád stejná). Nestavový NAT je mnohem méně omezující. Přesto se i tento NAT týká jen velmi malého množství případů, typicky multi-homing sítí.
-
Lebo mozno ma firma pobocky (alebo nejake zariadenia) po celom svete na sietach roznych providerov s roznymi podmienkami. Ak uvazujeme, ze teda vsade dostane firma aspon ten /64 prefix, tak proste vnutorna siet bude mat adresovanie z VPNky so spolocnym prefixom pre cely svet, s dalsim logickym delenim a smerom von pojdu vzdy cez prefix, ktory im provider prideli.
Ano, je vela moznosti, ako to zriesit inak, od roznych IPv6 moznosti az po pouzitie dvoch IP adries, ale naco si to cele komplikovat?
-
Sten (neregistrovaný)
Taková typická situace je multi-homing. Máte více ISP s více různými veřejnými IPv6 prefixy. Uvnitř sítě použijete ULA (lokální) adresy a podle toho, přes kterého ISP to zrovna jde ven, to přeložíte do patřičného prefixu. Výhodu to má ve chvíli, kdy jeden ISP vypadne a je potřeba udělat rychlý failover (jde udělat faliover pomocí RA, ale to není tak super rychlé a problém je i s tím, že se celá síť přečísluje).
-
Filip JirsákStříbrný podporovatelproblém je i s tím, že se celá síť přečísluje
Myslím, že u IPv6 se počítá, že zařízení budou mít více IP adres. Takže ta zařízení by spíš měla mít alespoň 3 IP adresy (lokální a od obou ISP) a při výpadku jedné linky se pouze do sítě oznámí změna routeru. IP adresy tedy zařízením zůstanou, pouze začnou preferovat jiný router a tím pádem i jinou odchozí adresu. Mělo by tak fungovat i přehození na jinou linku bez výpadku – nová spojení se začnou navazovat přes druhou linku, ale stávající spojení se dokončí na té první (protože zařízením ty IP adresy zůstanou). -
Santiago (neregistrovaný)
> IP adresy tedy zařízením zůstanou, pouze začnou preferovat jiný router a tím pádem i jinou odchozí adresu.
Je casty omyl spojovat default router s pouzivanou odchozi adresou. AFAIK ale specifikace takove chovani nepredepisuje. Klient ma proste seznam prefixu a seznam default routeru, kde jak prefixy tak default routery timeoutuji zvlast. Preference jednoho default routeru neznamena pouzivat 'jeho' prefixy. Vytimeoutovani default routeru neznamena prestat pouzivat adresy jim pridelene.
Postupny prechod na druhou linku tim jde zaridit, akorat router (ci routery) musi korektne routovat i podle zdrojove adresy. Stejne tak zmena prefixu pri precislovani. Ale neni to vhodne reseni pro okamzitou zmenu uplinku v pripade vypadku primarni linky. Tam by bylo treba okamzite vytimeoutovani prefixu asociovaneho s primarnim uplinkem, ale to taky moc dobre nejde (Valid lifetime neni obecne akceptovan mensi nez 2 hodiny, maximalne je mozne ty adresy okamzite udelat deprecated). Takze prakticky je ten NAT66 pro tenhle case asi nejlepsi reseni.
-
Filip JirsákStříbrný podporovatel
Nevadí, že specifikace takové chování nepředepisuje. To chování je logické. Např. linuxové jádro se takhle pokud vím chová - pokud nejsou určena zvláštní pravidla, zdrojová IP adresa se nastavuje podle routovací tabulky (tj. ne nutně podle výchozí brány, ale podle sítě, se kterou chci komunikovat).
-
Santiago (neregistrovaný)
Zaprve, v pripade heterogenni site tezko spolehat na to, ze konkretni implementace se chovaji nejak nad miru danou specifikaci.
Zadruhe, z implementacniho hlediska i z hlediska toho, jak je psane RFC 4861, to chovani logicke neni. Ten text je vcelku jasne formulovan tak, ze ruzne zaznamy z RA se zpracovavaji nezavisle (router list, prefix list), takze nema moc smysl si tu informaci (od ktereho routeru je tento prefix) vubec pamatovat. Nehlede na to, ze ty propagovane prefixy nejsou primarne kvuli autokonfiguraci, ale kvuli urceni toho, ktere adresy jsou onlink, takze pri korektni konfiguraci routeru by kazdy router na lince mel propagovat vsechny prefixy, ktere se na te lince vyskytuji, ne jen 'kazdy svuj prefix'.
Zatreti, Linux voli zdrojove adresy podle routovaci tabulky v IPv4. Co se tyce IPv6, tam AFAIK Linux pouziva primocare chovani dle RFC 3484, tedy sekvencni sada pravidel v zasade koncici vyberem podle longest matching prefix, kde 'dostupnost routeru propagujiciho dany prefix' nehraje roli (krom pripadu, kdy host sam ma vic interfacu, ale to neni ten use case, ktery tu resime).
-
j (neregistrovaný)
IPv6 ma spoustu vyhod - predevsim pro uzivatele. Pro ISP to zadne zasadni vyhody nema, pro ne to znamena dalsi konfiguraci v siti.
Procpak si i BFU zprovoznujou 6tkovy tunely treba za ucelem pouzivani torrentu? Protoze pak skutecne p2p komunikace funguje. Jen po ne zcela optimalnich trasach.
-
Santiago (neregistrovaný)
> Lepší multicast (mistrovství v hokeji bez sekání) - viz RFC2464
Multicast ma mnoho praktickych problemu, IPv6 multicast sice oproti IPv4 multicastu par (jednodussich) odstranuje, ale ty vyznamne porad zustavaji.
> zjednoduší se routovací tabulky pro BGP, protože se dá hierarchicky členit podle geografických jednotek
To se realne pouzivat nebude. Jednak sitova topologie neodpovida geografickym jednotkam a jednak se od jakekoliv agregace nad urovni AS spis upousti kvuli bezpecnosti (zabezpecujici technologie jako RPKI a BGPSEC jsou nekompatibilni se super-AS agregaci, AS-SET v BGP jsou deprecated). Vyhoda je tak akorat v tom, ze kazde AS bude mit v globalnich tabulkach jen par velkych prefixu a ne mnoho malych.
