На един разговор на ИББ седнах да обяснявам на един голям привърженик на 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, за да се обясни)