Osobně doufám, že vypukne "panika" a jejím výsledkem bude, že všichni významní hráči se začnou ujišťovat, že jejich servery jsou dostupné přes IPv6. Blbé, je, že Microsoft s velkou slávou IPv6 zavedl v roce 2011 (na ostro viz http://blogs.bing.com/search/2011/06/17/world-ipv6-day-next-generation-of-internet-was-successfully-tested/), ale nyní to nefunguje - ani http://www.bing.com ani http://ipv6.bing.com (ten překvapivě resolvuje na IPv4 adresu). U Google je nutné použít adresu http://ipv6.google.com. U nás v ČR IPv6 například neposkytuje http://www.idnes.cz (jedou na Microsoftu), ale zato u Seznamu je to lepší - přes IPv6 funguje http://www.seznam.cz, http://www.novinky.cz i http://www.super.cz, ale nefunguje http://www.prozeny.cz.
Ještě blbější je, že já sice doma IPv6 mám (ADSL od O2), ale na některé adresy to hloupne (zpoždění, timeouty), protože O2 nejede IPv6 nativně, ale přes tunel a tím pádem dochází zřejmě k problému s MTU (je menší než 1500 kvůli tomu tunelu) a když někdo po cestě zahazuje ICMPv6, tak je to v čudu. Proto mám doma na ADSL od O2 podporu IPv6 vypnutou. Ale ve škole to v současné době funguje naprosto bez problémů (nativní IPv6 od Cesnetu) - problémy jsem u některých webů zaznamenal naposledy asi před 1,5 rokem (bylo to IIRC vždycky kvůli timeoutu DNS). Předpokládám, že právě kvůli potížím, na které narážím doma u O2 a ve škole občas kvůli DNS, Google neposkytuje IPv6 na hlavní adrese (protože pak bych s tím z domova mohl mít potíže) a Microsoft se na to vyprdnul úplně.
Jinak ze zavádění IPv6 mám rozporuplné pocity, protože je vidět, že je to navržené od stolu a nikoliv tak, že by to dělal nějaký praktik. Jednoduchost IPv4 je v IPv6 prostě pryč :-( Další technický problém je s podporou v nejrůznějších zařízeních, kde něco buď nefunguje nebo se dané formy šprajcnou a všechno se tím komplikuje (např. odmítnutí DNS přes ND u Cisco & Microsoft - prý "to není spolehlivé"), nebo tristní přístup k IPv6 NAT (výmluvy NAT není firewall jsou trapné, protože já jako správce hraničního routeru potřebuju portforwading, DNAT a ocenil bych i SNAT) nebo potíže s podsítěmi /127 (Mikrotik stále nemá ROSv7 ani v betě).
Čili výsledek je, že velcí poskytovatelé budou hrát o čas a ždímat z malých poskytovatelů a zákazníků čím dál vyšší částky za veřejné IPv4, dokud to nedosáhne absurdních rozměrů (a zřejmě kvůli tomu někteří malí poskytovatelé budou pohlceni těmi velkými).
Google už docela dlouho nabízí IPv6 na hlavní stránce automaticky. Vlastně všechny služby u Google mi už velmi dlouho automaticky jedou po šestce. Google.cz mi třeba vrací 2a00:1450:4014:80a::1018.
Ovšem souhlasím s tím, že situace u poskytovatelů je všelijaká. Například iHned nějakou dobu šestku měl, ale pak se tam změnili správci, pohrabali se v serverech a teď už šestku nenabízejí :-/.
V mém textu došlo k vynechání myšlenky - Google nemá pro svoji doménu IPv6 DNS server, takže stanice s IPv6-only nemusí fungovat. Na adrese http://ipv6.google.com lze snadno ověřit IPv6 komunikaci, protože to jméno se resolvuje jenom na IPv6 adresu a není tam tak možný IPv4 fallback, když IPv6 zrovna nefunguje. Za zkomolení se omlouvám.
Co se týká NAT pro IPv6, tak Linuxové jádro to má od verze 3.9 (IIRC), což diskvalifikuje Mikrotik (ROS6 má 3.3). Naštěstí (alespoň pro mne) Linus není IPv6 purista, nýbrž pragmatik a praktik. NAT se hodí například při failover řešení, přesunu serveru, změnách topologie vnitřní sítě atd., do kterých nikomu na netu nic není a nikdo se tím nebude zabývat. Správce hraničního routeru to však musí nějak řešit a to nejlépe nějak hodně rychle (změny v DNS nepatří mezi nejrychlejší a znásilňovat DNS kvůli nějakému "hezkému" designu IPv6 je ujetý). Z tábora IPv6 puristů zní, že NAT pro IPv6 je fuj, protože NAT není firewall, jenže to je jen (teoretická) pravda, protože to je narážka na maškarádu (tj. dynamický NAT). A školit toho, kdo dělá firewall blbě tím, že škrtnu celý NAT, je ujetý na druhou.
Na adrese http://ipv6.google.com lze snadno ověřit IPv6 komunikaci, protože to jméno se resolvuje jenom na IPv6 adresu a není tam tak možný IPv4 fallback, když IPv6 zrovna nefunguje.
Na což nemá žádný vliv to, že DNS servery pro Google nemají IPv6, protože pro IPv6-only sítě selže oboje, jelikož se nedoptají DNS serverů (ale jen v případě, že správce sítě nepochopil, jak funguje DNS, a nepoužívá forwardery), a pro dual-stack sítě bude oboje fungovat.
změny v DNS nepatří mezi nejrychlejší a znásilňovat DNS kvůli nějakému "hezkému" designu IPv6 je ujetý
Snížení TLS kvůli přečíslování není žádné znásilňování. Tak je DNS navržené už od počátku a proto taky TLS lze snížit. Zato znásilňovat kvůli tomu routování a adresaci je úplně v pohodě.
protože O2 nejede IPv6 nativně, ale přes tunel
Kristepane, na to jsi přišel jak?
zřejmě k problému s MTU (je menší než 1500 kvůli tomu tunelu)
Ne, to protože u PPPoE je MTU 1492, ne 1500.
já jako správce hraničního routeru
Kristova noho... vzhledem k výše uvedenému bych doporučil, abys raději žádné routery nespravoval.
potřebuju portforwading, DNAT
K čemu?
Google funguje na IPv6 uz roky i bez pouziti ipv6.google.com. A musim nesouhlasit s tou jednoduchosti IPv4. Me pride jednodusi IPv6. Router (mikrotik) routuje do domaci site tunel od sixxs a at pripojim cokoliv s podporou IPv6 tak to hned beha, vcetne vlastni verejny IP adresy. U IPv4 aby clove resil ze je za NATem a z toho vyplivajici problemy...
Já s ním souhlasím. IPv6 je typický "overengineering" a podle mě přesně to je důvodem jeho velmi pomalého přijetí.
Prostě ta snaha všechno dělat jinak "a lépe" svědčí o určitém odtržení jeho tvůrců od praxe. Nic s tím nenaděláme, k těm chybám došlo už zhruba před 20 léty a musíme s IPv6 žít.
Můj domácí provider je v tomto také lempl, tak používám 6to4 tunel :-) Na současném Internetu je IPv6 konektivita prakticky k ničemu, vlastně to mám jen na hraní.... Dost by mě zajímalo, kolik procent IPv6 provozu je tvořeno právě takovými nenativními přístupy.
Microsoft s velkou slávou IPv6 zavedl v roce 2011, ale nyní to nefunguje
No, MS se hlavně dodnes nedokopal k podpoře RDNSS. Ale hlavně že si „plnou podporu IPv6“ odškrtli. (Schválně jestli se ukáže Lael a vysvětlí to.)
U Google je nutné použít adresu http://ipv6.google.com
$ host -t AAAA google.com google.com has IPv6 address 2a00:1450:4014:80b::100e
O2 nejede IPv6 nativně, ale přes tunel a tím pádem dochází zřejmě k problému s MTU (je menší než 1500 kvůli tomu tunelu)
MTU přes PPPoE (ADSL) je 1492 bajtů. Nemá to nic společného s tunely.
Jednoduchost IPv4 je v IPv6 prostě pryč
Kterou jednoduchost máte na mysli? NAT? ICE? Stavové DHCP?
výmluvy NAT není firewall jsou trapné, protože já jako správce hraničního routeru potřebuju portforwading, DNAT a ocenil bych i SNAT
Výmluvy, že potřebujete port forwarding či (tipuji stavový) NAT, jsou trapné ;-)
NAT pro IPv6 existuje, slouží pro překlad sítě (prefixu /64) na jinou síť, používá se to třeba pro multihoming. Stavový NAT ve stylu IPv4 je naštěstí mrtvý a s ním i port forwarding.
potíže s podsítěmi /127
RFC 4291: All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field
Na co potřebujete síť /127? Point-to-point spoje žádné IP adresy nepotřebují.
No, MS se hlavně dodnes nedokopal k podpoře RDNSS. Ale hlavně že si „plnou podporu IPv6“ odškrtli. (Schválně jestli se ukáže Lael a vysvětlí to.)
No, ale zato vysílají nesmyslné zběsilé záplavy paketů na deprecated site-local adresy (FEC0::/10) a hledají DNS tam. Rozum zůstává stát...
Why doesn't Windows support RFC 6106 and when will it support it?
That’s a good question. RFC 6106 is intended for configuring DNS server addresses in environments that don’t have DHCP servers. We don’t see any demand for it, however, for several reasons.
First, much of the perceived complexity associated with stateful DHCP has been mitigated with stateless DHCP implementations (RFC 3736).
Second, the requirements for customer premise equipment (RFC 6204) specify DHCPv6 support as a MUST have, and DHCP is important for lots of other reasons – such as assigning DNS servers. In other words, most people are going to need to deploy a DHCPv6 server anyway even if they don’t want it for assigning IP addresses. If Windows supported RFC 6106, it wouldn’t really simplify things for most customers – since they would still have DHCPv6 deployed anyway for configuring other aspects of the hosts. In fact, RFC 6106 support would further instigate fragmentation of the network configuration space and make it harder for software and hardware partners to engineer IPv6 support. RFC 5505 discuses some of the principles of host configurations, including the value of minimizing diversity (section 2.3). -- Christopher Palmer - Microsoft
http://blogs.msdn.com/b/b8/archive/2012/06/05/connecting-with-ipv6-in-windows-8.aspx
Pokud jsem si všiml, tak existují dvě cesty: DHCPv6 a RDNSS. MS se rozhodl pro tu první, a Palmer popisuje důvody. Jeden z nich mi připadá jako celkem silný: requirements for customer premise equipment (RFC 6204) specify DHCPv6 support as a MUST have. Navíc většina sítí je a dlouho bude dual-stack, takže se DHCP nevyhnete.
BTW podpora RDNSS v OS není nijak slavná, a není to zdaleka jen o Windows.
https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems
BTW2 jestli vám RDNSS na Windows z nějakého důvodu chybí, můžete si triviálně stáhnout a nainstalovat rdnssd-win32.
Pokud jsem si všiml, tak existují dvě cesty: DHCPv6 a RDNSS. MS se rozhodl pro tu první, a Palmer popisuje důvody.
Tohle není buď — anebo, podporovat lze klidně oboje. Windows také umí FTP, WebDAV a CIFS.
Navíc většina sítí je a dlouho bude dual-stack, takže se DHCP nevyhnete.
DHCPv4 a DHCPv6 jsou dva velmi rozdílné protokoly.
podpora RDNSS v OS není nijak slavná, a není to zdaleka jen o Windows.
Když odtamtud vyhodím všechny různé verze Windows, tak to neumí buď v případě, kdy ten systém nepodporuje ani DHCP, nebo když je to serverový OS, kde se SLAAC nepoužívá.
Ad podporovat lze klidně oboje - to jistě lze, ale je to daleko větší chaos.
Ad takže se DHCP nevyhnete; DHCPv4 a DHCPv6 jsou dva velmi rozdílné protokoly - naopak jsou to dva příbuzné protokoly, stejně jako například SMB1 a SMB2. Není problém je implementovat oba v jednom SW; nakonec ve Windows je to tak udělané.
Ad serverový OS, kde se SLAAC nepoužívá - proč ne? Na IPv4 serveru není problém použít DHCP, a desítky procent našich serverů ho i používají. Ovšem na rozdíl od SLAAC v případě DHCPv6 máte alespoň záznam o tom, kdo kdy kterou IP adresu získal.
Na IPv4 serveru není problém použít DHCP, a desítky procent našich serverů ho i používají.
Ano, stavový, který přiděluje pevně nastavené IP adresy. To samozřejmě ty serverové OS umí i pro IPv6.
Ovšem na rozdíl od SLAAC v případě DHCPv6 máte alespoň záznam o tom, kdo kdy kterou IP adresu získal.
To samozřejmě můžete mít i u SLAAC. Tedy pokud to umíte.
přes DHCPv6 ano, přes SLAAC těžko.
Ano, ty serverové OS samozřejmě neumí získávat IP adresu ze stavového DHCP serveru pomocí SLAAC. *sigh*
jinými slovy necháte klienta, ať si vylosuje IP adresu, a pak se to snažíte odchytit. Oproti tomu je DHCP daleko lepší volba.
RFC 6204 nevyžaduje podporu stavového DHCP ani u klientů, ani u routerů. S bezstavovým DHCP se DHCP server tu IP adresu stejně nedozví, protože se používají link-local adresy. Logovat Neighbor Advertisement je tak triviální, že to snad půjde i ve Windows.
Vetsi hovadinu si uz nenasel? Zadnej, ani jedinej home user nebude NIKDY provozovat DHCP server. Proc by mel?
50% krabek ktery umej IPv6 neumej dhcp ani jako klient. Proste proto, ze to nanic nepotrebujou, zbytecne slozita implementace. Staci jim Ipcko a gw. Proc by mel nekdo konfigurovat dhcp? Precist par bytu navic z paketu ze kteryho si widle prectou gw ... jo to potrebuje nejmin 150 schuzi nejvyssiho vedeni ...
Jinak receno, widle IPv6 neumej a nikdy umet nebudou.
Důkaz kruhem. LOL!
No, přesně. Když se člověk podívá na widlousoidní DHCP6 server, tak tam krom DNS jde nastavit ještě (S)NTP server, který Widle přirozeně ignorují naprosto stejně, jako ho ignorují u DHCPv4, plus NIS servery (to určitě využije skoro každý). Opravdu musthave!
- We don’t see any demand for it
- requirements for customer premise equipment (RFC 6204) specify DHCPv6 support as a MUST have
- RFC 5505 discuses some of the principles of host configurations, including the value of minimizing diversity
Plus co jsem psal já:
- většina sítí je a dlouho bude dual-stack, takže se DHCP nevyhnete.
- jestli vám RDNSS na Windows z nějakého důvodu chybí, můžete si triviálně stáhnout a nainstalovat rdnssd-win32
Kdo to řeší? Zatím jsem si všiml vás a jedince "j".
Ale zpátky k tématu. Podle svých slov jste neviděl v textu žádné argumenty. Já jsem vám je vytáhnul v bodech, a přesto k nim nemáte komentář. Takže fakt nemáte lepší argumenty než "Banda dementů z Redmondu"? Ono to totiž zatím vypadá, že "90 procent bezcenných žvástů o ničem" popisuje spíš vaše příspěvky na ten Palmerův text.
RFC 5505 discuses some of the principles of host configurations, including the value of minimizing diversity
Přesně tak. RDNSS je součástí Router Advertisment, které se používá pro SLAAC. Přidávat do sítě další protokol pro „donastavení“ SLAAC byste se měl vyhnout.
We don’t see any demand for it × můžete si triviálně stáhnout a nainstalovat rdnssd-win32
Nevidíte v tom dost silný rozpor? Kdy by psal software pro něco, co vlastně vůbec nechce?
Ad don’t see any demand for it × můžete si triviálně stáhnout; Nevidíte v tom dost silný rozpor? - nevidím. Windows mají cca 1.3 miliardy instalací. Rdnssd-win32 má za poslední rok 364 downloadů. To je 0.000028% instalací Windows, tedy zjevný nezájem.
http://sourceforge.net/projects/rdnssd-win32/files/stats/timeline?dates=2014-07-03+to+2015-07-03
Naprostá většina firemních sítí jede na IPv4, některé v kombinaci s IPv6.
Navíc vám trochu nesedí časová souslednost. Pokud máte barák plný počítačů, tak nejspíš po síti fungují, a můžete používat centrální správu. Pokud vytváříte novou síť a budete do baráku vozit stovky počítačů, tak jednak použijete (i) IPv6, a potom při předinstalaci těch počítačů není problém na ně nahrát jakýkoliv SW.
Nevím proč někteří mají sklony hledat problémy tam, kde žádné nejsou.
To vis, tohle by v M$ nezvladli, na to nemaj dostatecne matematicky vzdelany vyvojare .... http://sourceforge.net/projects/rdnssd-win32/ (pokud by chtel nekdo binarku, muzu ji nekam uploadnout).