татко Крокодил

Понеже не ми стигна времето на lightning talk-а на OpenFest, ето едно по-подробно разписване на темата ми, “Защо мразим IPv6”.
Презентацията може да се свали от тук.

Ще започна със следната статистика по темата за IPv4 адресите:
Percentage of available address space announced: 62.1
Percentage of allocated address space announced: 65.4
Percentage of available address space allocated: 95.0
(weekly routing table report от 20ти ноември 2010)
Счита се, че някъде около април 2011та година IANA ще раздаде последните си останали /8 мрежи и изведнъж ще стане страшно. Това не значи, че RIR-овете нямат още достатъчно за раздаване, а и както виждате по статистиката от раздадените адреси още не всички се announce-ват, което ни дава още съвсем прилично количество време.
Дори обаче да свършат тотално за раздаване адресите, има съществуващи решения от типа на LSN (large-scale NAT) или CGN (carrier-grade NAT), две имена за почти същото, които ще помогнат да продължи растежа на мрежата, най-вече защото повечето трафик така и така е HTTP, който минава прекрасно през всякакви NAT-ове.
И, дори и да го нямаше това, пак Internet няма да спре, защото са свършили адресите, небето няма да падне, колкото и човека да се изредят да го кажат. Така че, аман от паника и натиск да се въведе нещо, което е пълно с глупости.

Разбира се, във IPv6 има и някои неща, които (може би по случайност) са хубави:
– прилично голямо адресно пространство, което позволява и да се отдели network locator-а в първите 64 бита
– премахната фрагментацията от router-ите и PMTUD е задължителна част от протокола, т.е. няма да има начин вече (малоумни) security експерти да казват “спрете всичкото ICMP”
– Няма (нужда от) NAT. Малко хора обичат NAT-а, и при подходящи stateful firewall-и спокойно ще може да се постигне същата функционалност.
– По-добра интеграция на IPSec (което трябва да се види доколко ще е полезно/работещо)

Като почнем с проблемите обаче става интересно:
– четейки документацията, човек остава с впечатлението, че са се старали (на принципа на Intercal) да направят нещата максимално различни от IPv4, точно като проява на синдрома “Not invented here”. Вместо ARP се използва ND (протокол, който работи върху ICMPv6), по подразбиране се прави stateless address autoconfiguration и по принцип в началната конфигурация на host-овете има добавен един още един елемент – router-а, който да раздава разни неща. Т.е. началния setup изглежда по следния начин:
машината тръгва
генерира си по някакъв начин 64 бита и с тях си прави link-local адрес, който през ND проверява дали е уникален, вдига го и се join-ва в multicast група
(навсякъде broadcast-а е заменен с multicast, да се чуди човек защо)
в multicast групата чува локален router пак по ND протокола (т.нар. router advertisement), който дава prefix и още няколко параметъра, вкл. дали да си говори с dhcp сървър (два бита, дали да иска адрес от него, и/или да иска и други параметри)
нататъка според двата бита решава как да си говори с dhcp сървър

Понеже dhcp-то се счита от IPv6 хората за нещо срамно, поддръжката му и работата му са бая странни и даже има разширение (още експериментално) да се раздава и DNS сървър от router-а (т.е. нека да омажем нещата колкото ни е възможно). Поради всичките тия неща на HAR миналата година открихме как най-лесно се раздават IPv6 адреси на nameserver-и чрез писането им на листи и лепенето им по разни стени.

Изобщо като цяло поне за мен го няма principle of least surprise. Би трябвало да се вземе в предвид как много хора са правили IPv4 мрежи, имат идея как работят и че принципите в тях не случайно са станали такива след прилично дебъгване и доизпипване.

– стари грешки – бяха направили задължителен т.нар. Type 0 routing header (т.е. source routing), добре, че преди около година се сетиха да го махнат. Source routing-а е прекрасен начин за реализация на tcp spoofing атаки.

– Като цяло има малко свързаност все още, особено в България – ако сте краен клиент е почти невъзможно да получите IPv6 свързаност вкъщи директно от доставчика си, не само защото те не са го подкарали навсякъде, а и защото крайните router-чета, които повечето хора ползват вкъщи просто не го поддържат. Всъщност има две причини да има IPv6 свързаност в България – едната е ентусиазма на разни хора, другата е, че в изискванията на Софийския Университет за Internet доставчик това е задължително условие и така бяха успели да накарат БТК да подкарат някаква такава свързаност.

– Липсва v6-only съдържание, с малки изключения (някои академични неща).

– IPv6 свързаността в почти всички случаи е с по-ниско качество от IPv4 – разчита се твърде много на тунели, тези тунели минават през всякакви странни места и винаги имат някакъв overhead. Всъщност, знам само за един случай, в който е валидно обраното – един доставчик, дето по една и съща тръба доставял v4 и v6 и за v6 нямало shaper-и. Като добавка, повечето router-и (особено тия, които Cisco прави) имат по-ниска производителност на IPv6 пакети.
Тази причина е основната да не виждам смисъл да подкарвам за моя проект IPv6 свързаност.

– Има и разни други неща, които слава богу (на сървърите) бяха преборени от здравия разум (например да няма PI адреси и multihoming да се прави като на всяка машина се дават по един адрес от всяка мрежа, към която сте свързани и чрез SHIM6 и черна магия машините да избират от кой адрес с кого да си комуникират, т.е. да изнесем routing-а от router-ите).

Като цяло, deployment-а на IPv6 се дължи на една сериозна група ентусиасти и на маркетингов натиск от тях и техни сподвижници. За момента нито е лесно и удобно, нито е особено смислено за повечето хора. Когато стане достатъчно лесно и удобно да се подкара и стане достатъчно нормална част от internet-а, може да се мисли по въпроса, но дотогава просто не си струва.

бележка: още съм скапан от openfest и разни други работи, така че може да не съм обяснил нещо достатъчно точно, ако имате въпроси/изяснявания, коментирайте.

На един разговор на ИББ седнах да обяснявам на един голям привърженик на IPv6 къде са проблемите с deployment-а за които аз знам, и какво би било да добавя ipv6 поддръжка в единия проект, с който се занимавам (среден по големина content provider). Така както го гледам, моят случай поне от техническа гледна точка има най-малкия брой мотики за настъпване и пак е доста неприятен, някой може да опише другите случаи (офисна мрежа, интернет доставчик).
След техническата част ще напиша моето мнение защо бих или не бих се занимал с това.

Като начало, става въпрос за едноцифрено число router-и, двуцифрено число switch-ове, трицифрено число сървъри и трафик от порядъка на десетки Gbps. Има някакво количество in-house написан софтуер, ползва се gentoo linux като дистрибуция.

1) Поддръжка на IPv6 стек
– Рекомпилация на всички kernel-и на сървъри, понеже по подразбиране няма, един рестарт. Действието е сравнително поносимо и може да се направи в рамките на една седмица.
– По принцип router-ската операционна система има поддръжка, трябва да се провери дали за текущата и версия има известни проблеми. Понеже е писана от оня производител, дето почва с C, не се ползва най-последната версия заради разни забавни нови проблеми, които те дописват. Upgrade на това нещо е по принцип поносим с малка загуба на свързаност, поради redundant management модулит.
– На switch-овете няма какво да се пипа – тяхната layer3 работа е само management, той може да върви и по ipv4 без никакви проблеми.

Като цяло, нещо, което може да се направи в рамките на две седмици.

2) Свързаност
По принцип в момента имаме 5 transit доставчика и 3 peering такива. За нормална работа ми трябва от два транзита да имам v6 свързаност, което по принцип е възможно при няколко от тях, като процедурата за да се разбереш с тях е крива, бюрократична и бавна. Поради малкото количество на тоя трафик нямам нужда от peering-и, или те могат да се договорят допълнително и да не са спънка.
По-важния момент е транзитите ми да имат такава свързаност с Cogent и Hurricane Electric, така че да виждам целия съществуващ ipv6 (тези две автономни системи в момента не се виждат една-друга по v6 заради малоумщина от страна на Cogent).
Друг момент ще е нови филтри и route-map-ове за различните v6-свързани неща, т.е. дублиране и преправяне на router-ската конфигурация за v6.

3) Адреси
Имам собствена автономна система и v4 адреси, процедурата за получаване на v6 адреси е сравнително проста и не би трябвало да отнеме повече от няколко дни.
Ще ми е нужно да си променя management базата, за да мога да раздавам и статични v6 адреси.

4) DNS
Основния ми DNS се движи от външен доставчик. Трябва да успея да му обясня да дава v6 отговори само ако е получил заявката по v6 или да си пренеса DNS-а при мен и пак да правя същото. Нито една от двете идеи не ме радва особено, въпреки че заради DNSSEC може да ми се наложи да направя второто.
Това е нужно поради все още съществуващите достатъчно хора, които си мислят, че имат ipv6 свързност, но реално стигат само до доставчика си и никъде повече.

5) Софтуер – писан от други хора
Повечето open-source софтуер, който ползваме поддържа v6 и е въпрос на рекомпилация и реконфигурация, което с gentoo е една промяна в portage и малко скърцане. Работа за седмица-две с изчистване на проблемите.
Не ми е известен еквивалент на geoip базата за адреси за v6, ще трябва да се пише нещо наново, вероятно в ip.ludost.net.
За анализ на log-овете ползваме google analytics, не знам там как е v6 поддръжката.

6) Софтуер писан от нас
Трябва всичко да се port-не да има v6 поддръжка.
– Като цяло повечето неща са лесни, в книгата на Стивънс (Unix Network Programming vol.1) има добро описание и информация как се прави.
– Имаме ftp сървър, който трябва да видим как ще му добавим подобна поддръжка (има вероятно разширение на протокола).
– Имаме вътрешни binary протоколи, при които трябва да се вземе предвид, че може да предават и v6 адреси и ще трябва да се променят. Бая е гадно и ще иска много внимателен update и едновременен upgrade на трицифрено число машини.
– Имаме да направим промени в базата дани в няколко таблици, за да можем да сложим v6 адрес. Някои от тях са огромни и не е ясно дали ще можем да направим нормално alter без да убием услугата поне за половин час.
(някой да знае за база, която може да прави alter на таблица без да я lock-ва за писане и четене?:) )
Това е мъка, гърч и тестове поне няколко месеца.

7) Тестове
Трябва да си намерим свързаност някъде в България, за да можем да направим пълен тест на всичките неща. Както съм отбелязал по-долу, откриването на такъв доставчик е сложна задача.

8) Поддръжка
– kill switch – нужен ми е начин да мога да върна бързо и сравнително безболезнено услугата до ipv4-only състояние. Причината е най-вече в това, че ipv6 реализациите не са минали същото тестване и проверки/проблеми, през които са преминали ipv4 нещата, и съответно можем да очакваме нещата като teardrop да се преродят в ipv6 вариант и да има всякакви гадни проблеми поне още известно време.
– Вариант за определени места да не давам отговори с v6 адреси изобщо, понеже
а) нямам свързаност до тях
б) връзката дотам е бавна (например някой windows е решил да си направи teredo тунел, който работи със скоростта на dial-up)
в) някакъв проблем в неговия v6 стек или по пътя води до някакви допълнителни проблеми
– Вариант за определени хора да могат по някакъв начин да избират да не ползват v6 към мен.
– Инструментариум за диагностика на проблеми, причинени от v6 – looking glass и т.н..

Сумарно си мисля, че за 6 месеца може и да се реализира. Също така може и да пропускам нещо важно :)

Интересното в този случай е, че само т. 6 при мен няма да я има при доста от малките корпоративни мрежи и при някои от средните, останалото си остава да се свърши, като има и допълнителни гадости. Както се вижда, не е особено проста задача и всяка стъпка може да създаде проблеми.

И защо бих искал да го направя?
Няма някакви сериозни причини, освен, че би ми било забавно. Няма потребители само на v6. Няма потребители, на които v6 свързаността да им е по-бърза от v4 свързаността. Има много малко крайни потребители на v6, понеже почти няма хардуер, който (като за краен тъп потребителски домашен router) да се справя със задачката. Има малко доставчици, които карат v6 истински (в България НЯМА такива – тези, които имат някаква свързаност не я дават към съществена част от крайните си клиенти, а само към много големи такива, където v6 е изискване за някакъв търг).

Реално погледнато, _вероятно_ академичните среди биха били единствения ми сериозен клиент за такива неща. Не мога да оценя доколко би си струвало само заради тях да се направи подобно нещо и колко ще са щастливи от моя трафик.

Нека и пак да кажа – аз съм реално по-лесен случай от останалите. Аз нямам крайни потребители за чиято свързаност да отговарям, имам две операционни системи (Linux и IOS), имам както и да го погледнем не повече от 5-6 типа различни машини, занимавам се с услуга която няма проблеми с NAT и не предава адреси в себе си (не ми се мисли каква ще е ситуацията със SIP или H.323) и реално за всичко, което имам поддръжката е възможна, т.е. нямам устройства, които да няма начин да поддържат v6.

За момента не съществува причина някой да иска да направи подобно нещо.
(не, “небето пада/ip адресите свършват” не е такава причина, но това ще иска отделен post, за да се обясни)