Vlákno názorů k článku 10 důvodů, proč mít NAT na IPv6 od yá - co treba RFC a vyhledy do budoucna?

co treba RFC a vyhledy do budoucna?

to jo, ale od toho mají svého poskytovatele.

spis by mel byt pripojen tak jak si krabicky reknou

Rozumne to je, pokud to dotycny tak chce, ale pokud nema ani paru o nejakem routovani, nema smysl to resit. Proste bude na subnetu spolu s dalsi tisicovnou klientu.

No, ja bych rek ze pro 99% uzivatelu je to tak maximalne sprosty slovo.

Pokud je připojen více než jeden počítač, tak je to IMHO celkem rozumné... Minimálně při použití IPv6. Ono je pak vlastně jedno, jestli je tam těch dalších počítačů 5, 10 nebo 2^27 :)

tak zase na druhou stranu, málokdo má zájem o sousedovy broadcasty.

No predevsim bezna domacnost nepotrebuje router ani firewall v extra kabce, protoze BFU si to stejne neumi nakonfit a ted je tato konfigurace standardem predevsim proto, aby vubec bylo mozne pripojit vic nez jedno zarizeni.

Pokud by bylo i na IPv4 pridelovano bez kecu potrebne mnozstvi adres, tak to neni treba ani ted.

A on snad existuje nějaký důvod, aby ho neměla?

protože za chvíli bude mít svou IP adresu i záchod, který bude hlásit doktorovi, jak dobře jste se vys.al :-)

A proc by mela mit standardni domacnost svuj subnen ? Neexistuje pro to zadny duvod.

Ale zapomel jste, ze NAT neni firewall, takze k propojeni privatnich adres pres NAT stejne potrebujete firewall, a jestli ne tak jste blazen.
A skutecny firewall je skoro stejne narocny jako nejaka proxy.

Ja nevidim zadny duvod pouzivat privatni adresy, misto nich se daji pouzivat "normalni" adresy oddelene firewallem od zbytku site.

A proč byste to tak nemohli mít dál? V případě IPv6 jsou pro tohle určeny unikátní lokální (unique-local) adresy, které vám mohou vyhovět naprosto stejně.
Jinak doporučuji ke studiu toto...

A co firmy, které mají desítky, či stovky poboček po celém světě (propojené přes VPN tunely) a chtějí mít všude jednotný rozsah IP? Jak zajistí, aby jim ISP přiřadil stejný prefix? My ve firmě máme desetitisíce počítačů po celém světě a IP adresy máme hierarchicky organizované podle fyzického umístění (10.číslo státu.číslo pobočky/podsíť­.podsíť/číslo pc)
Pro obyčejné lození na web není problém mít vnitřní síť úplně oddělenou od internetu s privátními adresami a jednotlivé pobočky propojené přes internet pomocí VPN tunelů a ven se leze přes proxy. Problém je v tom, že máme hromadu serverů, které jsou přístupné z venku a k tomu využíváme NAT (1:1) a taky máme dost stanic, které komunikují s "venkem" po protokolech, kterým se přes proxy moc chodit nechce.

pro firmy co chtej smirovat zamestnance je to velmi prakticke:)

Tohle řeší prefix delegation u DHCP (umi napriklad ISC DHCP od verze 4.1)

> ad 5 - toto řeší v IPv6 ULA adresy ve spojení s proxy servery,

Pripojeni site s privatnima (ULA) adresama k Internetu pres proxy server je mnohem mene prakticke reseni nez pripojeni site s privatnima adresama k Internetu pres NAT.

což je jenom hloupá výmluva, protože toto je věc, která se dá velmi jednoduše nastavit přinejhorším změnou firmware. (ostatně stávající krabičky stejně IPv6 neumí, takže svým zákazníkům můžete poradit, co si mají koupit)

O strukturu sítě v domácnosti se starat musím. Je potřeba rozlišovat tři situace:
- je připojen pouze jeden počítač - musím přidělit adresu /128,
- v domácnosti je jeden subnet - přidělit /64
- v domácnosti je více subnetů - přidělit /56 či /60.

V prvním případě mohu přidělovat přes DHCPv6. Tuto adresu mohu přidělovat v podstatě náhodně v rámci příslušného rozsahu.

Ve druhém případě musí přidělit přes DHCPv6 jednu externí adresu, při dalším DHCPv6 pro vnitřní rozhraní musím přidělit /64 subnet a do svého routeru doplnit směrovací údaj. Problémem je, kdy mám tento směrovací záznam zrušit - pokud by měl být natrvalo, tak musím domácímu routeru přiřazovat pořád stejnou externí IPv6 adresu a pořád stejný vnitřní /64 rozsah. Nebo musím monitorovat stav přidělování z DHCPv6 serveru a v okamžiku, kdy propadne pronájem, tak zrušit záznam ve směrovacích tabulkách.

Pokud si v domácnosti někdo zapojí druhý vnitřní router, tak ten požádá o adresu pro své externí rozhraní, dostane adresu od DHCPv6 serveru z hraničního routeru (popřípadě přes autokonfiguraci). A poté vnitřní router požádá o adresu pro své interní rozhraní. A hraniční router, protože dostal jen /64 subnet, tak požadavek nejspíš zamítne. Nebo ho může předat na DHCPv6 server poskytovatele a ten přidělí další /64 subnet, hraniční router bude muset upravit své směrovací tabulky a předá upravenou DHCPv6 odpověď vnitřnímu routeru.

Neznám specifikaci DHCPv6 protokolu tak, abych byl schopen říct, že mnou uvedená konstrukce je vůbec možná. Určitě ale nevím o žádné implementaci. Většina autorů však píše o tom, že jsem v tomto případě měl hraničnímu routeru přidělit větší rozsah (/56 či /60). Ale jak to poznám??? Jediná šance je vytvořit aplikaci, ve které budou jednotliví uživatelé žádat o velikost svého rozsahu. Mohl bych tuto možnost dodatečně zpoplatnit ....

Většina domácích routerů nejde konfigurovat po WAN portu. Změnit konfiguraci IP, znamená dojít k uživateli fyzicky.

V soucasnosti prisel do domacnosti BFU technik nebo kamarad a zmenil jedno nastaveni na hloupe krabicce a vse fungovalo.
Ted pokud bude v siti jeden/dva stroje, co bude mit vyply autokonfig, tak je musite obejit vsechny. A kdyz je otevrene nezabezpecene AP a cela sit v autokonfigu, tak radsi ani nedomyslet.

Pro existenci NAT zadne duvody nejsou.

O strukturu site domacnosti se starat nemusite, kazdy jejich zarizeni jednoduse dostane nejakou IP. Nevidim v tom zadny problem vzhledem k rozsahu adres. Pokud si domacnost pozada, jednoduse pridelite prefix, stejne jako dosud jednu IPv4. Navic nebude muset kazdy BFU vecne resit po netu, proc mu nefunguje tohle a tamhle ... jak ma co kde nastavit ve sve hloupe krabce aby mohl byt active ...

Prechod k jinemu ISP zakaznik vubec nepozna. Pokud poskytuje do site nejake sluzby, pak jiste pouziva DNS, pokud ne, je mu uplne sumafuk ze se mu zmeni adresy.

ad 1 - ISP by měl mít vlastní AS s BGP, měl by mít připojení do více sítí. Pokud by se ale mluvilo o zákazníkovi, tak tomuto problému rozumím. Plánované přechody k jinému ISP v IPv6 usnadňuje možnost mít přiděleno více adres.

ad 2 - v rámci sítě ISP není potřeba a ani vhodné dodržovat hierarchickou strukturu IPv6 adres z důvodu úspor ve směrovacích tabulkách.

ad 3 - měnit najednou adresy všech nameserverů je zhovadilost i v IPv4. Pokud se to udělá postupně, tak není problém - pokud tedy nezpřístupňujete zákazníkům jen jeden nameserver.

ad 4 - mohu zákazníkovi přidělit dva IPv6 adresní rozsahy. Z představy, že bych měl v IPv4 pro zákazníky udržovat měsíce výjimky typu DST-NAT se potím hrůzou.

ad 5 - toto řeší v IPv6 ULA adresy ve spojení s proxy servery,

ad 6 - opět ULA adresy,

ad 7 - pravděpodobnost kolizí v IPv4 je o mnoho řádů vyšší,

ad 8 - prostudujte si http://anonymous-p2p.org/index.html a najděte si programy, které podporují IPv6 (popřípadě podpořte finančně naprogramování podpory pro IPv6 - např. pro I2N),

ad 9 - jak jste sám psal, řeší NAT64

ad 10 - tato oblast se příliš neřeší a ani se tomu nedivím. Tento problém nastane u různých specifických zařízení (kamery, printservery, sondy, ...), které ale stačí mít dostupné v rámci privátní IPv4 sítě. Pokud by potřebovali komunikovat přes IPv6, tak se využijí proxy servery.

Pro existenci NATu v IPv6 bych viděl dva důvody:
- připojování malých koncových zákazníků (hlavně domácnosti), neboť jich je mnoho a použití NATu znamená, že se nemusím starat o strukturu jejich sítě,
- usnadnění přechodu zákazníka od jednoho ISP k druhému,