Aktualizováno 10.4. 13:15:
Myslíte si, že Microsoftí služby Office 365 a Outlook.com jsou použitelné s IPv6? Bohužel jsem se dnes přesvědčil, že nikoliv. Naštěstí jsem se rozhodl provést upgrade pracovního ultrabooku na Windows 10 Creators update o víkendu a ne ve všední den, kdy mám puštěný Outlook 2016 a od rána do večera řeším věci i na základě příchozí pošty. A jak spolu vše, co bylo napsáno souvisí? Více v článku.
Na základě tohoto článku a vcelku pozitivních ohlasů, např. na konečně inteligentnější volbu wifi sítě či VPN spojení i dalšího pokusu Microsoftu, jak se vyrovnat s high DPI, jsem se rozhodl včera večer spustit upgrade a šel jsem spát. Myslím, že jsem instalaci ještě jednou odklepl a poté se na ultrabook podíval až ráno. Vše vypadalo OK, až na nesmyslnou hlášku týkající se síťové Xerox tiskárny. Takže jsem spustil Disk Cleanup, čímž se uvolnilo 40 GB drahého SSD prostoru. A jelikož byl víkend, tak jsem průběžně zkoušel všechny programy, ale poštu jsem nepotřeboval, na to mi stačil mobil.
Až teď večer jsem si všiml, že nemám puštěný Outlook 2016. Spustím a vidím "Loading profile...". Víc ani ťuk, ani při opakovaných pokusech. Takže klasika - outlook.exe /safe - nepomáhá. Tak scanpst.exe na všech .ost souborech - nepomáhá. Přeci nebudu mazat profil a pak znovu synchronizovat gigabajty v .ost souborech. Někde jsem našel fintu, že člověk vypnul na notebooku wifi, nastartoval Outlook v airplane módu, pak wifi zapnul a pošta se mu začala korektně synchronizovat. Takže jsem zkusil to samé - a Outlook nastartoval jako z praku. Tím pádem musí být .ost soubory v pohodě. Zapnu wifi a najednou koukám, že mailbox z on-premise Exchange se v pohodě připojil a synchronizuje se, zatímco mailbox v O365 a též osobní schránka v Outlook.com hlásí pořád Trying to connect... - a víc nic.
Takže jsem přes CTRL+ pravoklik na ikonce Outlooku v notifikační oblasti zvolil Test Email AutoConfiguration - zadám e-mail, heslo - a nic, "Autoconfiguration was unable to determine your settings!".To přeci není možné.
Pak mne to napadlo - mám doma z Mikrotiku navázaný 6to4 tunel do Hurricane Electric pro studijní a testovací účely IPv6. Tj. i na ultrabooku mám dualstack a IPv6 adresu začínající 2001:470::/32. A v minulosti jsem si poladil preference tak, aby IPv4 bylo preferovanější než 6to4 HE.NET. To vypadá, že upgrade tohle rozbil.
Rychlý test:
ping www.google.com
Pinging www.google.com [2a00:1450:400c:c04::69] with 32 bytes of data:
Reply from 2a00:1450:400c:c04::69: time=56ms
Aha, takže systém preferuje IPv6 před IPv4. Jelikož vím, že na on-premise Exchange serveru z Internetu nepodporujeme IPv6 a nemáme ve veřejné DNS zóně žádné IPv6 DNS záznamy, tak by to ale znamenalo, že Microsoft sice tyto záznamy pro své služby má, ale tyto služby jsou v reálu nefunkční!
Takže celé to bádání nad outlookovským Loading profile... bylo zbytečné, musím nejdříve ze všeho opět upřednostnit IPv4 před IPv6. Jak já to ale tenkrát udělal? Samozřejmě nebyl čas na napsání článku, takže poznámka určitě někde existuje, ale bůh ví, jestli v podobě .txt souboru, někde ve OneNote, ve zprávě odeslané sobě samému. Nakonec pomohl tento starší článek, kterým jsem to samé řešil už v době Windows 7. Ve Windows 10 vypadají IPv6 preference takto:
netsh interface ipv6 show prefixpolicies
Querying active state...
Precedence Label Prefix
---------- ----- --------------------------------
50 0 ::1/128
40 1 ::/0
35 4 ::ffff:0:0/96
30 2 2002::/16
5 5 2001::/32
3 13 fc00::/7
1 11 fec0::/10
1 12 3ffe::/16
1 3 ::/96
No jo, IPv6 adresy mají prioritu 40, zatímco IPv4 adresy pouze 35. Jelikož je jakýkoliv můj odchozí IPv6 provoz routován do TunnelBrokeru, dochází sice k vyšší latenci, ale zároveň vím, jak velmi snadno privilegovat IPv4, aniž bych přišel o možnost si s IPv6 ve volných chvílích hrát. Přidal jsem ještě jednu politiku:
netsh interface ipv6 add prefixpolicy 2001:470::/32 10 20
Jinými slovy vše, co jde do TunnelBrokeru, bude mít prioritu 10, zatímco IPv4 má default prioritu 35. Opět rychlá kontrola:
ping www.google.com
Pinging www.google.com [74.125.206.104] with 32 bytes of data:
Reply from 74.125.206.104: bytes=32 time=19ms TTL=41
No vida, tak už se světem komunikuji pomocí IPv4. Po chvíli se přepnu do Outlooku 2016 - a co nevidím, obě dvě služby, tj. O365 i Outlook.com se konečně připojily a probíhá synchronizace složek. Hanba ti, Microsofte! Takže ještě pro pořádek zopakování Test Email AutoConfiguration - prošel zcela bez problémů.
Při všem tom bádání jsem dnes nalezl články, které krásně dokumentují, jaký je stav s IPv6. Je to zoufalé. Když už plně soběstačnou IPv6-only síť není schopen rozjet ani Microsoft, tak kdo tedy? Jeden odkaz za všechny - https://www.theregister.co.uk/2017/01/19/windows_10_bug_undercuts_ipv6_rollout/.
Doplnění 10.4. 13:15:
Nedalo mi to a k problému se dnes ještě jednou vrátil. A zjistil jsem, že při poslední migraci domácího routeru se mi bůhví jak ztratilo jedno IPv6 pravidlo. Pravidlo povolující LAN klientům přistupovat k HE.NET. Docela trapné.
Každopádně platí, že Creators update resetuje prefix policies do default stavu. Před upgrade jsem tam totiž musel stoprocentně mít upravenou politiku, aby bylo IPv4 preferováno před IPv6, jinak bych na botu v konfiguraci routeru přišel už před mnoha měsíci.
A také platí výše uvedené přidání nového prefix pravidla, které mi dovolí to, co chci. Tedy:
- preferovat IPv4 před IPv6 realizovaným prostřednictvím 6to4 tunelu. Pokud tedy v DNS zóně existují dva záznamy, jeden pro IPv4, druhý pro IPv6, ve finále se použije hodnota IPv4 adresy.
- zpřístupnit IPv6-only adresy a DNS záznamy, např. speedtest6.cesnet.cz nebo ipv6.whatismyv6.com, ale třeba taky ipv6.google.com.